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.
Optimize layout calculations in HashMap
This now produces the same assembly code as the previous implementation.
cc #51163 @nnethercote @gnzlbg @andjo403
Do not promote union field accesses
r? @eddyb
technically a breaking change, but the code errored on the previous stable and produces UB + a warning on the current stable. I don't think we need a crater run in that case.
