Remove universes from `ty::ParamEnv`
This change was never meant to land. #48407 takes an alternate approach. However, that PR is now blocked on some issues with canonicalization, and rebasing these reverts gets harder each time, so let's just get this bit out of the way now.
r? @nikomatsakis
Check for known but incorrect attributes
fixes#43988
- Change nested_visit_map so it will recursively check functions
- Add visit_stmt and visit_expr for impl Visitor for CheckAttrVisitor and check for incorrect
inline and repr attributes on staements and expressions
- Add regression test for issue #43988
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
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.
Add is_whitespace and is_alphanumeric to str.
The other methods from `UnicodeStr` are already stable inherent
methods on str, but these have not been included.
r? @SimonSapin
