Rustup#17447
Merged
Merged
Conversation
This better matches how the argument is actually used.
See `rustc_hir::intravisit::{walk_expr,walk_pat_expr}`.
Carry the `b_offset` inside `BackendRepr::ScalarPair` Inspired by rust-lang/compiler-team#1007 but doesn't actually change any of the layout rules just yet. This turned out to be a nice change even if we didn't use the extra flexibility, IMHO, because it allowed so many things like ```diff @@ -222,12 +224,12 @@ fn from_const_alloc<Bx: BuilderMethods<'a, 'tcx, Value = V>>( let val = read_scalar(offset, size, s, bx.immediate_backend_type(layout)); OperandRef { val: OperandValue::Immediate(val), layout, move_annotation: None } } - BackendRepr::ScalarPair( - a @ abi::Scalar::Initialized { .. }, - b @ abi::Scalar::Initialized { .. }, - ) => { + BackendRepr::ScalarPair { + a: a @ abi::Scalar::Initialized { .. }, + b: b @ abi::Scalar::Initialized { .. }, + b_offset, + } => { let (a_size, b_size) = (a.size(bx), b.size(bx)); - let b_offset = (offset + a_size).align_to(b.default_align(bx).abi); assert!(b_offset.bytes() > 0); let a_val = read_scalar( offset, ``` as *oh my* was that little magic incantation copy-pasted all over the place. Apologies for the pretty-giant PR. I tried to make it as direct a change as I could: if it was `(..)` before it's `{ .. }` now, if it was `(_, _)` before it's `{ a: _, b: _, b_offset: _ }` now. I kept the names the same so the code lines were unchanged even if normally I might have just renamed things, etc. I'll add some inline notes for places of particular interest. r? @workingjubilee
…olbinarycat rustdoc: do not include extra stuff in span This change prevents our lints from returning a span with stuff in it that isn't actually part of the doc comment. When that happens, it returns `None` instead. Fixes rust-lang#16169, since the bug was reported against the `clippy::doc_paragraphs_missing_punctuation` lint but is actually a bug in `source_span_for_markdown_range_inner`.
allow mGCA const arguments to fall back to anon consts makes good progress on rust-lang/project-const-generics#108 `min_generic_const_args` (mGCA) is all about "is this const lowered to a const item with a body, or, is it "directly" represented and visible in the type system?" Here's various answers to the question of "can we represent this const arg directly?" - if we answer "no", then we fall back to an anon const (or error, sometimes, depending on context) on **stable**, the full list of things can be directly represented is (... it's just the one thing) - paths to generic const parameters on `main`, under mGCA, **before** this PR: - absolutely everything, if something cannot be represented directly, compiler error - `const { }` gives you an escape hatch to go back to being an anon const on macro**ful** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro on macro**less** gca, the directly represented things will be: - paths to const parameters - `direct_const_arg!` macro (not *particularly* useful under macro**less** gca) - struct expressions, arrays, blah blah - currently, paths to *anything*, even if that produces a compiler error later down the line (potential followup work here...) this PR implements macro**less** gca, with the intent of a quick follow-up introducing a "macroless gca" feature and transitioning `#[feature(min_generic_const_args)]` to be macro**ful** gca Also of note is that this PR removes the logic to skip generating "fake" DefIds for directly represented AnonConsts under mGCA, we now always generate a DefId when encountering an AnonConst. This lines up with stable, which has a fake AnonConst DefId for a directly represented plain path generic parameter (i.e. the bullet point under the "stable" entry above). r? @BoxyUwU
view-types: HIR lowering
Specifically, from `Block`, `Pat`, `Path`, `Ty`, `Visibility`. This field is usually `None`. It only gets filled in for paths that might later be re-tokenized via `TokenStream::from_ast`, e.g. because of macro or cfg use. All such cases go through a single place: `parse_nonterminal`. This commit changes `parse_nonterminal` to store the non-`None` lazy attr token stream *next* to the node in `ParseNtResult` (using the new `WithTokens` type) instead of *inside* the parsed node. Along with some minor changes to the relevant `HasTokens` and `HasAttrs` impls, this is enough for things to work. These AST nodes all shrink by 8 bytes, as do various other nodes that contain nodes of these types. A guide to the changes: - `compiler/rustc_ast/src/tokenstream.rs` has the new `WithTokens` type. - `compiler/rustc_parse/src/parser/nonterminal.rs`, `compiler/rustc_expand/src/mbe/transcribe.rs` and `compiler/rustc_parse/src/parser/mod.rs` have minor changes due to the changes to `ParseNtResult`. - `compiler/rustc_ast/src/ast_traits.rs` has the `HasTokens`/`HasAttrs` changes. - Everything else is just mechanical changes for the removal of the `tokens` field.
Clippy subtree update r? Manishearth Cargo.lock update due to Clippy version bump and itertools version bump in Clippy.
Remove some AST `tokens` fields This commit removes/moves the `tokens` field from various AST node types, shrinking them. Details in individual commits.
merge DefKind::InlineConst into AnonConst This is a closely related followup to rust-lang/rust#158375 (a condition of merging that PR was doing this as a followup) This merge conflicts with rust-lang/rust#158617 ; prefer merging that one first please~ This PR is within the general goal of const generics / `generic_const_args` and perhaps specifically rust-lang/project-const-generics#108 but is mostly a code cleanup rather than implementing any particular feature --- Anon consts (the `1 + 2` in `let x: [u8; 1 + 2];`) are closely related to inline consts (the `const {}` in `let x = const { 1 + 2 };`). They are especially related now that both can be used in the type system (by the above PR) and should be treated identically in that scenario. In general, they should be treated the same, as evidenced by the number of matches touched in this PR that just match on both. This PR merges the two DefKinds into one, mostly arbitrarily and bikesheddily choosing to use the name `AnonConst` for the merged concept (e.g. both `DefKind::InlineConst` and `DefKind::AnonConst` used `ast::AnonConst`, so `ast::AnonConst` should probably be named whatever the merged `DefKind` concept is named). When you absolute must distinguish between the two, `tcx.anon_const_kind` allows you to do so - however, anon consts/inline consts in the type system intentionally appear identically under `anon_const_kind`. Indeed, the places where we distinguish between the two raised my eyebrows a few times when doing this PR, and being a little more explicit and loud about it is helpful for code clarity, IMO. r? @BoxyUwU
From 72 bytes to 64 bytes, by boxing `ForLoop`, which is the biggest variant. There are now 11 `ExprKind` variants that are 31 bytes, so future improvements here will be very difficult.
First steps of late-bound turbofishing (place FnDef behind a dummy binder) r? oli-obk This PR is part of rust-lang/rust#156581. This should be functionally identical to prior behavior, with the added fact that FnDef now places its arguments behind a binder. most changes boil down to - replacing `args` from `FnDef` with `args.no_bound_vars().unwrap()` - replacing `Ty::new_fn_def(/* ... */, args)` with `Ty::new_fn_def(/* ... */, ty::Binder::dummy(args))`
…crum Bump rustc-demangle to 0.1.28 This PR is part of the splat lang experiment: rust-lang/rust#153629 It brings in the changes from rust-lang/rustc-demangle#90, which encode splatted types with a `w` prefix in type mangling. This is required to fix the symbol clashes in rust-lang/rust#158644. We need to upgrade the compiler and standard library to avoid "can't demangle" panics or errors. Some tools might work without the upgrade, but we might as well do it there as well. @rustbot label +C-enhancement +F-splat +T-compiler +A-name-mangling
Shrink `ast::Expr64` From 72 bytes to 64 bytes, by boxing `ForLoop`, which is the biggest variant. There are now 11 `ExprKind` variants that are 31 bytes, so future improvements here will be very difficult.
Rename ModDefId to ModId and use more Addresses some FIXMEs. The `ModDefId` was used pretty sparingly, and honestly I wondered if it should exist at all. After making these changes, I think the type is worth it. Most notably it is now used in `Visibility::Restricted`. I first renamed `ModDefId` to `ModId` since I think the former is over-specific, and also this is more in line with `BodyId` or `OwnerId`. I'll wait for initial feedback before fixing rustdoc/clippy.
Fix `overflowing_literals` lint with repeated negation Fixes rust-lang/rust#158295 This PR consists of: two commits with non-functional cleanups, a commit that adds a test, and a commit that actually changes the behavior. The following description concerns the changed behavior. See the test changed in the fourth commit for code demonstrating the change in behavior. --- The `overflowing_literal` lint is, I believe, supposed to consider the literal and not the surrounding context when deciding whether to lint. This is in contrast to the `arithmetic_overflow` lint, which only considers code that executes at run time, which excludes the negation inside a literal. According to [the reference](https://doc.rust-lang.org/1.96.0/reference/expressions/operator-expr.html#r-expr.operator.int-overflow.unary-neg), a negation in front of an integer does not result in an overflow. I think of this as: a negation, and only one negation, in front of an integer, is "part of" the integer. Therefore, the `overflowing_literal` lint should consider that when linting. It should not consider the second or third negation. Therefore, this PR changes `overflowing_literals` so that it only lints on `128_i8` when there is no preceding negation at all. This is in contrast to the previous behavior, which lints on `128_i8` preceded by an even number of negations.
Once `sym::ignore` has been matched, the attribute can't be a `DocComment` and trying to match one is pointless.
`AttrItem` currently contains an `AttrItemKind` which is either `Parsed` or `Unparsed`. In the `Parsed` case the surrounding `AttrItem` is basically fake, with a meaningless `unsafety` field, a synthetic (non-ident) symbol, and an empty `tokens`. This commit moves `Parsed` up one level to become a new variant of `AttrKind`. It no longer needs to pretend to be an `AttrKind::Normal`, and makes a number of things simpler: - No `unparsed_ref` calls needed. - Replaces the `attr_into_trace` and `Attribute::replace_args` mess with the much simpler `convert_normal_to_parsed`. The commit converts a numberof non-exhaustive `AttrKind` matches (those that don't involve matching a single attribute) to exhaustive, for future-proofing. It uses `unreachable!` on all the `AttrKind::Parsed` cases that aren't hit by the full test suite.
This commit pushes further than the previous one, relying more heavily on looking directly at `AttrKind::Parsed` to handle various cases. Note that the removed clippy code was actually dead.
AST attributes use "early parsed"/"parsed" terminology to refer to the
`CfgTrace` and `CfgAttrTrace` attributes. I think this terminology is
meant to echo the terminology used for HIR attributes, i.e.
`hir::Attribute::{Parsed,Unparsed}`, probably because
`hir::Attribute::Parsed` is used for attributes that aren't stored in a
token-based form.
But this naming is misleading. "Early parsed" attributes aren't parsed
at all because they are inserted by the compiler and cannot be written
in source code. There are also two comments that claim that these
attributes are kept in parsed form "so they don't have to be reparsed
every time they're used, for performance", which is simply incorrect.
This commit renames these as "synthetic" attributes, which better
reflects their nature. The commit also fixes the incorrect comments.
Note that `is_parsed_attribute` is unchanged, because it refers to the
HIR attribute meaning. (And the removal of the synthetic attributes from
it in the previous commit is now more obviously correct.)
Collaborator
|
Some changes occurred in clippy_lints/src/doc cc @notriddle |
rustbot
added
the
S-waiting-on-review
flip1995
enabled auto-merge
July 23, 2026 18:42
|
Lintcheck changes for 4a940e5
This comment will be updated if you push new changes |
rustbot
removed
the
S-waiting-on-review
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
14 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
r? @ghost
changelog: none