mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
98d65d62c5
rust/tests/debuginfo/captured-fields-1.rs

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

96 lines
2.7 KiB
Rust
Raw Normal View History

Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
//@ compile-flags:-g
Remove the `capture_disjoint_fields` feature
2023-02-27 19:21:15 -06:00
//@ edition:2021
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// === GDB TESTS ===================================================================================
// gdb-command:run
// gdb-command:print test
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo. Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name. This commit also emits '{closure_env#0}' as the name of these types in order to disambiguate them from the accompanying closure function '{closure#0}'. Previously both were assigned the same name.
2022-01-19 10:56:53 -06:00
// gdbr-check:$1 = captured_fields_1::main::{closure_env#0} {_ref__my_ref__my_field1: 0x[...]}
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// gdb-command:continue
// gdb-command:print test
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo. Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name. This commit also emits '{closure_env#0}' as the name of these types in order to disambiguate them from the accompanying closure function '{closure#0}'. Previously both were assigned the same name.
2022-01-19 10:56:53 -06:00
// gdbr-check:$2 = captured_fields_1::main::{closure_env#1} {_ref__my_ref__my_field2: 0x[...]}
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// gdb-command:continue
// gdb-command:print test
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo. Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name. This commit also emits '{closure_env#0}' as the name of these types in order to disambiguate them from the accompanying closure function '{closure#0}'. Previously both were assigned the same name.
2022-01-19 10:56:53 -06:00
// gdbr-check:$3 = captured_fields_1::main::{closure_env#2} {_ref__my_ref: 0x[...]}
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// gdb-command:continue
// gdb-command:print test
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo. Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name. This commit also emits '{closure_env#0}' as the name of these types in order to disambiguate them from the accompanying closure function '{closure#0}'. Previously both were assigned the same name.
2022-01-19 10:56:53 -06:00
// gdbr-check:$4 = captured_fields_1::main::{closure_env#3} {my_ref: 0x[...]}
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// gdb-command:continue
// gdb-command:print test
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo. Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name. This commit also emits '{closure_env#0}' as the name of these types in order to disambiguate them from the accompanying closure function '{closure#0}'. Previously both were assigned the same name.
2022-01-19 10:56:53 -06:00
// gdbr-check:$5 = captured_fields_1::main::{closure_env#4} {my_var__my_field2: 22}
Store names of captured variables in `optimized_mir` - Closures in external crates may get compiled in because of monomorphization. We should store names of captured variables in `optimized_mir`, so that they are written into the metadata file and we can use them to generate debuginfo. - If there are breakpoints inside closures, the names of captured variables stored in `optimized_mir` can be used to print them. Now the name is more precise when disjoint fields are captured.
2021-05-15 06:01:13 -05:00
// gdb-command:continue
// gdb-command:print test
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo. Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name. This commit also emits '{closure_env#0}' as the name of these types in order to disambiguate them from the accompanying closure function '{closure#0}'. Previously both were assigned the same name.
2022-01-19 10:56:53 -06:00
// gdbr-check:$6 = captured_fields_1::main::{closure_env#5} {my_var: captured_fields_1::MyStruct {my_field1: 11, my_field2: 22}}
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// gdb-command:continue
// === LLDB TESTS ==================================================================================
// lldb-command:run
Use explicit LLDB commands instead of `print`/`p` aliases.
2024-03-15 09:05:57 -05:00
// lldb-command:v test
// lldbg-check:(captured_fields_1::main::{closure_env#0}) test = { _ref__my_ref__my_field1 = 0x[...] }
Store names of captured variables in `optimized_mir` - Closures in external crates may get compiled in because of monomorphization. We should store names of captured variables in `optimized_mir`, so that they are written into the metadata file and we can use them to generate debuginfo. - If there are breakpoints inside closures, the names of captured variables stored in `optimized_mir` can be used to print them. Now the name is more precise when disjoint fields are captured.
2021-05-15 06:01:13 -05:00
// lldb-command:continue
Use explicit LLDB commands instead of `print`/`p` aliases.
2024-03-15 09:05:57 -05:00
// lldb-command:v test
// lldbg-check:(captured_fields_1::main::{closure_env#1}) test = { _ref__my_ref__my_field2 = 0x[...] }
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// lldb-command:continue
Use explicit LLDB commands instead of `print`/`p` aliases.
2024-03-15 09:05:57 -05:00
// lldb-command:v test
// lldbg-check:(captured_fields_1::main::{closure_env#2}) test = { _ref__my_ref = 0x[...] }
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// lldb-command:continue
Use explicit LLDB commands instead of `print`/`p` aliases.
2024-03-15 09:05:57 -05:00
// lldb-command:v test
// lldbg-check:(captured_fields_1::main::{closure_env#3}) test = { my_ref = 0x[...] }
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// lldb-command:continue
Use explicit LLDB commands instead of `print`/`p` aliases.
2024-03-15 09:05:57 -05:00
// lldb-command:v test
// lldbg-check:(captured_fields_1::main::{closure_env#4}) test = { my_var__my_field2 = 22 }
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// lldb-command:continue
Use explicit LLDB commands instead of `print`/`p` aliases.
2024-03-15 09:05:57 -05:00
// lldb-command:v test
// lldbg-check:(captured_fields_1::main::{closure_env#5}) test = { my_var = { my_field1 = 11 my_field2 = 22 } }
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
// lldb-command:continue
#![allow(unused)]
struct MyStruct {
my_field1: u32,
my_field2: u32,
}
fn main() {
debuginfo: Make sure that type names for closure and generator environments are unique in debuginfo. Before this change, closure/generator environments coming from different instantiations of the same generic function were all assigned the same name even though they were distinct types with potentially different data layout. Now we append the generic arguments of the originating function to the type name. This commit also emits '{closure_env#0}' as the name of these types in order to disambiguate them from the accompanying closure function '{closure#0}'. Previously both were assigned the same name.
2022-01-19 10:56:53 -06:00
let mut my_var = MyStruct { my_field1: 11, my_field2: 22 };
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
let my_ref = &mut my_var;
let test = || {
let a = &mut my_ref.my_field1;
};
_zzz(); // #break
let test = || {
let a = &my_ref.my_field2;
};
_zzz(); // #break
let test = || {
let a = &my_ref;
};
_zzz(); // #break
let test = || {
let a = my_ref;
};
_zzz(); // #break
Store names of captured variables in `optimized_mir` - Closures in external crates may get compiled in because of monomorphization. We should store names of captured variables in `optimized_mir`, so that they are written into the metadata file and we can use them to generate debuginfo. - If there are breakpoints inside closures, the names of captured variables stored in `optimized_mir` can be used to print them. Now the name is more precise when disjoint fields are captured.
2021-05-15 06:01:13 -05:00
let test = move || {
let a = my_var.my_field2;
};
_zzz(); // #break
Name the captured upvars for closures/generators in debuginfo Previously, debuggers print closures as something like ``` y::main::closure-0 (0x7fffffffdd34) ``` The pointer actually references to an upvar. It is not very obvious, especially for beginners. It's because upvars don't have names before, as they are packed into a tuple. This commit names the upvars, so we can expect to see something like ``` y::main::closure-0 {_captured_ref__b: 0x[...]} ```
2021-05-05 10:50:44 -05:00
let test = || {
let a = my_var;
};
_zzz(); // #break
}
fn _zzz() {}
Reference in New Issue Copy Permalink