summary refs log tree commit diff
path: root/src/librustc_resolve
AgeCommit message (Collapse)AuthorLines
2016-11-08Auto merge of #36843 - petrochenkov:dotstab, r=nikomatsakisbors-1/+1
Stabilize `..` in tuple (struct) patterns I'd like to nominate `..` in tuple and tuple struct patterns for stabilization. This feature is a relatively small extension to existing stable functionality and doesn't have known blockers. The feature first appeared in Rust 1.10 6 months ago. An example of use: https://github.com/rust-lang/rust/pull/36203 Closes https://github.com/rust-lang/rust/issues/33627 r? @nikomatsakis
2016-11-06Auto merge of #37506 - jseyfried:improve_shadowing_checks, r=nrcbors-16/+29
macros: improve shadowing checks This PR improves macro-expanded shadowing checks to work with out-of-(pre)order expansion. Out-of-order expansion became possible in #37084, so this technically a [breaking-change] for nightly. The regression test from this PR is an example of code that would break. r? @nrc
2016-11-03Stabilize `..` in tuple (struct) patternsVadim Petrochenkov-1/+1
2016-11-02Rollup merge of #37498 - sanxiyn:unused-type-alias, r=eddybJonathan Turner-3/+0
Remove unused type aliases Found by extending the dead code lint. The lint itself is work in progress because of false positives. cc #37455.
2016-11-02Fix shadowing checking.Jeffrey Seyfried-8/+21
2016-10-31Remove unused type aliasesSeo Sanghyeon-3/+0
2016-10-31Rollup merge of #37475 - AndiDog:feature/error-explanation-E0532, ↵Guillaume Gomez-1/+41
r=GuillaumeGomez Add E0532 error explanation This resolves one of the error list in https://github.com/rust-lang/rust/issues/35347 - just because I stumbled over it today. I assumed the error code should be removed from `register_diagnostics!` because it's now defined above. Since that is my first code contribution, please check that all is in order. It would be helpful to know how to run the test for the `compile_fail,E0532` part. I did `make check-stage1-cfail NO_REBUILD=1` but that doesn't test the inlined example. r? @GuillaumeGomez
2016-10-31Cleanup `Resolver::disallowed_shadowing`.Jeffrey Seyfried-11/+11
2016-10-31Add E0532 error explanationAndreas Sommer-1/+41
2016-10-28Rollup merge of #37430 - robinst:missing-crate-message-add-semicolon, r=eddybGuillaume Gomez-1/+1
Add semicolon to "Maybe a missing `extern crate foo`" message I had it a couple of times that I was missing the "extern crate" line after I introduced a new dependency. So I copied the text from the message and inserted it into the beginning of my code, only to find the compiler complaining that I was missing the semicolon. (I forgot to add it after the text that I had pasted.) There's a similar message which does include the semicolon, namely "help: you can import it into scope: `use foo::Bar;`". I think the two messages should be consistent, so this change adds it for "extern crate".
2016-10-27Preparations and cleanupVadim Petrochenkov-60/+15
Diagnostics for struct path resolution errors in resolve and typeck are unified. Self type is treated as a type alias in few places (not reachable yet). Unsafe cell is seen in constants even through type aliases. All checks for struct paths in typeck work on type level.
2016-10-27Add semicolon to "Maybe a missing `extern crate foo`" messageRobin Stocker-1/+1
I had it a couple of times that I was missing the "extern crate" line after I introduced a new dependency. So I copied the text from the message and inserted it into the beginning of my code, only to find the compiler complaining that I was missing the semicolon. (I forgot to add it after the text that I had pasted.) There's a similar message which does include the semicolon, namely "help: you can import it into scope: `use foo::Bar;`". I think the two messages should be consistent, so this change adds it for "extern crate".
2016-10-26Rollup merge of #37394 - cramertj:cramertj/unused-import-with-id, ↵Guillaume Gomez-4/+6
r=GuillaumeGomez Add identifier to unused import warnings Fix #37376. For some reason, though, I'm getting warnings with messages like "76:9: 76:16: unused import: `self::g`" instead of "unused import: `self::g`". @pnkfelix Any ideas what might be causing this?
2016-10-25Avoid false positive `unused_extern_crates`.Jeffrey Seyfried-0/+1
2016-10-25Support `use $crate;` with a future compatibility warning.Jeffrey Seyfried-10/+25
2016-10-25Fix `$crate`-related regressions.Jeffrey Seyfried-3/+7
2016-10-25Add identifier to unused import warningsTaylor Cramer-4/+6
2016-10-25Auto merge of #37360 - jseyfried:fix_label_scope, r=nrcbors-19/+13
resolve: fix label scopes Fixes #37353 (turns an ICE back into an error). r? @nrc
2016-10-24Refactor away `CrateLoader::load_macros`.Jeffrey Seyfried-4/+5
2016-10-24Refactor away fields `MacroDef::{use_locally, export}`.Jeffrey Seyfried-13/+13
2016-10-24Import macros in `resolve` instead of in `metadata::macro_import`.Jeffrey Seyfried-58/+336
2016-10-22Fix label scopes.Jeffrey Seyfried-19/+13
2016-10-21Auto merge of #37247 - jseyfried:future_proof_no_link, r=nrcbors-1/+1
macros: Future proof `#[no_link]` This PR future proofs `#[no_link]` for macro modularization (cc #35896). First, we resolve all `#[no_link] extern crate`s. `#[no_link]` crates without `#[macro_use]` or `#[macro_reexport]` are not resolved today, this is a [breaking-change]. For example, ```rust ``` Any breakage can be fixed by simply removing the `#[no_link] extern crate`. Second, `#[no_link] extern crate`s will define an empty module in type namespace to eventually allow importing the crate's macros with `use`. This is a [breaking-change], for example: ```rust mod syntax {} //< This becomes a duplicate error. ``` r? @nrc
2016-10-19Future proof `#[no_link]`.Jeffrey Seyfried-1/+1
2016-10-19Improve `$crate`.Jeffrey Seyfried-3/+31
2016-10-19Use `Ident`s instead of `Name`s in `ImportDirective`'s paths.Jeffrey Seyfried-44/+37
2016-10-19nit: Import `Ident` in `resolve`.Jeffrey Seyfried-14/+14
2016-10-19Rollup merge of #37198 - jseyfried:future_proof_macros_11, r=nrcEduard-Mihai Burtescu-50/+42
macros 1.1: future proofing and cleanup This PR - uses the macro namespace for custom derives (instead of a dedicated custom derive namespace), - relaxes the shadowing rules for `#[macro_use]`-imported custom derives to match the shadowing rules for ordinary `#[macro_use]`-imported macros, and - treats custom derive `extern crate`s like empty modules so that we can eventually allow, for example, `extern crate serde_derive; use serde_derive::Serialize;` backwards compatibly. r? @alexcrichton
2016-10-15Treat custom derive extern crates like empty modules.Jeffrey Seyfried-0/+6
2016-10-15Use the macro namespace for custom derives.Jeffrey Seyfried-33/+27
2016-10-15Refactor `syntax::ext::base::Resolver::resolve_invoc`.Jeffrey Seyfried-17/+9
2016-10-14Rollup merge of #36307 - faebser:E0408_new_error_format, r=GuillaumeGomezJonathan Turner-2/+4
Changed error message E0408 to new format Followed your text and was able to change the ouput to the new format. I did not encounter any broken test therefore this is a really small commit. Thanks for letting me hack on the compiler :) r? @jonathandturner
2016-10-13Changed error message E0408 to new formatFabian Frei-2/+4
r? @jonathandturner
2016-10-12Rollup merge of #37084 - jseyfried:cleanup_expanded_macro_use_scopes, r=nrcAlex Crichton-127/+212
macros: clean up scopes of expanded `#[macro_use]` imports This PR changes the scope of macro-expanded `#[macro_use]` imports to match that of unexpanded `#[macro_use]` imports. For example, this would be allowed: ```rust example!(); macro_rules! m { () => { #[macro_use(example)] extern crate example_crate; } } m!(); ``` This PR also enforces the full shadowing restrictions from RFC 1560 on `#[macro_use]` imports (currently, we only enforce the weakened restrictions from #36767). This is a [breaking-change], but I believe it is highly unlikely to cause breakage in practice. r? @nrc
2016-10-12Rollup merge of #37023 - jseyfried:fix_extern_crate_back_compat, r=nrcAlex Crichton-1/+2
Fix importing inaccessible `extern crate`s (with a warning) Fixes #36747, fixes #37020, and fixes #37021. r? @nrc
2016-10-11Auto merge of #36871 - petrochenkov:pdderr, r=nikomatsakisbors-5/+1
Turn compatibility lint `match_of_unit_variant_via_paren_dotdot` into a hard error The lint was introduced 10 months ago and made deny-by-default 7 months ago. In case someone is still using it, https://github.com/rust-lang/rust/pull/36868 contains a stable replacement. r? @nikomatsakis
2016-10-11Remove `LegacyBindingKind::MacroUse`.Jeffrey Seyfried-34/+15
2016-10-11Clean up the scopes of expanded `#[macro_use]` imports.Jeffrey Seyfried-23/+25
2016-10-11Add support for undetermined macro invocations.Jeffrey Seyfried-12/+7
2016-10-11Merge branch 'persistent_macro_scopes' into cleanup_expanded_macro_use_scopesJeffrey Seyfried-117/+224
2016-10-11Check for shadowing errors after all invocations have been expanded.Jeffrey Seyfried-17/+26
2016-10-10Avoid quadratic complexity.Jeffrey Seyfried-2/+18
2016-10-08Persistent macro scopes.Jeffrey Seyfried-99/+167
2016-10-07Rename `resolve::macros::{ExpansionData -> InvocationData}`.Jeffrey Seyfried-29/+29
2016-10-07Immutable `ExpansionData`.Jeffrey Seyfried-23/+37
2016-10-07Auto merge of #36945 - alexcrichton:proc-macro-rename, r=nrcbors-2/+2
rustc: Rename rustc_macro to proc_macro This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-07Support importing inaccessible `extern crate`s with a warning again.Jeffrey Seyfried-1/+2
2016-10-06rustc: Rename rustc_macro to proc_macroAlex Crichton-2/+2
This commit blanket renames the `rustc_macro` infrastructure to `proc_macro`, which reflects the general consensus of #35900. A follow up PR to Cargo will be required to purge the `rustc-macro` name as well.
2016-10-05Turn compatibility lint `match_of_unit_variant_via_paren_dotdot` into a hard ↵Vadim Petrochenkov-5/+1
error
2016-10-04Remove some unused methods from metadataVadim Petrochenkov-0/+1
Address comments + Fix rebase
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-07-14 07:17:28 +0000