Instead, create a single MovePathIndex that represents all statics.
(An alternative here would be to disallow representing statics at all.
I am hesitant to do that right now, in part because it could impose a
requirement that I thread checks for static data into the calling
code, either as pre- or post-invocation of `fn move_path_for`.)
emit (via debug!) scary message from `fn borrowck_mir` until basic
prototype is in place.
Gather children of move paths and set their kill bits in
dataflow. (Each node has a link to the child that is first among its
siblings.)
Hooked in libgraphviz based rendering, including of borrowck dataflow
state.
doing this well required some refactoring of the code, so I cleaned it
up more generally (adding comments to explain what its trying to do
and how it is doing it).
Update: this newer version addresses most review comments (at least
the ones that were largely mechanical changes), but I left the more
interesting revisions to separate followup commits (in this same PR).
Fix mis-uses of projection mode
A couple of places where we construct a fresh inference context were
incorrectly assuming that we were past coherence checking. This commit
corrects them to use `Topmost` rather than `AnyFinal` as the projection mode.
Fixes#32324
r? @nikomatsakis
Update snapshots to 2016-03-18 (235d774).
The new snapshots notably include @nikomatsakis' #32164 fix for the regionck error spew.
Also, `./configure --enable-orbit` *and/or* `make RUSTFLAGS="-Z orbit"` should work now (#32080).
A couple of places where we construct a fresh inference context were
incorrectly assuming that we were past coherence checking. This commit
corrects them to use `Topmost` rather than `AnyFinal` as the projection mode.
Fixes#32324
docs: The `data-layout` field is no longer required in custom targets
The `data-layout` field is no longer required. It was made optional in 958d563825.
The `os` field is always required.
Related to #31367
Alter E0412 help message wording
The initial wording does not make sense due to an extra 'to'.
There are two potential candidates we can change this to:
- 'you can import it into scope'
- 'to import it into scope'
In keeping the changes minimal, we choose the first, as this is more in line with the grammar of the extended candidates help message.
The initial wording does not make sense due to an extra 'to'.
There are two potential candidates we can change this to:
- 'you can import it into scope'
- 'to import it into scope'
In keeping the changes minimal, we choose the first, as this is more in line with the grammar of the extended candidates help message.
Fix floating point fast-math intrinsics
The implementation did not handle the case where both operands were constants, which caused an llvm assertion:
```
rustc: //buildslave//rust-buildbot//slave//nightly-dist-rustc-musl-linux//build//src//llvm//include/llvm/Support/Casting.h:237:
typename llvm::cast_retty<X, Y*>::ret_type llvm::cast(Y*) [with X = llvm::Instruction; Y = llvm::Value; typename llvm::cast_retty<X, Y*>::ret_type = llvm::Instruction*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
```
Change compare_exchange to return a Result<T, T>
As per the discussion in #31767
I also changed the feature name from `extended_compare_and_swap` to `compare_exchange`.
r? @alexcrichton
std: Revert addition of `into_ascii_*` methods
The addition of these methods in #31335 required adding impls of the trait for
the `String` and `Vec<T>` types. This unfortunately caused a regression (#32074)
in type inference for using these methods which the libs team has decided to not
push forward with. These methods were stabilized in #32020 which was intended to
get backported to beta, but the backport hasn't happened just yet. This commit
reverts both the addition and stabilization of these methods.
One proposed method of handling this, in #32076, was to move the methods to an
extra trait to avoid conflicts with type inference. After some discussion,
however, the libs team concluded that we probably want to reevaluate what we're
doing here, so discussion will continue on the tracking issue, #27809.
Closes#32074
Fixes issue #29124.
If method is called on a function type a note is generated to suggest
that the developer may have forgotten to call it.
e.g.
fn main() {
let mut guess = String::new();
std::io::stdin.read_line(&mut guess);
}
will generate the note:
note: called method on function type. did you mean `std::io::stdin().read_line(..)`?
Use explicit -march flags in the i586 mk file
`-march` should definitely go last, after the environment `$C(XX)FLAGS`, or it's going to remain brittle.
This should fix cross-compilation issues on x86_64 (possibly x86 too on some newer distros) - it was far too assuming of me to expect you really had to want i586 using your own flags.
Make AssertRecoverSafe's field public
It's basically the very definition of a newtype, so we might as well
make things easy on people and let them construct and access it
directly.
r? @aturon
docs: `let` introduces a statement
I changes *expression* to *statement* to make more accurate, because in Rust, `let` introduces a declaration statement.
Fix usability problem when browse document locally
You cannot use `history.replaceState` when you browse locally, it breaks the security policy of Chrome and perhaps other browsers.
Closes https://github.com/rust-lang/rust/issues/32307
Thank @crumblingstatue for the help!
syntax: impl ToTokens for P<ast::ImplItem>
I'm working on updating zinc for latest rust, and it appears that I need this impl[0].
More generally, I realise that libsyntax is "Whatever the compiler team needs to build a compiler", but should I just open a PR fleshing this out for all types?
https://github.com/hackndev/zinc/blob/master/ioreg/src/builder/setter.rs#L194-L197
