One negative side-effect of this change is that there might be quite a bit of copying strings out of the codemap, i.e. one copy for every block that gets translated, just for taking a look at the last character of the block. If this turns out to cause a performance problem then `CodeMap::span_to_snippet()` could be changed return `Option<&str>` instead of `Option<String>`.
Fixes#18791
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
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.
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.)
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 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
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)
(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
