Add `-Ztrait-solver=next-coherence`
Flag that conditionally uses the trait solver *only* during coherence, for more testing and/or eventual partial-migration onto the trait solver (in the medium- to long-term).
* This still uses the selection context in some of the coherence methods I think, so it's not "complete". Putting this up for review and/or for further work in-tree.
* I probably need to spend a bit more time making sure that we don't sneakily create any other infcx's during coherence that also need the new solver enabled.
r? `@lcnr`
Fall back to bidirectional normalizes-to if no subst-relate candidate in alias-relate goal
Sometimes we get into the case where the choice of normalizes-to branch in alias-relate are both valid, but we cannot make a choice of which one to take because they are different -- either returning equivalent but permuted region constraints, or equivalent opaque type definitions but differing modulo normalization.
In this case, we can make progress by considering a fourth candidate where we compute both normalizes-to branches together and canonicalize that as a response. This is essentially the AND intersection of both normalizes-to branches. In an ideal world, we'd be returning something more like the OR intersection of both branches, but we have no way of representing that either for regions (maybe eventually) or opaques (don't see that happening ever).
This is incomplete, so like the subst-relate fallback it's only considered outside of coherence. But it doesn't seem like a dramatic strengthening of inference or anything, and is useful for helping opaque type inference succeed when the hidden type is a projection.
## Example
Consider the goal - `AliasRelate(Tait, <[i32; 32] as IntoIterator>::IntoIter)`.
We have three ways of currently solving this goal:
1. SubstRelate - fails because we can't directly equate the substs of different alias kinds.
2. NormalizesToRhs - `Tait normalizes-to <[i32; 32] as IntoIterator>::IntoIter`
* Ends up infering opaque definition - `Tait := <[i32; 32] as IntoIterator>::IntoIter`
3. NormalizesToLhs - `<[i32; 32] as IntoIterator>::IntoIter normalizes-to Tait`
* Find impl candidate, substitute the associated type - `std::array::IntoIter<i32, 32>`
* Equate `std::array::IntoIter<i32, 32>` and `Tait`
* Ends up infering opaque definition - `Tait := std::array::IntoIter<i32, 32>`
The problem here is that 2 and 3 are essentially both valid, since we have aliases that normalize on both sides, but due to lazy norm, they end up inferring different opaque type definitions that are only equal *after* normalizing them further.
---
r? `@lcnr`
Emit an error when return-type-notation is used with type/const params
These are not intended to be supported initially, even though the compiler supports them internally...
Add `task::Waker::noop`
I have found myself reimplementing this function many times when I need a `Context` but don't have a runtime or `futures` to hand.
Prior art: [`futures::task::noop_waker`](https://docs.rs/futures/0.3/futures/task/fn.noop_waker.html) and [`futures::task::noop_waker_ref`](https://docs.rs/futures/0.3/futures/task/fn.noop_waker_ref.html)
Tracking issue: https://github.com/rust-lang/rust/issues/98286
Unresolved questions:
1. Should we also add `RawWaker::noop()`? (I don't think so, I can't think of a use case for it)
2. Should we also add `Context::noop()`? Depending on the future direction `Context` goes a "noop context" might not even make sense in future.
3. Should it be an associated constant instead? That would allow for `let cx = &mut Context::from_waker(&Waker::NOOP);` to work on one line which is pretty nice. I don't really know what the guideline is here.
r? rust-lang/libs-api `@rustbot` label +T-libs-api -T-libs
Improved std support for ps vita target
Fixed a couple of things in std support for ps vita via Vita SDK newlib oss implementation:
- Added missing hardware features to target spec
- Compile in thumb by default (newlib is also compiled in thumb)
- Fixed fs calls. Vita newlib has a not-very-posix dirent. Also vita does not expose inodes, it's stubbed as 0 in stat, and I'm stubbing it here for dirent (because vita newlibs's dirent doesn't even have that field)
- Enabled signal handlers for panic unwinding
- Dropped static link requirement from the platform support md. Also, rearranged sections to better stick with the template.
This loop is doing two different things. For inlined items, it's adding
them to the CGU. For all items, it's recording them in
`mono_item_placements`.
This commit splits it into two separate loops. This avoids putting root
mono items into `reachable`, and removes the low-value check that
`roots` doesn't contain inlined mono items.
Currently it sorts by symbol name, which is a mangled name like
`_ZN1a4main17hb29587cdb6db5f42E`, which leads to non-obvious orderings.
This commit changes it to use the existing
`items_in_deterministic_order`, which iterates in source code order.
Run tests on PGO/LTO/BOLT optimized dist artifacts
This PR adds baisc tests for the optimized dist builds on x64 Linux and Windows. A subset of the test suite is run, so it's not perfect, but it's better than the status quo (which is basically no testing at all, apart from the perf bot on Linux).
r? `@ghost`
- remove useless commands from test Makefile
- do not unnecessarily remove metadata temporary files because they'll be managed by MaybeTempDir
- remove unused FailedRemove error introduced by this PR
If `-o -` or `--emit KIND=-` is provided, output will be written
to stdout instead. Binary output (`obj`, `llvm-bc`, `link` and
`metadata`) being written this way will result in an error unless
stdout is not a tty. Multiple output types going to stdout will
trigger an error too, as they will all be mixded together.
Remove default visitor impl in region constraint generation
I wanted to group it together with other possibly minor borrowck cleanups but that's all I have right now so I rather put it up than forget about it before doing something else.
r? `@compiler-errors`
Add new Tier-3 targets: `loongarch64-unknown-none*`
This PR adds new Tier-3 targets `loongarch64-unknown-none*` that are introduced by MCP rust-lang/compiler-team#628
Sometimes, especially with MIR validation, the backtraces from delayed
bugs are noise and make it harder to look at them. Respect the
environment variable and don't print it when the user doesn't want it.
Rollup of 7 pull requests
Successful merges:
- #111058 (Correct fortanix LVI test print function)
- #111369 (Added custom risc32-imac for esp-espidf target)
- #111962 (Make GDB Python Pretty Printers loadable after spawning GDB, avoiding required `rust-gdb`)
- #112019 (Don't suggest changing `&self` and `&mut self` in function signature to be mutable when taking `&mut self` in closure)
- #112199 (Fix suggestion for matching struct with `..` on both ends)
- #112220 (Cleanup some `EarlyBinder::skip_binder()` -> `EarlyBinder::subst_identity()`)
- #112325 (diagnostics: do not suggest type name tweaks on type-inferred closure args)
r? `@ghost`
`@rustbot` modify labels: rollup
Cleanup some `EarlyBinder::skip_binder()` -> `EarlyBinder::subst_identity()`
fix some incorrect `skip_binder()`'s as identified in https://github.com/rust-lang/rust/pull/112006#pullrequestreview-1448369203
r? ``@compiler-errors`` ``@lcnr`` ``@jackh726``
(hope it's alright to just tag everyone who commented 😅)
Fix suggestion for matching struct with `..` on both ends
### Before This PR
```
error: expected `}`, found `,`
--> src\main.rs:8:17
|
8 | Foo { .., x, .. } => (),
| --^
| | |
| | expected `}`
| `..` must be at the end and cannot have a trailing comma
|
help: move the `..` to the end of the field list
|
8 - Foo { .., x, .. } => (),
8 + Foo { .., x, , .. } => (),
|
```
### After This PR
```
error: expected `}`, found `,`
--> tests/ui/parser/issue-112188.rs:11:17
|
11 | let Foo { .., x, .. } = f; //~ ERROR expected `}`, found `,`
| --^-
| | |
| | expected `}`
| `..` must be at the end and cannot have a trailing comma
| help: remove the starting `..`
```
Fixes#112188.
Don't suggest changing `&self` and `&mut self` in function signature to be mutable when taking `&mut self` in closure
Current suggestion for when taking a mutable reference to `self` in a closure (as an upvar) will produce a machine-applicable suggestion to change the `self` in the function signature to `mut self`, but does not account for the specialness of implicit self in that it can already have `&` and `&mut` (see #111554). This causes the function signature to become `test(&mut mut self)` which does not seem desirable.
```
error[E0596]: cannot borrow `self` as mutable, as it is not declared as mutable
--> src/sound_player.rs:870:11
|
869 | pub fn test(&mut self) {
| ---- help: consider changing this to be mutable: `mut self`
870 | || test2(&mut self);
| ^^^^^^^^^ cannot borrow as mutable
```
This PR suppresses the "changing this to be mutable" suggestion if the implicit self is either `ImplicitSelfKind::ImmRef` or `ImplicitSelfKind::MutRef`.
Fixes#111554.
Make GDB Python Pretty Printers loadable after spawning GDB, avoiding required `rust-gdb`
Fixes#111961
Makes the Python pretty printer library source'able from within GDB after spawn, making the wrapper script `rust-gdb` become not the required approach to use the pretty printer library.
Allows for integration into GUI:s that wrap GDB extremely easy. The previous design complicates this feature.
Added custom risc32-imac for esp-espidf target
ESP32-C6 and the upcoming ESP32-P4 are the first Espressif chips that support the "A" (atomic) extension of the RISCV specification.
As such, they do not work with the existing `riscv32imc-esp-espidf` target and instead need a new one (in this PR) called `riscv32imac-esp-espidf`.
