| Age | Commit message (Collapse) | Author | Lines |
|---|
|
resolve: Block expansion of a derive container until all its derives are resolved
So, it turns out there's one more reason to block expansion of a `#[derive]` container until all the derives inside it are resolved, beside `Copy` (https://github.com/rust-lang/rust/pull/63248).
The set of derive helper attributes registered by derives in the container also has to be known before the derives themselves are expanded, otherwise it may be too late (see https://github.com/rust-lang/rust/pull/63468#issuecomment-524550872 and the `#[stable_hasher]`-related test failures in https://github.com/rust-lang/rust/pull/63468).
So, we stop our attempts to unblock the container earlier, as soon as the `Copy` status is known, and just block until all its derives are resolved.
After all the derives are resolved we immediately go and process their helper attributes in the item, without delaying it until expansion of the individual derives.
Unblocks https://github.com/rust-lang/rust/pull/63468
r? @matthewjasper (as a reviewer of https://github.com/rust-lang/rust/pull/63248)
cc @c410-f3r
|
|
Cleanup: Consistently use `Param` instead of `Arg` #62426
Fixes #62426
|
|
|
|
Which is no longer dummy and is available from metadata now.
|
|
|
|
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.
|
|
All transparancies are passed explicitly now.
Also remove `#[rustc_macro_transparency]` annotations from built-in macros, they are no longer used.
`#[rustc_macro_transparency]` only makes sense for declarative macros now.
|
|
|
|
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.
|
|
|
|
expression
Maybe it made sense when it was introduced, but now it's doing something incorrect.
|
|
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
|
|
Merge Variant and Variant_
Extracted from #63468.
|
|
Add NodeId for Arm, Field and FieldPat
Extracted from #63468
|
|
expand: Unimplement `MutVisitor` on `MacroExpander`
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 hide under a generic visitor call.
Also, from all the implemented visitor methods only two were actually used.
cc https://github.com/rust-lang/rust/pull/63468#discussion_r313504119
|
|
|
|
|
|
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)
```
|
|
Some more libsyntax::attr cleanup
Much smaller patch than the last one, mostly just finishing up by removing some Span arguments.
r? @petrochenkov
|
|
|
|
|
|
|
|
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
|
|
Rename `ItemKind::Ty` to `ItemKind::TyAlias`
The current name is not entirely clear without context and `TyAlias` is consistent with `ItemKind::TraitAlias`.
|
|
|
|
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
|
|
Cleanup syntax::attr
Mostly removing needless arguments to constructors
r? @petrochenkov
|
|
Fix typo in Delimited::open_tt
|
|
|
|
|
|
|
