| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Denote `ControlFlow` as `#[must_use]`
I've repeatedly hit bugs in the compiler due to `ControlFlow` not being marked `#[must_use]`. There seems to be an accepted ACP to make the type `#[must_use]` (https://github.com/rust-lang/libs-team/issues/444), so this PR implements that part of it.
Most of the usages in the compiler that trigger this new warning are "root" usages (calling into an API that uses control-flow internally, but for which the callee doesn't really care) and have been suppressed by `let _ = ...`, but I did legitimately find one instance of a missing `?` and one for a never-used `ControlFlow` value in #137448.
Presumably this needs an FCP too, so I'm opening this and nominating it for T-libs-api.
This PR also touches the tools (incl. rust-analyzer), but if this went into FCP, I'd split those out into separate PRs which can land before this one does.
r? libs-api
`@rustbot` label: T-libs-api I-libs-api-nominated
|
|
|
|
|
|
|
|
Fix the OperandRef type for NullOp::{UbChecks,ContractChecks}
Stumbled on this while looking at something totally unrelated 🙃
r? saethlin
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #138283 (Enforce type of const param correctly in MIR typeck)
- #138439 (feat: check ARG_MAX on Unix platforms)
- #138502 (resolve: Avoid some unstable iteration)
- #138514 (Remove fake borrows of refs that are converted into non-refs in `MakeByMoveBody`)
- #138524 (Mark myself as unavailable for reviews temporarily)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
On Unix the limits can be gargantuan anyway so we're pretty
unlikely to hit them, but might still exceed it.
We consult ARG_MAX here to get an estimate.
|
|
Though I doubt anyone running rustc outside Unix/Windows
|
|
This also updates the estimate on Windows of the length argument
list to `saturating_add` to avoid overflow.
|
|
fix: remove the check of lld not supporting @response-file
In LLVM v9, lld has supported `@response-file.`
LLVM v9 was released on 2019-09-19.
The check was added back to 2018-03-14 (1.26.0) via 04442af18bf0.
It has been more than five years, and we ship our own lld regardlessly.
This should be happily removed.
See also:
* <https://github.com/llvm/llvm-project/commit/bb12396f9175eaf4586d8e5c76441977d97ccf93>
* <https://reviews.llvm.org/D63024>
|
|
atomic intrinsics: clarify which types are supported and (if applicable) what happens with provenance
The provenance semantics match what Miri implements and what the `AtomicPtr` API expects.
|
|
Don't `alloca` just to look at a discriminant
Today we're making LLVM do a bunch of extra work when you match on trivial stuff like `Option<bool>` or `ControlFlow<u8>`.
This PR changes that so that simple types like `Option<u32>` or `Result<(), Box<Error>>` can stay as `OperandValue::ScalarPair` and we can still read the discriminant from them, rather than needing to write them into memory to have a `PlaceValue` just to get the discriminant out.
Fixes #137503
|
|
Rollup of 6 pull requests
Successful merges:
- #137816 (attempt to support `BinaryFormat::Xcoff` in `naked_asm!`)
- #138109 (make precise capturing args in rustdoc Json typed)
- #138343 (Enable `f16` tests for `powf`)
- #138356 (bump libc to 0.2.171 to fix xous)
- #138371 (Update compiletest's `has_asm_support` to match rustc)
- #138404 (Cleanup sysroot locating a bit)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=petrochenkov,jieyouxu
Cleanup sysroot locating a bit
All commits should preserve existing behavior.
|
|
attempt to support `BinaryFormat::Xcoff` in `naked_asm!`
Fixes https://github.com/rust-lang/rust/issues/137219
So, the inline assembly support for xcoff is extremely limited. The LLVM [XCOFFAsmParser](https://github.com/llvm/llvm-project/blob/1b25c0c4da968fe78921ce77736e5baef4db75e3/llvm/lib/MC/MCParser/XCOFFAsmParser.cpp) does not support many of the attributes that LLVM itself emits, and that should exist based on [the assembler docs](https://www.ibm.com/docs/en/ssw_aix_71/assembler/assembler_pdf.pdf). It also does accept some that should not exist based on those docs.
So, I've tried to do the best I can given those limitations. At least it's better than emitting the directives for elf and having that fail somewhere deep in LLVM. Given that inline assembly for this target is incomplete (under `asm_experimental_arch`), I think that's OK (and again I don't see how we can do better given the limitations in LLVM).
r? ```@Noratrieb``` (given that you reviewed https://github.com/rust-lang/rust/pull/136637)
It seems reasonable to ping the [`powerpc64-ibm-aix` target maintainers](https://doc.rust-lang.org/rustc/platform-support/aix.html), hopefully they have thoughts too: ```@daltenty``` ```@gilamn5tr```
|
|
naked functions: on windows emit `.endef` without the symbol name
tracking issue: https://github.com/rust-lang/rust/issues/90957
fixes https://github.com/rust-lang/rust/issues/138320
The `.endef` directive does not take the name as an argument. Apparently the LLVM x86_64 parser does accept this, but on i686 it's rejected. In general `i686` does some special name mangling stuff, so it's good to include it in the naked function tests.
r? ````@ChrisDenton```` (because windows)
|
|
metadata: Ignore sysroot when doing the manual native lib search in rustc
This is the opposite alternative to https://github.com/rust-lang/rust/pull/138170 and another way to make native library search consistent between rustc and linker.
This way the directory list searched by rustc is still a prefix of the directory list considered by linker, but it's a shorter prefix than in #138170.
We can include the sysroot directories into rustc's search again later if the issues with #138170 are resolved, it will be a backward compatible change.
This may break some code doing weird things on unstable rustc, or tier 2-3 targets, like bundling `libunwind.a` or sanitizers into something.
Note that this doesn't affect shipped `libc.a`, because it lives in `self-contained` directories in sysroot, and `self-contained` sysroot is already not included into the rustc's search. All libunwind and sanitizer libs should be moved to `self-contained` sysroot too eventually.
With the consistent search directory list between rustc and linker we can make rustc own the native library search (at least for static libs) and use linker search only as a fallback (like in #123436). This will allow addressing issues like https://github.com/rust-lang/rust/pull/132394 once and for all on all targets.
r? ``@bjorn3``
|
|
|
|
what happens with provenance
|
|
Rollup of 12 pull requests
Successful merges:
- #134076 (Stabilize `std::io::ErrorKind::InvalidFilename`)
- #137504 (Move methods from Map to TyCtxt, part 4.)
- #138175 (Support rmeta inputs for --crate-type=bin --emit=obj)
- #138259 (Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs)
- #138280 (fix ICE in pretty-printing `global_asm!`)
- #138318 (Rustdoc: remove a bunch of `@ts-expect-error` from main.js)
- #138331 (Use `RUSTC_LINT_FLAGS` more)
- #138357 (merge `TypeChecker` and `TypeVerifier`)
- #138394 (remove unnecessary variant)
- #138403 (Delegation: one more ICE fix for `MethodCall` generation)
- #138407 (Delegation: reject C-variadics)
- #138409 (Use sa_sigaction instead of sa_union.__su_sigaction for AIX)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
In LLVM v9, lld has supported @response-file
LLVM v9 was released on 2019-09-19.
And the check was added back to 2018-03-14 (1.26.0) via 04442af18bf0.
It has been more than five years, and we ship our own lld regardlessly.
This should be happily removed.
See also:
* <https://github.com/llvm/llvm-project/commit/bb12396f9175eaf4586d8e5c76441977d97ccf93>
* <https://reviews.llvm.org/D63024>
|
|
Rollup of 7 pull requests
Successful merges:
- #137314 (change definitely unproductive cycles to error)
- #137701 (Convert `ShardedHashMap` to use `hashbrown::HashTable`)
- #138269 (uefi: fs: Implement FileType, FilePermissions and FileAttr)
- #138331 (Use `RUSTC_LINT_FLAGS` more)
- #138345 (Some autodiff cleanups)
- #138387 (intrinsics: remove unnecessary leading underscore from argument names)
- #138390 (fix incorrect tracing log)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=onur-ozkan,jieyouxu
Use `RUSTC_LINT_FLAGS` more
An alternative to the failed #138084.
Fixes #138106.
r? `````@jieyouxu`````
|
|
Move methods from Map to TyCtxt, part 4.
A follow-up to https://github.com/rust-lang/rust/pull/137350.
r? ```@Zalathar```
|
|
r=onur-ozkan,jieyouxu
Use `RUSTC_LINT_FLAGS` more
An alternative to the failed #138084.
Fixes #138106.
r? ````@jieyouxu````
|
|
All callers unwrap the result.
|
|
Remove `NtItem` and `NtStmt`
Another piece of #124141.
r? `@petrochenkov`
|
|
Today we're making LLVM do a bunch of extra work for every enum you match on, even trivial stuff like `Option<bool>`. Let's not.
|
|
Continuing the work from #137350.
Removes the unused methods: `expect_variant`, `expect_field`,
`expect_foreign_item`.
Every method gains a `hir_` prefix.
|
|
Prevent ICE in autodiff validation by emitting user-friendly errors
This PR moves `valid_ret_activity` and `valid_input_activity` checks to the macro expansion phase in compiler/rustc_builtin_macros/src/autodiff.rs, replacing the following internal compiler error (ICE):
```
error: internal compiler error:
compiler/rustc_codegen_ssa/src/codegen_attrs.rs:935:13:
Invalid input activity Dual for Reverse mode
```
with a more user-friendly message.
The issue specifically affected the test file `tests/ui/autodiff/autodiff_illegal.rs`, impacting the functions `f5` and `f6`.
The ICE can be reproduced by following [Enzyme's Rustbook](https://enzymead.github.io/rustbook/installation.html) installation guide.
Additionally, this PR adds tests for invalid return activity in `autodiff_illegal.rs`, which previously triggered an unnoticed ICE before these fixes.
r? ``@oli-obk``
|
|
Speed up target feature computation
The LLVM backend calls `LLVMRustHasFeature` twice for every feature. In short-running rustc invocations, this accounts for a surprising amount of work.
r? `@bjorn3`
|
|
|
|
It's no longer necessary now that `-Wunreachable_pub` is being passed.
|
|
Rollup of 8 pull requests
Successful merges:
- #136395 (Update to rand 0.9.0)
- #137279 (Make some invalid codegen attr errors structured/translatable)
- #137585 (Update documentation to consistently use 'm' in atomic synchronization example)
- #137926 (Add a test for `-znostart-stop-gc` usage with LLD)
- #138074 (Support `File::seek` for Hermit)
- #138238 (Fix dyn -> param suggestion in struct ICEs)
- #138270 (chore: Fix some comments)
- #138286 (triagebot.toml: Don't label `test/rustdoc-json` as A-rustdoc-search (…)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
also add test with `fastcall`, which on i686 uses a different mangling scheme
|
|
Revert <https://github.com/rust-lang/rust/pull/138084> to buy time to
consider options that avoids breaking downstream usages of cargo on
distributed `rustc-src` artifacts, where such cargo invocations fail due
to inability to inherit `lints` from workspace root manifest's
`workspace.lints` (this is only valid for the source rust-lang/rust
workspace, but not really the distributed `rustc-src` artifacts).
This breakage was reported in
<https://github.com/rust-lang/rust/issues/138304>.
This reverts commit 48caf81484b50dca5a5cebb614899a3df81ca898, reversing
changes made to c6662879b27f5161e95f39395e3c9513a7b97028.
|
|
Make some invalid codegen attr errors structured/translatable
|
|
|
|
Use workspace lints for crates in `compiler/`
This is nicer and hopefully less error prone than specifying lints via bootstrap.
r? ``@jieyouxu``
|
|
r=compiler-errors
compiler: Use `size_of` from the prelude instead of imported
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the prelude instead of importing or qualifying them. Apply this change across the compiler.
These functions were added to all preludes in Rust 1.80.
r? ``@compiler-errors``
|
|
Don't re-`assume` in `transmute`s that don't change niches
I noticed in nightly 2025-02-21 that `transmute` is emitting way more `assume`s than necessary for newtypes.
For example, the three transmutes in <https://rust.godbolt.org/z/fW1KaTc4o> emits
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
%0 = sub i32 %_1, 1
%1 = icmp ule i32 %0, -2
call void `@llvm.assume(i1` %1)
%2 = sub i32 %_1, 1
%3 = icmp ule i32 %2, -2
call void `@llvm.assume(i1` %3)
%4 = sub i32 %_1, 1
%5 = icmp ule i32 %4, -2
call void `@llvm.assume(i1` %5)
%6 = sub i32 %_1, 1
%7 = icmp ule i32 %6, -2
call void `@llvm.assume(i1` %7)
%8 = sub i32 %_1, 1
%9 = icmp ule i32 %8, -2
call void `@llvm.assume(i1` %9)
%10 = sub i32 %_1, 1
%11 = icmp ule i32 %10, -2
call void `@llvm.assume(i1` %11)
ret i32 %_1
}
```
But those are all just newtypes that don't change size or niches, so none of it's needed.
After this PR it's down to just
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
ret i32 %_1
}
```
because none of those `assume`s in the original actually did anything.
(Transmuting to something with a difference niche, though, still has the assumes -- the other tests continue to pass checking that.)
|
|
Use `trunc nuw`+`br` for 0/1 branches even in optimized builds
Rather than needing to use `switch` for them to include the `unreachable` arm.
|
|
|
|
self-contained linker: conservatively default to `-znostart-stop-gc` on x64 linux
To help stabilization, this PR disables an LLD optimization on x64 linux with respect to `--gc-sections` and encapsulation symbols: it will reduce the number of crates needing to opt-out of lld due to this bfd / lld difference. For example, all the people using [linkme](https://github.com/dtolnay/linkme), which [doesn't work with lld](https://github.com/dtolnay/linkme/issues/63) or on nightly, need to disable lld.
More information about all this, and the historical differences, can be found in:
- https://maskray.me/blog/2021-01-31-metadata-sections-comdat-and-shf-link-order
- https://lld.llvm.org/ELF/start-stop-gc
This optimization has [no visible impact](https://github.com/rust-lang/rust/pull/137685#issuecomment-2686116312) on our benchmarks, so we can use it by default and have a safer/more conservative starting point to remove friction during migration. We can them emit an FCW for the cases where lld detects reliance on encapsulation symbols without `-znostart-stop-gc`, and then revert back to lld's default after a while. No one compiling on nightly relies on this difference, obviously, so doing an FCW is not necessary until after lld is used on stable.
I've tested that this correctly links on `linkme` examples. I've also quickly tried to crate an rmake test but the setup with encapsulation symbols is annoying to reproduce: a few link section/name attributes is not enough, we also need to collect symbols between the encapsulation symbols, without referencing them in code, for `-znostart-stop-gc` to only impact this... It should of course be doable though, maybe ````@Kobzol```` will look into it if they have time.
r? ````@petrochenkov````
|
|
Add verbatim linker to AIXLinker
This adds support for the "verbatim" native link modifier on AIX, will successfully pass the `native-link-modifier-verbatim-linker test case`
|
|
|
|
(Except for `rustc_codegen_cranelift`.)
It's no longer necessary now that `unreachable_pub` is in the workspace
lints.
|
|
Use `std::mem::{size_of, size_of_val, align_of, align_of_val}` from the
prelude instead of importing or qualifying them.
These functions were added to all preludes in Rust 1.80.
|
