Disable dist tests on beta/stable
Should resolve the beta/stable part of https://github.com/rust-lang/rust/issues/113784. To be extra safe, I also made the read of `RUST_RELEASE_CHANNEL` optional, just in case it was missing.
r? `@Mark-Simulacrum`
[beta] backport
This PR backports:
- #113690: allow opaques to be defined by trait queries, again
- #113631: make MCP510 behavior opt-in to avoid conflicts between the CLI and target flavors
It also includes a bump of bootstrap to the released stable.
r? `@Mark-Simulacrum`
This likely will break on stable promotion because stable artifacts are named with stable version
rather than channel name; we'll want to figure out the right fix for that in a follow-up.
Don't call `query_normalize` when reporting similar impls
Firstly, It's sketchy to be using `query_normalize` at all during HIR typeck -- it's asking for an ICE 😅. Secondly, we're normalizing an impl trait ref that potentially has parameter types in `ty::ParamEnv::empty()`, which is kinda sketchy as well.
The only UI test change from removing this normalization is that we don't evaluate anonymous constants in impls, which end up giving us really ugly suggestions:
```
error[E0277]: the trait bound `[X; 35]: Default` is not satisfied
--> /home/gh-compiler-errors/test.rs:4:5
|
4 | <[X; 35] as Default>::default();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Default` is not implemented for `[X; 35]`
|
= help: the following other types implement trait `Default`:
&[T]
&mut [T]
[T; 32]
[T; core::::array::{impl#30}::{constant#0}]
[T; core::::array::{impl#31}::{constant#0}]
[T; core::::array::{impl#32}::{constant#0}]
[T; core::::array::{impl#33}::{constant#0}]
[T; core::::array::{impl#34}::{constant#0}]
and 27 others
```
So just fold the impls with a `BottomUpFolder` that calls `ty::Const::eval`. This doesn't work totally correctly with generic-const-exprs, but it's fine for stable code, and this is error reporting after all.
Rollup of 7 pull requests
Successful merges:
- #112931 (Enable zlib in LLVM on aarch64-apple-darwin)
- #113158 (tests: unset `RUSTC_LOG_COLOR` in a test)
- #113173 (CI: include workflow name in concurrency group)
- #113335 (Reveal opaques in new solver)
- #113390 (CGU formation tweaks)
- #113399 (Structurally normalize again for byte string lit pat checking)
- #113412 (Add basic types to SMIR)
r? `@ghost`
`@rustbot` modify labels: rollup
Structurally normalize again for byte string lit pat checking
We need to structurally normalize the pointee of a match scrutinee when trying to match byte string patterns -- we used[^1] to call `structurally_resolve_type`, which errors for type vars[^2], but lcnr added `try_structurally_resolve_type`[^3] in the mean time, which is the right thing to use here since it's totally opportunistic.
Fixes rust-lang/trait-system-refactor-initiative#38
[^1]: #112428
[^2]: #112993
[^3]: #113086
Reveal opaques in new solver
We were testing against the wrong reveal mode 😨
Also a couple of misc commits that I don't want to really put in separate prs
r? ``@lcnr``
CI: include workflow name in concurrency group
Currently, this won't change anything, because we only have one relevant workflow (`CI`), but for future proofing we should probably include the workflow name in the concurrency group.
Found by ``@klensy`` [here](https://github.com/rust-lang/rust/pull/113059#discussion_r1247213606).
tests: unset `RUSTC_LOG_COLOR` in a test
Setting `RUSTC_LOG_COLOR=always` is sometimes useful if tools that one pipes `RUSTC_LOG` into support coloured output, but it makes this test fail because it has a `.stderr` file with `WARN` log output.
Enable zlib in LLVM on aarch64-apple-darwin
Works on macOS 13.4, Xcode version 14.3.1.0.1.1683849156
This was disabled in #75500 on Apple Silicon Developer Transition Kit, but Apple appears to have fixed their zlib now
Rename `adjustment::PointerCast` and variants using it to `PointerCoercion`
It makes it sounds like the `ExprKind` and `Rvalue` are supposed to represent all pointer related casts, when in reality their just used to share a little enum variants. Make it clear there these are only coercions and that people who see this and think "why are so many pointer related casts not in these variants" aren't insane.
This enum was added in #59987. I'm not sure whether the variant sharing is actually worth it, but this at least makes it less confusing.
r? oli-obk
Rollup of 8 pull requests
Successful merges:
- #113413 (Add needs-triage to all new issues)
- #113426 (Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions)
- #113427 (Remove `variances_of` on RPITIT GATs, remove its one use-case)
- #113441 (miri: check that assignments do not self-overlap)
- #113453 (Remove unused from_method from rustc_on_unimplemented)
- #113456 (Avoid calling report_forbidden_specialization for RPITITs)
- #113466 (Update cargo)
- #113467 (Fix comment of `fn_can_unwind`)
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo
1 commits in 5b377cece0e0dd0af686cf53ce4637d5d85c2a10..45782b6b8afd1da042d45c2daeec9c0744f72cc7
2023-06-30 00:01:00 +0000 to 2023-07-05 16:54:51 +0000
- docs(ref): Provide guidance on version requirements (rust-lang/cargo#12323)
r? ``@ghost``
Remove unused from_method from rustc_on_unimplemented
Fixes#113439
`on_unimplemented_note` was calling `item_name` for RPITITs and that produced ICEs. I've added a regression test for that but also have removed `from_method` symbol entirely because it wasn't even used and by doing that the `item_name` call was also removed.
r? ``@compiler-errors``
Don't ICE in `resolve_bound_vars` when associated return-type bounds are in bad positions
I couldn't find a better way to avoid hitting this ICE, so let's just delay it.
The problem is that we really shouldn't even be *trying* to visit associated type bounds in `resolve_bound_vars` when they show up in impl headers, but we don't have enough context to do this.
Fixes#113423
DianQK