This PR adds a `UnificationTable` to the `TypeVariableTable` type which
is used store information about variable equality instead of just
storing them in a vector for later processing. By using a
`UnificationTable` equality relations can be resolved in O(n) (for all
realistic values of n) rather than O(n!) which can give massive
speedups in certain cases (see combine as an example).
Link to combine: https://github.com/Marwes/combine
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.
