| Age | Commit message (Collapse) | Author | Lines |
|---|
|
resolved
Also mark derive helpers as known as a part of the derive container's expansion instead of expansion of the derives themselves which may happen too late.
|
|
Modifies how Arg, Arm, Field, FieldPattern and Variant are visited
Part of the necessary work to accomplish #63468.
|
|
Part of the necessary work to accomplish #63468.
|
|
|
|
Replace them with equivalents of `Span::{def_site,call_site}` from proc macro API.
The new API is much less error prone and doesn't rely on macros having default transparency.
|
|
|
|
Solve the problem of `ParentScope` entries for eager expansions not exising in the resolver map by creating them on demand.
|
|
|
|
Make sure that all file loading happens via SourceMap
That way, callers don't need to repeat "let's add this to sm manually
for tracking dependencies" trick.
It should make it easier to switch to using `FileLoader` for binary
files in the future as well
cc #62948
r? @petrochenkov
|
|
For naming consistency with everything else in this area
|
|
|
|
The expansion info is not optional and should always exist
|
|
`Ident` has had a full span rather than just a `SyntaxContext` for a long time now.
|
|
For consistency with `ExpnId::root`.
Also introduce a helper `Span::with_root_ctxt` for creating spans with `SyntaxContext::root()` context
|
|
|
|
|
|
That way, callers don't need to repeat "let's add this to sm manually
for tracking dependencies" trick.
It should make it easier to switch to using `FileLoader` for binary
files in the future as well
|
|
Each call to `fully_expand_fragment` is something unique, interesting, and requiring attention.
It represents a "root" of expansion and its use means that something unusual is happening, like eager expansion or expansion performed outside of the primary expansion pass.
So, it shouldn't be hide under a generic visitor call.
Also, from all the implemented visitor methods only two were actually used.
|
|
|
|
|
|
```
error: unexpected `(` after qualified path
--> $DIR/vec-macro-in-pattern.rs:3:14
|
LL | Some(vec![x]) => (),
| ^^^^^^^
| |
| unexpected `(` after qualified path
| in this macro invocation
| use a slice pattern here instead
|
= help: for more information, see https://doc.rust-lang.org/edition-guide/rust-2018/slice-patterns.html
= note: this warning originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info)
```
|
|
|
|
Move special treatment of `derive(Copy, PartialEq, Eq)` from expansion infrastructure to elsewhere
As described in https://github.com/rust-lang/rust/pull/62086#issuecomment-515195477.
Reminder:
- `derive(PartialEq, Eq)` makes the type it applied to a "structural match" type, so constants of this type can be used in patterns (and const generics in the future).
- `derive(Copy)` notifies other derives that the type it applied to implements `Copy`, so `derive(Clone)` can generate optimized code and other derives can generate code working with `packed` types and types with `rustc_layout_scalar_valid_range` attributes.
First, the special behavior is now enabled after properly resolving the derives, rather than after textually comparing them with `"Copy"`, `"PartialEq"` and `"Eq"` in `fn add_derived_markers`.
The markers are no longer kept as attributes in AST since derives cannot modify items and previously did it through hacks in the expansion infra.
Instead, the markers are now kept in a "global context" available from all the necessary places, namely - resolver.
For `derive(PartialEq, Eq)` the markers are created by the derive macros themselves and then consumed during HIR lowering to add the `#[structural_match]` attribute in HIR.
This is still a hack, but now it's a hack local to two specific macros rather than affecting the whole expansion infra.
Ideally we should find the way to put `#[structural_match]` on the impls rather than on the original item, and then consume it in `rustc_mir`, then no hacks in expansion and lowering will be required.
(I'll make an issue about this for someone else to solve, after this PR lands.)
The marker for `derive(Copy)` cannot be emitted by the `Copy` macro itself because we need to know it *before* the `Copy` macro is expanded for expanding other macros.
So we have to do it in resolve and block expansion of any derives in a `derive(...)` container until we know for sure whether this container has `Copy` in it or not.
Nasty stuff.
r? @eddyb or @matthewjasper
|
|
Point at type ascription before macro invocation on expansion parse error
Fix https://github.com/rust-lang/rust/issues/47666. Follow up to https://github.com/rust-lang/rust/pull/62791.
r? @petrochenkov
|
|
infrastructure to elsewhere
|
|
|
|
There is no difference in the code/arguments, so go with the shorter
name throughout the code.
|
|
|
|
|
|
rustdoc: make #[doc(include)] relative to the containing file
This matches the behavior of other in-source paths like `#[path]` and the `include_X!` macros.
Fixes https://github.com/rust-lang/rust/pull/58373#issuecomment-462349380
Also addresses https://github.com/rust-lang/rust/issues/44732#issuecomment-467660239
cc #44732
This is still missing a stdsimd change (https://github.com/jonas-schievink/stdsimd/commit/42ed30e0b5fb5e2d11765b5d1e1f36234af85984), so CI will currently fail. I'll land that change once I get initial feedback for this PR.
|
|
https://github.com/rust-lang/rust/issues/60532
|
|
|
|
This makes them relative to the containing file instead of the crate
root
|
|
|
|
|
|
|
|
`InvocationKind::Attr { attr: None, .. }` meaning something entirely different from a regular attribute was confusing as hell.
|
|
It's more convenient to have all this highly related stuff together on one screen (for future refactorings).
The `expand_invoc` function is compact enough now, after all the previous refactorings.
|
|
Remove a bunch of `Option`s that assumed that dummy fragment creation could fail.
The test output changed due to not performing the expansion in `fn expand_invoc` in case of the recursion limit hit.
|
|
The root expansion was missing one.
Expansions created for "derive containers" (see one of the next commits for the description) also didn't get expansion info.
|
|
Creating a fresh expansion and immediately generating a span from it is the most common scenario.
Also avoid allocating `allow_internal_unstable` lists for derive markers repeatedly.
And rename `ExpnInfo::with_unstable` to `ExpnInfo::allow_unstable`, seems to be a better fitting name.
|
|
This way we are processing all of them in a single point, rather than separately for each syntax extension kind.
Also, the standard expected/found wording is used.
|
|
It either returns the indeterminacy error, or valid (but perhaps dummy) `SyntaxExtension`.
With this change enum `Determinacy` is no longer used in libsyntax and can be moved to resolve.
The regressions in diagnosics are fixed in the next commits.
|
|
ExpnInfo/MacroBacktrace/DiagnosticSpanMacroExpansion
We have to deal with dummy spans anyway
Remove def-site span from expander interfaces.
It's not used by the expansion infra, only by specific expanders, which can keep it themselves if they want it.
|
|
It was used to choose whether to apply derive markers like `#[rustc_copy_clone_marker]` or not,
but it was called before all the data required for resolution is available, so it could work incorrectly in some corner cases (like user-defined derives name `Copy` or `Eq`).
Delay the decision about markers until the proper resolution results are available instead.
|
|
More consistent with other naming:
ExpnFormat -> ExpnKind
ExpnKind::name -> ExpnKind::descr
DesugaringKind::name -> DesugaringKind::descr
Shorter, no tautology:
CompilerDesugaring -> Desugaring
CompilerDesugaringKind -> DesugaringKind
|
|
Stop visiting AST to discover those contexts, just iterate through hygiene data instead
|
|
|
|
|
|
|
