| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Couple of minor cleanups
|
|
Fix tail calls to `#[track_caller]` functions
We want `#[track_caller]` to be semver independent, i.e. it should not be a breaking change to add or remove it. Since it changes ABI of a function (adding an additional argument) we have to be careful to preserve this property when adding tail calls.
The only way to achieve this that I can see is:
- we forbid tail calls in functions which are marked with `#[track_caller]` (already implemented)
- tail-calling a `#[track_caller]` marked function downgrades the tail-call to a normal call (or equivalently tail-calls the shim made by fn def to fn ptr cast) (this pr)
Ideally the downgrade would be performed by a MIR pass, but that requires post mono MIR opts (cc ```@saethlin,``` rust-lang/rust#131650). For now I've changed code in cg_ssa to accomodate this behaviour (+ added a hack to mono collector so that the shim is actually generated)
Additionally I added a lint, although I don't think it's strictly necessary.
Alternative to rust-lang/rust#144762 (and thus closes rust-lang/rust#144762)
Fixes https://github.com/rust-lang/rust/issues/144755
|
|
|
|
|
|
|
|
|
|
Make no_mangle on foreign items explicit instead of implicit
for a followup PR I'm working on I need some foreign items to mangle. I could add a new attribute: `no_no_mangle` or something silly like that but by explicitly putting `no_mangle` in the codegen fn attrs of foreign items we can default it to `no_mangle` and then easily remove it when we don't want it.
I guess you'd know about this r? `@bjorn3.` Shouldn't be too hard to review :)
Builds on rust-lang/rust#144655 which should merge first.
|
|
|
|
The exact reasoning why we do not always pass the SDK root when linking
on macOS eludes me, but I suspect it's because we want to support
compiler drivers which do not support the `-isysroot` option.
Since we now pass the SDK root via the environment variable SDKROOT,
compiler drivers that don't support it can just ignore it.
Similarly, since we only warn when xcrun fails, users that expect their
compiler driver to provide the SDK location can do so now.
|
|
To allow using zig-cc or similar as the compiler driver.
|
|
This is more in-line with what Apple's tooling expects, and allows us to
better support custom compiler drivers (such as certain Homebrew and
Nixpkgs compilers) that prefer their own `-isysroot` flag.
Effectively, we now invoke the compiler driver as-if it was invoked as
`xcrun -sdk $sdk_name $tool`.
|
|
Reduce indentation and avoid needless checks (checking the target OS and
vendor is unnecessary).
|
|
r=wesleywiser
Add diagnostic explaining STATUS_STACK_BUFFER_OVERRUN not only being used for stack buffer overruns if link.exe exits with that exit code
`STATUS_STACK_BUFFER_OVERRUN` is also used for fast abnormal program termination, e.g. by abort(). Emit a special diagnostic to let people know that this most likely doesn't indicate a stack buffer overrun.
This doesn't look up the crash report in the event log to determine what the fast fail error code is. This is due to the way crashes are logged: When a process crash happens, the system logs an "Application Error" event, which contains the exit code and the process ID, but not the fast fail error code. A second event by Windows Error Reporting does contain that fast fail code, but not the process ID - but that event is not emitted at process exit, but when WER has dealt with it (on my system, it happens roughly two seconds later), so querying the code would have to read the `IntegratorReportId`, wait two seconds or potentially longer for the WER event with the same `ReportID`, and read out the code. (Also, that second event doesn't happen if WER is disabled.)
Fixes rust-lang/rust#100519.
|
|
atomicrmw on pointers: move integer-pointer cast hacks into backend
Conceptually, we want to have atomic operations on pointers of the form `fn atomic_add(ptr: *mut T, offset: usize, ...)`. However, LLVM does not directly support such operations (https://github.com/llvm/llvm-project/issues/120837), so we have to cast the `offset` to a pointer somewhere.
This PR moves that hack into the LLVM backend, so that the standard library, intrinsic, and Miri all work with the conceptual operation we actually want. Hopefully, one day LLVM will gain a way to represent these operations without integer-pointer casts, and then the hack will disappear entirely.
Cc ```@nikic``` -- this is the best we can do right now, right?
Fixes https://github.com/rust-lang/rust/issues/134617
|
|
|
|
It used to be necessary on Apple platforms to ship with the App Store,
but XCode 15 has stopped embedding LLVM bitcode and the App Store no
longer accepts apps with bitcode embedded.
|
|
Move metadata symbol export from exported_non_generic_symbols to exported_symbols
The metadata symbol must not be encoded in the crate metadata, and must be exported from proc-macros. Handling the export of the metadata symbol in exported_symbols handles both things at once without requiring manual fixups elsewhere.
|
|
coverage: Remove all unstable support for MC/DC instrumentation
Preliminary support for a partial implementation of “Modified Condition/Decision Coverage” instrumentation was added behind the unstable flag `-Zcoverage-options=mcdc` in 2024. These are the most substantial PRs involved:
- rust-lang/rust#123409
- rust-lang/rust#126733
At the time, I accepted these PRs with relatively modest scrutiny, because I did not want to stand in the way of independent work on MC/DC instrumentation. My hope was that ongoing work by interested contributors would lead to the code becoming clearer and more maintainable over time.
---
However, that MC/DC code has proven itself to be a major burden on overall maintenance of coverage instrumentation, and a major obstacle to other planned improvements, such as internal changes needed for proper support of macro expansion regions.
I have also become reluctant to accept any further MC/DC-related changes that would increase this burden.
That tension has resulted in an unhappy impasse. On one hand, the present MC/DC implementation is not yet complete, and shows little sign of being complete at an acceptable level of code quality in the foreseeable future. On the other hand, the continued existence of this partial MC/DC implementation is imposing serious maintenance burdens on every other aspect of coverage instrumentation, and is preventing some of the very improvements that would make it easier to accept expanded MC/DC support in the future.
While I know this will be disappointing to some, I think the healthy way forward is accept that I made the wrong call in accepting the current implementation, and to remove it entirely from the compiler.
|
|
Print CGU reuse statistics in `-Zprint-mono-items`
I'm trying to expose more information about incremental profiling from rustc (https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/Profiling.2Fanalysis.20of.20incremental.20builds/with/531383501). One of the things that would be quite useful to expose is the CGU reuse state, so that when you do a rebuild, you can see all the CGUs (and all the functions) that had to be recompiled.
Currently, we have (AFAIK) two ways of outputting monomorphization statistics:
1) `-Zdump-mono-stats` outputs statistics about number of instantiations and expected compilation cost of individual functions in the local crate being compiled. It can be outputted either as Markdown or JSON.
2) `-Zprint-mono-items` outputs a pair (item, CGU) for each monomorphized item.
I was thinking about recording CGU statistics in the self-profile output, but I realized that as a simpler step, we could just add CGU reuse data to `-Zprint-mono-items`, as an additional output. That is what this PR does.
|
|
r=WaffleLapkin
[codegen] assume the tag, not the relative discriminant
Address the issue mentioned in <https://github.com/llvm/llvm-project/issues/134024#issuecomment-3131782555> by changing discriminant calculation to `assume` on the originally-loaded `tag`, rather than on `cast(tag)-OFFSET`.
The previous way does make the *purpose* of the assume clearer, IMHO, since you see `assume(x != 4); if p { x } else { 4 }`, but doing it this way instead means that the `add`s optimize away in LLVM21, which is more important. And this new way is still easily thought of as being like metadata on the load saying specifically which value is impossible.
Demo of the LLVM20 vs LLVM21 difference: <https://llvm.godbolt.org/z/n54x5Mq1T>
r? ``@nikic``
|
|
|
|
used for stack buffer overruns if link.exe exits with that exit code
`STATUS_STACK_BUFFER_OVERRUN` is also used for fast abnormal program
termination, e.g. by abort(). Emit a special diagnostic to let people
know that this most likely doesn't indicate a stack buffer overrun.
|
|
exported_symbols
The metadata symbol must not be encoded in the crate metadata, and must
be exported from proc-macros. Handling the export of the metadata symbol
in exported_symbols handles both things at once without requiring manual
fixups elsewhere.
|
|
Rollup of 19 pull requests
Successful merges:
- rust-lang/rust#137831 (Tweak auto trait errors)
- rust-lang/rust#138689 (add nvptx_target_feature)
- rust-lang/rust#140267 (implement continue_ok and break_ok for ControlFlow)
- rust-lang/rust#143028 (emit `StorageLive` and schedule `StorageDead` for `let`-`else`'s bindings after matching)
- rust-lang/rust#143764 (lower pattern bindings in the order they're written and base drop order on primary bindings' order)
- rust-lang/rust#143808 (Port `#[should_panic]` to the new attribute parsing infrastructure )
- rust-lang/rust#143906 (Miri: non-deterministic floating point operations in `foreign_items`)
- rust-lang/rust#143929 (Mark all deprecation lints in name resolution as deny-by-default and report-in-deps)
- rust-lang/rust#144133 (Stabilize const TypeId::of)
- rust-lang/rust#144369 (Upgrade semicolon_in_expressions_from_macros from warn to deny)
- rust-lang/rust#144439 (Introduce ModernIdent type to unify macro 2.0 hygiene handling)
- rust-lang/rust#144473 (Address libunwind.a inconsistency issues in the bootstrap program)
- rust-lang/rust#144601 (Allow `cargo fix` to partially apply `mismatched_lifetime_syntaxes`)
- rust-lang/rust#144650 (Additional tce tests)
- rust-lang/rust#144659 (bootstrap: refactor mingw dist and fix gnullvm)
- rust-lang/rust#144682 (Stabilize `strict_overflow_ops`)
- rust-lang/rust#145026 (Update books)
- rust-lang/rust#145033 (Reimplement `print_region` in `type_name.rs`.)
- rust-lang/rust#145040 (rustc-dev-guide subtree update)
Failed merges:
- rust-lang/rust#143857 (Port #[macro_export] to the new attribute parsing infrastructure)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
add nvptx_target_feature
Tracking issue: #141468 (nvptx), which is part of #44839 (catch-all arches)
The feature gate is `#![feature(nvptx_target_feature)]`
This exposes the target features `sm_20` through `sm_120a` [as defined](https://github.com/llvm/llvm-project/blob/llvmorg-20.1.1/llvm/lib/Target/NVPTX/NVPTX.td#L59-L85) by LLVM.
Cc: ``````@gonzalobg``````
``````@rustbot`````` label +O-NVPTX +A-target-feature
|
|
This reverts commit 868bdde25b030e0b71a29a5dbc04a891036e702e.
|
|
This reverts commit b4d923cea0509933b1fb859930cb20784251f9be.
|
|
|
|
|
|
|
|
|
|
Instead of collecting pretty printers transitively when building
executables/staticlibs/cdylibs, let the debugger find each crate's
pretty printers via its .debug_gdb_scripts section. This covers the case
where libraries defining custom pretty printers are loaded dynamically.
|
|
Make sure that compiler and linker don't optimize the section's contents
away by adding the global holding the data to "llvm.used". The volatile
load in the main shim is retained because "llvm.used", which translates
to SHF_GNU_RETAIN on ELF targets, requires a reasonably recent linker;
emitting the volatile load ensures compatibility with older linkers, at
least when libstd is used.
Pretty printers in dylib dependencies are now emitted by the main crate
instead of the dylib; apart from matching how rlibs are handled, this
approach has the advantage that `omit_gdb_pretty_printer_section` keeps
working with dylib dependencies.
|
|
|
|
|
|
merge rustc_attr_data_structures into rustc_hir
this move was discussed on zulip: [#t-compiler > attribute parsing rework @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/attribute.20parsing.20rework/near/528530091)
Many PRs in the attribute rework depend on this move.
|
|
|
|
Fix linker-plugin-lto only doing thin lto
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
https://github.com/llvm/llvm-project/blob/560149b5e3c891c64899e9912e29467a69dc3a4c/clang/lib/CodeGen/BackendUtil.cpp#L1150
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
https://github.com/llvm/llvm-project/blob/e258bca9505f35e0a22cb213a305eea9b76d11ea/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L4441-L4446
try-job: x86_64-gnu-debug
try-job: aarch64-gnu-debug
|
|
When rust provides LLVM bitcode files to lld and the bitcode contains
function summaries as used for thin lto, lld defaults to using thin lto.
This prevents some optimizations that are only applied for fat lto.
We solve this by not creating function summaries when fat lto is
enabled. The bitcode for the module is just directly written out.
An alternative solution would be to set the `ThinLTO=0` module flag to
signal lld to do fat lto.
The code in clang that sets this flag is here:
https://github.com/llvm/llvm-project/blob/560149b5e3c891c64899e9912e29467a69dc3a4c/clang/lib/CodeGen/BackendUtil.cpp#L1150
The code in LLVM that queries the flag and defaults to thin lto if not
set is here:
https://github.com/llvm/llvm-project/blob/e258bca9505f35e0a22cb213a305eea9b76d11ea/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp#L4441-L4446
|
|
Only extract lang items once in codegen_fn_attrs
This one should be obvious. These two extraction points used to be far apart but now that they're refactored to be close it was rather obvious we're just doing double work....
r? ``@WaffleLapkin``
Buils on rust-lang/rust#144655
|
|
Implement support for `become` and explicit tail call codegen for the LLVM backend
This PR implements codegen of explicit tail calls via `become` in `rustc_codegen_ssa` and support within the LLVM backend. Completes a task on (https://github.com/rust-lang/rust/issues/112788). This PR implements all the necessary bits to make explicit tail calls usable, other backends have received stubs for now and will ICE if you use `become` on them. I suspect there is some bikeshedding to be done on how we should go about implementing this for other backends, but it should be relatively straightforward for GCC after this is merged.
During development I also put together a POC bytecode VM based on tail call dispatch to test these changes out and analyze the codegen to make sure it generates expected assembly. That is available [here](https://github.com/xacrimon/tcvm).
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#144072 (update `Atomic*::from_ptr` and `Atomic*::as_ptr` docs)
- rust-lang/rust#144151 (`tests/ui/issues/`: The Issues Strike Back [1/N])
- rust-lang/rust#144300 (Clippy fixes for miropt-test-tools)
- rust-lang/rust#144399 (Add a ratchet for moving all standard library tests to separate packages)
- rust-lang/rust#144472 (str: Mark unstable `round_char_boundary` feature functions as const)
- rust-lang/rust#144503 (Various refactors to the codegen coordinator code (part 3))
- rust-lang/rust#144530 (coverage: Infer `instances_used` from `pgo_func_name_var_map`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Various refactors to the codegen coordinator code (part 3)
Continuing from https://github.com/rust-lang/rust/pull/144062 this removes an option without any known users, uses the object crate in favor of LLVM for getting the LTO bitcode and improves the coordinator channel handling.
|
|
Some `let chains` clean-up
Not sure if this kind of clean-up is welcoming because of size, but I decided to try out one
r? compiler
|
|
|
|
Don't special-case llvm.* as nounwind
Certain LLVM intrinsics, such as `llvm.wasm.throw`, can unwind. Marking them as nounwind causes us to skip cleanup of locals and optimize out `catch_unwind` under inlining or when `llvm.wasm.throw` is used directly by user code.
The motivation for forcibly marking llvm.* as nounwind is no longer present: most intrinsics are linked as `extern "C"` or other non-unwinding ABIs, so we won't codegen `invoke` for them anyway.
Closes rust-lang/rust#132416.
`@rustbot` label +T-compiler +A-panic
|
