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.
Contract variables can be declared in the `requires` clause and
can be referenced both in `requires` and `ensures`, subject to usual
borrow checking rules.
This allows any setup common to both the `requires` and `ensures`
clauses to only be done once.
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
