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).
Documentation fix for E0368
Made the 'good' example compile.
I got to the [E0368 error page](https://doc.rust-lang.org/error-index.html#E0368) by following the link in the output of the
compiler. My understanding is that the first example is 'bad' and the
second one is 'good'. Following that logic, I pasted the second example
into the file and to my surprise it did not compile. This commit fixes
the example to make it paste-able.
On the other hand the docstring contained `compile_fail` flag, which might indicate that this was intentional.
I am also assuming here that the `Rust Compiler Error Index` page is generated from the file I changed.
Please let me know what do you think. Thanks a lot !
Update of the book; Error handling, section on custom error types: we…
… should also show the changes to the `cause` method.
When I started creating my own error type, I found that we also have to update the cause method, otherwise we have a missing match branch.
It would also be nice to elaborate on the relationship and difference between the description() and fmt() method, but that should be done by someone with more experience with them. :)
Correct Windows build instructions in README.md
http://mingw-w64.org/doku.php/download/mingw-builds now provides GCC 5.3 as a default version, but avoiding 5.x is exactly the reason why Mingw-builds are recommended instead of MSYS2's own mingw toolchain. One of the 4.9.x versions has to be manually chosen during installation.
r? @alexcrichton
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
http://mingw-w64.org/doku.php/download/mingw-builds now provides GCC 5.x as a default version, but avoiding 5.x is exactly the reason why Mingw-builds is recommended instead of MSYS2's own mingw toolchain. One of the 4.9.x versions has to manually chosen during installation.
Made the 'good' example compile.
I got to the E0368 error page by following the link in the output of the
compiler. My understanding is that the first example is 'bad' and the
second one is 'good'. Following that logic, I pasted the second example
into the file and to my surprise it did not compile. This commit fixes
the example to make it paste-able.
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
