| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
I missed this target when I changed all the other tier 3 targets. Only
realized that this one was still statically linked when I looked at the
list of targets in the test later.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
|
|
|
|
|
|
|
|
|
|
|
|
Consider errors in MIR as impossible predicates to empty the body.
The ICEs come from elaborating drops or performing state transform in MIR bodies that fail typeck or borrowck.
If the body is tainted, replace it with `unreachable`.
Fixes https://github.com/rust-lang/rust/issues/122630
Fixes https://github.com/rust-lang/rust/issues/122904
Fixes https://github.com/rust-lang/rust/issues/125185
Fixes https://github.com/rust-lang/rust/issues/139556
|
|
Co-authored-by: Anne Stijns <anstijns@gmail.com>
|
|
These code paths are surprisingly hot in the `large-workspace` benchmark; it
would be handy to see some detailed timings and execution counts.
|
|
|
|
naked_asm: emit a label starting with `func_end`
The `cargo asm` tool (`cargo install cargo-show-asm`) pattern matches on such labels to figure out where functions end: normal functions generated by LLVM always do have such a label. We don't guarantee that naked functions emit such a label, but having `cargo asm` work is convenient.
https://github.com/pacak/cargo-show-asm/blob/be45f67454ad8b634246a7fc69b3c6a963ee93f1/src/asm/statements.rs#L897-L901
To make the label name unique it's suffixed with the name of the current symbol.
r? ```@Amanieu```
|
|
Deref related cleanups in ref_prop
Cherry picked from rust-lang/rust#146710
r? cjgillot
|
|
fix issue with `cmse-nonsecure-entry` ABI being both async and c-variadic
tracking issue: https://github.com/rust-lang/rust/issues/75835
fixes https://github.com/rust-lang/rust/issues/132142
An `extern "cmse-nonsecure-entry"` function cannot be c-variadic (or, in any case, clang/LLVM does not support it, see https://godbolt.org/z/MaPjzGcE1). So just stop looking at the type if we know it'll be invalid anyway.
I'm not entirely sure how to test this. The ICE is only possible on the `thumbv8m.main-none-eabi` and some related targets. I think using `minicore` is the most convenient, but use of `async` requires quite a long list of lang items to be present. Maybe we want that anyway though? On the other hand, it's extra `minicore` surface that might go out of date.
An alternative is `run-make`, that should work, but is much less convenient. See also [#t-compiler/help > `async fn` and `minicore`](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/.60async.20fn.60.20and.20.60minicore.60/with/539427262).
r? `@ghost`
|
|
Stabilize `new_zeroed_alloc`
The corresponding `new_uninit` and `new_uninit_slice` functions were stabilized in rust-lang/rust#129401, but the zeroed counterparts were left for later out of a [desire](https://github.com/rust-lang/rust/issues/63291#issuecomment-2161039756) to stabilize only the minimal set. These functions are straightforward mirrors of the uninit functions and well-established. Since no blockers or design questions have surfaced in the past year, I think it's time to stabilize them.
Tracking issue: rust-lang/rust#129396
|
|
|
|
fixes for numerous clippy warnings
|
|
generate list of all variants with `target_spec_enum`
This helps us avoid the hardcoded lists elsewhere.
r? ``@Noratrieb``
|
|
|
|
These should have been removed earlier, when we switched to the corresponding
LLVM-C bindings.
|
|
Identify metavariable functions by using named symbols rather than
string comparisons.
|
|
|
|
Factor out the check for a variable that's still repeating.
|
|
This helps us avoid the hardcoded lists elsewhere.
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#146690 (add `[const] PartialEq` bound to `PartialOrd`)
- rust-lang/rust#146776 (fixes for numerous clippy warnings)
- rust-lang/rust#146777 (fix ./x readdir logic when CDPATH is set)
- rust-lang/rust#146781 (mbe: Fix feature gate for `macro_derive`)
- rust-lang/rust#146785 (btree: safety comments for init and new)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
r=wesleywiser
mbe: Fix feature gate for `macro_derive`
|
|
fixes for numerous clippy warnings
|
|
This commit updates the target specification of wasm targets to set the
`limit_rdylib_exports` value to `true` like it is on other native
platforms. This was originally not implemented long ago as `wasm-ld`
didn't have options for symbol exports, but since then it's grown a
`--export` flag and such to control this. A custom case is needed in the
linker implementation to handle wasm targets as `wasm-ld` doesn't
support linker scripts used on other targets, but other than that the
implementation is straightforward.
The goal of this commit is enable building dynamic libraries on
`wasm32-wasip2` which don't export every single symbol in the Rust
standard library. Currently, without otherwise control over symbol
visibility, all symbols end up being exported which generates
excessively large binaries because `--gc-sections` ends up doing nothing
as it's all exported anyway.
|
|
The `cargo asm` tool pattern matches on such labels to figure out where functions end: normal functions generated by LLVM always do have such a label. We don't guarantee that naked functions emit such a label, but having `cargo asm` work is convenient
|
|
|
|
cg_llvm: Move target machine command-line quoting from C++ to Rust
When this code was introduced in rust-lang/rust#130446 and rust-lang/rust#131805, it was complicated by the need to maintain compatibility with earlier versions of LLVM.
Now that LLVM 20 is the baseline (rust-lang/rust#145071), we can do all of the quoting in pure Rust code, and pass two flat strings to LLVM to be used as-is.
---
In this PR, my priority has been to preserve the existing behaviour as much as possible, without worrying too much about what the behaviour *should* be. (Though I did avoid a leading space before the first argument.)
|
|
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`.
|
|
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#146229 (Automatically switch to lto-fat when flag RUSTFLAGS="- Zautodiff=Enable" is set)
- rust-lang/rust#146484 (rustdoc-search: JavaScript optimization based on Firefox Profiler output)
- rust-lang/rust#146541 (std: simplify host lookup)
- rust-lang/rust#146615 (rustc_codegen_llvm: Feature Conversion Tidying)
- rust-lang/rust#146638 (`rustc_next_trait_solver`: canonical out of `EvalCtxt`)
- rust-lang/rust#146663 (Allow windows resource compiler to be overridden)
- rust-lang/rust#146691 (std: Fix WASI implementation of `remove_dir_all`)
- rust-lang/rust#146709 (stdarch subtree update)
- rust-lang/rust#146738 (Fix tidy spellchecking on Windows)
- rust-lang/rust#146740 (miri subtree update)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Allow windows resource compiler to be overridden
In rust-lang/rust#146018, it is now required to provide a resource compiler on windows when compiling rust. This allows toolchain builders to explicitly provide a path to an alternative, such as llvm-rc, instead of the one that's provided by the Windows SDK.
cc ```@lambdageek```
|
|
`rustc_next_trait_solver`: canonical out of `EvalCtxt`
we need to canonicalize outside of the trait solver as well, so it's just a lot nicer if canonicalization is more easily accessible
if you review it commit by commit the move is properly shown
|
|
r=workingjubilee
rustc_codegen_llvm: Feature Conversion Tidying
The author thinks we can improve `to_llvm_features`, a function to convert a Rust target feature name into an LLVM feature (or nothing, to ignore features unsupported by LLVM) for better maintainability.
1. We can simplify some clauses and some expressions.
2. There are some readability issues.
This PR attempts to resolve some of them by tidying many cases.
|
|
Automatically switch to lto-fat when flag RUSTFLAGS="- Zautodiff=Enable" is set
…t" is automatically set.
closes: [#142796](https://github.com/rust-lang/rust/issues/142796)
|
|
GVN: stop hashing opaque values
GVN generates values that are not meant to be unified with any other. For instance `Opaque` (aka we don't know anything), non-deterministic constants and borrows.
The current algorithm generates a unique index, so the generated `Value` will be different from all the existing. This is wasteful, as we should not hash that `Value` at all.
This PR proposes to do this. This involves partially reimplementing a `FxIndexSet`, but yields a small but consistent perf improvement (https://github.com/rust-lang/rust/pull/145737#issuecomment-3276951054).
|
|
In each of these casts, the LHS is already `u64`.
|
|
|
|
|
|
Signed-off-by: Karan Janthe <karanjanthe@gmail.com>
|
|
|
|
|
|
|
|
|
