| Age | Commit message (Collapse) | Author | Lines |
|---|
|
mbe: Implement `unsafe` attribute rules
This implements `unsafe attr` rules for declarative `macro_rules!` attributes, as specified in [RFC 3697](https://github.com/rust-lang/rfcs/pull/3697).
An invocation of an attribute that uses an `unsafe attr` rule requires the `unsafe(attr(...))` syntax.
An invocation of an attribute that uses an ordinary `attr` rule must *not* use the `unsafe(attr(...))` syntax.
`unsafe` is only supported on an `attr` rule, not any other kind of `macro_rules!` rule.
Tracking issue for `macro_rules!` attributes: https://github.com/rust-lang/rust/issues/143547
|
|
`LegacyAttr` here
`LegacyAttr` is only used for builtin attributes, and builtin attributes
have their safety checked by `check_attribute_safety`, so we don't need
to check `unsafety` here.
|
|
|
|
This simplifies subsequent initialization of enum variants.
|
|
mbe: macro_check: Fix function comments referencing non-existent parameters
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
|
|
mbe: Simplify check_redundant_vis_repetition
Eliminate a use of `map_or` in favor of a match.
Inline some variable definitions that don't add clarity, and that
prevent short-circuiting.
|
|
Reduce some uses of `LegacyBang`
- **Switch `dummy_bang` from `LegacyBang` to `Bang`**
- **mbe: Switch dummy extension used for errors from `LegacyBang` to `Bang`**
|
|
Eliminate a use of `map_or` in favor of a match.
Inline some variable definitions that don't add clarity, and that
prevent short-circuiting.
|
|
Several functions had comments referencing a non-existent `valid`
parameter. Remove those. The `guar` parameter that handles errors is
already documented.
In the process, remove another duplicate reference to an
already-documented parameter (`binders`).
|
|
mbe: Simplifications and refactoring
A few simplifications and refactors in advance of other work.
Macro metavariable expressions were using `Ident::as_str` and doing string
comparisons; I converted them to use symbols.
I factored out a function for transcribing a `ParseNtResult`, which will help
separate the evaluation and transcription of future macro metavariable
expressions.
|
|
|
|
|
|
Co-authored-by: Anne Stijns <anstijns@gmail.com>
|
|
Identify metavariable functions by using named symbols rather than
string comparisons.
|
|
|
|
Factor out the check for a variable that's still repeating.
|
|
|
|
|
|
|
|
|
|
support integer literals in `${concat()}`
Tracking issue: rust-lang/rust#124225
Adds support for using integer literals as arguments to `${concat()}` macro expressions.
Integer formatting such as `1_000` is preserved by this.
|
|
Strip frontmatter in fewer places
* Stop stripping frontmatter in `proc_macro::Literal::from_str` (RUST-146132)
* Stop stripping frontmatter in expr-ctxt (but not item-ctxt!) `include`s (RUST-145945)
* Stop stripping shebang (!) in `proc_macro::Literal::from_str`
* Not a breaking change because it did compare spans already to ensure there wasn't extra whitespace or comments (`Literal::from_str("#!\n0")` already yields `Err(_)` thankfully!)
* Stop stripping frontmatter+shebang inside some rustdoc code where it doesn't make any observable difference (see self review comments)
* (Stop stripping frontmatter+shebang inside internal test code)
Fixes https://github.com/rust-lang/rust/issues/145945.
Fixes https://github.com/rust-lang/rust/issues/146132.
r? fee1-dead
|
|
|
|
|
|
|
|
Derive `PartialEq` for `InvisibleOrigin`
For https://github.com/rust-lang/rust/pull/145354, we need `PartialEq` for `TokenStream` to "just work". However, due to the special comparison implementation that was used for `InvisibleOrigin`, this wasn't the case.
So I derived `PartialEq` for `InvisibleOrigin`, and used the previous special comparison logic only on the single place where it was actually required.
r? `````````@petrochenkov`````````
|
|
macro matching
|
|
Replace unimplemented()! with a more helpful compiler error.
|
|
|
|
Refactor lint buffering to avoid requiring a giant enum
Lint buffering currently relies on a giant enum `BuiltinLintDiag` containing all the lints that might potentially get buffered. In addition to being an unwieldy enum in a central crate, this also makes `rustc_lint_defs` a build bottleneck: it depends on various types from various crates (with a steady pressure to add more), and many crates depend on it.
Having all of these variants in a separate crate also prevents detecting when a variant becomes unused, which we can do with a dedicated type defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types directly.
Because the existing `BuiltinLintDiag` requires some additional types in order to decorate some variants, which are only available later in `rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn LintDiagnostic` case and the `BuiltinLintDiag` case.
---
With the infrastructure in place, use it to migrate three of the enum variants to use `LintDiagnostic` directly, as a proof of concept and to demonstrate that the net result is a reduction in code size and a removal of a boilerplate-heavy layer of indirection.
Also remove an unused `BuiltinLintDiag` variant.
|
|
print raw lifetime idents with r#
This replaces rust-lang/rust#143185 and fixes rust-lang/rust#143150
cc ``@fmease``
|
|
Rewrite the new attribute argument parser
Fixes https://github.com/rust-lang/rust/issues/143940
This rewrites the parser, should improve performance and maintainability.
This can be reviewed commit by commit
|
|
Lint buffering currently relies on a giant enum `BuiltinLintDiag`
containing all the lints that might potentially get buffered. In
addition to being an unwieldy enum in a central crate, this also makes
`rustc_lint_defs` a build bottleneck: it depends on various types from
various crates (with a steady pressure to add more), and many crates
depend on it.
Having all of these variants in a separate crate also prevents detecting
when a variant becomes unused, which we can do with a dedicated type
defined and used in the same crate.
Refactor this to use a dyn trait, to allow using `LintDiagnostic` types
directly.
This requires boxing, but all of this is already on the slow path
(emitting an error).
Because the existing `BuiltinLintDiag` requires some additional types in
order to decorate some variants, which are only available later in
`rustc_lint`, use an enum `DecorateDiagCompat` to handle both the `dyn
LintDiagnostic` case and the `BuiltinLintDiag` case.
|
|
|
|
|
|
|
|
rustc_expand: ensure stack in `InvocationCollector::visit_expr`
In Fedora, when we built rustc with PGO on ppc64le, we started failing
the test `issue-74564-if-expr-stack-overflow.rs`. This could also be
reproduced on other arches by setting a smaller `RUST_MIN_STACK`, so
it's probably just unlucky that ppc64le PGO created a large stack frame
somewhere in this recursion path. Adding an `ensure_sufficient_stack`
solves the stack overflow.
Historically, that test and its fix were added in rust-lang/rust#74708,
which was also an `ensure_sufficient_stack` in this area of code at the
time. However, the refactor in rust-lang/rust#92573 basically left that
to the general `MutVisitor`, and then rust-lang/rust#142240 removed even
that ensure call. It may be luck that our tier-1 tested targets did not
regress the original issue across those refactors.
|
|
Prevent impossible combinations in `ast::ModKind`.
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field. If the `inline` field is `Inline::Yes` then `had_parse_error` must be `Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No` variant. This makes it impossible to create the nonsensical combination of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
r? ```@Urgau```
|
|
`ModKind::Loaded` has an `inline` field and a `had_parse_error` field.
If the `inline` field is `Inline::Yes` then `had_parse_error` must be
`Ok(())`.
This commit moves the `had_parse_error` field into the `Inline::No`
variant. This makes it impossible to create the nonsensical combination
of `inline == Inline::Yes` and `had_parse_error = Err(_)`.
|
|
Extend `QueryStability` to handle `IntoIterator` implementations
This PR extends the `rustc::potential_query_instability` lint to check values passed as `IntoIterator` implementations.
Full disclosure: I want the lint to warn about this line (please see #138871 for why): https://github.com/rust-lang/rust/blob/aa8f0fd7163a2f23aa958faed30c9c2b77b934a5/src/librustdoc/json/mod.rs#L261
However, the lint warns about several other lines as well.
Final note: the functions `get_callee_generic_args_and_args` and `get_input_traits_and_projections` were copied directly from [Clippy's source code](https://github.com/rust-lang/rust/blob/4fd8c04da0674af2c51310c9982370bfadfa1b98/src/tools/clippy/clippy_lints/src/methods/unnecessary_to_owned.rs#L445-L496).
|
|
Fix adjacent code
Fix duplicate warning; merge test into `tests/ui-fulldeps/internal-lints`
Use `rustc_middle::ty::FnSig::inputs`
Address two review comments
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109006991
- https://github.com/rust-lang/rust/pull/139345#discussion_r2109058588
Use `Instance::try_resolve`
Import `rustc_middle::ty::Ty` as `Ty` rather than `MiddleTy`
Simplify predicate handling
Add more `#[allow(rustc::potential_query_instability)]` following rebase
Remove two `#[allow(rustc::potential_query_instability)]` following rebase
Address review comment
Update compiler/rustc_lint/src/internal.rs
Co-authored-by: lcnr <rust@lcnr.de>
|
|
In Fedora, when we built rustc with PGO on ppc64le, we started failing
the test `issue-74564-if-expr-stack-overflow.rs`. This could also be
reproduced on other arches by setting a smaller `RUST_MIN_STACK`, so
it's probably just unlucky that ppc64le PGO created a large stack frame
somewhere in this recursion path. Adding an `ensure_sufficient_stack`
solves the stack overflow.
Historically, that test and its fix were added in rust-lang/rust#74708,
which was also an `ensure_sufficient_stack` in this area of code at the
time. However, the refactor in rust-lang/rust#92573 basically left that
to the general `MutVisitor`, and then rust-lang/rust#142240 removed even
that ensure call. It may be luck that our tier-1 tested targets did not
regress the original issue across those refactors.
|
|
Add infrastructure to apply a derive macro to arguments, consuming and
returning a `TokenTree` only.
Handle `SyntaxExtensionKind::MacroRules` when expanding a derive, if the
macro's kinds support derive.
Add tests covering various cases of `macro_rules` derives.
Note that due to a pre-existing FIXME in `expand.rs`, derives are
re-queued and some errors get emitted twice. Duplicate diagnostic
suppression makes them not visible, but the FIXME should still get
fixed.
|
|
This handles various kinds of errors, but does not allow applying the
derive yet.
This adds the feature gate `macro_derive`.
|
|
Handle macros with multiple kinds, and improve errors
(I recommend reviewing this commit-by-commit.)
Switch to a bitflags `MacroKinds` to support macros with more than one kind
Review everything that uses `MacroKind`, and switch anything that could refer to more than one kind to use `MacroKinds`.
Add a new `SyntaxExtensionKind::MacroRules` for `macro_rules!` macros, using the concrete `MacroRulesMacroExpander` type, and have it track which kinds it can handle. Eliminate the separate optional `attr_ext`, now that a `SyntaxExtension` can handle multiple macro kinds.
This also avoids the need to downcast when calling methods on `MacroRulesMacroExpander`, such as `get_unused_rule`.
Integrate macro kind checking into name resolution's `sub_namespace_match`, so that we only find a macro if it's the right type, and eliminate the special-case hack for attributes.
This allows detecting and report macro kind mismatches early, and more precisely, improving various error messages. In particular, this eliminates the case in `failed_to_match_macro` to check for a function-like invocation of a macro with no function-like rules.
Instead, macro kind mismatches now result in an unresolved macro, and we detect this case in `unresolved_macro_suggestions`, which now carefully distinguishes between a kind mismatch and other errors.
This also handles cases of forward-referenced attributes and cyclic attributes.
----
In this PR, I've minimally fixed up `rustdoc` so that it compiles and passes tests. This is just the minimal necessary fixes to handle the switch to `MacroKinds`, and it only works for macros that don't actually have multiple kinds. This will panic (with a `todo!`) if it encounters a macro with multiple kinds.
rustdoc needs further fixes to handle macros with multiple kinds, and to handle attributes and derive macros that aren't proc macros. I'd appreciate some help from a rustdoc expert on that.
----
r? ````````@petrochenkov````````
|
|
Remove unused `#[must_use]`
Self-explanatory
Fixes https://github.com/rust-lang/rust/issues/145257
|
|
|
|
The use of `Not` to describe the `!` in `macro_rules!` reads
confusingly, and also results in search collisions with the diagnostic
structure `MacroRulesNot` elsewhere in the compiler. Rename it to use
the more conventional `Bang` for `!`.
|
|
This eliminates the case in `failed_to_match_macro` to check for a
function-like invocation of a macro with no function-like rules.
Instead, macro kind mismatches now result in an unresolved macro, and we
detect this case in `unresolved_macro_suggestions`, which now carefully
distinguishes between a kind mismatch and other errors.
This also handles cases of forward-referenced attributes and cyclic
attributes.
Expand test coverage to include all of these cases.
|
|
I discovered this via research through the git log, and I want to leave
additional guidance for future macro spelunkers.
|
