While we don't use GCC for the LLVM build, we do use its libstdc++,
and there has been an std::optional ABI break in this version.
This makes the libLLVM.so for LLVM 16 ABI-incompatible with newer
libstdc++ versions, which we use on all other builders, and which
download-ci-llvm users are likely to use.
Do not propose to remove `async move` if variables are captured by ref
Fixes#10482
changelog: FP [`redundant_async_block`] Do not propose to remove `async move` if variables are captured by ref
a general type system cleanup
removes the helper functions `traits::fully_solve_X` as they add more complexity then they are worth. It's confusing which of these helpers should be used in which context.
changes the way we deal with overflow to always add depth in `evaluate_predicates_recursively`. It may make sense to actually fully transition to not have `recursion_depth` on obligations but that's probably a bit too much for this PR.
also removes some other small - and imo unnecessary - helpers.
r? types
a general type system cleanup
removes the helper functions `traits::fully_solve_X` as they add more complexity then they are worth. It's confusing which of these helpers should be used in which context.
changes the way we deal with overflow to always add depth in `evaluate_predicates_recursively`. It may make sense to actually fully transition to not have `recursion_depth` on obligations but that's probably a bit too much for this PR.
also removes some other small - and imo unnecessary - helpers.
r? types
Only clear written-to locals in ConstProp
This aims to revert the regression in https://github.com/rust-lang/rust/pull/108872
Clearing all locals at the end of each bb is very costly.
This PR goes back to the original implementation of recording which locals are modified.
Update cargo
11 commits in 4a3c588b1f0a8e2dc8dd8789dbf3b6a71b02ed49..15d090969743630bff549a1b068bcaa8174e5ee3
2023-03-14 14:05:36 +0000 to 2023-03-21 17:54:28 +0000
- docs(contrib): Move higher level resolver docs into doc comments (rust-lang/cargo#11870)
- docs(contrib): Pull impl info out of architecture (rust-lang/cargo#11869)
- Update curl-sys (rust-lang/cargo#11871)
- Poll loop fixes (rust-lang/cargo#11624)
- clippy: warn `disallowed_methods` for `std::env::var` and friends (rust-lang/cargo#11828)
- Add --ignore-rust-version flag to cargo install (rust-lang/cargo#11859)
- Handle case mismatches when looking up env vars in the Config snapshot (rust-lang/cargo#11824)
- align semantics of generated vcs ignore files (rust-lang/cargo#11855)
- Add more information to wait-for-publish (rust-lang/cargo#11713)
- docs: Address warnings (rust-lang/cargo#11856)
- docs(contrib): Create a file overview in the nightly docs (rust-lang/cargo#11850)
Really dogfood clippy
The dogfood success condition was inverted in `tests/dogfood.rs`:
```rust
assert!(!failed_packages.is_empty(), …);
```
while instead the `failed_packages` collection must be empty:
```rust
assert!(failed_packages.is_empty(), …);
```
And indeed, several clippy lint source files were not clean and had to be fixed in the process.
changelog: none
The dogfood success condition was inverted in `tests/dogfood.rs`:
```rust
assert!(!failed_packages.is_empty(), …);
```
while instead the `failed_packages` collection must be empty:
```rust
assert!(failed_packages.is_empty(), …);
```
And indeed, several clippy lint source files were not clean and had to be
fixed in the process.
Rollup of 8 pull requests
Successful merges:
- #96391 (Windows: make `Command` prefer non-verbatim paths)
- #108164 (Drop all messages in bounded channel when destroying the last receiver)
- #108729 (fix: modify the condition that `resolve_imports` stops)
- #109336 (Constrain const vars to error if const types are mismatched)
- #109403 (Avoid ICE of attempt to add with overflow in emitter)
- #109415 (Refactor `handle_missing_lit`.)
- #109441 (Only implement Fn* traits for extern "Rust" safe function pointers and items)
- #109446 (Do not suggest bounds restrictions for synthesized RPITITs)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Use uninit checking from rustc
rustc has proper heuristics for actually checking whether a type allows being left uninitialized (by asking CTFE). We can now use this for our helper instead of rolling our own bad version with false positives.
I added this in rustc in rust-lang/rust#108669
Fix#10407
changelog: [`uninit_vec`]: fix false positives
changelog: [`uninit_assumed_init`]: fix false positives
Make local query providers receive local keys
When a query is marked `separate_provide_extern`, we can map a query key to a "local" form of the key, e.g. `DefId` -> `LocalDefId`. This simplifies a ton of code which either has to assert or use something like `expect_local` to assert that the query key is local.
Do not suggest bounds restrictions for synthesized RPITITs
Before this PR we were getting ...
```
warning: the feature `async_fn_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> tests/ui/async-await/in-trait/missing-send-bound.rs:5:12
|
5 | #![feature(async_fn_in_trait)]
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error: future cannot be sent between threads safely
--> tests/ui/async-await/in-trait/missing-send-bound.rs:17:20
|
17 | assert_is_send(test::<T>());
| ^^^^^^^^^^^ future returned by `test` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `impl Future<Output = ()>`
note: future is not `Send` as it awaits another future which is not `Send`
--> tests/ui/async-await/in-trait/missing-send-bound.rs:13:5
|
13 | T::bar().await;
| ^^^^^^^^ await occurs here on type `impl Future<Output = ()>`, which is not `Send`
note: required by a bound in `assert_is_send`
--> tests/ui/async-await/in-trait/missing-send-bound.rs:21:27
|
21 | fn assert_is_send(_: impl Send) {}
| ^^^^ required by this bound in `assert_is_send`
help: consider further restricting the associated type
|
16 | fn test2<T: Foo>() where impl Future<Output = ()>: Send {
| ++++++++++++++++++++++++++++++++++++
error: aborting due to previous error; 1 warning emitted
```
and we want this output ...
```
warning: the feature `async_fn_in_trait` is incomplete and may not be safe to use and/or cause compiler crashes
--> $DIR/missing-send-bound.rs:5:12
|
LL | #![feature(async_fn_in_trait)]
| ^^^^^^^^^^^^^^^^^
|
= note: see issue #91611 <https://github.com/rust-lang/rust/issues/91611> for more information
= note: `#[warn(incomplete_features)]` on by default
error: future cannot be sent between threads safely
--> $DIR/missing-send-bound.rs:17:20
|
LL | assert_is_send(test::<T>());
| ^^^^^^^^^^^ future returned by `test` is not `Send`
|
= help: within `impl Future<Output = ()>`, the trait `Send` is not implemented for `impl Future<Output = ()>`
note: future is not `Send` as it awaits another future which is not `Send`
--> $DIR/missing-send-bound.rs:13:5
|
LL | T::bar().await;
| ^^^^^^^^ await occurs here on type `impl Future<Output = ()>`, which is not `Send`
note: required by a bound in `assert_is_send`
--> $DIR/missing-send-bound.rs:21:27
|
LL | fn assert_is_send(_: impl Send) {}
| ^^^^ required by this bound in `assert_is_send`
error: aborting due to previous error; 1 warning emitted
```
r? `@compiler-errors`
Only implement Fn* traits for extern "Rust" safe function pointers and items
Since calling the function via an `Fn` trait will assume `extern "Rust"` ABI and not do any safety checks, only safe `extern "Rust"` function can implement the `Fn` traits. This syncs the logic between the old solver and the new solver.
r? `@compiler-errors`
Constrain const vars to error if const types are mismatched
When equating two consts of different types, if either are const variables, constrain them to the correct const error kind.
This helps us avoid "successfully" matching a const against an impl signature but leaving unconstrained const vars, which will lead to incremental ICEs when we call const-eval queries during const projection.
Fixes#109296
The second commit in the stack fixes a regression in the first commit where we end up mentioning `[const error]` in an impl overlap error message. I think the error message changes for the better, but I could implement alternative strategies to avoid this without delaying the overlap error message...
r? `@BoxyUwU`
Drop all messages in bounded channel when destroying the last receiver
Fixes#107466 by splitting the `disconnect` function for receivers/transmitters and dropping all messages in `disconnect_receivers` like the unbounded channel does. Since all receivers must be dropped before the channel is, the messages will already be discarded at that point, so the `Drop` implementation for the channel can be removed.
``@rustbot`` label +T-libs +A-concurrency
Windows: make `Command` prefer non-verbatim paths
When spawning Commands, the path we use can end up being queried using `env::current_exe` (or the equivalent in other languages). Not all applications handle these paths properly therefore we should have a stronger preference for non-verbatim paths when spawning processes.
rustc has proper heuristics for actually checking whether a type allows
being left uninitialized (by asking CTFE). We can now use this for our
helper instead of rolling our own bad version with false positives.
When running `x.py test` on a downloaded source distribution (e.g.
https://static.rust-lang.org/dist/rustc-<version>-src.tar.gz), the
crates in the vendor directory contain a number of executable files that
cause the tidy test to fail with the following message:
tidy error: binary checked into source: <path>
I see 26 such errors with the 1.68.0 source distribution. A few of these
are .rs source files with incorrect executable permission, but most are
scripts that are correctly marked executable.
This option was added to LLVM in
https://reviews.llvm.org/D121750?id=416339. It makes `llvm_unreachable`
in builds without assertions compile to an `LLVM_BUILTIN_TRAP` instead
of `LLVM_BUILTIN_UNREACHABLE` (which causes undefined behavior and is
equivalent to `std::hint::unreachable_unchecked`).
Having compiler bugs triggering undefined behavior generally seems
undesirable and inconsistent with Rust's goals. There is a check in
`src/tools/tidy/src/style.rs` to reject code using `llvm_unreachable`.
But it is used a lot within LLVM itself.
For instance, this changes a failure I get compiling `libcore` for m68k
from a `SIGSEGV` to `SIGILL`, which seems better though it still doesn't
provide a useful message without switching to an LLVM build with asserts.
It may be best not to do this if it noticeably degrades compiler
performance, but worthwhile if it doesn't do so in any significant way. I
haven't looked into what benchmarks there are for Rustc. That should be
considered before merging.
Include executed tests in the build metrics (and use a custom test display impl)
The main goal of this PR is to include all tests executed in CI inside the build metrics JSON files. I need this for Ferrocene, and `@Mark-Simulacrum` expressed desire to have this as well to ensure all tests are executed at least once somewhere in CI.
Unfortunately implementing this required rewriting inside of bootstrap all of the code to render the test output to console. libtest supports outputting JSON instead of raw text, which we can indeed use to populate the build metrics. Doing that suppresses the console output though, and compared to rustc and Cargo the console output is not included as a JSON field.
Because of that, this PR had to reimplement both the "pretty" format (one test per line, with `rust.verbose-tests = true`), and the "terse" format (the wall of dots, with `rust.verbose-tests = false`). The current implementation should have the exact same output as libtest, except for the benchmark output. libtest's benchmark output is broken in the "terse" format, so since that's our default I slightly improved how it's rendered.
Also, to bring parity with libtest I had to introduce support for coloring output from bootstrap, using the same dependencies `annotate-snippets` uses. It's now possible to use `builder.color_for_stdout(Color::Red, "text")` and `builder.color_for_stderr(Color::Green, "text")` across all of bootstrap, automatically respecting the `--color` flag and whether the stream is a terminal or not.
I recommend reviewing the PR commit-by-commit.
r? `@Mark-Simulacrum`
