Value trees won't have scalar ptr at all, so we need a scalar int printing method anyway. This way we'll be able to share that method between all const representations.
valtree is a version of constants that is inherently safe to be used within types.
This is in contrast to ty::Const which can have different representations of the same value. These representation differences can show up in hashing or equality comparisons, breaking type equality of otherwise equal types.
valtrees do not have this problem.
Rollup of 11 pull requests
Successful merges:
- #80385 (Clarify what `Cell::replace` returns)
- #82571 (Rustdoc Json: Add tests for Reexports, and improve jsondocck)
- #82860 (Add `-Z unpretty` flag for the THIR)
- #82950 (convert slice doc link to intra-doc links)
- #82965 (Add spirv extension handling in compiletest)
- #82966 (update MSYS2 link in README)
- #82979 (Fix "run" button position in error index)
- #83001 (Ignore Vim swap files)
- #83003 (rustdoc: tweak the search index format)
- #83013 (Adjust some `#[cfg]`s to take non-Unix non-Windows operating systems into account)
- #83018 (Reintroduce accidentally deleted assertions.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Adjust some `#[cfg]`s to take non-Unix non-Windows operating systems into account
This makes compilation to such targets (e.g. `wasm32-wasi`) easier.
cc rust-lang/miri#722bb6d1d0a09 (r48100619)
rustdoc: tweak the search index format
This essentially switches search-index.js from a "array of struct" to a "struct of array" format, like this:
{
"doc": "Crate documentation",
"t": [ 1, 1, 2, 3, ... ],
"n": [ "Something", "SomethingElse", "whatever", "do_stuff", ... ],
"q": [ "a::b", "", "", "", ... ],
"d": [ "A Struct That Does Something", "Another Struct", "a function", "another function", ... ],
"i": [ 0, 0, 1, 1, ... ],
"f": [ null, null, [], [], ... ],
"p": ...,
"a": ...
}
So `{ty: 1, name: "Something", path: "a::b", desc: "A Struct That Does Something", parent_idx: 0, search_type: null}` is the first item.
This makes the uncompressed version smaller, but it really shows on the compressed version:
notriddle:rust$ wc -c new-search-index1.52.0.js
2622427 new-search-index1.52.0.js
notriddle:rust$ wc -c old-search-index1.52.0.js
2725046 old-search-index1.52.0.js
notriddle:rust$ gzip new-search-index1.52.0.js
notriddle:rust$ gzip old-search-index1.52.0.js
notriddle:rust$ wc -c new-search-index1.52.0.js.gz
239385 new-search-index1.52.0.js.gz
notriddle:rust$ wc -c old-search-index1.52.0.js.gz
296328 old-search-index1.52.0.js.gz
That's a 4% improvement on the uncompressed version (fewer `[]`, and also changing `null` to `0` in the parent_idx list), and 20% improvement after gzipping it, thanks to putting like-typed data next to each other. Any compression algorithm based on a sliding window will probably show this kind of improvement.
Ignore Vim swap files
I got this from [a Stack Overflow answer][so].
(I didn't add `*~` because it was already there.)
[so]: https://stackoverflow.com/a/4824199
Add spirv extension handling in compiletest
We're trying to use `compiletest` for Rust-GPU's testsuite, and ran into an issue with host specific extensions. This adds handling to fix that.
convert slice doc link to intra-doc links
Continuing where #80189 stopped, with `core::slice`.
I had an issue with two dead links in my doc when implementing `Deref<Target = [T]>` for one of my type. This means that [`binary_search_by_key`](https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.binary_search_by_key) was available, but not [`sort_by_key`](https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.sort_by_key) even though it was linked in it's doc (same issue with [`as_ptr`](https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.as_ptr) and [`as_mut_pbr`](https://doc.rust-lang.org/nightly/std/primitive.slice.html#method.as_mut_ptr)). It becomes available if I implement `DerefMut`, as it needs an `&mut self`.
<details>
<summary>Code that will have dead links in its doc</summary>
```rust
pub struct A;
pub struct B;
impl std::ops::Deref for B{
type Target = [A];
fn deref(&self) -> &Self::Target {
&A
}
}
```
</details>
I removed the link to `sort_by_key` from `binary_search_by_key` doc as I didn't find a nice way to have a live link:
- `binary_search_by_key` is in `core`
- `sort_by_key` is in `alloc`
- intra-doc link `slice::sort_by_key` doesn't work, as `alloc` is not available when `core` is being build (the warning can't be ignored: ```error[E0710]: an unknown tool name found in scoped lint: `rustdoc::broken_intra_doc_links` ```)
- keeping the link as an anchor `#method.sort_by_key` meant a dead link
- an absolute link would work but doesn't feel right...
Add `-Z unpretty` flag for the THIR
This adds a new perma-unstable flag, `-Zunpretty=thir-tree`, that dumps the raw THIR tree for each body in the crate.
Implements the THIR part of MCP rust-lang/compiler-team#408, helps with rust-lang/rustc-dev-guide#1062.
Depends on #82495, blocked on that. Only the two last commits are added by this PR.
r? ```@spastorino``` cc ```@estebank```
Rustdoc Json: Add tests for Reexports, and improve jsondocck
The two changes are orthognal, so you can land just one if you want, but the improved errors realy helped write the tests.
Notably does not have the case from #80664, but I want to have all the ajacent cases tested before starting work on that to ensure I dont break anything.
Improves #81359
cc ```@CraftSpider```
r? ```@jyn514```
```@rustbot``` modify labels: +A-testsuite +T-rustdoc +A-rustdoc-json
Fix io::copy specialization using copy_file_range when writer was opened with O_APPEND
fixes#82410
While `sendfile()` returns `EINVAL` when the output was opened with O_APPEND, `copy_file_range()` does not and returns `EBADF` instead, which – unlike other `EBADF` causes – is not fatal for this operation since a regular `write()` will likely succeed.
We now treat `EBADF` as a non-fatal error for `copy_file_range` and fall back to a read-write copy as we already did for several other errors.
Enable MemorySSA in MemCpyOpt
LLVM 12 ships with an implementation of MemCpyOpt which is based on MSSA instead of MDA. This implementation can eliminate memcpys across blocks, and as such fixes many (but not all) failures to eliminate redundant memcpys for Rust code. Unfortunately this was only enabled by default shortly after LLVM 12 was cut. This backports the enablement to our LLVM fork.
Perf results: https://perf.rust-lang.org/compare.html?start=8fd946c63a6c3aae9788bd459d278cb2efa77099&end=0628b91ce17035fb5b6a1a99a4f2ab9ab69be7a8
There are improvements on check and debug builds, which indicate that rustc itself has become faster. For opt builds this is, on average, a very minor improvement as well, although there is one significant outlier with deep-vector-opt. This benchmark creates ~140000 zero stores, which are now coalesced into a memset slightly later, resulting in longer compile-time for intermediate passes.
Eagerly construct bodies of THIR
With this PR:
- the THIR is no longer constructed lazily, but is entirely built before being passed to the MIR Builder
- the THIR is now allocated in arenas instead of `Box`es
However, this PR doesn't make any changes to the way patterns are constructed: they are still boxed, and exhaustiveness checking is unchanged.
Implements MCP rust-lang/compiler-team#409.
Closesrust-lang/project-thir-unsafeck#1.
r? `@ghost` cc `@nikomatsakis` `@oli-obk`
This updates the LLVM submodule to pick up a backported patch
to enable MemorySSA-based MemCpyOpt, which is capable of optimizing
away memcpy's across basic blocks.
Shorten `rustc_middle::ty::mod`
Related to #60302.
This PR moves all `Adt*`, `Assoc*`, `Generic*`, and `UpVar*` types to separate files.
This, alongside some `use` reordering, puts `mod.rs` at ~2,200 lines, thus removing the `// ignore-tidy-filelength`.
The particular groups were chosen as they had 4 or more "substantive" members.
This essentially switches search-index.js from a "array of struct"
to a "struct of array" format, like this:
{
"doc": "Crate documentation",
"t": [ 1, 1, 2, 3, ... ],
"n": [ "Something", "SomethingElse", "whatever", "do_stuff", ... ],
"q": [ "a::b", "", "", "", ... ],
"d": [ "A Struct That Does Something", "Another Struct", "a function", "another function", ... ],
"i": [ 0, 0, 1, 1, ... ],
"f": [ null, null, [], [], ... ],
"p": ...,
"a": ...
}
So `{ty: 1, name: "Something", path: "a::b", desc: "A Struct That Does Something", parent_idx: 0, search_type: null}` is the first item.
This makes the uncompressed version smaller, but it really shows on the
compressed version:
notriddle:rust$ wc -c new-search-index1.52.0.js
2622427 new-search-index1.52.0.js
notriddle:rust$ wc -c old-search-index1.52.0.js
2725046 old-search-index1.52.0.js
notriddle:rust$ gzip new-search-index1.52.0.js
notriddle:rust$ gzip old-search-index1.52.0.js
notriddle:rust$ wc -c new-search-index1.52.0.js.gz
239385 new-search-index1.52.0.js.gz
notriddle:rust$ wc -c old-search-index1.52.0.js.gz
296328 old-search-index1.52.0.js.gz
notriddle:rust$
That's a 4% improvement on the uncompressed version (fewer `[]`),
and 20% improvement after gzipping it, thanks to putting like-typed
data next to each other. Any compression algorithm based on a sliding
window will probably show this kind of improvement.
