| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Declarations were already modernized, resulting in cases where a macro
couldn't resolve it's own identifier.
|
|
They were resolved with modern hygiene, making this just a strange way
to shadow lifetimes.
|
|
resolve: Improve candidate search for unresolved macro suggestions
Use same scope visiting machinery for both collecting suggestion candidates and actually resolving the names.
The PR is better read in per-commit fashion with whitespace changes ignored (the first commit in particular moves some code around).
This should be the last pre-requisite for https://github.com/rust-lang/rust/pull/62086.
r? @davidtwco
|
|
fakenine:normalize_use_of_backticks_compiler_messages_p7, r=alexreg
normalize use of backticks in compiler messages for librustc/lint
https://github.com/rust-lang/rust/issues/60532
|
|
|
|
|
|
https://github.com/rust-lang/rust/issues/60532
|
|
`normalize-stdout-test` removes the need for Make, and it can be updated
with `--bless` this way
|
|
Change some tests to `check-pass` that are only testing name resolution.
|
|
Add a test for the issue resolved by removing `resolve_macro_path`
Add a test making sure that extern prelude entries introduced from an opaque macro are not visible anywhere, even it that macro
Fix test output after rebase
|
|
Ok, it's hard to explain what happens, but identifier's hygienic contexts need to be "adjusted" to modules/scopes before they are resolved in them.
To be resolved in all kinds on preludes the identifier needs to be adjusted to the root expansion (aka "no expansion").
Previously this was done for the `macro m() { ::my_crate::foo }` case, but forgotten for all other cases.
|
|
|
|
|
|
|
|
|
|
tweak unresolved label suggestion
Only suggest label names in the same hygiene context, and use a
structured suggestion.
Question for reviewer: Is this the right way to check for label hygiene?
|
|
|
|
|
|
Only suggest label names in the same hygiene context, and use a
structured suggestion.
|
|
|
|
|
|
|
|
|
|
|
|
resolve: Filter away macro prelude in modules with `#[no_implicit_prelude]` on 2018 edition
This is a tiny thing.
For historical reasons macro prelude (macros from `#[macro_use] extern crate ...`, including `extern crate std`) is still available in modules with `#[no_implicit_prelude]`.
This PR provides proper isolation and removes those names from scope.
`#[no_implicit_prelude]` modules still have built-in types (`u8`), built-in attributes (`#[inline]`) and built-in macros (`env!("PATH")`) in scope. We can introduce some `#[no_implicit_prelude_at_all]` to remove those as well, but that's a separate issue.
The change is done only on 2018 edition for backward compatibility.
I'm pretty sure this can be done on 2015 as well because `#[no_implicit_prelude]` is rarely used, but I don't want to go through the crater/deprecation process right now, maybe later.
cc https://github.com/rust-lang/rust/issues/53977
r? @ghost
|
|
I also added `// skip-codegen` to each one, to address potential concerns
that this change would otherwise slow down our test suite spending time
generating code for files that are really just meant to be checks of
compiler diagnostics.
(However, I will say: My preference is to not use `// skip-codegen` if
one can avoid it. We can use all the testing of how we drive LLVM that
we can get...)
(Updated post rebase.)
|
|
on 2018 edition
|
|
|
|
Give a special message when the later use is from a call. Use the span
of the callee instead of the whole expression. For conflicting borrow
messages say that the later use is of the first borrow.
|
|
editions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
`$crate` is not resolved at def-site of a macro, but rather at "transitive def-site"
|
|
|
|
|
|
When encountering an unexisting method for a given trait where an
associated function has the same name, suggest using the appropriate
syntax, instead of using `help` text.
When only one candidate is found, do not call it "candidate #1", just
call it "the candidate".
|
|
|
|
|
|
This commit starts to lay some groundwork for the stabilization of custom
attribute invocations and general procedural macros. It applies a number of
changes discussed on [internals] as well as a [recent issue][issue], namely:
* The path used to specify a custom attribute must be of length one and cannot
be a global path. This'll help future-proof us against any ambiguities and
give us more time to settle the precise syntax. In the meantime though a bare
identifier can be used and imported to invoke a custom attribute macro. A new
feature gate, `proc_macro_path_invoc`, was added to gate multi-segment paths
and absolute paths.
* The set of items which can be annotated by a custom procedural attribute has
been restricted. Statements, expressions, and modules are disallowed behind
two new feature gates: `proc_macro_expr` and `proc_macro_mod`.
* The input to procedural macro attributes has been restricted and adjusted.
Today an invocation like `#[foo(bar)]` will receive `(bar)` as the input token
stream, but after this PR it will only receive `bar` (the delimiters were
removed). Invocations like `#[foo]` are still allowed and will be invoked in
the same way as `#[foo()]`. This is a **breaking change** for all nightly
users as the syntax coming in to procedural macros will be tweaked slightly.
* Procedural macros (`foo!()` style) can only be expanded to item-like items by
default. A separate feature gate, `proc_macro_non_items`, is required to
expand to items like expressions, statements, etc.
Closes #50038
[internals]: https://internals.rust-lang.org/t/help-stabilize-a-subset-of-macros-2-0/7252
[issue]: https://github.com/rust-lang/rust/issues/50038
|
|
current reality.
|
|
|
|
|
