mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
3e51277fe6
rust/src/test/ui/nll/match-on-borrowed.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

46 lines
1.3 KiB
Plaintext
Raw Normal View History

Make determining the discriminant a normal Shallow read Enum layout optimizations mean that the discriminant of an enum may not be stored in a tag disjoint from the rest of the fields of the enum. Stop borrow checking as though they are.
2018-12-13 14:53:07 -06:00
error[E0503]: cannot use `e` because it was mutably borrowed
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
--> $DIR/match-on-borrowed.rs:47:11
Make determining the discriminant a normal Shallow read Enum layout optimizations mean that the discriminant of an enum may not be stored in a tag disjoint from the rest of the fields of the enum. Stop borrow checking as though they are.
2018-12-13 14:53:07 -06:00
|
LL | E::V(ref mut x, _) => x,
| --------- borrow of `e.0` occurs here
...
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
LL | match e { // Don't know that E uses a tag for its discriminant
| ^ use of borrowed `e.0`
Make determining the discriminant a normal Shallow read Enum layout optimizations mean that the discriminant of an enum may not be stored in a tag disjoint from the rest of the fields of the enum. Stop borrow checking as though they are.
2018-12-13 14:53:07 -06:00
...
LL | x;
| - borrow later used here
error[E0503]: cannot use `*f` because it was mutably borrowed
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
--> $DIR/match-on-borrowed.rs:61:11
Make determining the discriminant a normal Shallow read Enum layout optimizations mean that the discriminant of an enum may not be stored in a tag disjoint from the rest of the fields of the enum. Stop borrow checking as though they are.
2018-12-13 14:53:07 -06:00
|
LL | E::V(ref mut x, _) => x,
| --------- borrow of `f.0` occurs here
...
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
LL | match f { // Don't know that E uses a tag for its discriminant
| ^ use of borrowed `f.0`
Make determining the discriminant a normal Shallow read Enum layout optimizations mean that the discriminant of an enum may not be stored in a tag disjoint from the rest of the fields of the enum. Stop borrow checking as though they are.
2018-12-13 14:53:07 -06:00
...
LL | x;
| - borrow later used here
Add tests for new match borrows
2018-09-13 16:04:00 -05:00
error[E0503]: cannot use `t` because it was mutably borrowed
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
--> $DIR/match-on-borrowed.rs:81:5
Add tests for new match borrows
2018-09-13 16:04:00 -05:00
|
LL | let x = &mut t;
| ------ borrow of `t` occurs here
LL | match t {
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
| ^^^^^^^ use of borrowed `t`
Add tests for new match borrows
2018-09-13 16:04:00 -05:00
...
LL | x;
| - borrow later used here
Fixed grammar/style in error messages and reblessed tests.
2019-09-01 12:09:59 -05:00
error[E0381]: use of possibly-uninitialized variable: `n`
Fix debugger stepping behavior around `match` expressions Previously, we would set up the source lines for `match` expressions so that the code generated to perform the test of the scrutinee was matched to the line of the arm that required the test and then jump from the arm block to the "next" block was matched to all of the lines in the `match` expression. While that makes sense, it has the side effect of causing strange stepping behavior in debuggers. I've changed the source information so that all of the generated tests are sourced to `match {scrutinee}` and the jumps are sourced to the last line of the block they are inside. This resolves the weird stepping behavior in all debuggers and resolves some instances of "ambiguous symbol" errors in WinDbg preventing the user from setting breakpoints at `match` expressions.
2021-07-23 17:55:36 -05:00
--> $DIR/match-on-borrowed.rs:93:11
Add tests for new match borrows
2018-09-13 16:04:00 -05:00
|
Update tests
2019-03-09 06:03:44 -06:00
LL | match n {}
Fixed grammar/style in error messages and reblessed tests.
2019-09-01 12:09:59 -05:00
| ^ use of possibly-uninitialized `n`
Add tests for new match borrows
2018-09-13 16:04:00 -05:00
Make determining the discriminant a normal Shallow read Enum layout optimizations mean that the discriminant of an enum may not be stored in a tag disjoint from the rest of the fields of the enum. Stop borrow checking as though they are.
2018-12-13 14:53:07 -06:00
error: aborting due to 4 previous errors
Add tests for new match borrows
2018-09-13 16:04:00 -05:00
hide `--explain` hint if error has no extended info
2019-04-17 12:26:38 -05:00
Some errors have detailed explanations: E0381, E0503.
Add tests for new match borrows
2018-09-13 16:04:00 -05:00
For more information about an error, try `rustc --explain E0381`.
Reference in New Issue Copy Permalink