about summary refs log tree commit diff
path: root/compiler/rustc_passes/src
AgeCommit message (Collapse)AuthorLines
2025-07-10Check assoc consts and tys later like assoc fnsMu001999-24/+46
2025-07-09Add opaque TypeId handles for CTFEOli Scherer-0/+1
2025-07-09Port `#[rustc_coherence_is_core]` to the new attribute systemPavel Grigorenko-1/+1
2025-07-09Port `#[rustc_allow_incoherent_impl]` to the new attribute systemPavel Grigorenko-5/+5
2025-07-09Port `#[rustc_paren_sugar]` to the new attribute systemPavel Grigorenko-2/+3
2025-07-09Port `#[fundamental]` to the new attribute systemPavel Grigorenko-1/+3
2025-07-09Port `#[marker]` to the new attribute systemPavel Grigorenko-7/+7
2025-07-09Port `#[rustc_unsafe_specialization_marker]` to the new attribute systemPavel Grigorenko-2/+8
2025-07-09Port `#[rustc_specialization_trait]` to the new attribute systemPavel Grigorenko-1/+2
2025-07-09Port `#[type_const]` to the new attribute systemPavel Grigorenko-5/+5
2025-07-09Port `#[rustc_coinductive]` to the new attribute systemPavel Grigorenko-3/+2
2025-07-09Port `#[rustc_do_not_implement_via_object]` to the new attribute systemPavel Grigorenko-2/+2
2025-07-09Port `#[rustc_deny_explicit_impl]` to the new attribute systemPavel Grigorenko-2/+2
2025-07-09Port `#[const_trait]` to the new attribute systemPavel Grigorenko-5/+5
2025-07-08Rollup merge of #143593 - mejrs:dummy, r=jdonszelmannMatthias Krüger-1/+2
Port #[rustc_dummy] r? ``@jdonszelmann``
2025-07-07Port #[rustc_dummy]mejrs-1/+2
2025-07-07Port `#[rustc_std_internal_symbol]` to the new attribute systemPavel Grigorenko-7/+5
2025-07-07Port `#[ffi_pure]` to the new attribute systemPavel Grigorenko-1/+3
2025-07-07Port `#[ffi_const]` to the new attribute systemPavel Grigorenko-2/+4
2025-07-07Port `#[export_stable]` to the new attribute systemPavel Grigorenko-4/+7
2025-07-07Rollup merge of #143544 - workingjubilee:rename-bare-fn, r=fmeaseJacob Pratt-5/+5
compiler: rename BareFn to FnPtr At some point "BareFn" was the chosen name for a "bare" function, without the niceties of `~fn`, `&fn`, or a few other ways of writing a function type. However, at some point the syntax for a "bare function" and any other function diverged even more. We started calling them what they are: function pointers, denoted by their own syntax. However, we never changed the *internal* name for these, as this divergence was very gradual. Personally, I have repeatedly searched for "FnPtr" and gotten confused until I find the name is BareFn, only to forget this until the next time, since I don't routinely interact with the higher-level AST and HIR. But even tools that interact with these internal types only touch on them in a few places, making a migration easy enough. Let's use a more intuitive and obvious name, as this 12+ year old name has little to do with current Rust.
2025-07-07Rollup merge of #143344 - JonathanBrouwer:path-parser, r=jdonszelmannJacob Pratt-1/+5
Port `#[path]` to the new attribute parsing infrastructure Ports `#[path]` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197 This PR duplicates a change from https://github.com/rust-lang/rust/pull/143237 Draft until that one is merged
2025-07-06compiler: rename {ast,hir}::BareFn* to FnPtr*Jubilee Young-5/+5
Fix some comments and related types and locals where it is obvious, e.g. - bare_fn -> fn_ptr - LifetimeBinderKind::BareFnType -> LifetimeBinderKind::FnPtrType Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
2025-07-06Support `#[align(…)]` on fns in `extern` blocksJules Bertholet-1/+1
2025-07-06Remove `repr(align)` codeJules Bertholet-4/+10
2025-07-06Port `#[path]` to the new attribute parsing infrastructureJonathan Brouwer-1/+5
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-06Rollup merge of #143252 - JonathanBrouwer:rewrite_empty_attribute, ↵Matthias Krüger-64/+32
r=jdonszelmann Rewrite empty attribute lint for new attribute parser cc `@jdonszelmann`
2025-07-06Rollup merge of #143477 - folkertdev:use-is-multiple-of, r=joshtriplettMatthias Krüger-1/+1
use `is_multiple_of` and `div_ceil` In tricky logic, these functions are much more informative than the manual implementations. They also catch subtle bugs: - the manual `is_multiple_of` often does not handle division by zero - manual `div_ceil` often does not consider overflow The transformation is free for `is_multiple_of` if the divisor is compile-time known to be non-zero. For `div_ceil` there is a small cost to considering overflow. Here is some assembly https://godbolt.org/z/5zP8KaE1d.
2025-07-06Rewrite empty attribute lintJonathan Brouwer-64/+32
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-05Port `#[ignore]` to the new attribute parsing infrastructureJonathan Brouwer-1/+4
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-05use `div_ceil` instead of manual logicFolkert de Vries-1/+1
2025-07-04Port `#[non_exhaustive]` to the new attribute parsing infrastructureJonathan Brouwer-8/+8
2025-07-04Rollup merge of #143400 - GrigorenkoPV:attributes/lints, r=jdonszelmannMatthias Krüger-3/+5
Port `#[rustc_pass_by_value]` to the new attribute system Part of rust-lang/rust#131229 r? `@oli-obk`
2025-07-04Port `#[rustc_pass_by_value]` to the new attribute systemPavel Grigorenko-3/+5
2025-07-03Port `#[no_implicit_prelude]` to the new attribute parsing infrastructureJonathan Brouwer-8/+35
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-03Rollup merge of #142876 - JonathanBrouwer:target_feature_parser, r=oli-obkJana Dönszelmann-29/+29
Port `#[target_feature]` to new attribute parsing infrastructure Ports `target_feature` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197 r? ``@jdonszelmann``
2025-07-03setup CI and tidy to use typos for spellchecking and fix few typosklensy-2/+2
2025-07-03Port `#[target_feature]` to the new attribute parsing infrastructureJonathan Brouwer-29/+29
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-01Rollup merge of #143279 - GuillaumeGomez:rm-itemkind-descr, r=oli-obkGuillaume Gomez-1/+1
Remove `ItemKind::descr` method Follow-up of rust-lang/rust#143234. After this PR is merged, it will remain two `descr` methods: * `hir::GenericArg::descr` * `hir::AssocItemConstraintKind::descr` For both these enums, I don't think there is the right equivalent in `hir::DefKind` so unless I missed something, we can't remove these two methods because we can't convert these enums into `hir::DefKind`. r? `@oli-obk`
2025-07-01Port `#[rustc_object_lifetime_default]` to the new attribute parsing ↵Jonathan Brouwer-2/+3
infrastructure
2025-07-01Remove `ItemKind::descr` methodGuillaume Gomez-1/+1
2025-07-01Auto merge of #142921 - JonathanBrouwer:rustc_attributes_parser, r=oli-obkbors-27/+7
Port `#[rustc_layout_scalar_valid_range_start/end]` to the new attrib… Ports `rustc_layout_scalar_valid_range_start` and `rustc_layout_scalar_valid_range_end` to the new attribute parsing infrastructure for https://github.com/rust-lang/rust/issues/131229#issuecomment-2971353197 r? `@jdonszelmann`
2025-06-29Port #[link_section] to the new attribute parsing infrastructureAnne Stijns-4/+6
2025-06-28Port `#[link_name]` to the new attribute parsing infrastructureJonathan Brouwer-21/+21
Co-authored-by: Anne Stijns <anstijns@gmail.com> Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-27Port `#[rustc_layout_scalar_valid_range_start/end]` to the new attribute ↵Jonathan Brouwer-27/+7
parsing infrastructure Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-27Port `#[used]` to new attribute parsing infrastructureJonathan Brouwer-47/+10
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-26Move mixed export_name/no_mangle check to check_attr.rs and improve the errorJonathan Brouwer-0/+45
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-26Port `#[export_name]` to the new attribute parsing infrastructureJonathan Brouwer-4/+6
Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-06-25Rollup merge of #142724 - xizheyin:avoid_overwrite_args, r=oli-obkJana Dönszelmann-2/+4
Add runtime check to avoid overwrite arg in `Diag` ## Origin PR description At first, I set up a `debug_assert` check for the arg method to make sure that `args` in `Diag` aren't easily overwritten, and I added the `remove_arg()` method, so that if you do need to overwrite an arg, then you can explicitly call `remove_arg()` to remove it first, then call `arg()` to overwrite it. For the code before the rust-lang/rust#142015 change, it won't compile because it will report an error ``` arg `instance`already exists. ``` This PR also modifies all diagnostics that fail the check to pass the check. There are two cases of check failure: 1. ~~Between *the parent diagnostic and the subdiagnostic*, or *between the subdiagnostics* have the same field between them. In this case, I renamed the conflicting fields.~~ 2. ~~For subdiagnostics stored in `Vec`, the rendering may iteratively write the same arg over and over again. In this case, I changed the auto-generation with `derive(SubDiagnostic)` to manually implementing `SubDiagnostic` and manually rendered it with `eagerly_translate()`, similar to https://github.com/rust-lang/rust/issues/142031#issuecomment-2984812090, and after rendering it I manually deleted useless arg with the newly added `remove_arg` method.~~ ## Final Decision After trying and discussing, we made a final decision. For `#[derive(Subdiagnostic)]`, This PR made two changes: 1. After the subdiagnostic is rendered, remove all args of this subdiagnostic, which allows for usage like `Vec<Subdiag>`. 2. Store `diag.args` before setting arguments, so that you can restore the contents of the main diagnostic after deleting the arguments after subdiagnostic is rendered, to avoid deleting the main diagnostic's arg when they have the same name args.
2025-06-25Add runtime check to avoid overwrite arg easily in diag and store and ↵xizheyin-2/+4
restore snapshot when set subdiag arg Signed-off-by: xizheyin <xizheyin@smail.nju.edu.cn>