This patch adds depth markings to all entries in the `ScopeTree`'s
`parent_map`. This change increases memory usage somewhat, but permits a
much faster algorithm to be used:
- If one scope has a greater depth than the other, the deeper scope is
moved upward until they are at equal depths.
- Then we move the two scopes upward in lockstep until they match.
This avoids the need to keep track of which scopes have already been
seen, which was the major part of the cost of the old algorithm. It also
reduces the number of child-to-parent moves (which are hash table
lookups) when the scopes start at different levels, because it never
goes past the nearest common ancestor the way the old algorithm did.
Finally, the case where one of the scopes is the root is now handled in
advance, because that is moderately common and lets us skip everything.
This change speeds up runs of several rust-perf benchmarks, the best by
6%.
When using `..` somewhere other than the end, parse the rest of the
pattern correctly while still emitting an error.
Add suggestions to either remove trailing `,` or moving the `..` to the
end.
We currently give a specific message when encountering a `..` anywhere
other than the end of a pattern. Modify the parser to accept it (while
still emitting the error) so that we don't also trigger "missing fields
in pattern" errors afterwards.
Rollup of 7 pull requests
Successful merges:
- #50852 (Add doc comment to hiding portions of code example)
- #51183 (Update rustdoc book to suggest using Termination trait instead of hidden ‘foo’ function)
- #51255 (Fix confusing error message for sub_instant)
- #51256 (Fix crate-name option in rustdoc)
- #51308 (Check array indices in constant propagation)
- #51343 (test: Ignore some problematic tests on sparc and sparc64)
- #51358 (Tests that #39963 is fixed on MIR borrowck)
Failed merges:
Check array indices in constant propagation
Previously, uses of constant weren't correctly propagated.
This fixes#48920.
r? @oli-obk because you suggested it
Fix confusing error message for sub_instant
When subtracting an Instant from another, the function will panick when `RHS > self`, but the error message confusingly displays a different error:
```rust
let i = Instant::now();
let other = Instant::now();
if other > i {
println!("{:?}", i - other);
}
```
This results in a panic:
```
thread 'test_instant' panicked at 'other was less than the current instant', libstd/sys/unix/time.rs:292:17
```
But clearly, `other` was actually greater than the current instant.
Update rustdoc book to suggest using Termination trait instead of hidden ‘foo’ function
Closes#50721.
I suggest that someone double-checks my English since I am not a native speaker.
r? @steveklabnik
Add doc comment to hiding portions of code example
fixes#50816
Not sure if this is all that's needed, but I think it's a good start. One thing to note is that the code block is a text block where it could possibly be a rust block.
Select Polonius algorithm via `POLONIUS_ALGORITHM` environment variable
This pull request allows selecting the Polonius algorithm being used by providing an environment variable `POLONIUS_ALGORITHM`.
Example usage:
```
POLONIUS_ALGORITHM=compare RUST_LOG=rustc_mir::borrow_check::nll=trace ./x.py test --stage 1 --compare-mode polonius -- src/test/ui/nll/issue-47680.rs
...
stderr:
------------------------------------------
INFO 2018-05-31T17:35:31Z: rustc_mir::borrow_check::nll: Using Polonius algorithm: Compare
INFO 2018-05-31T17:35:31Z: rustc_mir::borrow_check::nll: Using Polonius algorithm: Compare
------------------------------------------
...
```
r? @nikomatsakis
When writing a struct literal in an expression that expects a block to
be started afterwards (like an `if` statement), do not suggest using the
same struct literal:
```
did you mean `S { /* fields * /}`?
```
Instead, suggest surrounding the expression with parentheses:
```
did you mean `(S { /* fields * /})`?
```
Suggest not mutably borrowing a mutable reference
This PR would (hopefully) solve #45392. I deviated a bit from @estebank's instructions since the error span only included the borrowed expression (e.g. the `b` in `&mut b`). I also didn't check the mutability of the local binding, since this whole case is concerned with an immutable local.
I can see two outstanding questions:
1. `note_immutability_blame` is called in two places, but I only have one test case. I think it covers the call in `report_bckerror`, but I'm not sure how to trigger the call from `report_aliasability_violation`.
2. There is one failing test, where the local binding is `self: &mut Self`. I'm not entirely sure what the correct output should be, but I think the new message should also apply. Unfortunately, since this parameter is parsed differently, its `let_span` covers both the pattern and the type, leading to a wrong suggestion text. I'm not sure how to correctly identify this case.
