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.
