Rustc pull update#1679
Open
Kobzol wants to merge 1993 commits into
Open
Conversation
…szelmann Simplify how inline asm handles `MaybeUninit` This is just better, but this is also allows it to handle changes from rust-lang/rust#149614 (i.e. `ManuallyDrop` containing `MaybeDangle`).
Rollup of 13 pull requests Successful merges: - rust-lang/rust#148756 (Warn on codegen attributes on required trait methods) - rust-lang/rust#148790 (Add new Tier-3 target: riscv64im-unknown-none-elf) - rust-lang/rust#149271 (feat: dlopen Enzyme) - rust-lang/rust#149459 (std: sys: fs: uefi: Implement set_times and set_perm) - rust-lang/rust#149771 (bootstrap readme: make easy to read when editor wrapping is not enabled) - rust-lang/rust#149856 (Provide an extended framework for type visit, for use in rust-analyzer) - rust-lang/rust#149950 (Simplify how inline asm handles `MaybeUninit`) - rust-lang/rust#150014 (Metadata loader cleanups) - rust-lang/rust#150021 (document that mpmc channels deliver an item to (at most) one receiver) - rust-lang/rust#150029 (Update books) - rust-lang/rust#150031 (assert impossible branch is impossible) - rust-lang/rust#150034 (do not add `I-prioritize` when `F-*` labels are present) - rust-lang/rust#150036 (Use the embeddable filename for coverage artifacts) r? `@ghost` `@rustbot` modify labels: rollup
Subtree sync for rustc_codegen_cranelift Nothing too exciting since the last sync. r? ``@ghost`` ``@rustbot`` label +A-codegen +A-cranelift +T-compiler
…uwer Rollup of 12 pull requests Successful merges: - rust-lang/rust#145933 (Expand `str_as_str` to more types) - rust-lang/rust#148849 (Set -Cpanic=abort in windows-msvc stack protector tests) - rust-lang/rust#149925 (`cfg_select!`: parse unused branches) - rust-lang/rust#149952 (Suggest struct pattern when destructuring Range with .. syntax) - rust-lang/rust#150022 (Generate macro expansion for rust compiler crates docs) - rust-lang/rust#150024 (Support recursive delegation) - rust-lang/rust#150048 (std_detect: AArch64 Darwin: expose SME F16F16 and B16B16 features) - rust-lang/rust#150083 (tests/run-make-cargo/same-crate-name-and-macro-name: New regression test) - rust-lang/rust#150102 (Fixed ICE for EII with multiple defaults due to duplicate definition in nameres) - rust-lang/rust#150124 (unstable.rs: fix typos in comments (implementatble -> implementable)) - rust-lang/rust#150125 (Port `#[rustc_lint_opt_deny_field_access]` to attribute parser) - rust-lang/rust#150126 (Subtree sync for rustc_codegen_cranelift) Failed merges: - rust-lang/rust#150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers) r? `@ghost` `@rustbot` modify labels: rollup
All usages of `memory_index` start by calling `invert_bijective_mapping`, so storing the inverted mapping directly saves some work and simplifies the code.
…ubilee layout: Store inverse memory index in `FieldsShape::Arbitrary` All usages of `memory_index` start by calling `invert_bijective_mapping`, so storing the inverted mapping directly saves some work and simplifies the code.
Rollup of 6 pull requests Successful merges: - rust-lang/rust#149633 (Enable `outline-atomics` by default on AArch64 FreeBSD) - rust-lang/rust#149788 (Move shared offload globals and define per-kernel globals once) - rust-lang/rust#149989 (Improve filenames encoding and misc) - rust-lang/rust#150012 (rustc_target: Add `efiapi` ABI support for LoongArch) - rust-lang/rust#150116 (layout: Store inverse memory index in `FieldsShape::Arbitrary`) - rust-lang/rust#150159 (Split eii macro expansion code) r? `@ghost` `@rustbot` modify labels: rollup
…,saethlin Replace Rvalue::NullaryOp by a variant in mir::Operand. Based on rust-lang/rust#148151 This PR fully removes the MIR `Rvalue::NullaryOp`. After rust-lang/rust#148151, it was only useful for runtime checks like `ub_checks`, `contract_checks` and `overflow_checks`. These are "runtime" checks, boolean constants that may only be `true` in codegen. It depends on a rustc flag passed to codegen, so we need to represent those flags cross-crate. This PR replaces those runtime checks by special variants in MIR `ConstValue`. This allows code that expects constants to manipulate those as such, even if we may not always be able to evaluate them to actual scalars.
Subtree sync for rustc_codegen_cranelift The main highlight this time is a Cranelift update. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
MGCA: Support struct expressions without intermediary anon consts r? oli-obk tracking issue: rust-lang/rust#132980 Fixes rust-lang/rust#127972 Fixes rust-lang/rust#137888 Fixes rust-lang/rust#140275 due to delaying a bug instead of ICEing in HIR ty lowering. ### High level goal Under `feature(min_generic_const_args)` this PR adds another kind of const argument. A struct/variant construction const arg kind. We represent the values of the fields as themselves being const arguments which allows for uses of generic parameters subject to the existing restrictions present in `min_generic_const_args`: ```rust fn foo<const N: Option<u32>>() {} trait Trait { #[type_const] const ASSOC: usize; } fn bar<T: Trait, const N: u32>() { // the initializer of `_0` is a `N` which is a legal const argument // so this is ok. foo::<{ Some::<u32> { 0: N } }>(); // this is allowed as mgca supports uses of assoc consts in the // type system. ie `<T as Trait>::ASSOC` is a legal const argument foo::<{ Some::<u32> { 0: <T as Trait>::ASSOC } }>(); // this on the other hand is not allowed as `N + 1` is not a legal // const argument foo::<{ Some::<u32> { 0: N + 1 } }>(); } ``` This PR does not support uses of const ctors, e.g. `None`. And also does not support tuple constructors, e.g. `Some(N)`. I believe that it would not be difficult to add support for such functionality after this PR lands so have left it out deliberately. We currently require that all generic parameters on the type being constructed be explicitly specified. I haven't really looked into why that is but it doesn't seem desirable to me as it should be legal to write `Some { ... }` in a const argument inside of a body and have that desugar to `Some::<_> { ... }`. Regardless this can definitely be a follow-up PR and I assume this is some underlying consistency with the way that elided args are handled with type paths elsewhere. This PRs implementation of supporting struct expressions is somewhat incomplete. We don't handle `Foo { ..expr }` at all and aren't handling privacy/stability. The printing of `ConstArgKind::Struct` HIR nodes doesn't really exist either :') I've tried to keep the implementation here somewhat deliberately incomplete as I think a number of these issues are actually quite small and self contained after this PR lands and I'm hoping it could be a good set of issues to mentor newer contributors on 🤔 I just wanted the "bare minimum" required to actually demonstrate that the previous changes are "necessary". ### `ValTree` now recurse through `ty::Const` In order to actually represent struct/variant construction in `ty::Const` without going through an anon const we would need to introduce some new `ConstKind` variant. Let's say some hypothetical `ConstKind::ADT(Ty<'tcx>, List<Const<'tcx>>)`. This variant would represent things the same way that `ValTree` does with the first element representing the `VariantIdx` of the enum (if its an enum), and then followed by a list of field values in definition order. This *could* work but there are a few reasons why it's suboptimal. First it would mean we have a second kind of `Const` that can be normalized. Right now we only have `ConstKind::Unevaluated` which possibly needs normalization. Similarly with `TyKind` we *only* have `TyKind::Alias`. If we introduced `ConstKind::ADT` it would need to be normalized to a `ConstKind::Value` eventually. This feels to me like it has the potential to cause bugs in the long run where only `ConstKind::Unevaluated` is handled by some code paths. Secondly it would make type equality/inference be kind of... weird... It's desirable for `Some { 0: ?x } eq Some { 0: 1_u32 }` to result in `?x=1_u32`. I can't see a way for this to work with this `ConstKind::ADT` design under the current architecture for how we represent types/consts and generally do equality operations. We would need to wholly special case these two variants in type equality and have a custom recursive walker separate from the existing architecture for doing type equality. It would also be somewhat unique in that it's a non-rigid `ty::Const` (it can be normalized more later on in type inference) while also having somewhat "structural" equality behaviour. Lastly, it's worth noting that its not *actually* `ConstKind::ADT` that we want. It's desirable to extend this setup to also support tuples and arrays, or even references if we wind up supporting those in const generics. Therefore this isn't really `ConstKind::ADT` but a more general `ConstKind::ShallowValue` or something to that effect. It represents at least one "layer" of a types value :') Instead of doing this implementation choice we instead change `ValTree::Branch`: ```rust enum ValTree<'tcx> { Leaf(ScalarInt), // Before this PR: Branch(Box<[ValTree<'tcx>]>), // After this PR Branch(Box<[Const<'tcx>]>), } ``` The representation for so called "shallow values" is now the same as the representation for the *entire* full value. The desired inference/type equality behaviour just falls right out of this. We also don't wind up with these shallow values actually being non-rigid. And `ValTree` *already* supports references/tuples/arrays so we can handle those just fine. I think in the future it might be worth considering inlining `ValTree` into `ty::ConstKind`. E.g: ```rust enum ConstKind { Scalar(Ty<'tcx>, ScalarInt), ShallowValue(Ty<'tcx>, List<Const<'tcx>>), Unevaluated(UnevaluatedConst<'tcx>), ... } ``` This would imply that the usage of `ValTree`s in patterns would now be using `ty::Const` but they already kind of are anyway and I think that's probably okay in the long run. It also would mean that the set of things we *could* represent in const patterns is greater which may be desirable in the long run for supporting things such as const patterns of const generic parameters. Regardless, this PR doesn't actually inline `ValTree` into `ty::ConstKind`, it only changes `Branch` to recurse through `Const`. This change could be split out of this PR if desired. I'm not sure if there'll be a perf impact from this change. It's somewhat plausible as now all const pattern values that have nesting will be interning a lot more `Ty`s. We shall see :> ### Forbidding generic parameters under mgca Under mgca we now allow all const arguments to resolve paths to generic parameters. We then *later* actually validate that the const arg should be allowed to access generic parameters if it did wind up resolving to any. This winds up just being a lot simpler to implement than trying to make name resolution "keep track" of whether we're inside of a non-anon-const const arg and then encounter a `const { ... }` indicating we should now stop allowing resolving to generic parameters. It's also somewhat in line with what we'll need for a `feature(generic_const_args)` where we'll want to decide whether an anon const should have any generic parameters based off syntactically whether any generic parameters were used. Though that design is entirely hypothetical at this point :) ### Followup Work - Make HIR ty lowering check whether lowering generic parameters is supported and if not lower to an error type/const. Should make the code cleaner, fix some other bugs, and maybe(?) recover perf since we'll be accessing less queries which I think is part of the perf regression of this PR - Make the ValTree setup less scuffed. We should find a new name for `ConstKind::Value` and the `Val` part of `ValTree` and `ty::Value` as they no longer correspond to a fully normalized structure. It may also be worth looking into inlining `ValTreeKind` into `ConstKind` or atleast into `ty::Value` or sth 🤔 - Support tuple constructors and const constructors not just struct expressions. - Reduce code duplication between HIR ty lowering's handling of struct expressions, and HIR typeck's handling of struct expressions - Try fix perf rust-lang/rust#149114 (comment). Maybe this will clear up once we clean up `ValTree` a bit and stop doing double interning and whatnot
For some reason git-subtree incorrectly synced those changes.
Fix some divergences with the cg_clif subtree For some reason git-subtree incorrectly synced those changes. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
…uwer Rollup of 3 pull requests Successful merges: - rust-lang/rust#150141 (Misc cleanups from reading some borrowck code) - rust-lang/rust#150297 (Fix compile issue in Vita libstd) - rust-lang/rust#150341 (Fix some divergences with the cg_clif subtree) r? `@ghost` `@rustbot` modify labels: rollup
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: 48622726c4a91c87bf6cd4dbe1000c95df59906e Filtered ref: cd67a857259ae6c8e166020f097dd070d6c16fb3 Upstream diff: rust-lang/rust@8401398...4862272 This merge was created using https://github.com/rust-lang/josh-sync.
Rustc pull update
…acro_transparency`
Finish transition from `semitransparent` to `semiopaque` for `rustc_macro_transparency` Since it's a bit annoying to have different names for the same thing. My understanding is that this is just internal stuff that is not part of any public API even tough rust-analyzer knows about it. Continuation of - rust-lang/rust#139084. Discovered while investigating - rust-lang/rust#150514
Rollup of 11 pull requests Successful merges: - rust-lang/rust#150272 (docs(core): update `find()` and `rfind()` examples) - rust-lang/rust#150385 (fix `Expr::can_have_side_effects` for `[x; N]` style array literal and binary expressions) - rust-lang/rust#150561 (Finish transition from `semitransparent` to `semiopaque` for `rustc_macro_transparency`) - rust-lang/rust#150574 (Clarify `MoveData::init_loc_map`.) - rust-lang/rust#150762 (Use functions more in rustdoc GUI tests) - rust-lang/rust#150808 (rename the `derive_{eq, clone_copy}` features to `*_internals`) - rust-lang/rust#150816 (Fix trait method anchor disappearing before user can click on it) - rust-lang/rust#150821 (tests/ui/borrowck/issue-92157.rs: Remove (bug not fixed)) - rust-lang/rust#150829 (make attrs actually use `Target::GenericParam`) - rust-lang/rust#150834 (Add tracking issue for `feature(multiple_supertrait_upcastable)`) - rust-lang/rust#150864 (The aarch64-unknown-none target requires NEON, so the docs were wrong.) r? @ghost
Stabilize `alloc_layout_extra` Tracking issue: rust-lang/rust#55724 FCP completed in rust-lang/rust#55724 (comment) Closes rust-lang/rust#55724 ---- As per rust-lang/rust#55724 (comment), - `repeat_packed` and `extend_packed` are unchanged - `repeat` now excludes trailing padding on the last element from the total array size - `dangling` renamed to `dangling_ptr` - `padding_needed_for` not stabilized, changed to accept `Alignment` instead of `usize` and moved to the `ptr_aligment_type` feature flag (tracking issue: rust-lang/rust#102070)
Rollup of 8 pull requests Successful merges: - rust-lang/rust#148769 (Stabilize `alloc_layout_extra`) - rust-lang/rust#150200 (Add title field to `ice.md` issue template) - rust-lang/rust#150955 (Underscore-prefixed bindings are explicitly allowed to be unused) - rust-lang/rust#151200 (time: Add saturating arithmetic for `SystemTime`) - rust-lang/rust#151235 (Change field `bit_width: usize` to `bits: u32` in type info) - rust-lang/rust#151242 (Port #[needs_allocator] to attribute parser) - rust-lang/rust#151274 (Include a link to `count_ones` in the docs for `uN::count_zeros` [docs only]) - rust-lang/rust#151279 (remove trailing periods in built-in attribute gate messages) r? @ghost
…e_diagnostic` throughout the codebase This PR was mostly made by search&replacing
Remove the diagnostic lints Removes the `untranslatable_diagnostic` and `diagnostic_outside_of_impl` lints These lints are allowed for a while already. Per rust-lang/compiler-team#959, we no longer want to enforce struct diagnostics for all usecases, so this is no longer useful. r? @Kivooeo I recommend reviewing commit by commit (also feel free to wait with reviewing until the MCP is accepted) @rustbot +S-blocked Blocked by rust-lang/compiler-team#959
…uwer Rollup of 15 pull requests Successful merges: - rust-lang/rust#148623 (Ignore `#[doc(hidden)]` items when computing trimmed paths for printing) - rust-lang/rust#150550 (Miscellaneous cleanups to borrowck related code) - rust-lang/rust#150879 (Remove the diagnostic lints) - rust-lang/rust#150895 (rustc_errors: Add (heuristic) Syntax Highlighting for `rustc --explain`) - rust-lang/rust#150987 (remote-test-server: Fix header in batch mode) - rust-lang/rust#151004 (std: implement `sleep_until` on Apple platforms) - rust-lang/rust#151045 (Simplify some literal-value negations with `u128::wrapping_neg`) - rust-lang/rust#151119 (Support pointers in type reflection) - rust-lang/rust#151171 (Do not recover from `Trait()` if generic list is unterminated) - rust-lang/rust#151231 (HIR typeck cleanup: clarify and re-style `check_expr_unop`) - rust-lang/rust#151249 (Parse ident with allowing recovery when trying to diagnose) - rust-lang/rust#151295 (THIR patterns: Use `ty::Value` in more places throughout `const_to_pat`) - rust-lang/rust#151326 (Remove `DiagMessage::Translated` in favour of `DiagMessage::Str`) - rust-lang/rust#151361 (add test for issue 61463) - rust-lang/rust#151371 (Add `S-blocked` to `labels_blocking_approval`) r? @ghost
…rtdev stdarch subtree update Subtree update of `stdarch` to rust-lang/stdarch@62d5595. Created using https://github.com/rust-lang/josh-sync. r? @ghost
Rollup of 15 pull requests Successful merges: - rust-lang/rust#158497 (stdarch subtree update) - rust-lang/rust#152225 (Add supertrait item shadowing for type-level path resolution) - rust-lang/rust#158194 (Adds RmetaLinkCache a per-link cache that uses path as the key of dec…) - rust-lang/rust#158466 (rustdoc: show impl Trait<Box<Local>> for Foreign, etc on Local's docs) - rust-lang/rust#158501 (miri subtree update) - rust-lang/rust#153097 (Expand `OptionFlatten`'s iterator methods) - rust-lang/rust#157614 (Move tests drop) - rust-lang/rust#157996 (perf: drop the full-crate AST walk in check_unused) - rust-lang/rust#158163 (Fix too-short variance slice in `variances_of` cycle recovery) - rust-lang/rust#158233 (Allow the unstable attribute on foreign type) - rust-lang/rust#158433 (Fix inconsistent safety requirement in VecDeque::nonoverlapping_ranges) - rust-lang/rust#158464 (Reorganize `tests/ui/issues` [15/N]) - rust-lang/rust#158470 (Upgrade `jsonsocck` and `jsondoclint` to edition 2024.) - rust-lang/rust#158485 (Reorganize `tests/ui/issues` [16/N]) - rust-lang/rust#158488 (Upgrade `rustdoc-json-types` to 2024 edition.)
To emphasize that just because you see a `Scalar(I32)` that doesn't really tell you anything about the alignment it has -- one should be looking at the type (well, the place) for that. No actual layout or behaviour changes in *this* PR.
Rename `align` to `default_align` on `Scalar` and `Primitive` To emphasize that just because you see a `Scalar(I32)` that doesn't really tell you anything about the alignment it has -- one should be looking at the type (well, the place) for that. (The `size` method doesn't really have that problem -- i32 is always 4 bytes, no matter the context -- so is left untouched.) No actual layout or behaviour changes in *this* PR. Just the rename and some comments. r? @workingjubilee
Rollup of 6 pull requests Successful merges: - rust-lang/rust#157718 (Do not increase depth when evaluating nested goals of `NormalizesTo`) - rust-lang/rust#158449 (QNX target renaming) - rust-lang/rust#158483 (signed strict division: just use normal division) - rust-lang/rust#158516 ( Deduplicate codegen backends in bootstrap config) - rust-lang/rust#158542 (Rename `align` to `default_align` on `Scalar` and `Primitive`) - rust-lang/rust#158636 (linkchecker: upgrade to `html5ever v0.39`)
Introduce a dedicated panic for null reference production to distinguish producing a reference from a null pointer from an actual null pointer dereference. This emits a dedicated panic message for null reference production while preserving the existing panic for actual dereferences.
Distinguish null reference production from null pointer dereference in UB checks Closes rust-lang/rust#154044 This change distinguishes null reference production from actual null pointer dereferences in the UB checks. Producing a reference from a null pointer (for example, `&*ptr`) is undefined behavior even if no memory is dereferenced. This change introduces a dedicated `AssertKind::NullReferenceConstructed` and runtime panic so these cases produce a more accurate diagnostic while preserving the existing panic for actual null pointer dereferences. Summary - Add `AssertKind::NullReferenceConstructed`. - Emit it for null reference production in the MIR null check pass. - Add `panic_null_reference_constructed` and its lang item. - Keep `NullPointerDereference` for actual dereferences. - Update the affected UI tests.
Rollup of 13 pull requests Successful merges: - rust-lang/rust#158478 (Use correct typing mode in mir building for the next solver) - rust-lang/rust#158796 (Distinguish null reference production from null pointer dereference in UB checks) - rust-lang/rust#158821 (add regression test for late-bound type method probe ICE) - rust-lang/rust#158245 (Update the rustc_perf submodule) - rust-lang/rust#158346 (Prevent rustdoc auto-trait ICEs with `-Znext-solver=globally`) - rust-lang/rust#158536 (Instatiate binder instead of skipping when suggesting function arg error) - rust-lang/rust#158553 (Avoid infinite recursion when trying to build valtrees for self-referential consts) - rust-lang/rust#158679 (Document blocking guarantees for `std::sync`) - rust-lang/rust#158826 (Reorganize `tests/ui/issues` [19/N]) - rust-lang/rust#158860 (Delete `impl_def_id` field from `ImplHeader`) - rust-lang/rust#158867 (rewrite `Align::max_for_target` in a more obvious way) - rust-lang/rust#158878 (borrowck: Inline `free_region_constraint_info()` to simplify the code) - rust-lang/rust#158881 (Update mdbook to 0.5.4)
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
Rollup of 23 pull requests Successful merges: - rust-lang/rust#158968 (stdarch subtree update) - rust-lang/rust#154445 (rustdoc: Represent `--output-format=json` coverage and ir differently) - rust-lang/rust#158495 (Rename HAS_CT_PROJECTION to HAS_CONST_ALIAS) - rust-lang/rust#158666 (Carry the `b_offset` inside `BackendRepr::ScalarPair`) - rust-lang/rust#158870 (std: merge the unix-like io::error modules into one file) - rust-lang/rust#158920 (Update wasm-component-ld to 0.5.26) - rust-lang/rust#158926 (wrapping_sh* methods: clarify underspecified reference) - rust-lang/rust#158927 (add core test run with `-Zforce-intrinsic-fallback`) - rust-lang/rust#158932 (Do not build the compiler when invoking `x perf compare`) - rust-lang/rust#158937 (Emit the emscripten entry point as `__main_argc_argv`) - rust-lang/rust#151379 (Stabilize `VecDeque::retain_back` from `truncate_front`) - rust-lang/rust#156144 (Better docs for PartialEq (includes macro rename)) - rust-lang/rust#156548 ( Library support for aarch64-unknown-linux-pauthtest target) - rust-lang/rust#157995 (`Vec::dedup_by` docs explicit function argument order) - rust-lang/rust#158307 (CI job for parallel frontend ui tests) - rust-lang/rust#158741 (Simplify `Option::into_flat_iter` signature) - rust-lang/rust#158807 (Add regression test for CString::clone_into unwind safety) - rust-lang/rust#158862 (Fix the span for parameter suggestion ) - rust-lang/rust#158894 (Make the ordering of non-terminal binds in ambiguity error messages deterministic) - rust-lang/rust#158902 (add codegen test for range length bound propagation) - rust-lang/rust#158913 (Update `browser-ui-test` version to `0.24.1`) - rust-lang/rust#158935 (std: support real fd methods on Emscripten) - rust-lang/rust#158978 (Add regression test for too-big by-value ABI args)
This way codegen backends don't have to check for a magic symbol name prefix to detect LLVM intrinsic calls and thus can more easily handle them separately as necessary.
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))`
…uwer Rollup of 13 pull requests Successful merges: - rust-lang/rust#157706 (Deny `todo!()` in tidy) - rust-lang/rust#158535 (Support `#[track_caller]` on EII declarations) - rust-lang/rust#158632 (First steps of late-bound turbofishing (place FnDef behind a dummy binder)) - rust-lang/rust#158846 (Fix unused variable warnings for diverging expressions) - rust-lang/rust#159002 (Small refactorings in `need_type_info` module) - rust-lang/rust#159202 (Bump rustc-demangle to 0.1.28) - rust-lang/rust#159216 (Avoid using probe self_ty for delegation arguments) - rust-lang/rust#156609 (Consider structurally impossible Sized predicates in MIR) - rust-lang/rust#157993 (Expose more info about ADTs and functions in rustc_public) - rust-lang/rust#158804 (Clarify `as_uninit_mut` may point to uninitialized memory) - rust-lang/rust#158854 (Add `#[rustc_test_entrypoint_marker]`) - rust-lang/rust#158998 (Some minor ast validation and visiting cleanups) - rust-lang/rust#159123 (doc: clarify attr parser APIs)
…folkertdev Introduce InstanceKind::LlvmIntrinsic This way codegen backends don't have to check for a magic symbol name prefix to detect LLVM intrinsic calls and thus can more easily handle them separately as necessary.
…uwer Rollup of 22 pull requests Successful merges: - rust-lang/rust#156047 (Fix trait method resolution on an adjusted never type) - rust-lang/rust#157824 (Comptime inherent impls) - rust-lang/rust#158235 (Store `DefId` instead of `EiiDecl` in `EiiImplResolution::Known`) - rust-lang/rust#158723 (Support EII on Windows MSVC) - rust-lang/rust#158993 (rerun in original typing mode if we meet any opaques in post analysis) - rust-lang/rust#159160 (Make `HasTokens` a sub-trait of `HasAttrs`.) - rust-lang/rust#159183 (Introduce InstanceKind::LlvmIntrinsic) - rust-lang/rust#159251 (Bump rustc-perf submodule) - rust-lang/rust#155013 (Suggest the `[const] Destruct` bound for type parameters in const functions when missing) - rust-lang/rust#159155 (unstable book: Document `diagnostic_on_unknown` feature) - rust-lang/rust#159235 (Add regression test for rust-lang/rust#95719) - rust-lang/rust#159243 (inline Once wait and wait_force) - rust-lang/rust#159255 (Replace shortened type with `_` instead of `...` as placeholder) - rust-lang/rust#159259 (Add regression test for rust-lang/rust#144033) - rust-lang/rust#159265 (bootstrap: skip intrinsic-test when rustfmt is unavailable) - rust-lang/rust#159269 (disable range-len-try-from.rs on s390x) - rust-lang/rust#159272 (slice: make swap delegate to swap_unchecked) - rust-lang/rust#159274 (bootstrap: Rename `std_crates_for_run_make` to `std_crates_for_make_run`) - rust-lang/rust#159275 (remove obsolete comment) - rust-lang/rust#159277 (Construct `tokens` for attrs made by `mk_attr_word` and other variants) - rust-lang/rust#159283 (Remove obsolete verbose flag from deref/ref suggestions) - rust-lang/rust#159290 (rustc-dev-guide subtree update)
Rename `errors.rs` file to `diagnostics.rs` (14/N) Follow-up of rust-lang/rust#157485. r? @JonathanBrouwer
…and NVPTX For AVR, AMDGCN, and NVPTX, crates built with different target CPU values are not generally link-compatible. Add a `requires_consistent_cpu` flag to the target spec and enable it for these targets. When the flag is set, treat `-Ctarget-cpu` as a target modifier and require all linked crates to agree on its value. Reject `-Ctarget-cpu=native` before codegen for targets that set `requires_consistent_cpu` to true. Also do not include `native` in the printed `target-cpus` list for such targets. Add tests covering: - which built-in targets set `requires-consistent-cpu` - cross-crate behavior with and without `requires-consistent-cpu` - that an omitted `-Ctarget-cpu` compares equal to an explicitly specified default CPU - rejection and printing behavior for `native` - precedence of repeated `-Ctarget-cpu` flags in metadata comparison and LLVM IR
…uwer Rollup of 17 pull requests Successful merges: - rust-lang/rust#159301 (Update Enzyme to handle LLVM23) - rust-lang/rust#159365 (fix: point at method call chain when a return-position `impl Trait` assoc type diverges) - rust-lang/rust#159402 (Clarify safety requirements for SIMD shl/shr and masked load/store) - rust-lang/rust#159408 (rustc_data_structures: Expand documentation for rustc jobserver APIs) - rust-lang/rust#159410 (rustdoc: remove old `--emit` types) - rust-lang/rust#158398 (Comment about empty run_passes, fixup of rust-lang/rust#158040) - rust-lang/rust#158843 (Fix ICE in `write_interface` when the interface file can't be written) - rust-lang/rust#159302 (Implement `Debug` helpers via `Cell`) - rust-lang/rust#159332 (Honor field-level lint attributes in non_snake_case) - rust-lang/rust#159340 (Rename `errors.rs` file to `diagnostics.rs` (14/N)) - rust-lang/rust#159386 (add a fallback for `fmuladdf*`) - rust-lang/rust#159391 (Update tests for LLVM 23) - rust-lang/rust#159400 (Update books) - rust-lang/rust#159401 (Gate `tests/debuginfo/function-call.rs` on min GDB 15.1) - rust-lang/rust#159404 ([aarch64][win] Pass oversized c-variadic args indirectly on Arm64EC) - rust-lang/rust#159405 (Manually implement Clone for GrowableBitSet) - rust-lang/rust#159415 (rustdoc: rename the doc parts metadata params)
Convert `-Ctarget-cpu` into a target-modifier for AVR, AMDGCN and NVPTX Crates built for AVR, AMDGCN and NVPTX that specify different values for `-Ctarget-cpu` cannot be soundly linked together. This PR attempts to make `rustc` ensure that no crates with disagreeing values for `-Ctarget-cpu` are linked together. This is achieved by converting `-Ctarget-cpu` into a target-modifier depending on `--target`. To do this, the consistency check for `-Ctarget-cpu` considers mismatching values as inconsistent only for targets for which the new flag `requires_consistent_cpu` is set in their target spec. **Why should `-Ctarget-cpu` be a target-modifier for `nvptx`?** <details><summary>PTX is a single-module contract</summary> <p> PTX requires a binary to start with .version (`ptx$$`) then .target (`sm_$$`). If the ptx contains instructions that are not supported by either .version or .target, the binary is ill-formed and will be rejected by ptxas. The concept of features that can be mixed and matched in a binary does not exist for nvptx and is therefore not supported by LLVM. </p> </details> <details><summary>It prevents the production of bitcode that cannot be codegen'd after linking</summary> <p> A target modifier should prevent configurations that are not composable across crates when those crates are linked together. The most prominent example is when enabling a target feature changes the ABI, making cross-crate calls inherently unsound. In the case of nvptx, ABI mismatch is (at least for now) not the core problem motivating target modifiers. NVIDIA’s documented PTX calling convention has [remained stable since ptx20](https://docs.nvidia.com/cuda/ptx-writers-guide-to-interoperability/index.html#function-calling-sequence). However, in the current state it is possible to produce bitcode that cannot be codegen'd after linking, because some operations are only lowerable for sufficiently new SM/PTX levels. In the best case this results in an LLVM error during the final llc step, but this is not something we should rely on for correctness. nvptx has a special compilation pipeline where instead of linking the final PTX object, instead LLVM bitcode is linked. The resulting artifact is then compiled in one invocation. Now consider crate A which is independently compiled into bitcode with the following rustc arguments: ```Rust //@ compile-flags: --target nvptx64-nvidia-cuda -C target-cpu=sm_70 --crate-type=rlib #[cfg(target_feature = "sm_70")] fn foo() { // cannot be lowered to ptx before "sm_70: so currently produces an LLVM error } #[cfg(not(target_feature = "sm_70"))] fn foo() { // can be lowered to ptx before "sm_70" } pub fn bar() { foo() } ``` Crate A is a dependency of crate B. In the *rustc* invocation of crate B 1. crate B is compiled into bitcode, too 2. both bitcode artifacts are bitcode-linked by *llvm-link* 3. the resulting bitcode artifact is compiled by *llc -mcpu=sm_60* This should now ideally create an LLVM error, because the linked bitcode contains code paths that were selected under `sm_70` assumptions but the final NVPTX codegen is targeting `sm_60`, where those operations are not lowerable. An LLVM error here is better than silent miscompilation, but it’s not a promise we should rely on. A real example where this could happen is the lowering of atomic loads and stores with non-relaxed orderings, which is known to depend on the selected SM level. </p> </details> **Why should `-Ctarget-cpu` be a target-modifier for `amdgcn` and `avr`?** - In case of AVR the target-cpu defines the ISA, which is encoded in the ELF header flags, amdgcn also encodes the cpu directly into those flags - To not rely on *lld* which currently prevents it for both by looking at those flags [AVR](https://github.com/llvm/llvm-project/blob/597ffbe09d5f774f861ee55e50022bf84d7f98e2/lld/test/ELF/avr-flags.s) and [amdgcn](https://github.com/llvm/llvm-project/blob/597ffbe09d5f774f861ee55e50022bf84d7f98e2/lld/test/ELF/amdgpu-elf-flags-err.s) Previous discussions about the topic can be found [here](rust-lang/rust#131799 (comment)) and [here](rust-lang/rust#141468). I also created a [Zulip discussion](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Making.20-Ctarget-cpu.20a.20target-modifier.20on.20NVPTX/with/566622679). I am unsure if a MCP is needed before proceeding. If you think so please let me know. Creating *target-modifiers* for NVPTX *target-features* is to be done in a follow-up. cc @kjetilkjeka as target maintainer for NVPTX cc @Flakebi as target maintainer for amdgcn cc @Patryk27 as target maintainer for AVR cc @RalfJung you were very involved in the discussions so far Target modifier tracking issue: rust-lang/rust#136966
…uwer Rollup of 5 pull requests Successful merges: - rust-lang/rust#159188 (Always generate private and hidden items in JSON docs of the stdlib) - rust-lang/rust#159567 (Update rustc crate crossbeam-epoch to 0.9.20) - rust-lang/rust#150732 (Convert `-Ctarget-cpu` into a target-modifier for AVR, AMDGCN and NVPTX ) - rust-lang/rust#159549 (restrict const-eval-related 'content' triggers to library/ folder) - rust-lang/rust#159570 (fix ICE in opsem inhabitedness check)
…uwer Rollup of 11 pull requests Successful merges: - rust-lang/rust#159712 (Subtree sync for rustc_codegen_cranelift) - rust-lang/rust#155697 (Stabilize c-variadic function definitions) - rust-lang/rust#159285 (Simplify `apply_effects_in_range`) - rust-lang/rust#159596 (unify the AST repr of type const and const RHS) - rust-lang/rust#159607 (test: update riscv32e-registers.rs for LLVM 24 MC diagnostic changes) - rust-lang/rust#159659 (Move `Limit` out of `rustc_hir`) - rust-lang/rust#159707 (fix error when a dangling ref in a ManuallyDrop is used in a pattern) - rust-lang/rust#158738 (next_trait_solver: Recover from GCE const exprs) - rust-lang/rust#159451 (Remove config cloning in compiletest) - rust-lang/rust#159646 (Increase depth for float infer var fallback hack) - rust-lang/rust#159705 (bootstrap: Prefer `cfg!(not(test))` when skipping code paths during unit tests)
This updates the rust-version file to 165cce8d820b229af8f6a8226cf0b910b57600ff.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@165cce8 Filtered ref: rust-lang/rustc_codegen_cranelift@c70baf1 Upstream diff: rust-lang/rust@...165cce8 This merge was created using https://github.com/rust-lang/josh-sync.
bjorn3
reviewed
Jul 23, 2026
| extern_types, | ||
| decl_macro, | ||
| rustc_attrs, | ||
| rustc_private, |
Member
There was a problem hiding this comment.
This repo and the rust-lang/rust repo got desynced I guess. CI fails with this feature enabled.
Member
Author
There was a problem hiding this comment.
This change was created in the pull PR even if I tried it a ~month ago, I'm not sure where is it coming from. Should I just remove this change? Not sure if CI will be green in rust-lang/rust then, though.
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
19 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.
Merge ref '165cce8d820b' from rust-lang/rust
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: rust-lang/rust@165cce8
Filtered ref: c70baf1
Upstream diff: rust-lang/rust@...165cce8
This merge was created using https://github.com/rust-lang/josh-sync.