Enable target_feature on any LLVM 6+
In `LLVMRustHasFeature()`, rather than using `MCInfo->getFeatureTable()`
that is specific to Rust's LLVM fork, we can use this in LLVM 6:
/// Check whether the subtarget features are enabled/disabled as per
/// the provided string, ignoring all other features.
bool checkFeatures(StringRef FS) const;
Now rustc using external LLVM can also have `target_feature`.
r? @alexcrichton
In `LLVMRustHasFeature()`, rather than using `MCInfo->getFeatureTable()`
that is specific to Rust's LLVM fork, we can use this in LLVM 6:
/// Check whether the subtarget features are enabled/disabled as per
/// the provided string, ignoring all other features.
bool checkFeatures(StringRef FS) const;
Now rustc using external LLVM can also have `target_feature`.
Stabilize TryFrom / TryInto, and tweak impls for integers
Fixes https://github.com/rust-lang/rust/issues/33417 (tracking issue)
----
This adds:
* `impl From<u16> for usize`
* `impl From<i16> for isize`
* `impl From<u8> for isize`
… replacing corresponding `TryFrom<Error=!>` impls. (`TryFrom` still applies through the generic `impl<T, U> TryFrom<U> for T where T: From<U>`.) Their infallibility is supported by the C99 standard which (indirectly) requires pointers to be at least 16 bits.
The remaining `TryFrom` impls that define `type Error = !` all involve `usize` or `isize`. This PR changes them to use `TryFromIntError` instead, since having a return type change based on the target is a portability hazard.
Note: if we make similar assumptions about the *maximum* bit size of pointers (for all targets Rust will ever run on in the future), we could have similar `From` impls converting pointer-sized integers to large fixed-size integers. RISC-V considers the possibility of a 128-bit address space (RV128), which would leave only `impl From<usize> for u128` and `impl From<isize> for u128`. I [found](https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20171017a-cheri-poster.pdf) some [things](http://www.csl.sri.com/users/neumann/2012resolve-cheri.pdf) about 256-bit “capabilities”, but I don’t know how relevant that would be to Rust’s `usize` and `isize` types.
I chose conservatively to make no assumption about the future there. Users making their portability decisions and using something like `.try_into().unwrap()`.
----
Since this feature already went through FCP in the tracking issue https://github.com/rust-lang/rust/issues/33417, this PR also proposes **stabilize** the following items:
* The `convert::TryFrom` trait
* The `convert::TryFrom` trait
* `impl<T> TryFrom<&[T]> for &[T; $N]` (for `$N` up to 32)
* `impl<T> TryFrom<&mut [T]> for &mut [T; $N]` (for `$N` up to 32)
* The `array::TryFromSliceError` struct, with impls of `Debug`, `Copy`, `Clone`, and `Error`
* `impl TryFrom<u32> for char`
* The `char::CharTryFromError` struct, with impls of `Copy`, `Clone`, `Debug`, `PartialEq`, `Eq`, `Display`, and `Error`
* Impls of `TryFrom` for all (?) combinations of primitive integer types where `From` isn’t implemented.
* The `num::TryFromIntError` struct, with impls of `Debug`, `Copy`, `Clone`, `Display`, `From<!>`, and `Error`
Some minor remaining questions that I hope can be resolved in this PR:
* Should the impls for error types be unified?
* ~Should `TryFrom` and `TryInto` be in the prelude? `From` and `Into` are.~ (Yes.)
implement minmax intrinsics
This adds the `simd_{fmin,fmax}` intrinsics, which do a vertical (lane-wise) `min`/`max` for floating point vectors that's equivalent to Rust's `min`/`max` for `f32`/`f64`.
It might make sense to make `{f32,f64}::{min,max}` use the `minnum` and `minmax` intrinsics as well.
---
~~HELP: I need some help with these. Either I should go to sleep or there must be something that I must be missing. AFAICT I am calling the `maxnum` builder correctly, yet rustc/LLVM seem to insert a call to `llvm.minnum` there instead...~~ EDIT: Rust's LLVM version is too old :/
Add basic PGO support.
This PR adds two mutually exclusive options for profile usage and generation using LLVM's instruction profile generation (the same as clang uses), `-C pgo-use` and `-C pgo-gen`.
See each commit for details.
Introduce unsafe offset_from on pointers
Adds intrinsics::exact_div to take advantage of the unsafe, which reduces the implementation from
```asm
sub rcx, rdx
mov rax, rcx
sar rax, 63
shr rax, 62
lea rax, [rax + rcx]
sar rax, 2
ret
```
down to
```asm
sub rcx, rdx
sar rcx, 2
mov rax, rcx
ret
```
(for `*const i32`)
See discussion on the `offset_to` tracking issue https://github.com/rust-lang/rust/issues/41079
Some open questions
- Would you rather I split the intrinsic PR from the library PR?
- Do we even want the safe version of the API? https://github.com/rust-lang/rust/issues/41079#issuecomment-374426786 I've added some text to its documentation that even if it's not UB, it's useless to use it between pointers into different objects.
and todos
- [x] ~~I need to make a codegen test~~ Done
- [x] ~~Can the subtraction use nsw/nuw?~~ No, it can't https://github.com/rust-lang/rust/pull/49297#discussion_r176697574
- [x] ~~Should there be `usize` variants of this, like there are now `add` and `sub` that you almost always want over `offset`? For example, I imagine `sub_ptr` that returns `usize` and where it's UB if the distance is negative.~~ Can wait for later; C gives a signed result https://github.com/rust-lang/rust/issues/41079#issuecomment-375842235, so we might as well, and this existing to go with `offset` makes sense.
adds simd_select intrinsic
The select SIMD intrinsic is used to select elements from two SIMD vectors using a mask:
```rust
let mask = b8x4::new(true, false, false, true);
let a = f32x4::new(1., 2., 3., 4.);
let b = f32x4::new(5., 6., 7., 8.);
assert_eq!(simd_select(mask, a, b), f32x4::new(1., 6., 7., 4.));
```
The number of lanes between the mask and the vectors must match, but the vector width of the mask does not need to match that of the vectors. The mask is required to be a vector of signed integers.
Note: this intrinsic will be exposed via `std::simd`'s vector masks - users are not expected to use it directly.
Stabilize the copy_closures and clone_closures features
In addition to the `Fn*` family of traits, closures now implement `Copy` (and similarly `Clone`) if all of the captures do.
Tracking issue: https://github.com/rust-lang/rust/issues/44490
Stabilize termination_trait, split out termination_trait_test
For #48453.
First time contribution, so I'd really appreciate any feedback on how this PR can be better.
Not sure exactly what kind of documentation update is needed. If there is no PR to update the reference, I can try doing that this week as I have time.
support elision in impl headers
You can now do things like:
```
impl MyTrait<'_> for &u32 { ... }
```
Each `'_` or elided lifetime is a fresh parameter. `'_` and elision are still not permitted in associated type values. (Plausibly we could support that if there is a single input lifetime.) The original lifetime elision RFC was a bit unclear on this point: [as documented here, I think this is the correct interpretation, both because it fits existing impls and it's most analogous to the behavior in fns](https://github.com/rust-lang/rust/issues/15872#issuecomment-338700138).
We do not support elision with deprecated forms:
```
impl MyTrait for std::cell::Ref<u32> { } // ERROR
```
Builds on the in-band lifetime stuff.
r? @cramertj
Fixes#15872
Lower the priority of unstable methods when picking a candidate.
Previously, when searching for the impl of a method, we do not consider the stability of the impl. This leads to lots of insta-inference-regressions due to method ambiguity when a popular name is chosen. This has happened multiple times in Rust's history e.g.
* `f64::from_bits` #40470
* `Ord::{min, max}` #42496
* `Ord::clamp` #44095 (eventually got reverted due to these breakages)
* `Iterator::flatten` #48115 (recently added)
This PR changes the probing order so that unstable items are considered last. If a stable item is found, the unstable items will not be considered (but a future-incompatible warning will still be emitted), thus allowing stable code continue to function without using qualified names.
Once the unstable feature is stabilized, the ambiguity error will still be emitted, but the user can also use newly stable std methods, while the current situation is that downstream user is forced to update the code without any immediate benefit.
(I hope that we could bring back `Ord::clamp` if this PR is merged.)
