Avoid silencing relevant follow-up errors
r? `@matthewjasper`
This PR only adds new errors to tests that are already failing and fixes one ICE.
Several tests were changed to not emit new errors. I believe all of them were faulty tests, and not explicitly testing for the code that had new errors.
A more efficient slice comparison implementation for T: !BytewiseEq
(This is a follow up PR on #113654)
This PR changes the implementation for `[T]` slice comparison when `T: !BytewiseEq`. The previous implementation using zip was not optimized properly by the compiler, which didn't leverage the fact that both length were equal. Performance improvements are for example 20% when testing that `[Some(0_u64); 4096].as_slice() == [Some(0_u64); 4096].as_slice()`.
`~const` trait and projection bounds do not imply their non-const counterparts
This PR removes the hack where we install a non-const trait and projection bound for every `const_trait` and `~const` projection bound we have in the AST. It ends up messing up more things than it fixes, see words below.
Fixes#119718
cc `@fmease` `@fee1-dead` `@oli-obk`
r? fee1-dead or one of y'all i don't care
---
My understanding is that this hack was added to support the following code:
```rust
pub trait Owo<X = <Self as Uwu>::T> {}
#[const_trait]
pub trait Uwu: Owo {}
```
Which is concretely lifted from in the `FromResidual` and `Try` traits. Since within the param-env of `trait Uwu`, we only know that `Self: ~const Uwu` and not `Self: Uwu`, the projection `<Self as Uwu>::T` is not satsifyable.
This causes problems such as #119718, since instantiations of `FnDef` types coming from `const fn` really do **only** implement one of `FnOnce` or `const FnOnce`!
---
In the long-term, I believe that such code should really look something more like:
```rust
#[const_trait]
pub trait Owo<X = <Self as ~const Uwu>::T> {}
#[const_trait]
pub trait Uwu: Owo {}
```
... and that we should introduce some sort of `<T as ~const Foo>::Bar` bound syntax, since due to the fact that `~const` bounds can be present in item bounds, e.g.
```rust
#[const_trait] trait Foo { type Bar: ~const Destruct; }
```
It's easy to see that `<T as Foo>::Bar` and `<T as ~const Foo>::Bar` (or `<T as const Foo>::Bar`) can be distinct types with distinct item bounds!
**Admission**: I know I've said before that I don't like `~const` projection syntax, I do at this point believe they're necessary to fully express bounds and types in a maybe-const world.
Making `User<T>` and `User<[T]>` `Send`
All `User` types in SGX point to owned memory in userspace. Special care is always needed when accessing this memory as it must be assumed that an attacker is always able to change its content. Therefore, we can also easily transfer this memory between thread boundaries.
cc: ``@mzohreva`` ``@vn971`` ``@belalH`` ``@jethrogb``
GNU/Hurd: unconditionally use inline stack probes
LLVM 11 has been unsupported since 45591408b1, so this doesn't need to be conditional on the LLVM version.
cc `@sthibaul`
rustdoc-search: reuse individual types in function signatures
Because `search.js` never mutates the function signature after loading it,
they can be safely and easily reused across functions.
This change doesn't change the format of the search index.
It only changes `search.js`.
Profiler output: https://notriddle.com/rustdoc-html-demo-9/fn-signature-opti2/index.html
<table><tr><th>benchmark<th>before<th>after
<tr><th>arti<td>
```
user: 002.228 s
sys: 000.315 s
wall: 001.663 s
child_RSS_high: 315668 KiB
group_mem_high: 285948 KiB
```
<td>
```
user: 001.805 s
sys: 000.231 s
wall: 001.398 s
child_RSS_high: 235864 KiB
group_mem_high: 203056 KiB
```
<tr><th>cortex-m<td>
```
user: 000.143 s
sys: 000.035 s
wall: 000.140 s
child_RSS_high: 59168 KiB
group_mem_high: 23000 KiB
```
<td>
```
user: 000.138 s
sys: 000.031 s
wall: 000.133 s
child_RSS_high: 58944 KiB
group_mem_high: 22220 KiB
```
<tr><th>sqlx<td>
```
user: 000.792 s
sys: 000.115 s
wall: 000.536 s
child_RSS_high: 156716 KiB
group_mem_high: 122948 KiB
```
<td>
```
user: 000.824 s
sys: 000.084 s
wall: 000.535 s
child_RSS_high: 136668 KiB
group_mem_high: 101792 KiB
```
<tr><th>stm32f4<td>
```
user: 006.665 s
sys: 003.533 s
wall: 008.624 s
child_RSS_high: 1037660 KiB
group_mem_high: 1022516 KiB
```
<td>
```
user: 005.997 s
sys: 003.185 s
wall: 007.987 s
child_RSS_high: 832068 KiB
group_mem_high: 810908 KiB
```
<tr><th>stm32f4xx-hal<td>
```
user: 000.317 s
sys: 000.051 s
wall: 000.203 s
child_RSS_high: 77060 KiB
group_mem_high: 41776 KiB
```
<td>
```
user: 000.287 s
sys: 000.046 s
wall: 000.180 s
child_RSS_high: 75216 KiB
group_mem_high: 39200 KiB
```
<tr><th>ripgrep<td>
```
user: 000.463 s
sys: 000.063 s
wall: 000.295 s
child_RSS_high: 101288 KiB
group_mem_high: 66364 KiB
```
<td>
```
user: 000.472 s
sys: 000.036 s
wall: 000.247 s
child_RSS_high: 82708 KiB
group_mem_high: 47056 KiB
```
</tr></table>
Remove `-Zdont-buffer-diagnostics`.
It was added in #54232. It seems like it was aimed at NLL development, which is well in the past. Also, it looks like `-Ztreat-err-as-bug` can be used to achieve the same effect. So it doesn't seem necessary.
r? ``@pnkfelix``
Merge dead bb pruning and unreachable bb deduplication.
Both routines share the same basic structure: iterate on all bbs to identify work, and then renumber bbs.
We can do both at once.
Rework and improve the unstable documentation of check-cfg
This PR rework and improve the unstable documentation of the check-cfg feature.
The goal is to have a simpler to understand documentation with examples that are more practical and less theoretical. As well as making the documentation more explicit about the whereabouts of the feature.
`@rustbot` label +T-compiler +F-check-cfg
unify query canonicalization mode
Exclude from canonicalization only the static lifetimes that appear in the param env because of #118965 . Any other occurrence can be canonicalized safely AFAICT.
r? `@lcnr`
Support async recursive calls (as long as they have indirection)
Before #101692, we stored coroutine witness types directly inside of the coroutine. That means that a coroutine could not contain itself (as a witness field) without creating a cycle in the type representation of the coroutine, which we detected with the `OpaqueTypeExpander`, which is used to detect cycles when expanding opaque types after that are inferred to contain themselves.
After `-Zdrop-tracking-mir` was stabilized, we no longer store these generator witness fields directly, but instead behind a def-id based query. That means there is no technical obstacle in the compiler preventing coroutines from containing themselves per se, other than the fact that for a coroutine to have a non-infinite layout, it must contain itself wrapped in a layer of allocation indirection (like a `Box`).
This means that it should be valid for this code to work:
```
async fn async_fibonacci(i: u32) -> u32 {
if i == 0 || i == 1 {
i
} else {
Box::pin(async_fibonacci(i - 1)).await
+ Box::pin(async_fibonacci(i - 2)).await
}
}
```
Whereas previously, you'd need to coerce the future to `Pin<Box<dyn Future<Output = ...>>` before `await`ing it, to prevent the async's desugared coroutine from containing itself across as await point.
This PR does two things:
1. Only report an error if an opaque expansion cycle is detected *not* through coroutine witness fields.
* Instead, if we find an opaque cycle through coroutine witness fields, we compute the layout of the coroutine. If that results in a cycle error, we report it as a recursive async fn.
4. Reworks the way we report layout errors having to do with coroutines, to make up for the diagnostic regressions introduced by (1.). We actually do even better now, pointing out the call sites of the recursion!
Adding alignment to the cases to test for specific error messages.
Adding alignment to the list of cases to test for specific error message. Covers `>`, `^` and `<`.
Pinging people who chimed in last time ( https://github.com/rust-lang/rust/pull/106805 ): ``@estebank`` , ``@compiler-errors`` and ``@Nilstrieb``
Fix broken build for ESP IDF due to #119026
`target_os = "espidf"` in `libc` lacks the `SOMAXCONN` constant, but that's probably irrelevant in this context, as `UnixListener` is not supported on ESP IDF - it being a single process "OS" only.
The PR just re-uses the `128` constant so that the code builds. Trying to use the listener on ESP IDF will fail with `ENOSYS`, which is fine.
*UPDATE* Might not fail with `ENOSYS` - need to test what error code would be returned, but that doesn`t change anything.
mir-opt and custom target fixes
From https://github.com/rust-lang/rust/issues/115642#issuecomment-1879589022
> > Could you please test the last two commits from https://github.com/onur-ozkan/rust/commits/panic-abort-mir-opt when you have the time? The first commit should resolve the error of using the nightly flag with a stable compiler, and the second one should resolve the custom target issue.
> I tested with the two commits and the errors of using nightly flag and custom target specs were not seen.
Testing was completed for the test suites like ui, run-pass-valgrind, coverage, mir-opt, codegen, assembly, incremental.
Fixes#115642
Use `assert_unsafe_precondition` for `char::from_u32_unchecked`
Use `assert_unsafe_precondition` in `char::from_u32_unchecked` so that it can be stabilized as `const`.
Add -Zuse-sync-unwind
Currently Rust uses async unwind by default, but async unwind will bring non-negligible size overhead. it would be nice to allow users to choose this.
In addition, async unwind currently prevents LLVM from generate compact unwind for MachO, if one wishes to generate compact unwind for MachO, then also needs this flag.
Rollup of 10 pull requests
Successful merges:
- #118903 (Improved support of collapse_debuginfo attribute for macros.)
- #119033 (coverage: `llvm-cov` expects column numbers to be bytes, not code points)
- #119598 (Fix a typo in core::ops::Deref's doc)
- #119660 (remove an unnecessary stderr-per-bitwidth)
- #119663 (tests: Normalize `\r\n` to `\n` in some run-make tests)
- #119681 (coverage: Anonymize line numbers in branch views)
- #119704 (Fix two variable binding issues in lint let_underscore)
- #119725 (Add helper for when we want to know if an item has a host param)
- #119738 (Add `riscv32imafc-esp-espidf` tier 3 target for the ESP32-P4.)
- #119740 (Remove crossbeam-channel)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove crossbeam-channel
The standard library's std::sync::mpsc basically is a crossbeam channel, and for the use case here will definitely suffice. This drops this dependency from librustc_driver.
Add helper for when we want to know if an item has a host param
r? ````@fmease```` since you're a good reviewer and no good deed goes unpunished
This helper will see far more usages as built-in traits get constified.
coverage: Anonymize line numbers in branch views
Extracted from #118305, as this is now the only part of that PR that needs to touch compiletest.
---
Coverage tests run the `llvm-cov` tool to generate a coverage report for a test program, and then compare the report against a known-good snapshot.
We use the `anonymize_coverage_line_numbers` function to replace line numbers in coverage reports with `LL`, so that they are less sensitive to lines being added or removed. This PR augments the existing code by making it also support the slightly different line number syntax used when reporting branch regions.
Currently the compiler never emits branch regions, so there is no way to write a coverage test that makes use of this new capability. Instead, I've added a unit test that checks against some sample reports taken from #118305. That unit test can be removed when some form of branch coverage support gets merged, and real branch coverage tests are added to the coverage test suite.
(I have also manually tested this change as part of my draft branch-coverage PR.)
tests: Normalize `\r\n` to `\n` in some run-make tests
The output is produced by printf from C code in these cases, and printf prints in text mode, which means `\n` will be printed as `\r\n` on Windows.
In --bless mode the new output with `\r\n` will replace expected output in `tests/run-make/raw-dylib-*\output.txt` files, which use \n, always resulting in dirty files in the repo.
remove an unnecessary stderr-per-bitwidth
also update some regexp, `a(lloc)?` would no longer match now that we have compiletest itself do alloc ID normalization.
r? ````@oli-obk````
coverage: `llvm-cov` expects column numbers to be bytes, not code points
Normally the compiler emits column numbers as a 1-based number of Unicode code points.
But when we embed coverage mappings for `-Cinstrument-coverage`, those mappings will ultimately be read by the `llvm-cov` tool. That tool assumes that column numbers are 1-based numbers of *bytes*, and relies on that assumption when slicing up source code to apply highlighting (in HTML reports, and in text-based reports with colour).
For the very common case of all-ASCII source code, bytes and code points are the same, so the difference isn't noticeable. But for code that contains non-ASCII characters, emitting column numbers as code points will result in `llvm-cov` slicing strings in the wrong places, producing mangled output or fatal errors.
(See https://github.com/taiki-e/cargo-llvm-cov/issues/275 as an example of what can go wrong.)
Improved support of collapse_debuginfo attribute for macros.
Added walk_chain_collapsed function to consider collapse_debuginfo attribute in parent macros in call chain.
Fixed collapse_debuginfo attribute processing for cranelift (there was if/else branches error swap).
cc https://github.com/rust-lang/rust/issues/100758
It was added in #54232. It seems like it was aimed at NLL development,
which is well in the past. Also, it looks like `-Ztreat-err-as-bug` can
be used to achieve the same effect. So it doesn't seem necessary.
