move `once` module out of `poison`
From https://github.com/rust-lang/rust/issues/134645#issuecomment-3324577500, since `Once` will not have a non-poisoning variant, we remove it from the `poison` module.
Additionally:
1. Renames `once::ExclusiveState` to `OnceExclusiveState` since it was a bit confusing reading just `ExclusiveState` where it is used.
2. Reorders a few module definitions and re-exports in `library/std/src/sync/mod.rs` for clarity.
Also, once this is merged, I think that we can begin the process of stabilizing [`sync_poison_mod`](https://github.com/rust-lang/rust/issues/134646)
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
Change the tidy license checker
This adds a bunch of licenses to the global list of allowed licenses that are at least as permissive as some other license in the list. In addition it adds another list for licenses that are allowed to be used by tools, but not by the runtime. All permissive licenses from the exception lists are added here. This makes it clearer what actual exceptions to our permissive licensing policy are and will hopefully make it a bit easier to review future changes to the list of licenses rather than just adding whatever license is necessary to the global list of allowed licenses or to the list of exceptions.
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
compiletest: Store the selected edition in `TestProps`
While working on a larger overhaul of directive processing, I ran into difficulty with the `has_edition` local variable.
Storing the selected edition in `TestProps` should make it easier to extract parts of directive processing into independent handler functions, because the `//@ edition` handler won't need access to additional mutable state outside of `TestProps`.
We still automatically add the edition to `compile_flags`, because there is too much existing compiletest code relying on that behaviour.
r? jieyouxu
compiletest: Move `AuxProps` out of `EarlyProps`
The primary purpose of `EarlyProps` is to discover revisions, so that we can create a separate test structure for each revision.
Revisions can (and do) have different auxiliaries, and up-to-date checking is already done per-revision, so it makes more sense to perform up-to-date checks based on the current revisions's auxiliaries only.
r? jieyouxu
enzyme/autodiff is compatible with download-ci=true
To my surprise autodiff just works out of the box with download-ci=true. Thanks to all the bootstrap people who over the past helped me to link properly against the sysroot LLVM, which seems to pay off here.
That also helps with enabling Rust in Enzyme CI, since CCache for some reason doesn't seem to cache LLVM correctly on their runners.
I verified that this works with
` ./configure --release-channel=nightly --enable-llvm-enzyme --enable-option-checking --disable-docs --enable-llvm-assertions --set llvm.download-ci-llvm=true`. However, shouldn't download-ci-llvm already be the default? Why do I still have to manually set it with this pr?
I tested it afterwards with
`./x.py test --stage 1 tests/codegen-llvm/autodiff`
r? bootstrap
closes https://github.com/rust-lang/rust/issues/147535
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.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#146167 (Deny-by-default never type lints)
- rust-lang/rust#147382 (unused_must_use: Don't warn on `Result<(), Uninhabited>` or `ControlFlow<Uninhabited, ()>`)
- rust-lang/rust#147821 (Do not GC the current active incremental session directory)
r? `@ghost`
`@rustbot` modify labels: rollup
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
The primary purpose of `EarlyProps` is to discover revisions, so that we can
create a separate test structure for each revision.
Revisions can (and do) have different auxiliaries, and up-to-date checking is
already done per-revision, so it makes more sense to perform up-to-date checks
based on the current revisions's auxiliaries only.
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.
compiletest: Include a file path in `DirectiveLine`
This avoids the need to laboriously pass a test/aux file path into dozens of directive parsing methods that already take a `DirectiveLine`.
r? jieyouxu
use minicore for more tests
r? `@jieyouxu`
Unfortunately this doesn't work for all tests; minicore sometimes fails to build with errors like
```
rustc-LLVM ERROR: ILP32E cannot be used with the D ISA extension
```
and
```
error: the target features paca, pacg must all be either enabled or disabled together
```
These errors are meant to be triggered in the tests, but not in minicore.
It seems like all ``@compile-flags`` are forwarded to minicore. Maybe we should exclude `-Ctarget-feature` from that? Or provide some way to set flags only for the current file, not minicore?
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.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#138679 (Issue-125323: ICE non-ADT in struct pattern when long time constant evaluation is in for loop)
- rust-lang/rust#146490 (Rehome 26 `tests/ui/issues/` tests to other subdirectories under `tests/ui/` [rust-lang/rust#5 of Batch rust-lang/rust#2])
- rust-lang/rust#147438 (Rename "non-inline module" to "file module" in proc macro diagnostics)
- rust-lang/rust#147724 (Fix ICE in pattern matching with generic const array length errors)
- rust-lang/rust#147813 (Warn on unused_attributes in uitests )
- rust-lang/rust#147816 (Do not error out for `download-rustc` if LTO is configured)
- rust-lang/rust#147845 (Add regression test for 134355)
r? `@ghost`
`@rustbot` modify labels: rollup
