| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update the graphviz tests accordingly.
Fixes #22073. (Includes regression test for the issue.)
(Factoring of aatch CFG code, Part 4.)
|
|
This breaks code that referred to variant names in the same namespace as
their enum. Reexport the variants in the old location or alter code to
refer to the new locations:
```
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
=>
```
pub use self::Foo::{A, B};
pub enum Foo {
A,
B
}
fn main() {
let a = A;
}
```
or
```
pub enum Foo {
A,
B
}
fn main() {
let a = Foo::A;
}
```
[breaking-change]
|
|
|
|
|
|
the CFG for match statements.
There were two bugs in issue #14684. One was simply that the borrow
check didn't know about the correct CFG for match statements: the
pattern must be a predecessor of the guard. This disallows the bad
behavior if there are bindings in the pattern. But it isn't enough to
prevent the memory safety problem, because of wildcards; thus, this
patch introduces a more restrictive rule, which disallows assignments
and mutable borrows inside guards outright.
I discussed this with Niko and we decided this was the best plan of
action.
This breaks code that performs mutable borrows in pattern guards. Most
commonly, the code looks like this:
impl Foo {
fn f(&mut self, ...) {}
fn g(&mut self, ...) {
match bar {
Baz if self.f(...) => { ... }
_ => { ... }
}
}
}
Change this code to not use a guard. For example:
impl Foo {
fn f(&mut self, ...) {}
fn g(&mut self, ...) {
match bar {
Baz => {
if self.f(...) {
...
} else {
...
}
}
_ => { ... }
}
}
}
Sometimes this can result in code duplication, but often it illustrates
a hidden memory safety problem.
Closes #14684.
[breaking-change]
|
|
Each test works by rendering the flowgraph for the last identified
block we see in expanded pretty-printed output, and comparing it (via
`diff`) against a checked in "foo.dot-expected.dot" file.
Each test post-processes the output to remove NodeIds ` (id=NUM)` so
that the expected output is somewhat stable (or at least independent
of how we assign NodeIds) and easier for a human to interpret when
looking at the expected output file itself.
----
Test writing style notes:
I usually tried to write the tests in a way that would avoid duplicate
labels in the output rendered flow graph, when possible.
The tests that have string literals "unreachable" in the program text
are deliberately written that way to remind the reader that the
unreachable nodes in the resulting graph are not an error in the
control flow computation, but rather a natural consequence of its
construction.
|
