Deprecate `Vec::remove_item`
In #40062 we decided to remove that method. In #71834 it was said that we want to deprecate it for a few cycles before removing it. That's what this PR does.
Prevent attacker from manipulating FPU tag word used in SGX enclave
Insufficient sanitization of the x87 FPU tag word in the trusted enclave runtime allowed unprivileged adversaries in the containing host application to induce incoherent or unexpected results for ABI-compliant compiled enclave application code that uses the x87 FPU.
Vulnerability was disclosed to us by Fritz Alder, Jo Van Bulck, David Oswald and Frank Piessens
cc: @jethrogb
ci: disable alt build during try builds
The alt build is not actually needed often, and it can be added back on a case-by-case basis if a specific PR needs access to it.
This will free up a builder.
r? @Mark-Simulacrum
RISC-V Emulated Testing
Adds a disabled docker image on which to run RISC-V tests. Based on the armhf image.
Test using
```
./src/ci/docker/run.sh riscv64gc-linux
```
cc: @msizanoen1
remove leftover mentions of `skol` and `int` from the compiler
This PR mostly changes `skol` -> `placeholder` and all cases where `int` is used as a type to `i32`.
Properly encode AnonConst into crate metadata
Fixes#68104
Previous, we were encoding AnonConst as a regular Const, causing us to
treat them differently after being deserialized in another compilation
session.
Rollup of 16 pull requests
Successful merges:
- #71420 (Specialization is unsound)
- #71899 (Refactor `try_find` a little)
- #72689 (add str to common types)
- #72791 (update coerce docs and unify relevant tests)
- #72934 (forbid mutable references in all constant contexts except for const-fns)
- #73027 (Make `need_type_info_err` more conservative)
- #73347 (Diagnose use of incompatible sanitizers)
- #73359 (shim.rs: avoid creating `Call` terminators calling `Self`)
- #73399 (Clean up E0668 explanation)
- #73436 (Clean up E0670 explanation)
- #73440 (Add src/librustdoc as an alias for src/tools/rustdoc)
- #73442 (pretty/mir: const value enums with no variants)
- #73452 (Unify region variables when projecting associated types)
- #73458 (Use alloc::Layout in DroplessArena API)
- #73484 (Update the doc for std::prelude to the correct behavior)
- #73506 (Bump Rustfmt and RLS)
Failed merges:
r? @ghost
Update the doc for std::prelude to the correct behavior
Fixes#64686.
One line change to ensure the docs are correct about the behavior of the compiler when inserting`std::prelude::v1`.
I don't think examples are necessary but I can add some (especially those from the original issue) if needed.
Unify region variables when projecting associated types
This is required to avoid cycles when evaluating auto trait predicates.
Notably, this is required to be able add Chalk types to `CtxtInterners` for `cfg(parallel_compiler)`.
r? @nikomatsakis
pretty/mir: const value enums with no variants
Fixes#72181.
This PR modifies the pretty printer and const eval in the MIR so that `destructure_const` (used in `pretty_print_const_value`) can handle enums with no variants (or types containing enums with no variants).
I'm not convinced that this is the correct approach, folks more familiar with `destructure_const` would be able to say - happy to adjust the PR. Looking through `destructure_const` and the functions that it invokes, it didn't seem like it was written to handle zero-variant-enums - I assume that case is handled earlier in some way so `destructure_const` doesn't need to under normal circumstances. It didn't seem like it would be straightforward to make `destructure_const` handle this case in a first-class-feeling way (e.g. adding a `Variants::None` variant), so this PR makes some minimal changes to avoid ICEs.
Diagnose use of incompatible sanitizers
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
Make `need_type_info_err` more conservative
Makes sure arg patterns we are going to suggest on are actually contained within the span of the obligation that caused the inference error (credit to @lcnr for suggesting this fix).
There's a subtle trade-off regarding the handling of local patterns which I've left a comment about.
Resolves#72690
update coerce docs and unify relevant tests
Merges `test/ui/coerce` with `test/ui/coercion`.
Updates the documentation of `librustc_typeck/check/coercion.rs`.
Adds 2 new coercion tests.
add str to common types
I already expected this to be the case and it may slightly improve perf.
Afaict if we ever want to change str into a lang item this would have to get reverted.
As that would be fairly simple I don't believe this to cause any problems in the future.
Refactor `try_find` a little
~~This works like `find_map`, but mapping to a `Try` type. It stops when `Ok` is `Some(value)`, with an additional short-circuit on `Try::Error`. This is similar to the unstable `try_find`, but has the advantage of being able to directly return the user's `R: Try` type directly, rather than converting to `Result`.~~
(removed -- `try_find_map` was declined in review)
This PR also refactors `try_find` a little to match style. The `E` type parameter was unnecessary, so it's now removed. The folding closure now has reduced parametricity on just `T = Self::Item`, rather
than the whole `Self` iterator type. There's otherwise no functional change in this.
Specialization is unsound
As discussed in https://github.com/rust-lang/rust/issues/31844#issuecomment-617013949, it might be a good idea to warn users of specialization that the feature they are using is unsound.
I also expanded the "incomplete feature" warning to link the user to the tracking issue.
Rollup of 13 pull requests
Successful merges:
- #71568 (Document unsafety in slice/sort.rs)
- #72709 (`#[deny(unsafe_op_in_unsafe_fn)]` in liballoc)
- #73214 (Add asm!() support for hexagon)
- #73248 (save_analysis: improve handling of enum struct variant)
- #73257 (ty: projections in `transparent_newtype_field`)
- #73261 (Suggest `?Sized` when applicable for ADTs)
- #73300 (Implement crate-level-only lints checking.)
- #73334 (Note numeric literals that can never fit in an expected type)
- #73357 (Use `LocalDefId` for import IDs in trait map)
- #73364 (asm: Allow multiple template string arguments; interpret them as newline-separated)
- #73382 (Only display other method receiver candidates if they actually apply)
- #73465 (Add specialization of `ToString for char`)
- #73489 (Refactor hir::Place)
Failed merges:
r? @ghost
The `E` type parameter was unnecessary, so it's now removed. The folding
closure now has reduced parametricity on just `T = Self::Item`, rather
than the whole `Self` iterator type. There's otherwise no functional
change in this.
ty: projections in `transparent_newtype_field`
Fixes#73249.
This PR modifies `transparent_newtype_field` so that it handles
projections with generic parameters, where `normalize_erasing_regions`
would ICE.
Refactor hir::Place
For the following code
```rust
let c = || bar(foo.x, foo.x)
```
We generate two different `hir::Place`s for both `foo.x`.
Handling this adds overhead for analysis we need to do for RFC 2229.
We also want to store type information at each Projection to support
analysis as part of the RFC. This resembles what we have for
`mir::Place`
This commit modifies the Place as follows:
- Rename to `PlaceWithHirId`, where there `hir_id` is that of the
expressioin.
- Move any other information that describes the access out to another
struct now called `Place`.
- Removed `Span`, it can be accessed using the [hir
API](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/hir/map/struct.Map.html#method.span)
- Modify `Projection` to be a strucutre of its own, that currently only
contains the `ProjectionKind`.
Adding type information to projections wil be completed as part of https://github.com/rust-lang/project-rfc-2229/issues/5
Closes https://github.com/rust-lang/project-rfc-2229/issues/3
Only display other method receiver candidates if they actually apply
Previously, we would suggest `Box<Self>` as a valid receiver, even if
method resolution only succeeded due to an autoderef (e.g. to `&self`)
asm: Allow multiple template string arguments; interpret them as newline-separated
Allow the `asm!` macro to accept a series of template arguments, and interpret them as if they were concatenated with a '\n' between them. This allows writing an `asm!` where each line of assembly appears in a separate template string argument.
This syntax makes it possible for rustfmt to reliably format and indent each line of assembly, without risking changes to the inside of a template string. It also avoids the complexity of having the user carefully format and indent a multi-line string (including where to put the surrounding quotes), and avoids the extra indentation and lines of a call to `concat!`.
For example, rewriting the second example from the [blog post on the new inline assembly syntax](https://blog.rust-lang.org/inside-rust/2020/06/08/new-inline-asm.html) using multiple template strings:
```rust
fn main() {
let mut bits = [0u8; 64];
for value in 0..=1024u64 {
let popcnt;
unsafe {
asm!(
" popcnt {popcnt}, {v}",
"2:",
" blsi rax, {v}",
" jz 1f",
" xor {v}, rax",
" tzcnt rax, rax",
" stosb",
" jmp 2b",
"1:",
v = inout(reg) value => _,
popcnt = out(reg) popcnt,
out("rax") _, // scratch
inout("rdi") bits.as_mut_ptr() => _,
);
}
println!("bits of {}: {:?}", value, &bits[0..popcnt]);
}
}
```
Note that all the template strings must appear before all other arguments; you cannot, for instance, provide a series of template strings intermixed with the corresponding operands.
