Implements RFC 438.
Fixes#19092.
This is a [breaking-change]: change types like `&Foo+Send` or `&'a mut Foo+'a` to `&(Foo+Send)` and `&'a mut (Foo+'a)`, respectively.
r? @brson
...of the type being matched.
This change will result in a better diagnostic for code like the following:
```rust
enum Enum {
Foo,
Bar
}
fn f(x: Enum) {
match x {
Foo => (),
Bar => ()
}
}
```
which would currently simply fail with an unreachable pattern error
on the 2nd arm.
The user is advised to either use a qualified path in the patterns
or import the variants explicitly into the scope.
This PR adds the `rust-lldb` script (feel free to bikeshed about the name).
The script will start LLDB and, before doing anything else, load [LLDB type summaries](http://lldb.llvm.org/varformats.html) that will make LLDB print values with Rust syntax. Just use the script like you would normally use LLDB:
```
rust-lldb executable-to-debug --and-any-other-commandline --args
```
The script will just add one additional commandline argument to the LLDB invocation and pass along the rest of the arguments to LLDB after that.
Given the following program...
```rust
fn main() {
let x = Some(1u);
let y = [0, 1, 2i];
let z = (x, y);
println!("{} {} {}", x, y, z);
}
```
...*without* the 'LLDB type summaries', values will be printed something like this...
```
(lldb) p x
(core::option::Option<uint>) $3 = {
= (RUST$ENUM$DISR = Some)
= (RUST$ENUM$DISR = Some, 1)
}
(lldb) p y
(long [3]) $4 = ([0] = 0, [1] = 1, [2] = 2)
(lldb) p z
((core::option::Option<uint>, [int, ..3])) $5 = {
= {
= (RUST$ENUM$DISR = Some)
= (RUST$ENUM$DISR = Some, 1)
}
= ([0] = 0, [1] = 1, [2] = 2)
}
```
...*with* the 'LLDB type summaries', values will be printed like this:
```
(lldb) p x
(core::option::Option<uint>) $0 = Some(1)
(lldb) p y
(long [3]) $1 = [0, 1, 2]
(lldb) p z
((core::option::Option<uint>, [int, ..3])) $2 = (Some(1), [0, 1, 2])
```
The 'LLDB type summaries' used by the script have been in use for a while in the LLDB autotests but I still consider them to be of alpha-version quality. If you see anything weird when you use them, feel free to file an issue.
The script will use whatever Rust "installation" is in PATH, so whichever `rustc` will be called if you type `rustc` into the console, this is the one that the script will ask for the LLDB extension module location. The build system will take care of putting the script and LLDB python module in the right places, whether you want to use the stage1 or stage2 compiler or the one coming with `make install` / `rustup.sh`.
Since I don't have much experience with the build system, Makefiles and shell scripts, please look these changes over carefully.
This is an initial pass at stabilizing the `iter` module. The module is
fairly large, but is also pretty polished, so most of the stabilization
leaves things as they are.
Some changes:
* Due to the new object safety rules, various traits needs to be split
into object-safe traits and extension traits. This includes `Iterator`
itself. While splitting up the traits adds some complexity, it will
also increase flexbility: once we have automatic impls of `Trait` for
trait objects over `Trait`, then things like the iterator adapters
will all work with trait objects.
* Iterator adapters that use up the entire iterator now take it by
value, which makes the semantics more clear and helps catch bugs. Due
to the splitting of Iterator, this does not affect trait objects. If
the underlying iterator is still desired for some reason, `by_ref` can
be used. (Note: this change had no fallout in the Rust distro except
for the useless mut lint.)
* In general, extension traits new and old are following an [in-progress
convention](rust-lang/rfcs#445). As such, they
are marked `unstable`.
* As usual, anything involving closures is `unstable` pending unboxed
closures.
* A few of the more esoteric/underdeveloped iterator forms (like
`RandomAccessIterator` and `MutableDoubleEndedIterator`, along with
various unfolds) are left experimental for now.
* The `order` submodule is left `experimental` because it will hopefully
be replaced by generalized comparison traits.
* "Leaf" iterators (like `Repeat` and `Counter`) are uniformly
constructed by free fns at the module level. That's because the types
are not otherwise of any significance (if we had `impl Trait`, you
wouldn't want to define a type at all).
Closes#17701
Due to renamings and splitting of traits, this is a:
[breaking-change]
- Add `IntoCow` trait, and put it in the prelude
- Add `is_owned`/`is_borrowed` methods to `Cow`
- Add `CowString`/`CowVec` type aliases (to `Cow<'_, String, str>`/`Cow<'_, Vec, [T]>` respectively)
- `Cow` implements: `Show`, `Hash`, `[Partial]{Eq,Ord}`
- `impl BorrowFrom<Cow<'a, T, B>> for B`
[breaking-change]s:
- `IntoMaybeOwned` has been removed from the prelude
- libcollections: `SendStr` is now an alias to `CowString<'static>` (it was aliased to `MaybeOwned<'static>`)
- libgraphviz:
- `LabelText` variants now wrap `CowString` instead of `MaybeOwned`
- `Nodes` and `Edges` are now type aliases to `CowVec` (they were aliased to `MaybeOwnedVec`)
- libstd/path: `Display::as_maybe_owned` has been renamed to `Display::as_cow` and now returns a `CowString`
- These functions now accept/return `Cow` instead of `MaybeOwned[Vector]`:
- libregex: `Replacer::reg_replace`
- libcollections: `str::from_utf8_lossy`
- libgraphviz: `Id::new`, `Id::name`, `LabelText::pre_escaped_content`
- libstd: `TaskBuilder::named`
r? @aturon
It looks like currently kinds required by traits are not propagated when they are wrapped in a TyTrait. Additionally, in SelectionContext::builtin_bound, no attempt is made to check whether the target trait or its supertraits require the kind specified.
This PR alters SelectionContext::builtin_bound to examine all supertraits in the target trait's bounds recursively for required kinds.
Alternatively, the kinds could be added to the TyTrait upon creation (by just setting its builtin_bounds to the union of the bounds requested in this instance and the bounds required by the trait), this option may have less overhead during compilation but information is lost about which kinds were explicitly requested for this instance (vs those specified by traits/supertraits) would be lost.
Code to fragment paths into pieces based on subparts being moved around, e.g. moving `x.1` out of a tuple `(A,B,C)` leaves behind the fragments `x.0: A` and `x.2: C`. Further discussion in borrowck/doc.rs.
Includes differentiation between assigned_fragments and moved_fragments, support for all-but-one array fragments, and instrumentation to print out the moved/assigned/unmmoved/parents for each function, factored out into a separate submodule.
These fragments can then be used by `trans` to inject stack-local dynamic drop flags. (They also can be hooked up with dataflow to reduce the expected number of injected flags.)
Includes differentiation between assigned_fragments and
moved_fragments, support for all-but-one array fragments, and
instrumentation to print out the moved/assigned/unmmoved/parents for
each function, factored out into separate submodule.
This is accomplished by:
1. Add `MatchMode` enum to `expr_use_visitor`.
2. Computing the match mode for each pattern via a pre-pass, and then
passing the mode along when visiting the pattern in
expr_use_visitor.
3. Adding a `fn matched_pat` callback to expr_use_visitor, which is
called on interior struct and enum nodes of the pattern (as opposed
to `fn consume_pat`, which is only invoked for identifiers at the
leaves of the pattern), and invoking it accordingly.
Of particular interest are the `cat_downcast` instances established
when matching enum variants.
This is to fix a problem where I could not reliably map attach the
type for each loan-path to the loan-path itself because the same
loan-path was ending up associated with two different types, because
the cmt's had diverged in their interpretation of the path.
To make this clean, refactored old `LoanPath` enum into a
`LoanPath` struct with a `ty::t` and a newly-added `LoanPathVariant` enum.
This enabled me to get rid of the ugly and fragile `LoanPath::to_type`
method, and I can probably also get rid of other stuff that was
supporting it, maybe.
`LpDowncast` carries the `DefId` of the variant itself. To support
this, added the enum variant `DefId` to the `cat_downcast` variant in
`mem_categorization::categorization`.
(updated to fix mem_categorization to handle downcast of enum
struct-variants properly.)
This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename
non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all
`unwrap` methods are retained as `#[deprecated]` for the near future. To update
code rename `unwrap` method calls to `into_inner`.
[rfc]: https://github.com/rust-lang/rfcs/pull/430
[breaking-change]
cc #19091
This commit removes the `std::local_data` module in favor of a new
`std::thread_local` module providing thread local storage. The module provides
two variants of TLS: one which owns its contents and one which is based on
scoped references. Each implementation has pros and cons listed in the
documentation.
Both flavors have accessors through a function called `with` which yield a
reference to a closure provided. Both flavors also panic if a reference cannot
be yielded and provide a function to test whether an access would panic or not.
This is an implementation of [RFC 461][rfc] and full details can be found in
that RFC.
This is a breaking change due to the removal of the `std::local_data` module.
All users can migrate to the new thread local system like so:
thread_local!(static FOO: Rc<RefCell<Option<T>>> = Rc::new(RefCell::new(None)))
The old `local_data` module inherently contained the `Rc<RefCell<Option<T>>>` as
an implementation detail which must now be explicitly stated by users.
[rfc]: https://github.com/rust-lang/rfcs/pull/461
[breaking-change]
This change applies the conventions to unwrap listed in [RFC 430][rfc] to rename
non-failing `unwrap` methods to `into_inner`. This is a breaking change, but all
`unwrap` methods are retained as `#[deprecated]` for the near future. To update
code rename `unwrap` method calls to `into_inner`.
[rfc]: https://github.com/rust-lang/rfcs/pull/430
[breaking-change]
Closes#13159
cc #19091
This breaks code like
```
let t = (42i, 42i);
... t.0::<int> ...;
```
Change this code to not contain an unused type parameter. For example:
```
let t = (42i, 42i);
... t.0 ...;
```
Closes https://github.com/rust-lang/rust/issues/19096
[breaking-change]
r? @aturon
This commit is an implementation of [RFC 240][rfc] when applied to the standard
library. It primarily deprecates the entirety of `string::raw`, `vec::raw`,
`slice::raw`, and `str::raw` in favor of associated functions, methods, and
other free functions. The detailed renaming is:
* slice::raw::buf_as_slice => slice::from_raw_buf
* slice::raw::mut_buf_as_slice => slice::from_raw_mut_buf
* slice::shift_ptr => deprecated with no replacement
* slice::pop_ptr => deprecated with no replacement
* str::raw::from_utf8 => str::from_utf8_unchecked
* str::raw::c_str_to_static_slice => str::from_c_str
* str::raw::slice_bytes => deprecated for slice_unchecked (slight semantic diff)
* str::raw::slice_unchecked => str.slice_unchecked
* string::raw::from_parts => String::from_raw_parts
* string::raw::from_buf_len => String::from_raw_buf_len
* string::raw::from_buf => String::from_raw_buf
* string::raw::from_utf8 => String::from_utf8_unchecked
* vec::raw::from_buf => Vec::from_raw_buf
All previous functions exist in their `#[deprecated]` form, and the deprecation
messages indicate how to migrate to the newer variants.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0240-unsafe-api-location.md
[breaking-change]
Closes#17863
This commit is an implementation of [RFC 240][rfc] when applied to the standard
library. It primarily deprecates the entirety of `string::raw`, `vec::raw`,
`slice::raw`, and `str::raw` in favor of associated functions, methods, and
other free functions. The detailed renaming is:
* slice::raw::buf_as_slice => slice::with_raw_buf
* slice::raw::mut_buf_as_slice => slice::with_raw_mut_buf
* slice::shift_ptr => deprecated with no replacement
* slice::pop_ptr => deprecated with no replacement
* str::raw::from_utf8 => str::from_utf8_unchecked
* str::raw::c_str_to_static_slice => str::from_c_str
* str::raw::slice_bytes => deprecated for slice_unchecked (slight semantic diff)
* str::raw::slice_unchecked => str.slice_unchecked
* string::raw::from_parts => String::from_raw_parts
* string::raw::from_buf_len => String::from_raw_buf_len
* string::raw::from_buf => String::from_raw_buf
* string::raw::from_utf8 => String::from_utf8_unchecked
* vec::raw::from_buf => Vec::from_raw_buf
All previous functions exist in their `#[deprecated]` form, and the deprecation
messages indicate how to migrate to the newer variants.
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0240-unsafe-api-location.md
[breaking-change]
Closes#17863
The struct_variant is not gated anymore. This commit just removes it and the resulting warnings when compiling rust. Now compiles with the snapshot from 11/18 (as opposed to PR #19014)
'Numeric' is the proper name of the unicode character class,
and this frees up the word 'digit' for ascii use in libcore.
Since I'm going to rename `Char::is_digit_radix` to
`is_digit`, I am not leaving a deprecated method in place,
because that would just cause name clashes, as both
`Char` and `UnicodeChar` are in the prelude.
[breaking-change]
Fixies #11671
This commit changes default relative libdir 'lib' to a relative libdir calculated using LIBDIR provided by --libdir configuration option. In case if no option was provided behavior does not change.
In the general case, at least, it is not possible to make an object out of an unsized type. This is because the object type would have to store the fat pointer information for the `self` value *and* the vtable -- meaning it'd have to be a fat pointer with three words -- but for the compiler to know that the object requires three words, it would have to know the self-type of the object (is `self` a thin or fat pointer?), which of course it doesn't.
Fixes#18333.
r? @nick29581
(Previously, scopes were solely identified with NodeId's; this
refactoring prepares for a future where that does not hold.)
Ground work for a proper fix to #8861.
(Previously, statically identifiable scopes/regions were solely
identified with NodeId's; this refactoring prepares for a future
where that 1:1 correspondence does not hold.)
Use the expected type to infer the argument/return types of unboxed closures. Also, in `||` expressions, use the expected type to decide if the result should be a boxed or unboxed closure (and if an unboxed closure, what kind).
This supercedes PR #19089, which was already reviewed by @pcwalton.
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc].
There are a number of breaking changes as a part of this commit which will need
to be handled to migrated old code:
* A number of formatting traits have been removed: String, Bool, Char, Unsigned,
Signed, and Float. It is recommended to instead use Show wherever possible or
to use adaptor structs to implement other methods of formatting.
* The format specifier for Boolean has changed from `t` to `b`.
* The enum `FormatError` has been renamed to `Error` as well as becoming a unit
struct instead of an enum. The `WriteError` variant no longer exists.
* The `format_args_method!` macro has been removed with no replacement. Alter
code to use the `format_args!` macro instead.
* The public fields of a `Formatter` have become read-only with no replacement.
Use a new formatting string to alter the formatting flags in combination with
the `write!` macro. The fields can be accessed through accessor methods on the
`Formatter` structure.
Other than these breaking changes, the contents of std::fmt should now also all
contain stability markers. Most of them are still #[unstable] or #[experimental]
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md
[breaking-change]
Closes#18904
Ensure that the type parameters passed to methods outlive the call expression.
Fixes#18899.
This is yet another case of forgotten to consistently enforce the constraints in every instance where they apply. Might be nice to try and refactor to make this whole thing more DRY, but for now here's a targeted fix.
r? @pcwalton
This fixes#17388.
Note that we don't check type parameters in trait-references and so on, so we accept some nonsense (I opened https://github.com/rust-lang/rust/issues/18865). (It may be easier to just add support for `T::Foo` and deprecate the qpath code until we can implement it more robustly using the trait lookup infrastructure, not sure.)
This commit applies the stabilization of std::fmt as outlined in [RFC 380][rfc].
There are a number of breaking changes as a part of this commit which will need
to be handled to migrated old code:
* A number of formatting traits have been removed: String, Bool, Char, Unsigned,
Signed, and Float. It is recommended to instead use Show wherever possible or
to use adaptor structs to implement other methods of formatting.
* The format specifier for Boolean has changed from `t` to `b`.
* The enum `FormatError` has been renamed to `Error` as well as becoming a unit
struct instead of an enum. The `WriteError` variant no longer exists.
* The `format_args_method!` macro has been removed with no replacement. Alter
code to use the `format_args!` macro instead.
* The public fields of a `Formatter` have become read-only with no replacement.
Use a new formatting string to alter the formatting flags in combination with
the `write!` macro. The fields can be accessed through accessor methods on the
`Formatter` structure.
Other than these breaking changes, the contents of std::fmt should now also all
contain stability markers. Most of them are still #[unstable] or #[experimental]
[rfc]: https://github.com/rust-lang/rfcs/blob/master/text/0380-stabilize-std-fmt.md
[breaking-change]
Closes#18904
Make old-fashioned functions in the `std::os` module utilize `IoResult`.
I'm still investigating the possibility to include more functions in this pull request. Currently, it covers `getcwd()`, `make_absolute()`, and `change_dir()`. The issues covered by this PR are #16946 and #16315.
A few concerns:
- Should we provide `OsError` in distinction from `IoError`? I'm saying this because in Python, those two are distinguished. One advantage that we keep using `IoError` is that we can make the error cascade down other functions whose return type also includes `IoError`. An example of such functions is `std::io::TempDir::new_in()`, which uses `os::make_absolute()` as well as returns `IoResult<TempDir>`.
- `os::getcwd()` uses an internal buffer whose size is 2048 bytes, which is passed to `getcwd(3)`. There is no upper limitation of file paths in the POSIX standard, but typically it is set to 4096 bytes such as in Linux. Should we increase the buffer size? One thing that makes me nervous is that the size of 2048 bytes already seems a bit excessive, thinking that in normal cases, there would be no filenames that even exceeds 512 bytes.
Fixes#16946.
Fixes#16315.
Any ideas are welcomed. Thanks!
os::getcwd() panics if the current directory is not available. According
to getcwd(3), there are three cases:
- EACCES: Permission denied.
- ENOENT: The current working directory has been removed.
- ERANGE: The buffer size is less than the actual absolute path.
This commit makes os::getcwd() return IoResult<Path>, not just Path,
preventing it from panicking.
As os::make_absolute() depends on os::getcwd(), it is also modified to
return IoResult<Path>.
Fixes#16946.
[breaking-change]
region binding at the impl site, so for method types that come from impls,
it is necessary to liberate/instantiate late-bound regions at multiple
depths.
Reduces memory usage significantly and opens opportunities for more parallel compilation.
This PR was previously #19002 but I closed it because bors didn't seem to recognize the `r+` annotations there.
The trait has an obvious, sensible implementation directly on vectors so
the MemWriter wrapper is unnecessary. This will halt the trend towards
providing all of the vector methods on MemWriter along with eliminating
the noise caused by conversions between the two types. It also provides
the useful default Writer methods on Vec<u8>.
After the type is removed and code has been migrated, it would make
sense to add a new implementation of MemWriter with seeking support. The
simple use cases can be covered with vectors alone, and ones with the
need for seeks can use a new MemWriter implementation.
The trait has an obvious, sensible implementation directly on vectors so
the MemWriter wrapper is unnecessary. This will halt the trend towards
providing all of the vector methods on MemWriter along with eliminating
the noise caused by conversions between the two types. It also provides
the useful default Writer methods on Vec<u8>.
After the type is removed and code has been migrated, it would make
sense to add a new implementation of MemWriter with seeking support. The
simple use cases can be covered with vectors alone, and ones with the
need for seeks can use a new MemWriter implementation.
Hello,
`dylib` [seems][1] to be no longer an option for the `kind` key of the `link` attribute.
UPDATE: It should be the other way around: It [seems][1] `dylib` has been lost as a possible variant of the `kind` key of the `link` attribute. See the comment below.
Regards,
Ivan
[1]: 8f87538786/src/librustc/metadata/creader.rs (L237)
creating a new Id object requires the format to match a subset of `ID` format defined by the DOT language. When the format did not match, the function called assert. This was not mentioned in the docs or the spec. I made the failure explicit by returning an Result<Id, ()>.
Following [the collections reform RFC](https://github.com/rust-lang/rfcs/pull/235), this PR:
* Adds a new `borrow` module to libcore. The module contains traits for borrowing data (`BorrowFrom` and `BorrowFromMut`), generalized cloning (`ToOwned`), and a clone-on-write smartpointer (`Cow`).
* Deprecates the `_equiv` family of methods on `HashMap` and `HashSet` by instead generalizing the "normal" methods like `get` and `remove` to use the new `std::borrow` infrastructure.
* Generalizes `TreeMap`, `TreeSet`, `BTreeMap` and `BTreeSet` to use the new `std::borrow` infrastructure for lookups.
[breaking-change]
This is especially useful for declaring a static with external linkage in an executable. There isn't any way to do that currently since we mark everything in an executable as internal by default.
Also, a quick fix to have the no-compiler-rt target option respected when building staticlibs as well.
groundwork for better performance.
Key points:
- Separate out determining which method to use from actually selecting
a method (this should enable caching, as well as the pcwalton fast-reject strategy).
- Merge the impl selection back into method resolution and don't rely on
trait matching (this should perform better but also is needed to resolve some
kind of conflicts, see e.g. `method-two-traits-distinguished-via-where-clause.rs`)
- Purge a lot of out-of-date junk and coercions from method lookups.
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
creating a new Id object requires the format to match a subset of `ID` format defined by the DOT language. When the format did not match, the function called assert. This was not mentioned in the docs or the spec. I made the failure explicit by returning an Result<Id, ()>.
not in hardcoded libdir path. If there was no LIBDIR provided
during configuration fallback to hardcoded paths.
Thanks to Jan Niklas Hasse for solution and to Alex Crichton for improvements.
Closes#11671
This was a simple case of substitutions being applied inconsistently. I haven't investigated why type parameters are actually showing up in the closure type here, but trans needs to handle them correctly in any case.
This implements a considerable portion of rust-lang/rfcs#369 (tracked in #18640). Some interpretations had to be made in order to get this to work. The breaking changes are listed below:
[breaking-change]
- `core::num::{Num, Unsigned, Primitive}` have been deprecated and their re-exports removed from the `{std, core}::prelude`.
- `core::num::{Zero, One, Bounded}` have been deprecated. Use the static methods on `core::num::{Float, Int}` instead. There is no equivalent to `Zero::is_zero`. Use `(==)` with `{Float, Int}::zero` instead.
- `Signed::abs_sub` has been moved to `std::num::FloatMath`, and is no longer implemented for signed integers.
- `core::num::Signed` has been removed, and its methods have been moved to `core::num::Float` and a new trait, `core::num::SignedInt`. The methods now take the `self` parameter by value.
- `core::num::{Saturating, CheckedAdd, CheckedSub, CheckedMul, CheckedDiv}` have been removed, and their methods moved to `core::num::Int`. Their parameters are now taken by value. This means that
- `std::time::Duration` no longer implements `core::num::{Zero, CheckedAdd, CheckedSub}` instead defining the required methods non-polymorphically.
- `core::num::{zero, one, abs, signum}` have been deprecated. Use their respective methods instead.
- The `core::num::{next_power_of_two, is_power_of_two, checked_next_power_of_two}` functions have been deprecated in favor of methods defined a new trait, `core::num::UnsignedInt`
- `core::iter::{AdditiveIterator, MultiplicativeIterator}` are now only implemented for the built-in numeric types.
- `core::iter::{range, range_inclusive, range_step, range_step_inclusive}` now require `core::num::Int` to be implemented for the type they a re parametrized over.
This patch tweaks the stability inheritance infrastructure so that
`#{stable]` attributes are not inherited. Doing so solves two problems:
1. It allows us to mark module *names* as stable without accidentally
marking the items they contain as stable.
2. It means that a `#[stable]` attribution must always appear directly
on the item it applies to, which makes it easier for reviewers to catch
changes to stable APIs.
Fixes#17484
This commit deprecates the entire libtime library in favor of the
externally-provided libtime in the rust-lang organization. Users of the
`libtime` crate as-is today should add this to their Cargo manifests:
[dependencies.time]
git = "https://github.com/rust-lang/time"
To implement this transition, a new function `Duration::span` was added to the
`std::time::Duration` time. This function takes a closure and then returns the
duration of time it took that closure to execute. This interface will likely
improve with `FnOnce` unboxed closures as moving in and out will be a little
easier.
Due to the deprecation of the in-tree crate, this is a:
[breaking-change]
cc #18855, some of the conversions in the `src/test/bench` area may have been a
little nicer with that implemented
This commit deprecates the entire libtime library in favor of the
externally-provided libtime in the rust-lang organization. Users of the
`libtime` crate as-is today should add this to their Cargo manifests:
[dependencies.time]
git = "https://github.com/rust-lang/time"
To implement this transition, a new function `Duration::span` was added to the
`std::time::Duration` time. This function takes a closure and then returns the
duration of time it took that closure to execute. This interface will likely
improve with `FnOnce` unboxed closures as moving in and out will be a little
easier.
Due to the deprecation of the in-tree crate, this is a:
[breaking-change]
cc #18855, some of the conversions in the `src/test/bench` area may have been a
little nicer with that implemented
Substs were not applied when calling `untuple_arguments_if_necessary`.
Just apply them once at the start of the function, rebinding `fty`.
Also change the function to take them by reference since we don't
need to consume them at all. Closes#18883
This patch tweaks the stability inheritance infrastructure so that
`#{stable]` attributes are not inherited. Doing so solves two problems:
1. It allows us to mark module *names* as stable without accidentally
marking the items they contain as stable.
2. It means that a `#[stable]` attribution must always appear directly
on the item it applies to, which makes it easier for reviewers to catch
changes to stable APIs.
Fixes#17484
Based on Windows bundle feedback we got to date,
- We *do* want to prefer the bundled linker: The external one might be for the wrong architecture (e.g. 32 bit vs 64 bit). On the other hand, binutils don't add many new features these days, so using an older bundled linker is not likely to be a problem.
- We *do* want to prefer bundled libraries: The external ones might not have the symbols we expect (e.g. what's needed for DWARF exceptions vs SjLj). Since `-L rustlib/<triple>/lib` appears first on the linker command line, it's a good place to keep our platform libs that we want to be found first.
Closes#18325, closes#17726.
Various miscellaneous changes pushing towards HRTB support:
1. Update parser and adjust ast to support `for<'a,'b>` syntax, both in closures and trait bounds. Warn on the old syntax (not error, for stage0).
2. Refactor TyTrait representation to include a TraitRef.
3. Purge `once_fns` feature gate and `once` keyword.
r? @pcwalton
This is a [breaking-change]:
- The `once_fns` feature is now officially deprecated. Rewrite using normal closures or unboxed closures.
- The new `for`-based syntax now issues warnings (but not yet errors):
- `fn<'a>(T) -> U` becomes `for<'a> fn(T) -> U`
- `<'a> |T| -> U` becomes `for<'a> |T| -> U`
`FnOnce` environments that fit within an `int` are passed to the closure by value. For some reason there was an assert that this would only happen if there were 1 or 0 free variables, but it can also happen if there are multiple variables that happen to fit.
Closes#18652
When establishing region links within a pattern, use the mem-cat
of the type the pattern matches against (that is, the result
of `iter.next()`) rather than that of the iterator type.
Closes#17068Closes#18767
This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.
This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.
cc #18585
I wanted to embed an `Rc<TraitRef>`, but I was foiled by the current
static rules, which prohibit non-Sync values from being stored in
static locations. This means that the constants for `ty_int` and so
forth cannot be initialized.
This resolves some issues that remained after adding support for monomorphizing unboxed closures in trans.
There were a few places where a set of substitutions for an unboxed closure type were dropped on the floor and later recalculated from scratch based on the def ID, but this failed spectacularly when the closure originated from a different param environment. The substitutions are now plumbed through end-to-end. Closes#18661
There was also a conflict in the meaning of the self param space within the body of the unboxed closure. Trans attempted to insert the unboxed closure type as the self type, but this could conflict with the self type from the param environment when an unboxed closure was used within a default method on a trait. Since the body of an unboxed closure cannot refer to its own self type or value, there's no need for it to actually use the self space. The downstream consumers of the substitutions in trans do not seem to need it either since they look up the type of the closure some other way, so I just stopped setting it. Closes#18685.
r? @pcwalton @nikomatsakis
This commit implements processing these two attributes at the crate level as
well as at the item level. When #[cfg] is applied at the crate level, then the
entire crate will be omitted if the cfg doesn't match. The #[cfg_attr] attribute
is processed as usual in that the attribute is included or not depending on
whether the cfg matches.
This was spurred on by motivations of #18585 where #[cfg_attr] annotations will
be applied at the crate-level.
cc #18585
Fixes#18567. `Struct{x:foo, .. with_expr}` did not walk `with_expr`, which allowed
using moved variables in some cases. The CFG for structs also built up with
`with_expr` happening before the fields, which is now reversed. (Fields are now
before the `with_expr` in the CFG)
As an optimization, once unboxed closures receive their environment by
value if it fits within the size of an `int`. An assert in this code
path assumed that this would only occur if the environment had no more
than a single free variable in it, but multiple smaller free variables
can easily be packed into the space of an `int`, particularly if any
of them are 0-sized. The assert can simply be removed.
Closes#18652
- When selecting an implicit trait impl for an unboxed closure, plumb
through and use the substitutions from impl selection instead of
using those from the current param environment in trans, which may
be incorrect.
- When generating a function declaration for an unboxed closure, plumb
through the substitutions from the param environment of the closure
as above. Also normalize the type to avoid generating duplicate
declarations due to regions being inconsistently replaced with
ReStatic elsewhere.
- Do not place the closure type in the self param space when
translating the unboxed closure callee, etc. It is not actually
used, and doing so conflicts with the self substitution from
default trait methods.
Closes#18661Closes#18685
Fixes#18567. Struct{x:foo, .. with_expr} did not walk with_expr, which allowed
using moved variables in some cases. The CFG for structs also built up with
with_expr happening before the fields, which is now reversed. (Fields are now
before the with_expr in the CFG)
This commit adds support for linting `extern crate` statements for stability
attributes attached to the crate itself. This is likely to be the mechanism used
to deny access to experimental crates that are part of the standard
distribution.
cc #18585
r? @aturon
`eq`, `ne`, `cmp`, etc methods now require one less level of indirection when dealing with `&str`/`&[T]`
``` rust
"foo".ne(&"bar") -> "foo".ne("bar")
slice.cmp(&another_slice) -> slice.cmp(another_slice)
// slice and another_slice have type `&[T]`
```
[breaking-change]
variables in the intracrate case. This requires a deeper distinction
between inter- and intra-crate so as to keep coherence working.
I suspect the best fix is to generalize the recursion check that
exists today, but this requires a bit more refactoring to achieve.
(In other words, where today it says OK for an exact match, we'd want
to not detect exact matches but rather skolemize each trait-reference
fresh and return AMBIG -- but that requires us to make builtin bounds
work shallowly like everything else and move the cycle detection into
the fulfillment context.)
This branch cleans up overloaded operator resolution so that it is strictly based on the traits in `ops`, rather than going through the normal method lookup mechanism. It also adds full support for autoderef to overloaded index (whereas before autoderef only worked for non-overloaded index) as well as for the slicing operators.
This is a [breaking-change]: in the past, we were accepting combinations of operands that were not intended to be accepted. For example, it was possible to compare a fixed-length array and a slice, or apply the `!` operator to a `&int`. See the first two commits in this pull-request for examples.
One downside of this change is that comparing fixed-length arrays doesn't always work as smoothly as it did before. Before this, comparisons sometimes worked due to various coercions to slices. I've added impls for `Eq`, `Ord`, etc for fixed-lengths arrays up to and including length 32, but if the array is longer than that you'll need to either newtype the array or convert to slices. Note that this plays better with deriving in any case than the previous scheme.
Fixes#4920.
Fixes#16821.
Fixes#15757.
cc @alexcrichton
cc @aturon
Key points are:
1. `a + b` maps directly to `Add<A,B>`, where `A` and `B` are the types of `a` and `b`.
2. Indexing and slicing autoderefs consistently.
This fixes some metadata/AST encoding problems that lead to ICEs. The way this is currently handled will need revisiting if abstract return types are added, as unboxed closure types from extern crates could show up without being inlined into the local crate.
Closes#16790 (I think this was fixed earlier by accident and just needed a test case)
Closes#18378Closes#18543
r? @pcwalton
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
This commit adds support for linting `extern crate` statements for stability
attributes attached to the crate itself. This is likely to be the mechanism used
to deny access to experimental crates that are part of the standard
distribution.
cc #18585
This almost completely avoids GEPi's and pointer manipulation,
postponing it until the end with one big write of the whole vector. This
leads to a small speed-up in compilation, and makes it easier for LLVM
to work with the values, e.g. with `--opt-level=0`,
pub fn foo() -> f32x4 {
f32x4(0.,0.,0.,0.)
}
was previously compiled to
define <4 x float> @_ZN3foo20h74913e8b13d89666eaaE() unnamed_addr #0 {
entry-block:
%sret_slot = alloca <4 x float>
%0 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 0
store float 0.000000e+00, float* %0
%1 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 1
store float 0.000000e+00, float* %1
%2 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 2
store float 0.000000e+00, float* %2
%3 = getelementptr inbounds <4 x float>* %sret_slot, i32 0, i32 3
store float 0.000000e+00, float* %3
%4 = load <4 x float>* %sret_slot
ret <4 x float> %4
}
but now becomes
define <4 x float> @_ZN3foo20h74913e8b13d89666eaaE() unnamed_addr #0 {
entry-block:
ret <4 x float> zeroinitializer
}
Removes all target-specific knowledge from rustc. Some targets have changed
during this, but none of these should be very visible outside of
cross-compilation. The changes make our targets more consistent.
iX86-unknown-linux-gnu is now only available as i686-unknown-linux-gnu. We
used to accept any value of X greater than 1. i686 was released in 1995, and
should encompass the bare minimum of what Rust supports on x86 CPUs.
The only two windows targets are now i686-pc-windows-gnu and
x86_64-pc-windows-gnu.
The iOS target has been renamed from arm-apple-ios to arm-apple-darwin.
A complete list of the targets we accept now:
arm-apple-darwin
arm-linux-androideabi
arm-unknown-linux-gnueabi
arm-unknown-linux-gnueabihf
i686-apple-darwin
i686-pc-windows-gnu
i686-unknown-freebsd
i686-unknown-linux-gnu
mips-unknown-linux-gnu
mipsel-unknown-linux-gnu
x86_64-apple-darwin
x86_64-unknown-freebsd
x86_64-unknown-linux-gnu
x86_64-pc-windows-gnu
Closes#16093
[breaking-change]
Closes#18126.
At the moment this mostly only changes notes that are particularly help-oriented or directly suggest the user to do something to help messages, and does not change messages that simply explain an error message further. If it is decided that those messages should also be help messages, I can add them to this PR, but for now I’m excluding them as I believe that changing those messages might leave very few places where notes would be appropriate.
There's currently a bug in it which fires erroneously on cross compiles,
preventing new nightlies from being generated. This can be reset back to Deny
once it's been fixed.
cc #18587
If a dylib is being produced, the compiler will now first check to see if it can
be created entirely statically before falling back to dynamic dependencies. This
behavior can be overridden with `-C prefer-dynamic`.
Due to the alteration in behavior, this is a breaking change. Any previous users
relying on dylibs implicitly maximizing dynamic dependencies should start
passing `-C prefer-dynamic` to compilations.
Closes#18499
[breaking-change]
There's currently a bug in it which fires erroneously on cross compiles,
preventing new nightlies from being generated. This can be reset back to Deny
once it's been fixed.
cc #18587
