One tricky detail here: There is some duplication of labor between `rustc::middle::const_eval` and `rustc_trans::trans::consts`. It might be good to explore ways to try to factor out the common structure to the two passes (by abstracting over the particular value-representation used in the compile-time interpreter).
rust_llvm: Add way to reflectively ask if a ValueRef is a known constant int.
Add option-returning variants to `const_to_int`/`const_to_uint` that
never assert fail. (These will be used for overflow checking from
rustc_trans::trans::consts.)
Added type-specific overflow checks when computing enum discriminant values.
Moved such overflow checking into one place (in `rustc::middle::ty`,
since it needs to be run on-demand during `const_eval` in some
scenarios), and revised `rustc_typeck` accordingly.
(Note that we only check for overflow if program did not provide a
discriminant value explicitly.)
Alex Crichton [Tue, 31 Mar 2015 23:01:03 +0000 (16:01 -0700)]
std: Stabilize last bits of io::Error
This commit stabilizes a few remaining bits of the `io::Error` type:
* The `Error::new` method is now stable. The last `detail` parameter was removed
and the second `desc` parameter was generalized to `E: Into<Box<Error>>` to
allow creating an I/O error from any form of error. Currently there is no form
of downcasting, but this will be added in time.
* An implementation of `From<&str> for Box<Error>` was added to liballoc to
allow construction of errors from raw strings.
* The `Error::raw_os_error` method was stabilized as-is.
* Trait impls for `Clone`, `Eq`, and `PartialEq` were removed from `Error` as it
is not possible to use them with trait objects.
This is a breaking change due to the modification of the `new` method as well as
the removal of the trait implementations for the `Error` type.
Alex Crichton [Tue, 31 Mar 2015 22:59:35 +0000 (15:59 -0700)]
rollup merge of #23288: alexcrichton/issue-19470
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
Alex Crichton [Tue, 31 Mar 2015 22:58:58 +0000 (15:58 -0700)]
rollup merge of #23908: aturon/stab-more-stragglers
* The `io::Seek` trait.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
Alex Crichton [Tue, 31 Mar 2015 22:58:57 +0000 (15:58 -0700)]
rollup merge of #23907: alexcrichton/impl-exit
This commit is an implementation of [RFC #1011][rfc] which adds an `exit`
function to the standard library for immediately terminating the current process
with a specified exit code.
Alex Crichton [Mon, 30 Mar 2015 18:00:05 +0000 (11:00 -0700)]
std: Clean out #[deprecated] APIs
This commit cleans out a large amount of deprecated APIs from the standard
library and some of the facade crates as well, updating all users in the
compiler and in tests as it goes along.
Alex Crichton [Tue, 31 Mar 2015 17:15:32 +0000 (10:15 -0700)]
rollup merge of #23876: alexcrichton/stabilize-any
This commit stabilizes the following APIs:
* `TypeId::of` - now that it has an `Any` bound it's ready to be stable.
* `Box<Any>::downcast` - now that an inherent impl on `Box<Any>` as well as
`Box<Any+Send>` is allowed the `BoxAny` trait is removed in favor of these
inherent methods.
This is a breaking change due to the removal of the `BoxAny` trait, but
consumers can simply remove imports to fix crates.
Alex Crichton [Tue, 31 Mar 2015 17:15:29 +0000 (10:15 -0700)]
rollup merge of #23766: alexcrichton/stabilize-raw-fd
This commit stabilizes the platform-specific `io` modules, specifically around
the traits having to do with the raw representation of each object on each
platform.
Specifically, the following material was stabilized:
* `AsRaw{Fd,Socket,Handle}`
* `RawFd` (renamed from `Fd`)
* `RawHandle` (renamed from `Handle`)
* `RawSocket` (renamed from `Socket`)
* `AsRaw{Fd,Socket,Handle}` implementations
* `std::os::{unix, windows}::io`
The following material was added as `#[unstable]`:
* `FromRaw{Fd,Socket,Handle}`
* Implementations for various primitives
There are a number of future improvements that are possible to make to this
module, but this should cover a good bit of functionality desired from these
modules for now. Some specific future additions may include:
* `IntoRawXXX` traits to consume the raw representation and cancel the
auto-destructor.
* `Fd`, `Socket`, and `Handle` abstractions that behave like Rust objects and
have nice methods for various syscalls.
At this time though, these are considered backwards-compatible extensions and
will not be stabilized at this time.
This commit is a breaking change due to the addition of `Raw` in from of the
type aliases in each of the platform-specific modules.
Aaron Turon [Tue, 31 Mar 2015 20:47:57 +0000 (13:47 -0700)]
Stabilize a few remaining stragglers
* The `io::Seek` trait, and `SeekFrom` enum.
* The `Iterator::{partition, unsip}` methods.
* The `Vec::into_boxed_slice` method.
* The `LinkedList::append` method.
* The `{or_insert, or_insert_with` methods in the `Entry` APIs.
Alex Crichton [Tue, 31 Mar 2015 21:41:59 +0000 (14:41 -0700)]
std: Add a process::exit function
This commit is an implementation of [RFC #1011][rfc] which adds an `exit`
function to the standard library for immediately terminating the current process
with a specified exit code.
Alex Crichton [Wed, 11 Mar 2015 00:59:23 +0000 (17:59 -0700)]
std: Remove #[old_orphan_check] from PartialEq
This is a deprecated attribute that is slated for removal, and it also affects
all implementors of the trait. This commit removes the attribute and fixes up
implementors accordingly. The primary implementation which was lost was the
ability to compare `&[T]` and `Vec<T>` (in that order).
This change also modifies the `assert_eq!` macro to not consider both directions
of equality, only the one given in the left/right forms to the macro. This
modification is motivated due to the fact that `&[T] == Vec<T>` no longer
compiles, causing hundreds of errors in unit tests in the standard library (and
likely throughout the community as well).
bors [Tue, 31 Mar 2015 18:26:20 +0000 (18:26 +0000)]
Auto merge of #23678 - richo:check-flightcheck, r=alexcrichton
Rationale for this, is that I lurked `ulimit -c unlimited` into my .profile to debug an unrelated crash, that I kept forgetting to set before hand. I then ran the test suite and discovered that I had 150 gigs of core dumps in `/cores`.
Very open to another approach, or to setting the limit to something higher than 0, but I think it would be nice if the build system tried to save you from yourself here.
Alex Crichton [Tue, 31 Mar 2015 17:15:26 +0000 (10:15 -0700)]
rollup merge of #23549: aturon/stab-num
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
bors [Tue, 31 Mar 2015 14:50:46 +0000 (14:50 +0000)]
Auto merge of #23549 - aturon:stab-num, r=alexcrichton
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Aaron Turon [Fri, 20 Mar 2015 06:42:18 +0000 (23:42 -0700)]
Stabilize std::num
This commit stabilizes the `std::num` module:
* The `Int` and `Float` traits are deprecated in favor of (1) the
newly-added inherent methods and (2) the generic traits available in
rust-lang/num.
* The `Zero` and `One` traits are reintroduced in `std::num`, which
together with various other traits allow you to recover the most
common forms of generic programming.
* The `FromStrRadix` trait, and associated free function, is deprecated
in favor of inherent implementations.
* A wide range of methods and constants for both integers and floating
point numbers are now `#[stable]`, having been adjusted for integer
guidelines.
* `is_positive` and `is_negative` are renamed to `is_sign_positive` and
`is_sign_negative`, in order to address #22985
* The `Wrapping` type is moved to `std::num` and stabilized;
`WrappingOps` is deprecated in favor of inherent methods on the
integer types, and direct implementation of operations on
`Wrapping<X>` for each concrete integer type `X`.
Rollup merge of #23866 - alexcrichton:switch-some-orders, r=aturon
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
Rollup merge of #23862 - jviereck:fix_23713_v2, r=steveklabnik
Based on the comment from @apasel422 in https://github.com/rust-lang/rust/pull/23791#issuecomment-87095298.
Where @apasel422 proposed
```
Moves the value out of the option if it is `Some`, or panics if it is `None`.
```
I include in this PR the version
```
Moves the value `v` out of the `Option` if it is `Some(v)`, or panics if it is `None`.
```
which
- is a little bit more precise about what value is actually returned
- uses `Option` over just "option" in the part `out of the [Option]
Rollup merge of #23859 - pnkfelix:fsk-lesser-box, r=nikomatsakis
Disallow writing through mutable pointers stored in non-mut Box.
Fix #14270
The fix works by making `cmt::freely_aliasable` result more fine-grained.
Instead of encoding the aliasability (i.e. whether the cmt is uniquely writable or not) as an option, now pass back an enum indicating either: 1. freely-aliasable (thus not uniquely-writable), 2. non-aliasable (thus uniquely writable), or 3. unique but immutable (and thus not uniquely writable, according to proposal from issue #14270.)
This is all of course a giant hack that will hopefully go away with an eventually removal of special treatment of `Box<T>` (aka `ty_unique`) from the compiler.
Rollup merge of #23852 - cmr:missing_doc, r=Manishearth
Due to a long-standing conservative approach to trait exports, all traits are
considered exported. However, the missing_docs lint uses the export map to
determine if something is public and ought to have documentation. This commit
modifies the lint to check if traits are private before emitting the warning.
Rollup merge of #23846 - rayglover:patch-rustdoc-stderr, r=alexcrichton
Currently if a rustdoc test panics then the fatal error message is not forwarded to the user. This change will have the test runner prefer forwarding anything on the stderr of the test process.
Rollup merge of #23839 - tyrion:patch-1, r=alexcrichton
The documentation says that 'The current convention is to use the `test` module
to hold your "unit-style"' but then defines the module as "tests" instead.
Also in the output of the command we can see:
```
test test::it_works ... ok
```
So I think the name of the module was meant to be "test"
Rollup merge of #23836 - Hoverbear:patch-1, r=steveklabnik
To not use `old_io` and `os`, which are deprecated. Since there is no more `MemoryMap` used byte parsing instead to generate the second potential error.
You can see the code working fine [here](http://is.gd/4g0wwp) on the PlayPen.
Huon Wilson [Mon, 30 Mar 2015 13:27:13 +0000 (00:27 +1100)]
Lex binary and octal literals more eagerly.
Previously 0b12 was considered two tokens, 0b1 and 2, as 2 isn't a valid
base 2 digit. This patch changes that to collapse them into one (and
makes `0b12` etc. an error: 2 isn't a valid base 2 digit).
This may break some macro invocations of macros with `tt` (or syntax
extensions) that rely on adjacent digits being separate tokens and hence
is a
[breaking-change]
The fix is to separate the tokens, e.g. `0b12` -> `0b1 2`.
Sean McArthur [Tue, 31 Mar 2015 00:56:48 +0000 (17:56 -0700)]
convert: remove FromError, use From<E> instead
This removes the FromError trait, since it can now be expressed using
the new convert::Into trait. All implementations of FromError<E> where
changed to From<E>, and `try!` was changed to use From::from instead.
Because this removes FromError, it is a breaking change, but fixing it
simply requires changing the words `FromError` to `From`, and
`from_error` to `from`.
Alex Crichton [Mon, 30 Mar 2015 23:43:04 +0000 (16:43 -0700)]
std: Stabilize the rest of Any/BoxAny
This commit stabilizes the following APIs:
* `TypeId::of` - now that it has an `Any` bound it's ready to be stable.
* `Box<Any>::downcast` - now that an inherent impl on `Box<Any>` as well as
`Box<Any+Send>` is allowed the `BoxAny` trait is removed in favor of these
inherent methods.
This is a breaking change due to the removal of the `BoxAny` trait, but
consumers can simply remove imports to fix crates.
Corey Richardson [Mon, 30 Mar 2015 03:41:54 +0000 (23:41 -0400)]
lint: handle private traits better
Due to a long-standing conservative approach to trait exports, all traits are
considered exported. However, the missing_docs lint uses the export map to
determine if something is public and ought to have documentation. This commit
modifies the lint to check if traits are private before emitting the warning.
Alex Crichton [Fri, 27 Mar 2015 18:12:28 +0000 (11:12 -0700)]
std: Standardize (input, output) param orderings
This functions swaps the order of arguments to a few functions that previously
took (output, input) parameters, but now take (input, output) parameters (in
that order).
bors [Mon, 30 Mar 2015 14:25:48 +0000 (14:25 +0000)]
Auto merge of #23673 - nikomatsakis:issue-23319-binops-ng-5, r=pnkfelix
The current binary operator code assumed that if the LHS was a scalar (`i32` etc), then the RHS had to match. This is not true with multidispatch. This PR generalizes the existing code to (primarily) use the traits -- this also allows us to defer the precise type-checking when the types aren't fully known. The one caveat is the unstable SIMD types, which don't fit in with the current traits -- in that case, the LHS type must be known to be SIMD ahead of time.
There is one semi-hacky bit in that during writeback, for builtin operators, if the types resolve to scalars (i32 etc) then we clear the method override. This is because we know what the semantics are and it is more efficient to generate the code directly. It also ensures that we can use these overloaded operators in constants and so forth.
Address Issue 14270 by making `cmt::freely_aliasable` result more fine-grained.
Instead of encoding the aliasability (i.e. whether the cmt is uniquely
writable or not) as an option, now pass back an enum indicating
either: 1. freely-aliasable (thus not uniquely-writable),
2. non-aliasble (thus uniquely writable), or 3. unique but immutable
(and thus not uniquely writable, according to proposal from issue
14270.)
This is all of course a giant hack that will hopefully go away with an
eventually removal of special treatment of `Box<T>` (aka `ty_unique`)
from the compiler.
projects / rust.git / log