Fix collapse toggle insertions on impl with docs
Just went through this one randomly... When an impl has docs, the collapse toggle isn't generated. This fixes it.
r? @QuietMisdreavus
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
[incremental] Don't panic if decoding the cache fails
If the cached data can't be loaded from disk, just issue a warning to
the user so they know why compilation is taking longer than usual but
don't fail the entire compilation since we can recover by ignorning the
on disk cache.
In the same way, if the disk cache can't be deserialized (because it has
been corrupted for some reason), report the issue as a warning and
continue without failing the compilation. `Decodable::decode()` tends to
panic with various errors like "entered unreachable code" or "index out
of range" if the input data is corrupted. Work around this by catching
panics from the `decode()` calls and continuing without the cached data.
Fixes#48847
Stabilize match_default_bindings
This includes a submodule update to rustfmt
in order to allow a stable feature declaration.
r? @nikomatsakis
cc https://github.com/rust-lang/rust/issues/42640
Many of the tests this PR touches are merely testing the current lack of desired future behavior around https://github.com/rust-lang/rust/issues/44849 and https://github.com/rust-lang/rust/issues/44848 (cc @tschottdorf). I noticed the bullets for those items were checked on the tracking issue-- I've unchecked them, as they don't appear to have been completed and I don't see any comments indicating that we don't want to pursue them further. Still, I think it's fine to stabilize the current behavior, as I think expanding it in the future should be backwards-compatible.
Introduce a TargetTriple enum to support absolute target paths
This PR replaces target triple strings with a `TargetTriple` enum, which represents either a target triple or a path to a JSON target file. The path variant is used if the `--target` argument has a `.json` extension, else the target triple variant is used.
The motivation of this PR is support for absolute target paths to avoid the need for setting the `RUST_TARGET_PATH` environment variable (see rust-lang/cargo#4905 for more information). For places where some kind of triple is needed (e.g. in the sysroot folder), we use the file name (without extension).
For compatibility, we keep the old behavior of searching for a file named `$(target_triple).json` in `RUST_TARGET_PATH` for non-official target triples.
If the cached data can't be loaded from disk, just issue a warning to
the user so they know why compilation is taking longer than usual but
don't fail the entire compilation since we can recover by ignorning the
on disk cache.
In the same way, if the disk cache can't be deserialized (because it has
been corrupted for some reason), report the issue as a warning and
continue without failing the compilation. `Decodable::decode()` tends to
panic with various errors like "entered unreachable code" or "index out
of range" if the input data is corrupted. Work around this by catching
panics from the `decode()` calls when joining the thread and continuing
without the cached data.
Fixes#48847
Once a target feature is enabled for a function that means that it in general
can't be inlined into other functions which don't have that target feature
enabled. This can cause both safety and LLVM issues if we were to actually
inline it, so `#[inline(always)]` both can't be respected and would be an error
if we did so!
Today LLVM doesn't inline functions with different `#[target_feature]`
annotations, but it turns out that if one is tagged with `#[inline(always)]`
it'll override this and cause scary LLVM error to arise!
This commit fixes this issue by forbidding these two attributes to be used in
conjunction with one another.
cc rust-lang-nursery/stdsimd#404
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.)
libsyntax: Remove obsolete.rs
This little piece of infra is obsolete (ha-ha) and is unlikely to be used in the future, even if new obsolete syntax appears.
