Add MOVBE x86 CPU feature
I have no idea if this is correct. I basically copied the ADX feature. I verified the feature is also called `movbe` in LLVM.
I marked this to become stable immediately, as part of the RFC 2045.
r? @alexcrichton
Improve bug message in check_ty
This branch was hit in Clippy and I think it would be nice to
show the thing that was unexpected in the bug message.
It's also in line with the other `bug!` messages in `check_ty`.
SGX target: improve panic & exit handling
Implement this part of the spec:
> The enclave must not rely on userspace to terminate other threads still running. Similarly, the enclave must not trust that it will no longer be entered by userspace, and it must safeguard against that in the entrypoints.
Also use `UserRef` to access panic buffer
r? @alexcrichton
cc @VardhanThigle
Mark str::trim.* functions as #[must_use].
The functions return a reference to a new object and do not modify in-place
as the following code shows:
````
let s = String::from(" hello ");
s.trim();
assert_eq!(s, " hello ");
````
The new reference should be bound to a variable as now indicated by #[must_use].
This branch was hit in Clippy and I think it would be nice to
show the thing that was unexpected in the bug message.
It's also in line with the other `bug!` messages in `check_ty`.
Attempt to debug 259 exit code on AppVeyor
Let's try to dig in a bit more and see where this is coming from, it
looks like AppVeyor is also unsure where this is coming from!
Do not set CC, CFLAGS, CXX, CXXFLAGS, AR, RANLIB in bootstrap, it breaks cross compilation
Fixes https://github.com/rust-lang/rust/issues/57812
I tested it in AArch64 Ubuntu container with several days old tree to have all the tools buildable.
I did **not** test native builds (amd64 -> amd64), leaving it to CI.
r? @alexcrichton
Add information to higher-ranked lifetimes conflicts error messages
Make these errors go through the new "placeholder error" code path, to have self tys displayed and make them hopefully less confusing.
Should fix#57362.
r? @nikomatsakis — so we can iterate on the specific wording you wanted.
Build the standard library for thumbv7neon-unknown-linux-gnueabihf in CI
Using the `dist-armv7-linux` image instead of `dist-various-1` in order to use the ARMv7 toolchain available in `dist-armv7-linux`.
Closes#57030.
Rollup of 7 pull requests
Successful merges:
- #57045 (Kill remaining uses of mem::uninitialized in libcore, liballoc)
- #57674 (Avoid erase_regions_ty queries if there are no regions to erase)
- #57833 (Print a slightly clearer message when failing to launch a thread)
- #57859 (Fix invalid background color)
- #57904 (add typo suggestion to unknown attribute error)
- #57915 (Pretty print `$crate` as `crate` or `crate_name` in more cases)
- #57950 (Extend E0106, E0261)
Failed merges:
r? @ghost
Extend E0106, E0261
This is a reopening of https://github.com/rust-lang/rust/pull/57310 with review comments addressed because the original author has since deleted their fork.
From the author (@purple-ice):
> Added an example that points out hardly obvious mistake one could make when writing impl for a new type.
r? @rust-lang/docs
add typo suggestion to unknown attribute error
Provides a suggestion using Levenshtein distance to suggest built-in attributes and attribute macros.
Fixes#49270.
Print a slightly clearer message when failing to launch a thread
As discussed in #46345, the `io::Error` you get when a thread fails to launch is of type `io::ErrorKind::WouldBlock`. This is super uninformative when an arbitrary `thread::spawn` fails somewhere in your code:
```
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 11,
kind: WouldBlock, message: "operation would block" }', src/libcore/result.rs:997:5
```
This PR improves the situation a little bit by using `expect` instead of `unwrap`. I don't consider this a complete fix for #46345 though.
Avoid erase_regions_ty queries if there are no regions to erase
It's overall faster to perform this extra check than to perform the
query, even if the result is already in the query cache.
Kill remaining uses of mem::uninitialized in libcore, liballoc
Kill remaining uses of mem::uninitialized in libcore and liballoc, and enable a lint that will warn when uses are added again in the future.
To avoid casting raw pointers around (which is always very dangerous because it is not typechecked at all -- it doesn't even get the "same size" sanity check that `transmute` gets), I also added two new functions to `MaybeUninit`:
```rust
/// Get a pointer to the first contained values.
pub fn first_ptr(this: &[MaybeUninit<T>]) -> *const T {
this as *const [MaybeUninit<T>] as *const T
}
/// Get a mutable pointer to the first contained values.
pub fn first_mut_ptr(this: &mut [MaybeUninit<T>]) -> *mut T {
this as *mut [MaybeUninit<T>] as *mut T
}
```
I changed some of the existing code to use array-of-`MaybeUninit` instead of `MaybeUninit`-of-array, successfully removing raw pointer casts there as well.
Using CC, CFLAGS, CXX, CXXFLAGS, AR and RANLIB breaks cross compilation
because host is built first and has correct values. The same
values are incorrect for the target however.
Use pinning for generators to make trait safe
I'm unsure whether there needs to be any changes to the actual generator transform. Tests are passing so the fact that `Pin<&mut T>` is fundamentally the same as `&mut T` seems to allow it to still work, but maybe there's something subtle here that could go wrong.
This is specified in [RFC 2349 § Immovable generators](https://github.com/rust-lang/rfcs/blob/master/text/2349-pin.md#immovable-generators) (although, since that RFC it has become safe to create an immovable generator, and instead it's unsafe to resume any generator; with these changes both are now safe and instead the unsafety is moved to creating a `Pin<&mut [static generator]>` which there are safe APIs for).
CC #43122
