CI: build CMake 3.20 to support LLVM 17
LLVM 17 will require CMake at least 3.20, so we have to go back to building our own CMake on the Linux x64 dist builder.
r? `@nikic`
Support reading uncompressed proc macro metadata
rust-lang/rust#113695 makes the dylib metadata uncompressed for perf reasons. This commit allows reading both the current compressed and future uncompressed dylib metadata.
rust-lang/rust#113695 makes the dylib metadata uncompressed for perf
reasons. This commit allows reading both the current compressed and
future uncompressed dylib metadata.
Handle TyAlias in projected_ty
First of all I still have no idea how MIR works but #15143 has been an issue that constantly made RA crash so I have been looking for a way to make RA stop panicking. I have zero claims that what I want to merge has any sense or is correct 😄 but there isn't any more panicking. Even if it is wrong may this be at least a step towards resolving this issue.
As is customary this PR fixes#15143
Eliminate ZST allocations in `Box` and `Vec`
This PR fixes 2 issues with `Box` and `RawVec` related to ZST allocations. Specifically, the `Allocator` trait requires that:
- If you allocate a zero-sized layout then you must later deallocate it, otherwise the allocator may leak memory.
- You cannot pass a ZST pointer to the allocator that you haven't previously allocated.
These restrictions exist because an allocator implementation is allowed to allocate non-zero amounts of memory for a zero-sized allocation. For example, `malloc` in libc does this.
Currently, ZSTs are handled differently in `Box` and `Vec`:
- `Vec` never allocates when `T` is a ZST or if the vector capacity is 0.
- `Box` just blindly passes everything on to the allocator, including ZSTs.
This causes problems due to the free conversions between `Box<[T]>` and `Vec<T>`, specifically that ZST allocations could get leaked or a dangling pointer could be passed to `deallocate`.
This PR fixes this by changing `Box` to not allocate for zero-sized values and slices. It also fixes a bug in `RawVec::shrink` where shrinking to a size of zero did not actually free the backing memory.
Default to stable toolchain for metrics workflow
Metrics CI is failing because of a function that was stabilized in 1.70. So for some reason, it's trying to use an older toolchain i seems though I don't understand why it randomly started complaining about that.
Make fields of mir::Terminator public
When trying to use the RA crate, I am unable to access the fields in `hir_def::mir::Terminator`.
I don't see any reason, why these should be private, especially as the fields of `hir_def::mir::Statement` are `pub`.
I am not sure if the fields in `hir_def::mir::SwitchTargets` should be made `pub` too, but at least they are read-accessible via some public methods..
Sorry if I missed something, this is my first PR.
Mark test for MIR execution limit as slow test
The test for MIR execution limit accounts for ~2/3 of total execution time of non-slow hir-ty tests. It significantly slows down edit-and-run-test type of workflow. Can we mark it as a slow test?
