about summary refs log tree commit diff
path: root/compiler
AgeCommit message (Collapse)AuthorLines
2025-10-03interpret #[used] as #[used(compiler)] on illumosiximeow-9/+43
illumos' `ld` does not support a flag like either SHF_GNU_RETAIN or SHF_SUNW_NODISCARD, so there is no way to communicate `#[used(linker)]` for that target. Setting `USED_LINKER` to try results in LLVM setting SHF_SUNW_NODISCARD for Solaris-like targets, which is an unknown section header flag for illumos `ld` and prevents sections from being merged that otherwise would. As a motivating example, the `inventory` crate produces `#[used]` items to merge into `.init_array`. Because those items have an unknown section header flag they are not merged with the default `.init_array` with `frame_dummy`, and end up never executed. Downgrading `#[used]` to `#[used(compiler)]` on illumos keeps so-attributed items as preserved as they had been before https://github.com/rust-lang/rust/pull/140872. As was the case before that change, because rustc passes `-z ignore` to illumos `ld`, it's possible that `used` sections are GC'd at link time. https://github.com/rust-lang/rust/issues/146169 describes this unfortunate circumstance.
2025-09-27Auto merge of #147074 - matthiaskrgr:rollup-sm3owsd, r=matthiaskrgrbors-289/+329
Rollup of 10 pull requests Successful merges: - rust-lang/rust#145113 (resolve: Do not finalize shadowed bindings) - rust-lang/rust#146523 (Demote both armebv7r-none-* targets.) - rust-lang/rust#146704 (port `#[debugger_visualizer]` to the new attribute system) - rust-lang/rust#146758 (Stop linking rs{begin,end} objects on x86_64-*-windows-gnu) - rust-lang/rust#146778 (Use standard attribute logic for allocator shim) - rust-lang/rust#146849 (Reduce some uses of `LegacyBang`) - rust-lang/rust#147016 (fix doc comments to be more standard) - rust-lang/rust#147027 (Add new `tyalias` intra-doc link disambiguator) - rust-lang/rust#147031 (mbe: Simplify check_redundant_vis_repetition) - rust-lang/rust#147058 (Ignore more failing ui tests for GCC backend) Failed merges: - rust-lang/rust#147046 (Rename `rust.use-lld` to `rust.bootstrap-override-lld`) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-26Rollup merge of #147031 - joshtriplett:mbe-opt-collect, r=lcnrMatthias Krüger-6/+6
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.
2025-09-26Rollup merge of #147016 - hkBst:whitespace-1, r=nnethercoteMatthias Krüger-23/+5
fix doc comments to be more standard
2025-09-26Rollup merge of #146849 - joshtriplett:macro-reduce-legacy-bang, r=petrochenkovMatthias Krüger-22/+19
Reduce some uses of `LegacyBang` - **Switch `dummy_bang` from `LegacyBang` to `Bang`** - **mbe: Switch dummy extension used for errors from `LegacyBang` to `Bang`**
2025-09-26Rollup merge of #146778 - nikic:allocator-shim-attributes, r=jackh726Matthias Krüger-114/+126
Use standard attribute logic for allocator shim Use llfn_attrs_from_instance() to generate the attributes for the allocator shim. This ensures that we generate all the usual attributes (and don't get to find out one-by-one that a certain attribute is important for a certain target). Additionally this will enable emitting the allocator-specific attributes (not included here). This change is quite awkward because the allocator shim uses SimpleCx, while llfn_attrs_from_instance uses CodegenCx. I've switched it to use SimpleCx plus tcx/sess arguments where necessary. If there's a simpler way to do this, I'd love to know about it...
2025-09-26Rollup merge of #146758 - mati865:amd64_mingw_no_rs_objects, r=petrochenkovMatthias Krüger-7/+21
Stop linking rs{begin,end} objects on x86_64-*-windows-gnu Until now, x86_64-pc-windows-gnu linked `rsbegin.o` and `rsend.o` just like i686-pc-windows-gnu, even though they were no-ops for it. This was likely done for the simplicity back when it was introduced. Today the things are different and these startup/end objects harm other features, like `build-std`. Given the demotion of i686-pc-windows-gnu from tier 1, there is no point in hurting x86_64-pc-windows-gnu, which remains a tier 1. The files are still shipped in case downstream crates expect them, as in case of the unmaintained `xargo`. Fixes https://github.com/rust-lang/rust/issues/146739
2025-09-26Rollup merge of #146704 - jdonszelmann:port-debug-visualizer, r=petrochenkovMatthias Krüger-109/+143
port `#[debugger_visualizer]` to the new attribute system
2025-09-26Rollup merge of #146523 - thejpster:demote-armebv7r-targets, r=jackh726Matthias Krüger-2/+2
Demote both armebv7r-none-* targets. OK, slightly more controversial than https://github.com/rust-lang/rust/pull/146520 and https://github.com/rust-lang/rust/pull/146522 - I'd like to drop the bare-metal **big-endian** Armv7-R targets down to Tier 3. The reason is simple - we cannot test them in https://github.com/rust-embedded/cortex-ar/. This because QEMU support for Big Endian Armv7-R is broken. I tried quite hard, but all the strings I printed with semihosting came out byte swapped (or "etybawa depp") because of how QEMU kludges the access to memory in big-endian mode. The target also has only a single maintainer. Although, if ````@chrisnc```` wants to put up a case for keeping it at Tier 2 though, I'm happy to hear it! This PR wil be rebased once https://github.com/rust-lang/rust/pull/146419 completes the queue.
2025-09-26Rollup merge of #145113 - petrochenkov:lessfinalize, r=lcnrMatthias Krüger-6/+7
resolve: Do not finalize shadowed bindings I.e. do not mark them as used, or non-speculatively loaded, or similar. Previously they were sometimes finalized during early resolution, causing issues like https://github.com/rust-lang/rust/pull/144793#issuecomment-3168108005.
2025-09-26reviewlcnr-7/+13
2025-09-26allow method calls on opaqueslcnr-32/+216
2025-09-26use `try_structurally_resolve_type` for method receiverlcnr-2/+3
We'll still error due to the `opt_bad_ty` of `method_autoderef_steps`. This slightly worsens the span of `infer_var.method()` which is now the same as for `Box::new(infer_var).method()`. Unlike `structurally_resolve_type`, `probe_op` does not check whether the infcx is already tainted, so this results in 2 previously not emitted errors.
2025-09-26remove unnecessary structurally resolvelcnr-3/+1
`autoderef` already resolved and `method_autoderef_steps` makes sure we won't encounter an inference variable
2025-09-26predefined opaques to `method_autoderef_steps`lcnr-15/+63
2025-09-26predefined opaques use `List`lcnr-77/+16
2025-09-26fix doc comments to be more standardMarijn Schouten-23/+5
2025-09-26Auto merge of #147054 - matthiaskrgr:rollup-660g92w, r=matthiaskrgrbors-41/+136
Rollup of 7 pull requests Successful merges: - rust-lang/rust#146283 (Resolve: (Ref)Cell wrappers to deny mutation during spec resolution.) - rust-lang/rust#146453 (Add general arm-linux.md platform doc.) - rust-lang/rust#146991 (const_caller_location to use real Span instead of `DUMMY_SP`) - rust-lang/rust#146994 (Add `clippy::unconditional_recursion` to `./x clippy ci`) - rust-lang/rust#147038 (Rename verbosity functions in bootstrap) - rust-lang/rust#147047 (rustdoc: put the toolbar on the all item index) - rust-lang/rust#147049 (std: fix warning in VEXos stdio module) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-26Rollup merge of #146991 - cachebag:span-caller-location, r=RalfJungMatthias Krüger-1/+1
const_caller_location to use real Span instead of `DUMMY_SP` Clarifying usage of DUMMY_SP
2025-09-26Rollup merge of #146283 - LorrensP-2158466:resolve-cm-cell, r=petrochenkovMatthias Krüger-40/+135
Resolve: (Ref)Cell wrappers to deny mutation during spec resolution. Introduces wrappers around `Cell` and `RefCell` that only allow mutation when we are not in speculative resolution. This is preparatory work for rust-lang/rust#145108. It would allow us to make `ImportData` and `ModuleData` sync and send safe. r? ``@petrochenkov``
2025-09-26Auto merge of #145882 - m-ou-se:format-args-extend-1-arg, r=petrochenkovbors-20/+0
Extended temporary argument to format_args!() in all cases Fixes https://github.com/rust-lang/rust/issues/145880 by removing the special case.
2025-09-25Auto merge of #146919 - lcnr:yeet-fast-path, r=fee1-deadbors-13/+1
remove incorrect fast path Using `tcx.is_copy_modulo_regions` drops information from the current `typing_env`. Writing a regression test for this is really hard. We need to prove `Copy` of something that doesn't directly reference a coroutine or an opaque, but does so indirectly. cc rust-lang/rust#146813.
2025-09-25Auto merge of #147037 - matthiaskrgr:rollup-xtgqzuu, r=matthiaskrgrbors-8/+6
Rollup of 8 pull requests Successful merges: - rust-lang/rust#116882 (rustdoc: hide `#[repr]` if it isn't part of the public ABI) - rust-lang/rust#135771 ([rustdoc] Add support for associated items in "jump to def" feature) - rust-lang/rust#141032 (avoid violating `slice::from_raw_parts` safety contract in `Vec::extract_if`) - rust-lang/rust#142401 (Add proper name mangling for pattern types) - rust-lang/rust#146293 (feat: non-panicking `Vec::try_remove`) - rust-lang/rust#146859 (BTreeMap: Don't leak allocators when initializing nodes) - rust-lang/rust#146924 (Add doc for `NonZero*` const creation) - rust-lang/rust#146933 (Make `render_example_with_highlighting` return an `impl fmt::Display`) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-25const_caller_location: edit FIXME to explain use of `DUMMY_SP`Akrm Al-Hakimi-1/+1
Co-authored-by: Ralf Jung <post@ralfj.de>
2025-09-25resolve: Do not finalize shadowed bindingsVadim Petrochenkov-6/+7
I.e. do not mark them as used, or non-speculative loaded, or similar. Previously they were sometimes finalized during early resolution, causing issues like https://github.com/rust-lang/rust/pull/144793#issuecomment-3168108005.
2025-09-25Auto merge of #146697 - cjgillot:invalidate-patch, r=lcnrbors-15/+21
Avoid invalidating CFG caches from MirPatch::apply. Small effort to reduce invalidating CFG caches.
2025-09-25Introduce and use CmCell during import resolution.LorrensP-2158466-40/+135
2025-09-25Rollup merge of #142401 - oli-obk:pattern-mango, r=petrochenkovMatthias Krüger-8/+6
Add proper name mangling for pattern types requires adding demangler support first https://github.com/rust-lang/rustc-demangle/pull/81 needed for https://github.com/rust-lang/rust/pull/136006#discussion_r2139792593 as otherwise we will have symbol collisions
2025-09-25mbe: Simplify check_redundant_vis_repetitionJosh Triplett-6/+6
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.
2025-09-25Auto merge of #147019 - Zalathar:rollup-boxzbmo, r=Zalatharbors-84/+273
Rollup of 14 pull requests Successful merges: - rust-lang/rust#145067 (RawVecInner: add missing `unsafe` to unsafe fns) - rust-lang/rust#145277 (Do not materialise X in [X; 0] when X is unsizing a const) - rust-lang/rust#145973 (Add `std` support for `armv7a-vex-v5`) - rust-lang/rust#146667 (Add an attribute to check the number of lanes in a SIMD vector after monomorphization) - rust-lang/rust#146735 (unstably constify float mul_add methods) - rust-lang/rust#146737 (f16_f128: enable some more tests in Miri) - rust-lang/rust#146766 (Add attributes for #[global_allocator] functions) - rust-lang/rust#146905 (llvm: update remarks support on LLVM 22) - rust-lang/rust#146982 (Remove erroneous normalization step in `tests/run-make/linker-warning`) - rust-lang/rust#147005 (Small string formatting cleanup) - rust-lang/rust#147007 (Explicitly note `&[SocketAddr]` impl of `ToSocketAddrs`) - rust-lang/rust#147008 (bootstrap.py: Respect build.jobs while building bootstrap tool) - rust-lang/rust#147013 (rustdoc: Fix documentation for `--doctest-build-arg`) - rust-lang/rust#147015 (Use `LLVMDisposeTargetMachine`) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-25Rollup merge of #147015 - Zalathar:dispose-tm, r=lqdStuart Cook-8/+3
Use `LLVMDisposeTargetMachine` After bumping the minimum LLVM version to 20 (rust-lang/rust#145071), we no longer need to run any custom code when disposing of a TargetMachine, so we can just use the upstream LLVM-C function.
2025-09-25Rollup merge of #147005 - GuillaumeGomez:string-formatting-cleanup, ↵Stuart Cook-5/+3
r=jdonszelmann Small string formatting cleanup This PR is mostly useless. I was going through this file, saw that and corrected it. That's pretty much it. Feel free to close it if it's a bother.
2025-09-25Rollup merge of #146905 - durin42:llvm-22-bitstream-remarks, r=nikicStuart Cook-0/+13
llvm: update remarks support on LLVM 22 LLVM change dfbd76bda01e removed separate remark support entirely, but it turns out we can just drop the parameter and everything appears to work fine. Fixes rust-lang/rust#146912 as far as I can tell (the test passes.)
2025-09-25Rollup merge of #146766 - nikic:global-alloc-attr, r=nnethercoteStuart Cook-3/+13
Add attributes for #[global_allocator] functions Emit `#[rustc_allocator]` etc. attributes on the functions generated by the `#[global_allocator]` macro, which will emit LLVM attributes like `"alloc-family"`. If the module with the global allocator participates in LTO, this ensures that the attributes typically emitted on the allocator declarations are not lost if the definition is imported. There is a similar issue when the allocator shim is used, but I've opted not to fix that case in this PR, because doing that cleanly is somewhat gnarly. Related to https://github.com/rust-lang/rust/issues/145995.
2025-09-25Rollup merge of #146735 - Qelxiros:const_mul_add, r=tgross35,RalfJungStuart Cook-0/+54
unstably constify float mul_add methods Tracking issue: rust-lang/rust#146724 r? `@tgross35`
2025-09-25Rollup merge of #146667 - calebzulawski:simd-mono-lane-limit, r=lcnr,RalfJungStuart Cook-66/+163
Add an attribute to check the number of lanes in a SIMD vector after monomorphization Allows std::simd to drop the `LaneCount<N>: SupportedLaneCount` trait and maintain good error messages. Also, extends rust-lang/rust#145967 by including spans in layout errors for all ADTs. r? ``@RalfJung`` cc ``@workingjubilee`` ``@programmerjake``
2025-09-25Rollup merge of #145973 - vexide:vex-std, r=tgross35Stuart Cook-1/+1
Add `std` support for `armv7a-vex-v5` This PR adds standard library support for the VEX V5 Brain (`armv7a-vex-v5` target). It is more-or-less an updated version of the library-side work done in rust-lang/rust#131530. This was a joint effort between me, `@lewisfm,` `@max-niederman,` `@Gavin-Niederman` and several other members of the [`vexide` project](https://github.com/vexide/). ## Background VEXos is a fairly unconventional operating system, with user code running in a restricted enviornment with regards to I/O capabilities and whatnot. As such, several OS-dependent APIs are unsupported or have partial support (such as `std::net`, `std::process`, and most of `std::thread`). A more comprehensive list of what does or doesn't work is outlined in the [updated target documentation](https://github.com/vexide/rust/blob/vex-std/src/doc/rustc/src/platform-support/armv7a-vex-v5.md). Despite these limitations, we believe that `libstd` support on this target still has value to users, especially given the popular use of this hardware for educational purposes. For some previous discussion on this matter, see [this comment](https://github.com/rust-lang/rust/pull/131530#issuecomment-2432856841). ## SDK Linkage VEXos doesn't really ship with an official `libc` or POSIX-style platform API (and though it does port newlib, these are stubbed on top of the underlying SDK). Instead, VEX provides their own SDK for calling platform APIs. Their official SDK is kept proprietary (with public headers), though open-source implementations exist. Following the precedent of the `armv6k-nintendo-3ds` team's work in rust-lang/rust#95897, we've opted not to directly link `libstd` to any SDK with the expectation that users will provide their own with one of the following options: - [`vex-sdk-download`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-download), which downloads an official proprietary SDK from VEX using a build script. - [`vex-sdk-jumptable`](https://crates.io/crates/vex-sdk-jumptable), which is a compatible, open-source reimplementation of the SDK using firmware jumps. - [`vex-sdk-pros`](https://github.com/vexide/vex-sdk/tree/main/packages/vex-sdk-pros), which uses the [PROS kernel](https://github.com/purduesigbots/pros) as a provider for SDK functions. - Linking their own implementation or stubbing the functions required by libstd. The `vex-sdk` crate used in the VEXos PAL provides `libc`-style FFI bindings for any compatible system library, so any of these options *should* work fine. A functional demo project using `vex-sdk-download` can be found [here](https://github.com/vexide/armv7a-vex-v5-demo/tree/main). ## Future Work This PR implements virtually everything we are currently able to implement given the current capabilities of the platform. The exception to this is file directory enumeration, though the implementation of that is sufficiently [gross enough](https://github.com/vexide/vexide/blob/c6c5bad11e035cf4e51d429dca7e427210185ed4/packages/vexide-core/src/fs/mod.rs#L987) to drive us away from supporting this officially. Additionally, I have a working branch implementing the `panic_unwind` runtime for this target, which is something that would be nice to see in the future, though given the volume of compiler changes i've deemed it out-of-scope for this PR.
2025-09-25Rollup merge of #145277 - dingxiangfei2009:fold-coercion-into-const, ↵Stuart Cook-1/+23
r=nnethercote Do not materialise X in [X; 0] when X is unsizing a const Fix rust-lang/rust#143671 It turns out that MIR builder materialise `X` in `[X; 0]` into a temporary local when `X` is unsizing a `const`. This led to a confusing call to destructor of `X` when such a destructor is declared. [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=8dfc933af89efeb89c881bc77498ba63) This patch may miss out other cases that we should avoid materialisation in case of `[X; 0]`. Suggestions to include is most welcome!
2025-09-25Auto merge of #147003 - matthiaskrgr:rollup-b5z9uiz, r=matthiaskrgrbors-11/+15
Rollup of 7 pull requests Successful merges: - rust-lang/rust#146556 (Fix duration_since panic on unix when std is built with integer overflow checks) - rust-lang/rust#146679 (Clarify Display for error should not include source) - rust-lang/rust#146753 (Improve the pretty print of UnstableFeature clause) - rust-lang/rust#146894 (Improve derive suggestion of const param) - rust-lang/rust#146950 (core: simplify `CStr::default()`) - rust-lang/rust#146958 (Fix infinite recursion in Path::eq with String) - rust-lang/rust#146971 (fix ICE in writeback due to bound regions) r? `@ghost` `@rustbot` modify labels: rollup
2025-09-25Use `LLVMDisposeTargetMachine`Zalathar-8/+3
2025-09-25Use standard attribute logic for allocator shimNikita Popov-114/+126
Use llfn_attrs_from_instance() to generate the attributes for the allocator shim. This ensures that we generate all the usual attributes (and don't get to find out one-by-one that a certain attribute is important for a certain target). Additionally this will enable emitting the allocator-specific attributes (not included here). This change is quite awkward because the allocator shim uses SimpleCx, while llfn_attrs_from_instance uses CodegenCx. I've switched it to use SimpleCx plus tcx/sess arguments where necessary. If there's a simpler way to do this, I'd love to know about it...
2025-09-24llvm: add a destructor to call releaseSerializerJosh Stone-0/+8
2025-09-24Small string formatting cleanupGuillaume Gomez-5/+3
2025-09-24Rollup merge of #146971 - lcnr:fix-writeback, r=BoxyUwUMatthias Krüger-5/+7
fix ICE in writeback due to bound regions fixes rust-lang/rust#117808 r? `@BoxyUwU`
2025-09-24Rollup merge of #146894 - tiif:suggest_feature_attr, r=BoxyUwUMatthias Krüger-4/+7
Improve derive suggestion of const param Make the suggestion not to remove the adt and use the name of the adt variant in the diagnostic. r? `@BoxyUwU`
2025-09-24Rollup merge of #146753 - tiif:unsatisfiable-unstable-feature, r=BoxyUwUMatthias Krüger-2/+1
Improve the pretty print of UnstableFeature clause As per https://github.com/rust-lang/rust/pull/145095#discussion_r2349439492, we could make the diagnostic for unsatisfiable ``UnstableFeature`` clause better. r? `@BoxyUwU`
2025-09-24unstably constify float mul_add methodsJeremy Smart-0/+54
Co-authored-by: Ralf Jung <post@ralfj.de>
2025-09-24Rollup merge of #146969 - RalfJung:maybe-null-errors, r=oli-obkMatthias Krüger-23/+33
const-eval: better wording for errors involving maybe-null pointers Fixes https://github.com/rust-lang/rust/issues/146748 r? ``@oli-obk``
2025-09-24Rollup merge of #146915 - clarfonthey:safe-intrinsics-2, r=RalfJungMatthias Krüger-0/+8
Make missed precondition-free float intrinsics safe So, in my defence, these were both separated out from the other intrinsics in the file *and* had a different safety comment in the stable versions, so, I didn't notice them before. But, in my offence, the entire reason I did the previous PR was because I was using them for SIMD intrinsic fallbacks, and `fabs` is needed for those too, so, I don't really have an excuse. Extra follow-up to rust-lang/rust#146683. r? ```@RalfJung``` who reviewed the previous one These don't appear to be used anywhere outside of the standard locations, at least.
2025-09-24Rollup merge of #146857 - tnuha:revert_self_has_no_region_infer, r=lcnrMatthias Krüger-1/+10
revert change removing `has_infer` check. Commit conservatively patch… …es for now, but more development proceeding. Hotfix for rust-lang/rust#146852.