Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#147577 (Improve error message for ambiguous numeric types in closure parameters)
- rust-lang/rust#147785 (fix incorrect line number when building trimmed multi-line suggestions)
- rust-lang/rust#147814 (btree: some cleanup with less unsafe)
- rust-lang/rust#147843 (Change the tidy license checker)
r? `@ghost`
`@rustbot` modify labels: rollup
fix incorrect line number when building trimmed multi-line suggestions
While fixing the issue https://github.com/rust-lang/rust-clippy/issues/15883 from `rust-clippy`, I tracked it down to a problem in `rustc` where line numbers were incorrect when building trimmed multi-line suggestions.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#147734 (Further tighten up relaxed bounds)
- rust-lang/rust#147888 (enzyme/autodiff is compatible with download-ci=true)
- rust-lang/rust#147898 (compiletest: Move `AuxProps` out of `EarlyProps`)
- rust-lang/rust#147903 (compiletest: Store the selected edition in `TestProps`)
r? `@ghost`
`@rustbot` modify labels: rollup
Further tighten up relaxed bounds
Follow-up to rust-lang/rust#142693, rust-lang/rust#135331 and rust-lang/rust#135841.
Fixesrust-lang/rust#143122.
* Reject relaxed bounds `?Trait` in the bounds of trait aliases.
Just like `trait Trait {}` doesn't mean `trait Trait: Sized {}` and we therefore reject `trait Trait: ?Sized {}`, `trait Trait =;` (sic!) doesn't mean `trait Trait = Sized;` (never did!) and as a logical consequence `trait Trait = ?Sized;` is meaningless and should be forbidden.
* Don't permit `?Sized` in more places (e.g., supertrait bounds, trait object types) if feature `more_maybe_bounds` is enabled.
That internal feature is only meant to allow the user to define & use *new* default traits (that have fewer rules to follow for now to ease experimentation).
* Unconditionally check that the `Trait` in `?Trait` is a default trait.
Previously, we would only perform this check in selected places which was very brittle and led to bugs slipping through.
* Slightly improve diagnostics.
Offload host2
r? `@oli-obk`
A follow-up to my previous gpu host PR. With this, I can (in theory) run a sufficiently simple Rust function on GPUs. I tested it on AMD, where the amdgcn tartget of rustc causes issues due to Addressspace castings, which might not be valid. If I (manually) fix them, I can run the generated IR on an AMD GPU. This should conceptually also work on NVIDIA or Intel. I updated the dev-guide acordingly: https://rustc-dev-guide.rust-lang.org/offload/usage.html
I am unhappy with the amount of standalone functions in my offload code, so in my second commit I bundled some of the code around two structs which are Rust versions of the LLVM/Offload structs which they represent. The structs themselves only have doc comments. Since I directly lower everything to llvm-ir I didn't saw a big value in modelling the struct member variables.
Do not GC the current active incremental session directory
when building a relatively large repo (https://github.com/oxidecomputer/omicron) on illumos under heavy CPU pressure, i saw some rustc invocations die like:
```
[..]/target/debug/incremental/<crate>-<hash>/<name>/dep-graph.part.bin: No such file or directory (os error 2)
```
a bit of debugging later and it seems that if the system is very slow, Unix-flavored `flock::Lock::new()` doesn't quite get the mutual exclusion `garbage_collect_session_directories` expects. before this patch i could reproduce this with the crate `nexus_db_queries` (in that repo) by pinning the full `cargo build` to one core and having a busy loop fighting on that same core. with this patch i cannot reproduce the issue. i took a look at how `flock::Lock` is used and i think this is the only problematic use, so i figure i'll propose this change particularly since i don't think file locking can be made.. good... for Unix in general.
------
In `setup_dep_graph`, we set up a session directory for the current incremental compilation session, load the dep graph, and then GC stale incremental compilation sessions for the crate. The freshly-created session directory ends up in this list of potentially-GC'd directories but in practice is not typically even considered for GC because the new directory is neither finalized nor `is_old_enough_to_be_collected`.
Unfortunately, `is_old_enough_to_be_collected` is a simple time check, and if `load_dep_graph` is slow enough it's possible for the freshly-created session directory to be tens of seconds old already. Then, old enough to be *eligible* to GC, we try to `flock::Lock` it as proof it is not owned by anyone else, and so is a stale working directory.
Because we hold the lock in the same process, the behavior of `flock::Lock` is dependent on platform-specifics about file locking APIs. `fcntl(F_SETLK)`-style locks used on non-Linux Unices do not provide mutual exclusion internal to a process. `fcntl_locking(2)` on Linux describes some relevant problems:
```
The record locks described above are associated with the process
(unlike the open file description locks described below). This
has some unfortunate consequences:
* If a process closes any file descriptor referring to a file,
then all of the process's locks on that file are released, [...]
* The threads in a process share locks. In other words, a
multithreaded program can't use record locking to ensure that
threads don't simultaneously access the same region of a file.
```
`fcntl`-locks will appear to succeed to lock the fresh incremental compilation directory, at which point we can remove it just before using it later for incremental compilation. Saving incremental compilation state later fails and takes rustc with it with an error like
```
[..]/target/debug/incremental/crate-<hash>/<name>/dep-graph.part.bin: No such file or directory (os error 2)
```
The release-lock-on-close behavior has uncomfortable consequences for the freshly-opened file description for the lock, but I think in practice isn't an issue. If we would close the file, we failed to acquire the lock, so someone else had the lock ad we're not releasing locks prematurely.
`flock(LOCK_EX)` doesn't seem to have these same issues, and because `flock::Lock::new` always opens a new file description when locking, I don't think Linux can have this issue.
From reading `LockFileEx` on MSDN I *think* Windows has locking semantics similar to `flock`, but I haven't tested there at all.
My conclusion is that there is no way to write a pure-POSIX `flock::Lock::new` which guarantees mutual exclusion across different file descriptions of the same file in the same process, and `flock::Lock::new` must not be used for that purpose. So, instead, avoid considering the current incremental session directory for GC in the first place. Our own `sess` is evidence we're alive and using it.
unused_must_use: Don't warn on `Result<(), Uninhabited>` or `ControlFlow<Uninhabited, ()>`
This suppresses warnings on things like `Result<(), !>`, which helps simplify code using the common pattern of having an `Error` associated type: code will only have to check the error if there is a possibility of error.
This will, for instance, help with future refactorings of `write!` in the standard library.
As this is a user-visible change to lint behavior, it'll require a lang FCP.
---
My proposal, here, is that we handle this simple case to make common patterns more usable. This does not rule out the possibility of adding more cases in the future, including general trait-based cases. However, I don't think we should make this common case wait on the more general cases. In particular, this solution does not close any doors on replacing this special case with a general case.
This would unblock some planned work in the standard library to make `write!` more usable for infallible cases (e.g. writing into a `Vec` or `String`).
Deny-by-default never type lints
In Rust [1.89.0](https://github.com/rust-lang/rust/milestone/133) we started emitting these lints in dependencies. I discussed the future steps with `@lcnr` and we think that before stabilizing the never type (and doing the breaking changes) we should deny the lints for ~4 releases.
This PR marks `never_type_fallback_flowing_into_unsafe` and `dependency_on_unit_never_type_fallback` lints as deny-by-default.
Tracking:
- https://github.com/rust-lang/rust/issues/35121
Related:
- https://github.com/rust-lang/rust/pull/141937
In `setup_dep_graph`, we set up a session directory for the current
incremental compilation session, load the dep graph, and then GC stale
incremental compilation sessions for the crate. The freshly-created
session directory ends up in this list of potentially-GC'd directories
but in practice is not typically even considered for GC because the new
directory is neither finalized nor `is_old_enough_to_be_collected`.
Unfortunately, `is_old_enough_to_be_collected` is a simple time check,
and if `load_dep_graph` is slow enough it's possible for the
freshly-created session directory to be tens of seconds old already.
Then, old enough to be *eligible* to GC, we try to `flock::Lock` it as
proof it is not owned by anyone else, and so is a stale working
directory.
Because we hold the lock in the same process, the behavior of
`flock::Lock` is dependent on platform-specifics about file locking
APIs. `fcntl(F_SETLK)`-style locks used on non-Linux Unices do not
provide mutual exclusion internal to a process. `fcntl_locking(2)` on
Linux describes some relevant problems:
```
The record locks described above are associated with the process
(unlike the open file description locks described below). This
has some unfortunate consequences:
* If a process closes any file descriptor referring to a file,
then all of the process's locks on that file are released, [...]
* The threads in a process share locks. In other words, a
multithreaded program can't use record locking to ensure that
threads don't simultaneously access the same region of a file.
```
`fcntl`-locks will appear to succeed to lock the fresh incremental
compilation directory, at which point we can remove it just before using
it later for incremental compilation. Saving incremental compilation
state later fails and takes rustc with it with an error like
```
[..]/target/debug/incremental/crate-<hash>/<name>/dep-graph.part.bin: No such file or directory (os error 2)
```
The release-lock-on-close behavior has uncomfortable consequences for
the freshly-opened file description for the lock, but I think in
practice isn't an issue. If we would close the file, we failed to
acquire the lock, so someone else had the lock ad we're not releasing
locks prematurely.
`flock(LOCK_EX)` doesn't seem to have these same issues, and because
`flock::Lock::new` always opens a new file description when locking, I
don't think Linux can have this issue.
From reading `LockFileEx` on MSDN I *think* Windows has locking
semantics similar to `flock`, but I haven't tested there at all.
My conclusion is that there is no way to write a pure-POSIX
`flock::Lock::new` which guarantees mutual exclusion across different
file descriptions of the same file in the same process, and
`flock::Lock::new` must not be used for that purpose. So, instead, avoid
considering the current incremental session directory for GC in the
first place. Our own `sess` is evidence we're alive and using it.
comments for deduce_param_attrs
Cc `@saethlin` since IIRC you experimented with codegen doing post-mono MIR ops? That seems to be in conflict with this pass.
Cc `@tmiasko`
r? `@scottmcm`
Refactor move analysis subpath representation
Follow up to rust-lang/rust#147055
This PR does two things:
1. Document/validate move analysis's assumptions about `Subslice` projections
2. Decouple move paths from `ProjectionElem`, using a new enum `MoveSubPath` instead
- This would be needed eventually when `ProjectionElem::Deref` is removed
I wanted to do even more abstraction, making `MovePathLookup::find` return an iterator to remove the special handling of subslices in borrowck, but that regressed diagnostics and just wasn't worth the complexity.
Issue-125323: ICE non-ADT in struct pattern when long time constant evaluation is in for loop
This PR fixes#125323
## Context
According to the issue, the ICE happens since #121206.
In the PR, some error methods were reorganized. For example, has_errors() was renamed to has_errors_exclude_lint_errors(). However, some codes which used the original has_errors() were not switched to has_errors_exclude_lint_errors(). I finally found that report_error() in writeback.rs causes this ICE. Currently the method uses tainted_by_errors() to get guar (ErrorGuaranteed), but originally it used dcx().has_errors() but it wasn't changed to has_errors_exclude_lint_errors() when changes in #121206 were merged. I don't think I fully understand how an error is propagated, but I suppose that the error from long time constant evaluation is unexpectedly propagated other parts (in this ICE, for loop), then cause the non-ADT in struct pattern ICE.
## Change
- Fix report_error() in writeback.rs: use dcx().has_errors_exclude_lint_errors() instead of tainted_by_errors() to prevent error propagation from constant evaluation.
- Add test for the ICE
- Modify some tests to align the change: Due to this fix, E0282 error happens (or not happen anymore) in some tests.
## NOTE
The 4th commit aims to revert the fix in #123516 because I confirmed that the ICE solved by the PR doesn't happen if I modify report_error(). I think the root cause of that ICE is the same as #125323 . But I can discard this commit since we can fix#125323 without it.
Result/Option layout guarantee clarifications
- It seems worth spelling out that this guarantee allows particular transmutes.
- After the `Result` section was written, the `Option` section it referenced gained *more* guarantees, saying that `None` is represented as `[0u8; N]`. Those guarantees were not meant to apply to `Result`. Make the `Result` section more self-contained to make this more clear.
- "Type has no fields" is unclear since there is no general definition of what the fields of some arbitrary type are. Replace that by a more accurate description of the actual check implemented [here](e379c77586/compiler/rustc_lint/src/types.rs (L828-L838)).
r? `@traviscross`
deduced_param_attrs: check Freeze on monomorphic types.
`deduced_param_attrs` currently checks `Freeze` bound on polymorphic MIR. This pessimizes the deduction, as generic types are not `Freeze` by default.
This moves the check to the ABI adjustment.
Simplify trivial constants in SimplifyConstCondition
After `InstSimplify-after-simplifycfg` with `-Zub_checks=false`, there are many of the following patterns.
```
_13 = const false;
assume(copy _13);
_12 = unreachable_unchecked::precondition_check() -> [return: bb1, unwind unreachable];
```
Simplifying them to unreachable early should make CFG simpler.
Rollup of 8 pull requests
Successful merges:
- rust-lang/rust#140153 (Implement `Debug` for `EncodeWide`)
- rust-lang/rust#145724 (the `#[track_caller]` shim should not inherit `#[no_mangle]`)
- rust-lang/rust#147258 (iter repeat: panic on last)
- rust-lang/rust#147454 (Fix backtraces with `-C panic=abort` on qnx; emit unwind tables by default)
- rust-lang/rust#147468 (Implement fs api set_times and set_times_nofollow)
- rust-lang/rust#147764 (Undo CopyForDeref assertion in const qualif)
- rust-lang/rust#147805 (use module_child index as disambiguator for external items)
- rust-lang/rust#147824 (docs: update Motor OS target docs)
r? `@ghost`
`@rustbot` modify labels: rollup
use module_child index as disambiguator for external items
When defining the items of an external module, if that item is an underscore we use it's index as the disambiguator. This is needed for parallel import resolution, which is being worked on in rust-lang/rust#145108.
r? `@petrochenkov`
Fix backtraces with `-C panic=abort` on qnx; emit unwind tables by default
While syncing https://github.com/rust-lang/rust/pull/143613 into Ferrocene as part of https://github.com/ferrocene/ferrocene/pull/1803, we noted a failure on our QNX targets:
```
---- [ui] tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs stdout ----
error: test did not exit with success! code=Some(134) so test would pass with `run-crash`
status: exit status: 134
command: RUSTC="/home/ci/project/build/x86_64-unknown-linux-gnu/stage2/bin/rustc" RUST_TEST_THREADS="1" "/home/ci/project/build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-client" "run" "0" "/home/ci/project/build/x86_64-unknown-linux-gnu/test/ui/panics/panic-abort-backtrace-without-debuginfo/a"
--- stdout -------------------------------
uploaded "/home/ci/project/build/x86_64-unknown-linux-gnu/test/ui/panics/panic-abort-backtrace-without-debuginfo/a", waiting for result
died due to signal 6
------------------------------------------
--- stderr -------------------------------
thread 'main' (1) panicked at /home/ci/project/tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs:39:9:
ERROR: no `this_function_must_be_in_the_backtrace` in stderr! actual stderr:
thread 'main' (1) panicked at /home/ci/project/tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs:27:5:
generate panic backtrace
stack backtrace:
0: 0x4e66a53643 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h55e010263b1e3169
1: 0x4e66a68cd2 - core::fmt::write::h0d6e2e8752abc333
2: 0x4e66a16919 - std::io::Write::write_fmt::h71c4c024d832b384
3: 0x4e66a1f8e2 - std::sys::backtrace::BacktraceLock::print::hdd80dfdf90bb7100
4: 0x4e66a221e0 - std::panicking::default_hook::{{closure}}::h77758f25a686500f
5: 0x4e66a21f69 - std::panicking::default_hook::ha63f7d476af6c267
6: 0x4e66a22999 - std::panicking::panic_with_hook::h3a36a8a0f0dd8ccd
7: 0x4e66a21cac - std::panicking::begin_panic::{{closure}}::h570dedb92e232392
8: 0x4e66a1fa69 - std::sys::backtrace::__rust_end_short_backtrace::h5366eec354f92733
9: 0x4e669f9589 - std::panicking::begin_panic::h04a4bd4c33dd4056
10: 0x4e66a00aca - panic_abort_backtrace_without_debuginfo::and_this_function_too::h5b034b94cbe9c3d3
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
------------------------------------------
---- [ui] tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs stdout end ----
failures:
[ui] tests/ui/panics/panic-abort-backtrace-without-debuginfo.rs
test result: FAILED. 19958 passed; 1 failed; 328 ignored; 0 measured; 0 filtered out; finished in 1827.71s
Some tests failed in compiletest suite=ui mode=ui host=x86_64-unknown-linux-gnu target=x86_64-pc-nto-qnx710
Build completed unsuccessfully in 0:43:28
Exited with code exit status 1
```
This patch applies the same fix as the one found in https://github.com/rust-lang/rust/pull/143613 of adding the `default_uwtable: true` to the target.
I've run it locally, when https://github.com/ferrocene/ferrocene/pull/1803 merges we'll know it has passed within our CI, which is about a close an analog as I can offer to Rust.
the `#[track_caller]` shim should not inherit `#[no_mangle]`
fixes https://github.com/rust-lang/rust/issues/143162
builds on https://github.com/rust-lang/rust/pull/143293 which introduced a mechanism to strip attributes from shims.
cc `@Jules-Bertholet` `@workingjubilee` `@bjorn3`
---
Summary:
This PR fixes an interaction between `#[track_caller]`, `#[no_mangle]`, and casting to a function pointer.
A function annotated with `#[track_caller]` internally has a hidden extra argument for the panic location. The `#[track_caller]` attribute is only allowed on `extern "Rust"` functions. When a function is annotated with both `#[no_mangle]` and `#[track_caller]`, the exported symbol has the signature that includes the extra panic location argument. This works on stable rust today:
```rust
extern "Rust" {
#[track_caller]
fn rust_track_caller_ffi_test_tracked() -> &'static Location<'static>;
}
mod provides {
use std::panic::Location;
#[track_caller] // UB if we did not have this!
#[no_mangle]
fn rust_track_caller_ffi_test_tracked() -> &'static Location<'static> {
Location::caller()
}
}
```
When a `#[track_caller]` function is converted to a function pointer, a shim is added to drop the additional argument. So this is a valid program:
```rust
#[track_caller]
fn foo() {}
fn main() {
let f = foo as fn();
f();
}
```
The issue arises when `foo` is additionally annotated with `#[no_mangle]`, the generated shim currently inherits this attribute, also exporting a symbol named `foo`, but one without the hidden panic location argument. The linker rightfully complains about a duplicate symbol.
The solution of this PR is to have the generated shim drop the `#[no_mangle]` attribute.
mismatched_lifetime_syntax lint refactors and optimizations
I found several opportunities to return early so I'm hoping those will have a perf improvement. Otherwise, it's various refactors for simplicity.
Limit impl_trait_header query to only trait impls
Changes `impl_trait_header` to panic on inherent impls intstead of returning None. A few downstream functions are split into option and non-option returning functions. This gets rid of a lot of unwraps where we know we have a trait impl, while there are still some cases where the Option is helpful.
Summary of changes to tcx methods:
* `impl_is_of_trait` (new)
* `impl_trait_header` -> `impl_trait_header`/`impl_opt_trait_header`
* `impl_trait_ref` -> `impl_trait_ref`/`impl_opt_trait_ref`
* `trait_id_of_impl` -> `impl_trait_id`/`impl_opt_trait_id`
Pre-compute MIR CFG caches for borrowck and other analyses
I was puzzled that https://github.com/rust-lang/rust/pull/142390 introduces additional computations of CFG traversals: borrowck computes them, right?
It turns out that borrowck clones the MIR body, so doesn't share its cache with other analyses.
This PR:
- forces the computation of all caches in `mir_promoted` query;
- modifies region renumbering to avoid dropping that cache.
error from const eval lint causes ICE at check_pat in late_lint, because the function expects the typeck result isn't tainted by error but it is.
To avoid the ICE, check_pat returns earlier if the typeck_result is tainted.
check_mod_deathness also has an issue from the same reason. visit_body for making live symbols expects the typeck result has no error.
So this commit adds a check in visit_nested_body to avoid the ICE.
However, if visit_nested_body just returns without doing anything, all codes with the error are marked as dead, because live_symbols is empty.
To avoid this side effect, visit_nested_body and other visit_* functions in MarkSymbolVistior should return appropriate error.
If a function returns ControlFlow::Break, live_symbols_and_ignore_derived_traits returns earlier with error,
then check_mod_deathness, the caller of the function returns earlier without pushing everything into dead_codes.
When -Z autodiff=Enable is used, the compiler automatically enables
fat-lto for all crates. However, proc-macro crates cannot use fat-lto
without the -Zdylib-lto flag, causing compilation errors.
This commit modifies the lto() method in Session to exclude proc-macro
crates from fat-lto when autodiff is enabled, while preserving the
existing behavior for all other crate types.
The fix ensures that:
- Non-proc-macro crates still get fat-lto when autodiff is enabled
- Proc-macro crates are excluded from fat-lto when autodiff is enabled
- Existing autodiff functionality remains unchanged for regular crates
Signed-off-by: Osama Abdelkader <osama.abdelkader@gmail.com>
