| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
|
|
Warn on pointless #[derive] in more places
This fixes the regression in #49934 and ensures that unused `#[derive]` invocations on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. There is a separate warning hardcoded for `#[derive]` on macro invocations since linting (even the early-lint pass) occurs after expansion. This also adds regression tests for some nodes that were already warning properly.
closes #49934
|
|
This fixes the regression in #49934 and ensures that unused `#[derive]`s on statements, expressions and generic type parameters survive to trip the `unused_attributes` lint. For `#[derive]` on macro invocations it has a hardcoded warning since linting occurs after expansion. This also adds regression testing for some nodes that were already warning properly.
closes #49934
|
|
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
|
|
|
|
|
|
|
|
|
|
|
|
Retains the `stmt_expr_attributes` feature requirement for attributes on expressions.
closes #41475
cc #38356
|
|
|
|
check stability of macro invocations
I haven't implemented tests yet but this should be a pretty solid prototype. I think as-implemented it will also stability-check macro invocations in the same crate, dunno if we want that or not.
I don't know if we want this to go through `rustc::middle::stability` or not, considering the information there wouldn't be available at the time of macro expansion (even for external crates, right?).
r? @nrc
closes #34079
cc @petrochenkov @durka @jseyfried #38356
|
|
|
|
|
|
|
|
|
|
|
|
errors
|
|
1. Change the return type of `expand_invoc()` and its subroutines to
`Option<Expansion>` from `Expansion`.
2. Return `None` when expanding a derive invocation if the item cannot
have derive on it (in `expand_derive_invoc()`).
|
|
tweaks and fixes for doc(include)
This PR makes a handful of changes around `#[doc(include="file.md")]` (https://github.com/rust-lang/rust/issues/44732):
* Turns errors when loading files into full errors. This matches the original RFC text.
* Makes the `missing_docs` lint check for `#[doc(include="file.md")]` as well as regular `#[doc="text"]` attributes.
* Loads files included by `#[doc(include="file.md")]` into dep-info, mirroring the behavior of `include_str!()` and friends.
* Adds or modifies tests to check for all of these.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Partial implementation of https://github.com/rust-lang/rfcs/pull/1990
(needs error reporting work)
cc #44732
|
|
This changes macro expansion to format the path of a macro directly
instead of usng the pprust infrastructure. The pprust infrastructure
tries to perform line-breaking in a slow fashion, which is undesired
when formatting the path of a macro.
This should to speed up expansion by a fair amount (I saw 20% on a
profiler on `rustc_mir`, and 50% of the time marked as "expansion" in
the profiler/time-passes is actually spent loading dependencies).
|
|
|
|
|
|
Now items are not fully configured until right before expanding derives.
|
|
|
|
|
|
A slight eccentricity of this change is that now non-ADT-derive errors prevent
derive-macro-not-found errors from surfacing (see changes to the
gating-of-derive compile-fail tests).
Resolves #43927.
|
|
Fix "new trace_macros doesn't work if there's an error during expansion"
Fixes #43493
|
|
|
|
|
|
|
|
|
|
Like #43008 (f668999), but _much more aggressive_.
|
|
|
|
|
|
This commit adds a new field to the `Item` AST node in libsyntax to optionally
contain the original token stream that the item itself was parsed from. This is
currently `None` everywhere but is intended for use later with procedural
macros.
|
|
Stabilizes:
* `compile_error!` as a macro defined by rustc
Closes #40872
|
|
|
|
|
|
remove variant `Token::SubstNt` in favor of `quoted::TokenTree::MetaVar`.
|
|
Related to #40872
|