Fix another ICE in `point_at_expr_source_of_inferred_type`
Types coming from method probes must only be investigated *structurally*, since they often contain escaping infer variables from generalization and autoderef. We already have a hack in this PR that erases variables from types, so just use that.
Fixes#108664
The note attached to this error is pretty bad:
```
here the type of `primes` is inferred to be `[_]`
```
But that's unrelated to the PR.
---
Side-note: This is a pretty easy to trigger beta regression, so I've nominated it. Alternatively, I'm slightly inclined to remove this code altogether until it can be reformulated to be more accurate and less ICEy.
Remove legacy PM leftovers
This drops two leftovers of legacy PM usage:
* We don't need to initialize passes anymore.
* The pass listing was still using legacy PM passes. Replace it with the corresponding new PM listing.
Deny capturing late-bound non-lifetime param in anon const
Introduce a new AnonConstBoundary so we can detect when we capture a late-bound non-lifetime param with `non_lifetime_binders` enabled.
In the future, we could technically do something like introduce an early-bound parameter on the anon const, and stick the late-bound param in its substs (kinda like how we turn late-bound lifetimes in opaques into early-bound ones). But for now, just deny it so we don't ICE.
Fixes#108191
Rollup of 8 pull requests
Successful merges:
- #108022 (Support allocations with non-Box<[u8]> bytes)
- #108367 (Re-apply "switch to the macos-12-xl builder")
- #108557 (Point error span at Some constructor argument when trait resolution fails)
- #108573 (Explain compile-time vs run-time difference in env!() error message)
- #108584 (Put backtick content from rustdoc search errors into a `<code>` elements)
- #108624 (Make `ExprKind` the first field in `thir::Expr`)
- #108644 (Allow setting hashmap toml values in `./configure`)
- #108672 (Feed queries on impl side for RPITITs when using lower_impl_trait_in_trait_to_assoc_ty)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Feed queries on impl side for RPITITs when using lower_impl_trait_in_trait_to_assoc_ty
I've added a test for traits that were already working and what I think is probably the last bit of infrastructure work needed.
In following PRs I'm going to start adding things TDD style, tests and code that make it work.
r? `@compiler-errors`
Make `ExprKind` the first field in `thir::Expr`
This makes its `Debug` impl print it first which is useful, as it's the most important part when looking at an expr.
Explain compile-time vs run-time difference in env!() error message
This PR is clarifying error message of `env!()` based on this user question: https://users.rust-lang.org/t/environment-variable-out-dir-is-undefined/90067
It makes it clear that `env!()` is for env variables defined at compile-time. There's special-case help text for common Cargo build script variables.
I've also rearranged the code to avoid allocating error message on the happy path when the env var is defined.
Point error span at Some constructor argument when trait resolution fails
This is a follow up to #108254 and #106477 which extends error span refinement to handle a case which I mistakenly believed was handled in #106477. The goal is to refine the error span depicted below:
```rs
trait Fancy {}
impl <T> Fancy for Option<T> where T: Iterator {}
fn want_fancy<F>(f: F) where F: Fancy {}
fn example() {
want_fancy(Some(5));
// (BEFORE) ^^^^^^^ `{integer}` is not an iterator
// (AFTER) ^ `{integer}` is not an iterator
}
```
I had used a (slightly more complex) example as an illustrative example in #108254 , but hadn't actually turned it into a test, because I had (incorrectly) believed at the time it was covered by existing behavior. It turns out that `Some` is slightly "special" in that it resolves differently from the other `enum` constructors I had tried, and therefore this test was actually broken.
I've now updated the tests to include this example, and fixed the code to correctly resolve the `Some` constructor so that the span of the error is reduced.
Support allocations with non-Box<[u8]> bytes
This is prep work for allowing miri to support passing pointers to C code, which will require `Allocation`s to be correctly aligned. Currently, it just makes `Allocation` generic and plumbs the necessary changes through the right places.
The follow-up to this will be adding a type in the miri interpreter which correctly aligns the bytes, using that for the Miri engine, then allowing Miri to pass pointers into these allocations to C calls.
Based off of #100467, credit to ```@emarteca``` for the code
Revert stabilization of `#![feature(target_feature_11)]`
This reverts #99767 due to the presence of bugs #108645 and #108646.
cc `@joshtriplett`
cc tracking issue #69098
r? `@ghost`
Rollup of 5 pull requests
Successful merges:
- #108516 (Restrict `#[rustc_box]` to `Box::new` calls)
- #108575 (Erase **all** regions when probing for associated types on ambiguity in astconv)
- #108585 (Run compiler test suite in parallel on Fuchsia)
- #108606 (Add test case for mismatched open/close delims)
- #108609 (Highlight whole expression for E0599)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Highlight whole expression for E0599
Fixes#108603
This adds a secondary label to highlight the whole expression leading to the error. It also prevents empty labels being recognised as 'unexpected' by compiletest - otherwise, tests with NOTE annotations would pick up empty labels.
`@rustbot` label +A-diagnostics
Restrict `#[rustc_box]` to `Box::new` calls
Currently, `#[rustc_box]` can be applied to any call expression with a single argument. This PR only allows it to be applied to calls to `Box::new`
Add support for QNX Neutrino to standard library
This change:
- adds standard library support for QNX Neutrino (7.1).
- upgrades `libc` to version `0.2.139` which supports QNX Neutrino
`@gh-tr`
⚠️ Backtraces on QNX require https://github.com/rust-lang/backtrace-rs/pull/507 which is not yet merged! (But everything else works without these changes) ⚠️
Tested mainly with a x86_64 virtual machine (see qnx-nto.md) and partially with an aarch64 hardware (some tests fail due to constrained resources).
Merge two different equality specialization traits in `core`
Arrays and slices each had their own version of this, without a matching set of `impl`s.
Merge them into one (still-`pub(crate)`) `cmp::BytewiseEq` trait, so we can stop doing all these things twice.
And that means that the `[T]::eq` → `memcmp` specialization picks up a bunch of types where that previously only worked for arrays, so examples like <https://rust.godbolt.org/z/KjsG8MGGT> will use it now instead of emitting loops.
r? the8472
Rollup of 7 pull requests
Successful merges:
- #108143 (rustdoc: search by macro when query ends with `!`)
- #108394 (Make `x doc --open` work on every book)
- #108427 (Recover from for-else and while-else)
- #108462 (Fix `VecDeque::append` capacity overflow for ZSTs)
- #108568 (Make associated_item_def_ids for traits use an unstable option to also return associated types for RPITITs)
- #108604 (Add regression test for #107280)
- #108605 (Add regression test for #105821)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Recover from for-else and while-else
This recovers from attempts at writing for-else or while-else loops, which might help users coming from e.g. Python.
```rs
for _ in 0..0 {
// ...
} else {
// ...
}
```
Combined with trying to store it in a let binding, the current diagnostic can be a bit confusing. It mentions let-else and suggests wrapping the loop in parentheses, which the user probably doesn't want. let-else doesn't make sense for `for` and `while` loops, as they are of type `()` (which already is an irrefutable pattern and doesn't need let-else).
<details>
<summary>Current diagnostic</summary>
```rs
error: right curly brace `}` before `else` in a `let...else` statement not allowed
--> src/main.rs:4:5
|
4 | } else {
| ^
|
help: wrap the expression in parentheses
|
2 ~ let _x = (for _ in 0..0 {
3 |
4 ~ }) else {
|
```
</details>
Some questions:
- Can the wording for the error message be improved? Would "for...else loops are not allowed" fit better?
- Should we be more "conservative" in case we want to support this in the future (i.e. say "for...else loops are **currently** not allowed/supported")?
- Is there a better way than storing a `&'static str` for the loop type? It is used for substituting the placeholder in the locale file (since it can emit either `for...else` or `while...else`). Maybe there is an enum I could use that I couldn't find
Make `x doc --open` work on every book
Before this PR, the `--open` flag had to be configured explicitly for every book, and most of them didn't configure it, resulting in the flag silently failing in all but two books.
In this PR, the code to check for the `--open` flag is in the underlying `RustbookSrc` step rather than all the individual steps. This is done by passing the parent step as a field of `RustbookSrc`, so that we can check for the correct step in `maybe_open_in_browser`.
This was part of a larger change that in the end wasn't worth it. Still, I think it could be useful as-is.
