nordic-dev.net/rust
nordic-dev.net/rust
2
0
Fork 0
mirror of https://github.com/rust-lang/rust.git synced 2024-11-27 09:14:20 +00:00
Code Issues Packages Projects Releases Wiki Activity
959b2c703d
rust/tests/ui/nll/match-on-borrowed.stderr

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

53 lines
1.5 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 20:53:07 +00: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 22:55:36 +00: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 20:53:07 +00:00
|
LL | E::V(ref mut x, _) => x,
Tweak E0597 CC #99430
2023-01-15 03:06:44 +00:00
| --------- `e.0` is borrowed here
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 20:53:07 +00:00
...
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 22:55:36 +00: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 20:53:07 +00: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 22:55:36 +00: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 20:53:07 +00:00
|
LL | E::V(ref mut x, _) => x,
Tweak E0597 CC #99430
2023-01-15 03:06:44 +00:00
| --------- `f.0` is borrowed here
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 20:53:07 +00:00
...
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 22:55:36 +00: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 20:53:07 +00:00
...
LL | x;
| - borrow later used here
Add tests for new match borrows
2018-09-13 21:04:00 +00: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 22:55:36 +00:00
--> $DIR/match-on-borrowed.rs:81:5
Add tests for new match borrows
2018-09-13 21:04:00 +00:00
|
LL | let x = &mut t;
Tweak E0597 CC #99430
2023-01-15 03:06:44 +00:00
| ------ `t` is borrowed here
Add tests for new match borrows
2018-09-13 21:04:00 +00:00
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 22:55:36 +00:00
| ^^^^^^^ use of borrowed `t`
Add tests for new match borrows
2018-09-13 21:04:00 +00:00
...
LL | x;
| - borrow later used here
Tweak wording and spans
2022-06-21 22:54:17 +00:00
error[E0381]: used binding `n` isn't initialized
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 22:55:36 +00:00
--> $DIR/match-on-borrowed.rs:93:11
Add tests for new match borrows
2018-09-13 21:04:00 +00:00
|
On partial uninit error point at where we need init When a binding is declared without a value, borrowck verifies that all codepaths have *one* assignment to them to initialize them fully. If there are any cases where a condition can be met that leaves the binding uninitialized or we attempt to initialize a field of an unitialized binding, we emit E0381. We now look at all the statements that initialize the binding, and use them to explore branching code paths that *don't* and point at them. If we find *no* potential places where an assignment to the binding might be missing, we display the spans of all the existing initializers to provide some context.
2022-06-21 18:57:45 +00:00
LL | let n: Never;
Tweak wording and spans
2022-06-21 22:54:17 +00:00
| - binding declared here but left uninitialized
Update tests
2019-03-09 12:03:44 +00:00
LL | match n {}
On partial uninit error point at where we need init When a binding is declared without a value, borrowck verifies that all codepaths have *one* assignment to them to initialize them fully. If there are any cases where a condition can be met that leaves the binding uninitialized or we attempt to initialize a field of an unitialized binding, we emit E0381. We now look at all the statements that initialize the binding, and use them to explore branching code paths that *don't* and point at them. If we find *no* potential places where an assignment to the binding might be missing, we display the spans of all the existing initializers to provide some context.
2022-06-21 18:57:45 +00:00
| ^ `n` used here but it isn't initialized
fix #102087, Suggest Default::default() when binding isn't initialized
2022-09-23 07:28:48 +00:00
|
help: consider assigning a value
|
LL | let n: Never = todo!();
| +++++++++
Add tests for new match borrows
2018-09-13 21:04:00 +00: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 20:53:07 +00:00
error: aborting due to 4 previous errors
Add tests for new match borrows
2018-09-13 21:04:00 +00:00
hide `--explain` hint if error has no extended info
2019-04-17 17:26:38 +00:00
Some errors have detailed explanations: E0381, E0503.
Add tests for new match borrows
2018-09-13 21:04:00 +00:00
For more information about an error, try `rustc --explain E0381`.
Reference in New Issue Copy Permalink