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
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.
Remove `masked_crates` from `clean::Crate`
Previously, `masked_crates` existed both on `Cache` and on
`clean::Crate`. During cache population, the `clean::Crate` version was
`take`n and moved to `Cache`.
This change removes the version on `clean::Crate` and instead directly
mutates `Cache.masked_crates` to initialize it. This has the advantage
of avoiding duplication and avoiding unnecessary allocation, as well as
making the flow of information through rustdoc less confusing.
The one downside I see is that `clean::utils::krate()` now uses the side
effect of mutating `DocContext.cache` instead of returning the data
directly, but it already mutated the `Cache` for other things (e.g.,
`deref_trait_did`) so it's not really new behavior. Also,
`clean::utils::krate()` is only called once (and is meant to only be
called once since it performs expensive and potentially destructive
operations) so the mutation shouldn't be an issue.
Follow-up to https://github.com/rust-lang/rust/pull/82018#discussion_r584197747.
cc `@jyn514`
Rollup of 9 pull requests
Successful merges:
- #81309 (always eagerly eval consts in Relate)
- #82217 (Edition-specific preludes)
- #82807 (rustdoc: Remove redundant enableSearchInput function)
- #82924 (WASI: Switch to crt1-command.o to enable support for new-style commands)
- #82949 (Do not attempt to unlock envlock in child process after a fork.)
- #82955 (fix: wrong word)
- #82962 (Treat header as first paragraph for shortened markdown descriptions)
- #82976 (fix error message for copy(_nonoverlapping) overflow)
- #82977 (Rename `Option::get_or_default` to `get_or_insert_default`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Treat header as first paragraph for shortened markdown descriptions
"The Rust Standard LibraryThe Rust Standard Library is the …" is an awful description.
Do not attempt to unlock envlock in child process after a fork.
This implements the first two points from https://github.com/rust-lang/rust/issues/64718#issuecomment-793030479
This is a breaking change for cases where the environment is accessed in a Command::pre_exec closure. Except for single-threaded programs these uses were not correct anyway since they aren't async-signal safe.
Note that we had a ui test that explicitly tried `env::set_var` in `pre_exec`. As expected it failed with these changes when I tested locally.
WASI: Switch to crt1-command.o to enable support for new-style commands
This switches Rust's WASI target to use crt1-command.o instead of
crt1.o, which enables support for new-style commands. By default,
new-style commands work the same way as old-style commands, so nothing
immediately changes here, but this will be needed by later changes to
enable support for typed arguments.
See here for more information on new-style commands:
- https://github.com/WebAssembly/wasi-libc/pull/203
- https://reviews.llvm.org/D81689
r? ```@alexcrichton```
rustdoc: Remove redundant enableSearchInput function
enableSearchInput was called from two places:
- setupSearchLoader
- addSearchOptions, which is itself called from setupSearchLoader only
This commit can safely get rid of the addSearchOptions calls entirely, and since the setupSearchLoader call is immediately preceded by other method calls on search_input, there's no need to check if it's set.
Edition-specific preludes
This changes `{std,core}::prelude` to export edition-specific preludes under `rust_2015`, `rust_2018` and `rust_2021`. (As suggested in https://github.com/rust-lang/rust/issues/51418#issuecomment-395630382.) For now they all just re-export `v1::*`, but this allows us to add things to the 2021edition prelude soon.
This also changes the compiler to make the automatically injected prelude import dependent on the selected edition.
cc `@rust-lang/libs` `@djc`
Implement RFC 2945: "C-unwind" ABI
## Implement RFC 2945: "C-unwind" ABI
This branch implements [RFC 2945]. The tracking issue for this RFC is #74990.
The feature gate for the issue is `#![feature(c_unwind)]`.
This RFC was created as part of the ffi-unwind project group tracked at rust-lang/lang-team#19.
### Changes
Further details will be provided in commit messages, but a high-level overview
of the changes follows:
* A boolean `unwind` payload is added to the `C`, `System`, `Stdcall`,
and `Thiscall` variants, marking whether unwinding across FFI boundaries is
acceptable. The cases where each of these variants' `unwind` member is true
correspond with the `C-unwind`, `system-unwind`, `stdcall-unwind`, and
`thiscall-unwind` ABI strings introduced in RFC 2945 [3].
* This commit adds a `c_unwind` feature gate for the new ABI strings.
Tests for this feature gate are included in `src/test/ui/c-unwind/`, which
ensure that this feature gate works correctly for each of the new ABIs.
A new language features entry in the unstable book is added as well.
* We adjust the `rustc_middle::ty::layout::fn_can_unwind` function,
used to compute whether or not a `FnAbi` object represents a function that
should be able to unwind when `panic=unwind` is in use.
* Changes are also made to
`rustc_mir_build::build::should_abort_on_panic` so that the function ABI is
used to determind whether it should abort, assuming that the `panic=unwind`
strategy is being used, and no explicit unwind attribute was provided.
[RFC 2945]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md
Remove the -Zinsert-sideeffect
This removes all of the code we had in place to work-around LLVM's
handling of forward progress. From this removal excluded is a workaround
where we'd insert a `sideeffect` into clearly infinite loops such as
`loop {}`. This code remains conditionally effective when the LLVM
version is earlier than 12.0, which fixed the forward progress related
miscompilations at their root.
This removes all of the code we had in place to work-around LLVM's
handling of forward progress. From this removal excluded is a workaround
where we'd insert a `sideeffect` into clearly infinite loops such as
`loop {}`. This code remains conditionally effective when the LLVM
version is earlier than 12.0, which fixed the forward progress related
miscompilations at their root.
