| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
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
|
|
|
|
|
|
|
|
Feature gate `rustc` attributes harder
Fixes https://github.com/rust-lang/rust/issues/62116
|
|
syntax: Unsupport `foo! bar { ... }` macros in the parser
Their support in expansion was removed in https://github.com/rust-lang/rust/pull/61606.
Also un-reserve `macro_rules` as a macro name, there's no ambiguity between `macro_rules` definitions and macro calls (it also wasn't reserved correctly).
cc https://github.com/rust-lang-nursery/wg-grammar/issues/51
|
|
|
|
Unreserve `macro_rules` as a macro name
|
|
|
|
|
|
The errors are either:
- The meta-variable used in the right-hand side is not bound (or defined) in the
left-hand side.
- The meta-variable used in the right-hand side does not repeat with the same
kleene operator as its binder in the left-hand side. Either it does not repeat
enough, or it uses a different operator somewhere.
This change should have no semantic impact.
|
|
Support `cfg` and `cfg_attr` on generic parameters
`cfg` attributes are supported in all other positions where attributes are accepted at all.
They were previously prohibited in https://github.com/rust-lang/rust/pull/51283 because they weren't implemented correctly before that and were simply ignored.
|
|
|
|
syntax: Factor out common fields from `SyntaxExtension` variants
And some other related cleanups.
Continuation of https://github.com/rust-lang/rust/pull/61606.
This will also help to unblock https://github.com/rust-lang/rust/pull/61877.
|
|
|
|
|
|
|
|
Allow attributes in formal function parameters
Implements https://github.com/rust-lang/rust/issues/60406.
This is my first contribution to the compiler and since this is a large and complex project, I am not fully aware of the consequences of the changes I have made.
**TODO**
- [x] Forbid some built-in attributes.
- [x] Expand cfg/cfg_attr
|
|
|
|
It's a less powerful duplicate of `SyntaxExtension::NormalTT`
|
|
|
|
|
|
|
|
|
|
|
