This addition landed in https://github.com/rust-lang/rust/pull/49305 and turned out to break crates that had their own copy of `TryFrom` in order to use it on the Stable channel :(
We’ll explore the possibility of the 2018 edition having a different prelude that includes this traits. However per the editions RFC this requires implementing a warning in the 2015 edition for code that *would* break.
bors [Fri, 30 Mar 2018 14:11:35 +0000 (14:11 +0000)]
Auto merge of #49425 - alexcrichton:disallow-inline-always, r=petrochenkov
rustc: Forbid #[inline(always)] with #[target_feature]
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.
kennytm [Thu, 29 Mar 2018 23:31:16 +0000 (01:31 +0200)]
Rollup merge of #49466 - glandium:master, r=rkruppe
Use f{32,64}::to_bits for is_zero test in vec::SpecFromElem
vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.
For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:
```
xorps xmm1, xmm1
ucomisd xmm0, xmm1
setnp al
sete cl
and cl, al
movq rax, xmm0
test rax, rax
setns al
and al, cl
ret
```
A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:
```
movq rax, xmm0
test rax, rax
sete al
ret
```
Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.
kennytm [Thu, 29 Mar 2018 23:31:15 +0000 (01:31 +0200)]
Rollup merge of #49464 - ollie27:rustbuild_junction_handle_leak, r=alexcrichton
rustbuild: Don't leak file handles when creating junctions on Windows
This fixes building the compiler docs because stage1-rustc\x86_64-pc-windows-msvc\doc is used twice which doesn't work if we still have a handle from the first time.
bors [Thu, 29 Mar 2018 23:19:52 +0000 (23:19 +0000)]
Auto merge of #49316 - alexcrichton:start-group-end-group, r=michaelwoerister
rustc: Group linked libraries where needed
This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.
This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!
To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)
Alex Crichton [Fri, 23 Mar 2018 21:33:22 +0000 (14:33 -0700)]
rustc: Group linked libraries where needed
This commit fixes a longstanding issue with the compiler with circular
dependencies between libcore and libstd. The `core` crate requires at least one
symbol, the ability to unwind. The `std` crate is the crate which actually
defines this symbol, but the `std` crate also depends on the `core` crate.
This circular dependency is in general disallowed in Rust as crates cannot have
cycles amongst them. A special exception is made just for core/std, but this is
also unfortunately incompatible with how GNU linkers work. GNU linkers will
process undefined symbols in a left-to-right fashion, only actually linking an
rlib like libstd if there are any symbols used from it. This strategy is
incompatible with circular dependencies because if we otherwise don't use
symbols from libstd we don't discover that we needed it until we're later
processing libcore's symbols!
To fix this GNU linkers support the `--start-group` and `--end-group` options
which indicate "libraries between these markers may have circular dependencies
amongst them. The linker invocation has been updated to automatically pass these
arguments when we're invoking a GNU linker and automatically calculate where the
arguments need to go (around libstd and libcore)
bors [Thu, 29 Mar 2018 11:34:17 +0000 (11:34 +0000)]
Auto merge of #49163 - SimonSapin:range-bounds, r=alexcrichton
Rename RangeArgument to RangeBounds, move it and Bound to libcore
As proposed in the tracking issue: https://github.com/rust-lang/rust/issues/30877
Changes to *stable* items:
* `core::ops::Bound` / `std::ops::Bound` is new
* `std::collections::Bound` is a deprecated reexport of it (does this actually cause a warning?)
Changes to *unstable* items
* `alloc::Bound` is gone
* `alloc::range::RangeArgument` is moved to `core::ops::RangeBounds` / `std::ops::RangeBounds`
* `alloc::range` is gone
* `std::collections::range::RangeArgument` is deprecated reexport, to be removed later
* `std::collections::range` is deprecated, to be removed later
* `impl RangeBounds<T> for Range{,From,To,Inclusive,ToInclusive}<&T>` are added
The idea of replacing this trait with a type to be used with `Into<_>` is left for future consideration / work.
bors [Thu, 29 Mar 2018 05:44:40 +0000 (05:44 +0000)]
Auto merge of #49313 - sgrif:sg-revert-stuff, r=nikomatsakis
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.
Mike Hommey [Thu, 29 Mar 2018 00:34:39 +0000 (09:34 +0900)]
Use f{32,64}::to_bits for is_zero test in vec::SpecFromElem
vec::SpecFromElem provides an optimization to use calloc to fill a Vec
when the element given to fill the Vec is represented by 0.
For floats, the test for that currently used is `x == 0. &&
x.is_sign_positive()`. When compiled in a standalone function, rustc
generates the following assembly:
```
xorps xmm1, xmm1
ucomisd xmm0, xmm1
setnp al
sete cl
and cl, al
movq rax, xmm0
test rax, rax
setns al
and al, cl
ret
```
A simpler test telling us whether the value is represented by 0, is
`x.to_bits() == 0`, which rustc compiles to:
```
movq rax, xmm0
test rax, rax
sete al
ret
```
Not that the test is hot in any way, but it also makes it clearer what
the intent in the rust code is.
Oliver Middleton [Wed, 28 Mar 2018 21:43:23 +0000 (22:43 +0100)]
rustbuild: Don't leak file handles when creating junctions on Windows
This fixes building the compiler docs because stage1-rustc\x86_64-pc-windows-msvc\doc is used twice which
doesn't work if we still have a handle from the first time.
kennytm [Wed, 28 Mar 2018 15:55:13 +0000 (17:55 +0200)]
Rollup merge of #49428 - cuviper:llvm6-target_feature, r=alexcrichton
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`.
kennytm [Wed, 28 Mar 2018 15:55:08 +0000 (17:55 +0200)]
Rollup merge of #49364 - wesleywiser:incr_handle_load_failure, r=michaelwoerister
[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.
bors [Wed, 28 Mar 2018 15:31:29 +0000 (15:31 +0000)]
Auto merge of #49394 - cramertj:stable-match-bindings, r=nikomatsakis
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.
bors [Wed, 28 Mar 2018 12:56:09 +0000 (12:56 +0000)]
Auto merge of #49019 - phil-opp:target-spec, r=pnkfelix
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.
Wesley Wiser [Fri, 23 Mar 2018 02:25:57 +0000 (22:25 -0400)]
[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 when joining the thread and continuing
without the cached data.
Alex Crichton [Tue, 27 Mar 2018 18:42:04 +0000 (11:42 -0700)]
rustc: Forbid #[inline(always)] with #[target_feature]
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.
Josh Stone [Tue, 27 Mar 2018 19:27:45 +0000 (12:27 -0700)]
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`.
* `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.)
projects / rust.git / log