about summary refs log tree commit diff
path: root/compiler/rustc_parse/src/validate_attr.rs
AgeCommit message (Collapse)AuthorLines
2025-06-20Rollup merge of #138291 - jdonszelmann:optimize-attr, r=oli-obkTrevor Gross-0/+1
rewrite `optimize` attribute to use new attribute parsing infrastructure r? ```@oli-obk``` I'm afraid we'll get quite a few of these PRs in the future. If we get a lot of trivial changes I'll start merging multiple into one PR. They should be easy to review :) Waiting on #138165 first
2025-06-18convert the `optimize` attribute to a new parserJana Dönszelmann-0/+1
2025-06-18add `#[align]` attributeFolkert de Vries-0/+1
Right now it's used for functions with `fn_align`, in the future it will get more uses (statics, struct fields, etc.)
2025-06-17make error codes reflect reality betterJana Dönszelmann-1/+8
2025-06-17use consistent attr errors in all attribute parsersJana Dönszelmann-1/+1
2025-06-17fix bugs in inline/force_inline and diagnostics of all attr parsersJana Dönszelmann-3/+7
2025-06-09use correct edition when warning for unsafe attributesFolkert de Vries-1/+6
If an attribute is re-emitted by a macro, the incorrect edition was used to emit warnings for unsafe attributes
2025-05-04Make attribute safety validation logic more obviousJieyou Xu-14/+47
2025-05-03Report the `unsafe_attr_outside_unsafe` lint at the closest nodeUrgau-5/+11
2025-04-19Make `#[naked]` an unsafe attributeFolkert de Vries-6/+0
2025-04-14Allow (but don't require) `#[unsafe(naked)]` so that `compiler-builtins` can ↵Folkert de Vries-0/+6
upgrade to it
2025-04-13error on unsafe attributes in pre-2024 editionsFolkert de Vries-2/+8
the `no_mangle`, `link_section` and `export_name` attributes are exceptions, and can still be used without an unsafe in earlier editions
2025-03-26expand: Leave traces when expanding `cfg` attributesVadim Petrochenkov-6/+3
2025-03-17expand: Leave traces when expanding `cfg_attr` attributesVadim Petrochenkov-1/+1
2024-12-21Properly record metavar spans for other expansions other than TTMichael Goulet-6/+2
2024-12-15Add hir::AttributeJonathan Dönszelmann-4/+2
2024-12-15Rename `value` field to `expr` to simplify later commits' diffsOli Scherer-4/+2
2024-12-02Change `AttrArgs::Eq` into a struct variantOli Scherer-3/+5
2024-10-06Rename NestedMetaItem to MetaItemInnercodemountains-3/+3
2024-09-22Reformat using the new identifier sorting from rustfmtMichael Goulet-3/+3
2024-09-11Also fix if in elseMichael Goulet-7/+5
2024-08-07Stabilize `unsafe_attributes`carbotaniuman-27/+13
2024-07-30Add toggle for `parse_meta_item` unsafe parsingcarbotaniuman-41/+41
This makes it possible for the `unsafe(...)` syntax to only be valid at the top level, and the `NestedMetaItem`s will automatically reject `unsafe(...)`.
2024-07-29Deny unsafe on more builtin attributescarbotaniuman-56/+92
2024-07-29Reformat `use` declarations.Nicholas Nethercote-2/+2
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-06-24coverage: Tighten validation of `#[coverage(off)]` and `#[coverage(on)]`Zalathar-3/+10
2024-06-23Add hard error and migration lint for unsafe attrscarbotaniuman-6/+58
2024-06-18Prefer `dcx` methods over fields or fields' methodsOli Scherer-5/+5
2024-06-07Rollup merge of #126052 - nnethercote:rustc_parse-more-cleanups, r=spastorinoMatthias Krüger-21/+13
More `rustc_parse` cleanups Following on from #125815. r? `@spastorino`
2024-06-06Parse unsafe attributescarbotaniuman-0/+1
2024-06-06Inline and remove `check_builtin_attribute`.Nicholas Nethercote-19/+11
It's small and has a single call site. Also change the second `parse_meta` call to use a simple `match`, like the first `parse_meta` call, instead of a confusing `map_err`+`ok` combination.
2024-06-06Reduce `pub` exposure.Nicholas Nethercote-3/+3
2024-05-21Rename buffer_lint_with_diagnostic to buffer_lintXiretza-1/+1
2024-05-21Convert uses of BuiltinLintDiag::Normal to custom variantsXiretza-21/+11
This ensures all diagnostic messages are created at diagnostic emission time, making them translatable.
2024-03-05Rename all `ParseSess` variables/fields/lifetimes as `psess`.Nicholas Nethercote-23/+25
Existing names for values of this type are `sess`, `parse_sess`, `parse_session`, and `ps`. `sess` is particularly annoying because that's also used for `Session` values, which are often co-located, and it can be difficult to know which type a value named `sess` refers to. (That annoyance is the main motivation for this change.) `psess` is nice and short, which is good for a name used this much. The commit also renames some `parse_sess_created` values as `psess_created`.
2024-02-25Add `ErrorGuaranteed` to `ast::ExprKind::Err`Lieselotte-1/+1
2024-02-23compiler: clippy::complexity fixesMatthias Krüger-1/+1
2024-02-15Add `ErrorGuaranteed` to `ast::LitKind::Err`, `token::LitKind::Err`.Nicholas Nethercote-2/+2
This mostly works well, and eliminates a couple of delayed bugs. One annoying thing is that we should really also add an `ErrorGuaranteed` to `proc_macro::bridge::LitKind::Err`. But that's difficult because `proc_macro` doesn't have access to `ErrorGuaranteed`, so we have to fake it.
2024-01-10Rename consuming chaining methods on `DiagnosticBuilder`.Nicholas Nethercote-1/+1
In #119606 I added them and used a `_mv` suffix, but that wasn't great. A `with_` prefix has three different existing uses. - Constructors, e.g. `Vec::with_capacity`. - Wrappers that provide an environment to execute some code, e.g. `with_session_globals`. - Consuming chaining methods, e.g. `Span::with_{lo,hi,ctxt}`. The third case is exactly what we want, so this commit changes `DiagnosticBuilder::foo_mv` to `DiagnosticBuilder::with_foo`. Thanks to @compiler-errors for the suggestion.
2024-01-08Make `DiagnosticBuilder::emit` consuming.Nicholas Nethercote-3/+3
This works for most of its call sites. This is nice, because `emit` very much makes sense as a consuming operation -- indeed, `DiagnosticBuilderState` exists to ensure no diagnostic is emitted twice, but it uses runtime checks. For the small number of call sites where a consuming emit doesn't work, the commit adds `DiagnosticBuilder::emit_without_consuming`. (This will be removed in subsequent commits.) Likewise, `emit_unless` becomes consuming. And `delay_as_bug` becomes consuming, while `delay_as_bug_without_consuming` is added (which will also be removed in subsequent commits.) All this requires significant changes to `DiagnosticBuilder`'s chaining methods. Currently `DiagnosticBuilder` method chaining uses a non-consuming `&mut self -> &mut Self` style, which allows chaining to be used when the chain ends in `emit()`, like so: ``` struct_err(msg).span(span).emit(); ``` But it doesn't work when producing a `DiagnosticBuilder` value, requiring this: ``` let mut err = self.struct_err(msg); err.span(span); err ``` This style of chaining won't work with consuming `emit` though. For that, we need to use to a `self -> Self` style. That also would allow `DiagnosticBuilder` production to be chained, e.g.: ``` self.struct_err(msg).span(span) ``` However, removing the `&mut self -> &mut Self` style would require that individual modifications of a `DiagnosticBuilder` go from this: ``` err.span(span); ``` to this: ``` err = err.span(span); ``` There are *many* such places. I have a high tolerance for tedious refactorings, but even I gave up after a long time trying to convert them all. Instead, this commit has it both ways: the existing `&mut self -> Self` chaining methods are kept, and new `self -> Self` chaining methods are added, all of which have a `_mv` suffix (short for "move"). Changes to the existing `forward!` macro lets this happen with very little additional boilerplate code. I chose to add the suffix to the new chaining methods rather than the existing ones, because the number of changes required is much smaller that way. This doubled chainging is a bit clumsy, but I think it is worthwhile because it allows a *lot* of good things to subsequently happen. In this commit, there are many `mut` qualifiers removed in places where diagnostics are emitted without being modified. In subsequent commits: - chaining can be used more, making the code more concise; - more use of chaining also permits the removal of redundant diagnostic APIs like `struct_err_with_code`, which can be replaced easily with `struct_err` + `code_mv`; - `emit_without_diagnostic` can be removed, which simplifies a lot of machinery, removing the need for `DiagnosticBuilderState`.
2023-12-24Remove `ParseSess` methods that duplicate `DiagCtxt` methods.Nicholas Nethercote-2/+2
Also add missing `#[track_caller]` attributes to `DiagCtxt` methods as necessary to keep tests working.
2023-12-18Rename `ParseSess::span_diagnostic` as `ParseSess::dcx`.Nicholas Nethercote-3/+3
2023-12-15NFC don't convert types to identical typesMatthias Krüger-1/+1
2023-12-12Improve an error involving attribute values.Nicholas Nethercote-22/+38
Attribute values must be literals. The error you get when that doesn't hold is pretty bad, e.g.: ``` unexpected expression: 1 + 1 ``` You also get the same error if the attribute value is a literal, but an invalid literal, e.g.: ``` unexpected expression: "foo"suffix ``` This commit does two things. - Changes the error message to "attribute value must be a literal", which gives a better idea of what the problem is and how to fix it. It also no longer prints the invalid expression, because the carets below highlight it anyway. - Separates the "not a literal" case from the "invalid literal" case. Which means invalid literals now get the specific error at the literal level, rather than at the attribute level.
2023-11-21Fix `clippy::needless_borrow` in the compilerNilstrieb-1/+1
`x clippy compiler -Aclippy::all -Wclippy::needless_borrow --fix`. Then I had to remove a few unnecessary parens and muts that were exposed now.
2023-11-19Don't sort `span_suggestions`, leave that to callerEsteban Küber-0/+1
2023-08-03Remove `MacDelimiter`.Nicholas Nethercote-5/+6
It's the same as `Delimiter`, minus the `Invisible` variant. I'm generally in favour of using types to make impossible states unrepresentable, but this one feels very low-value, and the conversions between the two types are annoying and confusing. Look at the change in `src/tools/rustfmt/src/expr.rs` for an example: the old code converted from `MacDelimiter` to `Delimiter` and back again, for no good reason. This suggests the author was confused about the types.
2023-07-24Optimize format usageYuri Astrakhan-7/+7
Per #112156, using `&` in `format!` may cause a small perf delay, so I tried to clean up one module at a time format usage. This PR includes a few removals of the ref in format (they do compile locally without the ref), as well as a few format inlining for consistency.
2023-05-16Avoid `&format("...")` calls in error message code.Nicholas Nethercote-1/+1
Error message all end up passing into a function as an `impl Into<{D,Subd}iagnosticMessage>`. If an error message is creatd as `&format("...")` that means we allocate a string (in the `format!` call), then take a reference, and then clone (allocating again) the reference to produce the `{D,Subd}iagnosticMessage`, which is silly. This commit removes the leading `&` from a lot of these cases. This means the original `String` is moved into the `{D,Subd}iagnosticMessage`, avoiding the double allocations. This requires changing some function argument types from `&str` to `String` (when all arguments are `String`) or `impl Into<{D,Subd}iagnosticMessage>` (when some arguments are `String` and some are `&str`).
2023-05-03Restrict `From<S>` for `{D,Subd}iagnosticMessage`.Nicholas Nethercote-1/+1
Currently a `{D,Subd}iagnosticMessage` can be created from any type that impls `Into<String>`. That includes `&str`, `String`, and `Cow<'static, str>`, which are reasonable. It also includes `&String`, which is pretty weird, and results in many places making unnecessary allocations for patterns like this: ``` self.fatal(&format!(...)) ``` This creates a string with `format!`, takes a reference, passes the reference to `fatal`, which does an `into()`, which clones the reference, doing a second allocation. Two allocations for a single string, bleh. This commit changes the `From` impls so that you can only create a `{D,Subd}iagnosticMessage` from `&str`, `String`, or `Cow<'static, str>`. This requires changing all the places that currently create one from a `&String`. Most of these are of the `&format!(...)` form described above; each one removes an unnecessary static `&`, plus an allocation when executed. There are also a few places where the existing use of `&String` was more reasonable; these now just use `clone()` at the call site. As well as making the code nicer and more efficient, this is a step towards possibly using `Cow<'static, str>` in `{D,Subd}iagnosticMessage::{Str,Eager}`. That would require changing the `From<&'a str>` impls to `From<&'static str>`, which is doable, but I'm not yet sure if it's worthwhile.