Make the `Query` enum a simple struct.
A lot of code in `rustc_query_system` is generic over it, only to encode an exceptional error case: query cycles.
The delayed computations are now done at cycle detection.
MIR-OPT: Pass to deduplicate blocks
This pass finds basic blocks that are completely equal,
and replaces all uses with just one of them.
```bash
$ RUSTC_LOG=rustc_mir::transform::deduplicate_blocks ./x.py build --stage 2 | grep "SUCCESS: Replacing: " > log
...
$ cat log | wc -l
23875
```
Fix sizes of repr(C) enums on hexagon
Enums on hexagon use a smallest size (but at least 1 byte) that fits all
the enumeration values. This is unlike many other ABIs where enums are
at least 32 bits.
Fixes#82100
Enums on hexagon use a smallest size (but at least 1 byte) that fits all
the enumeration values. This is unlike many other ABIs where enums are
at least 32 bits.
Rollup of 7 pull requests
Successful merges:
- #80595 (`impl PartialEq<Punct> for char`; symmetry for #78636)
- #81991 (Fix panic in 'remove semicolon' when types are not local)
- #82176 (fix MIR fn-ptr pretty-printing)
- #82244 (Keep consistency in example for Stdin StdinLock)
- #82260 (rustc: Show ``@path`` usage in stable)
- #82316 (Fix minor mistake in LTO docs.)
- #82332 (Don't generate src link on dummy spans)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
fix MIR fn-ptr pretty-printing
An uninitialized function pointer would get printed as `{{uninit fn()}` (notice the unbalanced parentheses), and a dangling fn ptr would ICE. This fixes both of that.
However, I have no idea how to add tests for this.
Also, I don't understand this MIR pretty-printing code. Somehow the print function `pretty_print_const_scalar` actually *returns* a transformed form of the const (but there is no doc comment explaining what is being returned); some match arms do `p!` while others do `self =`, and there's a wild mixture of `p!` and `write!`... all very mysterious and confusing.^^
r? ``@oli-obk``
name async generators something more human friendly in type error diagnostic
fixes#81457
Some details:
1. I opted to load the generator kind from the hir in TyCategory. I also use 1 impl in the hir for the descr
2. I named both the source of the future, in addition to the general type (`future`), not sure what is preferred
3. I am not sure what is required to make sure "generator" is not referred to anywhere. A brief `rg "\"generator\"" showed me that most diagnostics correctly distinguish from generators and async generator, but the `descr` of `DefKind` is pretty general (not sure how thats used)
4. should the descr impl of AsyncGeneratorKind use its display impl instead of copying the string?
Print -Ztime-passes (and misc stats/logs) on stderr, not stdout.
I've tried not to change anything that looked similar to `rustc --print`, where people might use automation, and/or any "bulk" prints, such as dumping an entire Graphviz (`dot`) graph on stdout.
The reason I want `-Ztime-passes` to be on stderr like debug logging is I can get a complete (and correctly interleaved) view just by looking at stderr, which is merely a convenience when running `rustc`/Cargo directly, but even more important when it's nested in a build script, as Cargo will split the build script output into stdout (named `output`) and `stderr`.
Ensure valid TraitRefs are created for GATs
This fixes `ProjectionTy::trait_ref` to use the correct substs. Places that need all of the substs have been updated to not use `trait_ref`.
r? ````@jackh726````
Implement RFC 2580: Pointer metadata & VTable
RFC: https://github.com/rust-lang/rfcs/pull/2580
~~Before merging this PR:~~
* [x] Wait for the end of the RFC’s [FCP to merge](https://github.com/rust-lang/rfcs/pull/2580#issuecomment-759145278).
* [x] Open a tracking issue: https://github.com/rust-lang/rust/issues/81513
* [x] Update `#[unstable]` attributes in the PR with the tracking issue number
----
This PR extends the language with a new lang item for the `Pointee` trait which is special-cased in trait resolution to implement it for all types. Even in generic contexts, parameters can be assumed to implement it without a corresponding bound.
For this I mostly imitated what the compiler was already doing for the `DiscriminantKind` trait. I’m very unfamiliar with compiler internals, so careful review is appreciated.
This PR also extends the standard library with new unstable APIs in `core::ptr` and `std::ptr`:
```rust
pub trait Pointee {
/// One of `()`, `usize`, or `DynMetadata<dyn SomeTrait>`
type Metadata: Copy + Send + Sync + Ord + Hash + Unpin;
}
pub trait Thin = Pointee<Metadata = ()>;
pub const fn metadata<T: ?Sized>(ptr: *const T) -> <T as Pointee>::Metadata {}
pub const fn from_raw_parts<T: ?Sized>(*const (), <T as Pointee>::Metadata) -> *const T {}
pub const fn from_raw_parts_mut<T: ?Sized>(*mut (),<T as Pointee>::Metadata) -> *mut T {}
impl<T: ?Sized> NonNull<T> {
pub const fn from_raw_parts(NonNull<()>, <T as Pointee>::Metadata) -> NonNull<T> {}
/// Convenience for `(ptr.cast(), metadata(ptr))`
pub const fn to_raw_parts(self) -> (NonNull<()>, <T as Pointee>::Metadata) {}
}
impl<T: ?Sized> *const T {
pub const fn to_raw_parts(self) -> (*const (), <T as Pointee>::Metadata) {}
}
impl<T: ?Sized> *mut T {
pub const fn to_raw_parts(self) -> (*mut (), <T as Pointee>::Metadata) {}
}
/// `<dyn SomeTrait as Pointee>::Metadata == DynMetadata<dyn SomeTrait>`
pub struct DynMetadata<Dyn: ?Sized> {
// Private pointer to vtable
}
impl<Dyn: ?Sized> DynMetadata<Dyn> {
pub fn size_of(self) -> usize {}
pub fn align_of(self) -> usize {}
pub fn layout(self) -> crate::alloc::Layout {}
}
unsafe impl<Dyn: ?Sized> Send for DynMetadata<Dyn> {}
unsafe impl<Dyn: ?Sized> Sync for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Debug for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Unpin for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Copy for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Clone for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Eq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialEq for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Ord for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> PartialOrd for DynMetadata<Dyn> {}
impl<Dyn: ?Sized> Hash for DynMetadata<Dyn> {}
```
API differences from the RFC, in areas noted as unresolved questions in the RFC:
* Module-level functions instead of associated `from_raw_parts` functions on `*const T` and `*mut T`, following the precedent of `null`, `slice_from_raw_parts`, etc.
* Added `to_raw_parts`
