mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7cf7ead0bc
rust/src/test/mir-opt/deduplicate_blocks.is_line_doc_comment_2.DeduplicateBlocks.diff

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

108 lines
5.6 KiB
Diff
Raw Normal View History

New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
- // MIR for `is_line_doc_comment_2` before DeduplicateBlocks
+ // MIR for `is_line_doc_comment_2` after DeduplicateBlocks
fn is_line_doc_comment_2(_1: &str) -> bool {
debug s => _1; // in scope 0 at $DIR/deduplicate_blocks.rs:2:36: 2:37
let mut _0: bool; // return place in scope 0 at $DIR/deduplicate_blocks.rs:2:48: 2:52
let mut _2: &[u8]; // in scope 0 at $DIR/deduplicate_blocks.rs:3:11: 3:23
Use larger span for adjustments on method calls Currently, we use a relatively 'small' span for THIR expressions generated by an 'adjustment' (e.g. an autoderef, autoborrow, unsizing). As a result, if a borrow generated by an adustment ends up causing a borrowcheck error, for example: ```rust let mut my_var = String::new(); let my_ref = &my_var my_var.push('a'); my_ref; ``` then the span for the mutable borrow may end up referring to only the base expression (e.g. `my_var`), rather than the method call which triggered the mutable borrow (e.g. `my_var.push('a')`) Due to a quirk of the MIR borrowck implementation, this doesn't always get exposed in migration mode, but it does in many cases. This commit makes THIR building consistently use 'larger' spans for adjustment expressions The intent of this change it make it clearer to users when it's the specific way in which a variable is used (for example, in a method call) that produdes a borrowcheck error. For example, an error message claiming that a 'mutable borrow occurs here' might be confusing if it just points at a usage of a variable (e.g. `my_var`), when no `&mut` is in sight. Pointing at the entire expression should help to emphasize that the method call itself is responsible for the mutable borrow. In several cases, this makes the `#![feature(nll)]` diagnostic output match up exactly with the default (migration mode) output. As a result, several `.nll.stderr` files end up getting removed entirely.
2021-09-16 15:01:22 -05:00
let mut _3: &str; // in scope 0 at $DIR/deduplicate_blocks.rs:3:11: 3:23
Disable destination propagation on all mir-opt-levels
2021-03-05 18:00:00 -06:00
let mut _4: usize; // in scope 0 at $DIR/deduplicate_blocks.rs:5:9: 5:31
let mut _5: bool; // in scope 0 at $DIR/deduplicate_blocks.rs:5:9: 5:31
let mut _6: usize; // in scope 0 at $DIR/deduplicate_blocks.rs:4:9: 4:37
let mut _7: bool; // in scope 0 at $DIR/deduplicate_blocks.rs:4:9: 4:37
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
scope 1 (inlined core::str::<impl str>::as_bytes) { // at $DIR/deduplicate_blocks.rs:3:11: 3:23
Only create a single expansion for each inline integration.
2022-02-27 09:09:52 -06:00
debug self => _3; // in scope 1 at $SRC_DIR/core/src/str/mod.rs:LL:COL
let mut _8: &str; // in scope 1 at $SRC_DIR/core/src/str/mod.rs:LL:COL
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
scope 2 {
}
}
bb0: {
StorageLive(_2); // scope 0 at $DIR/deduplicate_blocks.rs:3:11: 3:23
Use larger span for adjustments on method calls Currently, we use a relatively 'small' span for THIR expressions generated by an 'adjustment' (e.g. an autoderef, autoborrow, unsizing). As a result, if a borrow generated by an adustment ends up causing a borrowcheck error, for example: ```rust let mut my_var = String::new(); let my_ref = &my_var my_var.push('a'); my_ref; ``` then the span for the mutable borrow may end up referring to only the base expression (e.g. `my_var`), rather than the method call which triggered the mutable borrow (e.g. `my_var.push('a')`) Due to a quirk of the MIR borrowck implementation, this doesn't always get exposed in migration mode, but it does in many cases. This commit makes THIR building consistently use 'larger' spans for adjustment expressions The intent of this change it make it clearer to users when it's the specific way in which a variable is used (for example, in a method call) that produdes a borrowcheck error. For example, an error message claiming that a 'mutable borrow occurs here' might be confusing if it just points at a usage of a variable (e.g. `my_var`), when no `&mut` is in sight. Pointing at the entire expression should help to emphasize that the method call itself is responsible for the mutable borrow. In several cases, this makes the `#![feature(nll)]` diagnostic output match up exactly with the default (migration mode) output. As a result, several `.nll.stderr` files end up getting removed entirely.
2021-09-16 15:01:22 -05:00
StorageLive(_3); // scope 0 at $DIR/deduplicate_blocks.rs:3:11: 3:23
_3 = _1; // scope 0 at $DIR/deduplicate_blocks.rs:3:11: 3:23
Only create a single expansion for each inline integration.
2022-02-27 09:09:52 -06:00
StorageLive(_8); // scope 2 at $SRC_DIR/core/src/str/mod.rs:LL:COL
_8 = _3; // scope 2 at $SRC_DIR/core/src/str/mod.rs:LL:COL
- _2 = transmute::<&str, &[u8]>(move _8) -> bb14; // scope 2 at $SRC_DIR/core/src/str/mod.rs:LL:COL
+ _2 = transmute::<&str, &[u8]>(move _8) -> bb12; // scope 2 at $SRC_DIR/core/src/str/mod.rs:LL:COL
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
// mir::Constant
Only create a single expansion for each inline integration.
2022-02-27 09:09:52 -06:00
// + span: $SRC_DIR/core/src/str/mod.rs:LL:COL
tweak names and output and bless
2022-07-06 09:14:46 -05:00
// + literal: Const { ty: unsafe extern "rust-intrinsic" fn(&str) -> &[u8] {transmute::<&str, &[u8]>}, val: Value(<ZST>) }
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb1: {
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
switchInt((*_2)[0 of 4]) -> [47_u8: bb2, otherwise: bb5]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb2: {
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
switchInt((*_2)[1 of 4]) -> [47_u8: bb3, otherwise: bb5]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb3: {
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
switchInt((*_2)[2 of 4]) -> [47_u8: bb4, otherwise: bb5]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb4: {
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
- switchInt((*_2)[3 of 4]) -> [47_u8: bb10, otherwise: bb5]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
+ switchInt((*_2)[3 of 4]) -> [47_u8: bb9, otherwise: bb5]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb5: {
Disable destination propagation on all mir-opt-levels
2021-03-05 18:00:00 -06:00
_4 = Len((*_2)); // scope 0 at $DIR/deduplicate_blocks.rs:5:9: 5:31
_5 = Ge(move _4, const 3_usize); // scope 0 at $DIR/deduplicate_blocks.rs:5:9: 5:31
switchInt(move _5) -> [false: bb9, otherwise: bb6]; // scope 0 at $DIR/deduplicate_blocks.rs:5:9: 5:31
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb6: {
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
switchInt((*_2)[0 of 3]) -> [47_u8: bb7, otherwise: bb9]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb7: {
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
switchInt((*_2)[1 of 3]) -> [47_u8: bb8, otherwise: bb9]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb8: {
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
- switchInt((*_2)[2 of 3]) -> [47_u8: bb11, 33_u8: bb12, otherwise: bb9]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
+ switchInt((*_2)[2 of 3]) -> [47_u8: bb10, 33_u8: bb10, otherwise: bb9]; // scope 0 at $DIR/deduplicate_blocks.rs:3:5: 3:23
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
bb9: {
- _0 = const false; // scope 0 at $DIR/deduplicate_blocks.rs:7:14: 7:19
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
- goto -> bb13; // scope 0 at $DIR/deduplicate_blocks.rs:7:14: 7:19
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
- }
-
- bb10: {
_0 = const false; // scope 0 at $DIR/deduplicate_blocks.rs:4:41: 4:46
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
- goto -> bb13; // scope 0 at $DIR/deduplicate_blocks.rs:4:41: 4:46
+ goto -> bb11; // scope 0 at $DIR/deduplicate_blocks.rs:4:41: 4:46
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
- bb11: {
- _0 = const true; // scope 0 at $DIR/deduplicate_blocks.rs:5:35: 5:39
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
- goto -> bb13; // scope 0 at $DIR/deduplicate_blocks.rs:5:35: 5:39
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
- }
-
- bb12: {
+ bb10: {
_0 = const true; // scope 0 at $DIR/deduplicate_blocks.rs:6:35: 6:39
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
- goto -> bb13; // scope 0 at $DIR/deduplicate_blocks.rs:6:35: 6:39
+ goto -> bb11; // scope 0 at $DIR/deduplicate_blocks.rs:6:35: 6:39
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
- bb13: {
+ bb11: {
StorageDead(_2); // scope 0 at $DIR/deduplicate_blocks.rs:9:1: 9:2
return; // scope 0 at $DIR/deduplicate_blocks.rs:9:2: 9:2
}
- bb14: {
+ bb12: {
Only create a single expansion for each inline integration.
2022-02-27 09:09:52 -06:00
StorageDead(_8); // scope 2 at $SRC_DIR/core/src/str/mod.rs:LL:COL
Disable destination propagation on all mir-opt-levels
2021-03-05 18:00:00 -06:00
StorageDead(_3); // scope 0 at $DIR/deduplicate_blocks.rs:3:22: 3:23
_6 = Len((*_2)); // scope 0 at $DIR/deduplicate_blocks.rs:4:9: 4:37
_7 = Ge(move _6, const 4_usize); // scope 0 at $DIR/deduplicate_blocks.rs:4:9: 4:37
switchInt(move _7) -> [false: bb5, otherwise: bb1]; // scope 0 at $DIR/deduplicate_blocks.rs:4:9: 4:37
New pass to deduplicate blocks
2020-10-04 08:52:14 -05:00
}
}
Reference in New Issue Copy Permalink