jiebi/CodeConvo huggingface dataset:
Code change:
In debug mode, this prints But with optimizations, this prints: With optimizations and , this prints: This check in the MIR inliner is hiding this problem from the track-caller UI tests: label +A-mir-opt +A-mir-opt-inlining :
Nevermind that, the panic here is correct actually :D
Ignoring changes in the standard library and optimization level at which MIR inliner is enabled, bisection points to cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: ) -> OperandRef<'tcx, Bx::Value> { let tcx = bx.tcx(); <del> let mut span_to_caller_location = |span: Span| { </del> <ins> let mut span_to_caller_location = |mut span: Span| { // Remove `Inlined` marks as they pollute `expansion_cause`. while span.is_inlined() { span.remove_mark(); } </ins> let topmost = span.ctxt().outer_expn().expansion_cause().unwrap_or(span); let caller = tcx.sess.source_map().lookup_char_pos(topmost.lo()); let const_loc = tcx.const_caller_location((
Code change:
In debug mode, this prints But with optimizations, this prints: With optimizations and , this prints: This check in the MIR inliner is hiding this problem from the track-caller UI tests: label +A-mir-opt +A-mir-opt-inlining :
Nevermind that, the panic here is correct actually :D
Ignoring changes in the standard library and optimization level at which MIR inliner is enabled, bisection points to cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: location } <del> pub(crate) fn location_triple_for_span(&self, span: Span) -> (Symbol, u32, u32) { </del> <ins> pub(crate) fn location_triple_for_span(&self, mut span: Span) -> (Symbol, u32, u32) { // Remove `Inlined` marks as they pollute `expansion_cause`. while span.is_inlined() { span.remove_mark(); } </ins> let topmost = span.ctxt().outer_expn().expansion_cause().unwrap_or(span); let caller = self.tcx.sess.source_map().lookup_char_pos(topmost.lo()); (
Code change:
In debug mode, this prints But with optimizations, this prints: With optimizations and , this prints: This check in the MIR inliner is hiding this problem from the track-caller UI tests: label +A-mir-opt +A-mir-opt-inlining :
Nevermind that, the panic here is correct actually :D
Ignoring changes in the standard library and optimization level at which MIR inliner is enabled, bisection points to cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: pub fn fresh_expansion(self, expn_id: LocalExpnId) -> Span { HygieneData::with(|data| { self.with_ctxt(data.apply_mark( <del> SyntaxContext::root(), </del> <ins> self.ctxt(), </ins> expn_id.to_expn_id(), Transparency::Transparent, ))
Code change:
In debug mode, this prints But with optimizations, this prints: With optimizations and , this prints: This check in the MIR inliner is hiding this problem from the track-caller UI tests: label +A-mir-opt +A-mir-opt-inlining :
Nevermind that, the panic here is correct actually :D
Ignoring changes in the standard library and optimization level at which MIR inliner is enabled, bisection points to cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: // run-pass // revisions: default mir-opt <ins> //[default] compile-flags: -Zinline-mir=no </ins> //[mir-opt] compile-flags: -Zmir-opt-level=4 macro_rules! caller_location_from_macro {
Code change:
In debug mode, this prints But with optimizations, this prints: With optimizations and , this prints: This check in the MIR inliner is hiding this problem from the track-caller UI tests: label +A-mir-opt +A-mir-opt-inlining :
Nevermind that, the panic here is correct actually :D
Ignoring changes in the standard library and optimization level at which MIR inliner is enabled, bisection points to cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: fn main() { let loc = core::panic::Location::caller(); assert_eq!(loc.file(), file!()); <del> assert_eq!(loc.line(), 10); </del> <ins> assert_eq!(loc.line(), 11); </ins> assert_eq!(loc.column(), 15); // `Location::caller()` in a macro should behave similarly to `file!` and `line!`, // i.e. point to where the macro was invoked, instead of the macro itself. let loc2 = caller_location_from_macro!(); assert_eq!(loc2.file(), file!()); <del> assert_eq!(loc2.line(), 17); </del> <ins> assert_eq!(loc2.line(), 18); </ins> assert_eq!(loc2.column(), 16); }
Code change:
In debug mode, this prints But with optimizations, this prints: With optimizations and , this prints: This check in the MIR inliner is hiding this problem from the track-caller UI tests: label +A-mir-opt +A-mir-opt-inlining :
Nevermind that, the panic here is correct actually :D
Ignoring changes in the standard library and optimization level at which MIR inliner is enabled, bisection points to cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium

Related discussion:
text: <ins> // run-pass // revisions: default mir-opt //[default] compile-flags: -Zinline-mir=no //[mir-opt] compile-flags: -Zmir-opt-level=4 use std::panic::Location; macro_rules! f { () => { Location::caller() }; } #[inline(always)] fn g() -> &'static Location<'static> { f!() } fn main() { let loc = g(); assert_eq!(loc.line(), 16); assert_eq!(loc.column(), 5); } </ins>
Code change:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim

Related discussion:
text: }); } else { debug_assert!(self.tcx.is_trait(trait_def_id)); <ins> if self.tcx.trait_is_auto(trait_def_id) { return; } </ins> for item in self.impl_or_trait_item(trait_def_id) { // Check whether `trait_def_id` defines a method with suitable name. if !self.has_applicable_self(&item) {
Code change:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim

Related discussion:
text: _ => false, } }) && (type_is_local || info.def_id.is_local()) <ins> && !self.tcx.trait_is_auto(info.def_id) </ins> && self .associated_value(info.def_id, item_name) .filter(|item| {
Code change:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim

Related discussion:
text: trait Bar { fn f(&self) { <del> self.g(); //~ ERROR the method `g` exists for reference `&Self`, but its trait bounds were not satisfied </del> <ins> // issue #105788 self.g(); //~ ERROR no method named `g` found for reference `&Self` in the current scope </ins> } }
Code change:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim

Related discussion:
text: LL |     fn g(&self); |     ---^-------- help: remove these associated items <del> error[E0599]: the method `g` exists for reference `&Self`, but its trait bounds were not satisfied --> $DIR/issue-105732.rs:9:14 </del> <ins> error[E0599]: no method named `g` found for reference `&Self` in the current scope --> $DIR/issue-105732.rs:10:14 </ins> | LL |         self.g(); <del> |              ^ | = note: the following trait bounds were not satisfied: `Self: Foo` which is required by `&Self: Foo` `&Self: Foo` = help: items from traits can only be used if the type parameter is bounded by the trait help: the following trait defines an item `g`, perhaps you need to add a supertrait for it: | LL | trait Bar: Foo { |          +++++ </del> <ins> |              ^ help: there is a method with a similar name: `f` </ins> error: aborting due to 2 previous errors
Code change:
Spawned off of I tried this code: I expected to see this happen: I expected the to be mapped to the local paths in the installed component, rather than being left as raw Instead, this happened: is showing up in the output. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
see related discussion from wg-debugging triage
in particular, pointed out that that this remapping should be happening if one has the component installed, and that the code doing the remapping should be executed here: and there is corresponding code in bootstrap dist code: There's some useful statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...
But this is currently a remapping at runtime only when using like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they set .
is , right? That is what it is mapped from, not what it is mapped to.
Its and 's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwise would be "empty" and would be a no-op), so I may be missing how this could already remap to the local component according to Felix's comment above ?
I believe these are not being remapped on purpose (based on ). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in (and and to some degree). There's also concerns about how it can affect binary size (). also discusses it some.
These paths are also not being remapped even when explicitly requested with

Related discussion:
text: const CWD: &str = "{{cwd}}"; const SRC_BASE: &str = "{{src-base}}"; const BUILD_BASE: &str = "{{build-base}}"; <ins> const RUST_SRC_BASE: &str = "{{rust-src-base}}"; </ins> const SYSROOT_BASE: &str = "{{sysroot-base}}"; const TARGET_LINKER: &str = "{{target-linker}}"; const TARGET: &str = "{{target}}";
Code change:
Spawned off of I tried this code: I expected to see this happen: I expected the to be mapped to the local paths in the installed component, rather than being left as raw Instead, this happened: is showing up in the output. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
see related discussion from wg-debugging triage
in particular, pointed out that that this remapping should be happening if one has the component installed, and that the code doing the remapping should be executed here: and there is corresponding code in bootstrap dist code: There's some useful statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...
But this is currently a remapping at runtime only when using like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they set .
is , right? That is what it is mapped from, not what it is mapped to.
Its and 's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwise would be "empty" and would be a no-op), so I may be missing how this could already remap to the local component according to Felix's comment above ?
I believe these are not being remapped on purpose (based on ). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in (and and to some degree). There's also concerns about how it can affect binary size (). also discusses it some.
These paths are also not being remapped even when explicitly requested with

Related discussion:
text: value = value.replace(TARGET, &config.target); } <ins> if value.contains(RUST_SRC_BASE) { let src_base = config.sysroot_base.join("lib/rustlib/src/rust"); src_base.try_exists().expect(&*format!("{} should exists", src_base.display())); let src_base = src_base.read_link().unwrap_or(src_base); value = value.replace(RUST_SRC_BASE, &src_base.to_string_lossy()); } </ins> value }
Code change:
Spawned off of I tried this code: I expected to see this happen: I expected the to be mapped to the local paths in the installed component, rather than being left as raw Instead, this happened: is showing up in the output. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
see related discussion from wg-debugging triage
in particular, pointed out that that this remapping should be happening if one has the component installed, and that the code doing the remapping should be executed here: and there is corresponding code in bootstrap dist code: There's some useful statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...
But this is currently a remapping at runtime only when using like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they set .
is , right? That is what it is mapped from, not what it is mapped to.
Its and 's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwise would be "empty" and would be a no-op), so I may be missing how this could already remap to the local component according to Felix's comment above ?
I believe these are not being remapped on purpose (based on ). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in (and and to some degree). There's also concerns about how it can affect binary size (). also discusses it some.
These paths are also not being remapped even when explicitly requested with

Related discussion:
text: } let base_dir = Path::new("/rustc/FAKE_PREFIX"); <del> // Paths into the libstd/libcore </del> <ins> // Fake paths into the libstd/libcore </ins> normalize_path(&base_dir.join("library"), "$SRC_DIR"); // `ui-fulldeps` tests can show paths to the compiler source when testing macros from // `rustc_macros` // eg. /home/user/rust/compiler normalize_path(&base_dir.join("compiler"), "$COMPILER_DIR"); <ins> // Real paths into the libstd/libcore let rust_src_dir = &self.config.sysroot_base.join("lib/rustlib/src/rust"); rust_src_dir.try_exists().expect(&*format!("{} should exists", rust_src_dir.display())); let rust_src_dir = rust_src_dir.read_link().unwrap_or(rust_src_dir.to_path_buf()); normalize_path(&rust_src_dir.join("library"), "$SRC_DIR_REAL"); </ins> // Paths into the build directory let test_build_dir = &self.config.build_base; let parent_build_dir = test_build_dir.parent().unwrap().parent().unwrap().parent().unwrap();
Code change:
Spawned off of I tried this code: I expected to see this happen: I expected the to be mapped to the local paths in the installed component, rather than being left as raw Instead, this happened: is showing up in the output. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
see related discussion from wg-debugging triage
in particular, pointed out that that this remapping should be happening if one has the component installed, and that the code doing the remapping should be executed here: and there is corresponding code in bootstrap dist code: There's some useful statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...
But this is currently a remapping at runtime only when using like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they set .
is , right? That is what it is mapped from, not what it is mapped to.
Its and 's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwise would be "empty" and would be a no-op), so I may be missing how this could already remap to the local component according to Felix's comment above ?
I believe these are not being remapped on purpose (based on ). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in (and and to some degree). There's also concerns about how it can affect binary size (). also discusses it some.
These paths are also not being remapped even when explicitly requested with

Related discussion:
text: // eg. /home/user/rust/build normalize_path(parent_build_dir, "$BUILD_DIR"); <del> // Paths into lib directory. normalize_path(&parent_build_dir.parent().unwrap().join("lib"), "$LIB_DIR"); </del> if json { // escaped newlines in json strings should be readable // in the stderr files. There's no point int being correct,
Code change:
Spawned off of I tried this code: I expected to see this happen: I expected the to be mapped to the local paths in the installed component, rather than being left as raw Instead, this happened: is showing up in the output. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
see related discussion from wg-debugging triage
in particular, pointed out that that this remapping should be happening if one has the component installed, and that the code doing the remapping should be executed here: and there is corresponding code in bootstrap dist code: There's some useful statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...
But this is currently a remapping at runtime only when using like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they set .
is , right? That is what it is mapped from, not what it is mapped to.
Its and 's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwise would be "empty" and would be a no-op), so I may be missing how this could already remap to the local component according to Felix's comment above ?
I believe these are not being remapped on purpose (based on ). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in (and and to some degree). There's also concerns about how it can affect binary size (). also discusses it some.
These paths are also not being remapped even when explicitly requested with

Related discussion:
text: <ins> //@ revisions: with-remap without-remap //@ compile-flags: -g -Ztranslate-remapped-path-to-local-path=yes //@ [with-remap]compile-flags: --remap-path-prefix={{rust-src-base}}=remapped //@ [with-remap]compile-flags: --remap-path-prefix={{src-base}}=remapped-tests-ui //@ [without-remap]compile-flags: //@ error-pattern: E0507 // The $SRC_DIR*.rs:LL:COL normalisation doesn't kick in automatically // as the remapped revision will not begin with $SRC_DIR_REAL, // so we have to do it ourselves. //@ normalize-stderr-test: ".rs:d+:d+" -> ".rs:LL:COL" use std::thread; struct Worker { thread: thread::JoinHandle<()>, } impl Drop for Worker { fn drop(&mut self) { self.thread.join().unwrap(); } } pub fn main(){} </ins>
Code change:
Spawned off of I tried this code: I expected to see this happen: I expected the to be mapped to the local paths in the installed component, rather than being left as raw Instead, this happened: is showing up in the output. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
see related discussion from wg-debugging triage
in particular, pointed out that that this remapping should be happening if one has the component installed, and that the code doing the remapping should be executed here: and there is corresponding code in bootstrap dist code: There's some useful statements mixed in there, I bet we might be able to figure out what's going on here without too much trickery...
But this is currently a remapping at runtime only when using like in UI tests, right ? Otherwise it's optionally done at compile-time on the dist builders if they set .
is , right? That is what it is mapped from, not what it is mapped to.
Its and 's presence seem to control (at rustc build-time and at runtime respectively) whether the remapping happens in the code you listed above (otherwise would be "empty" and would be a no-op), so I may be missing how this could already remap to the local component according to Felix's comment above ?
I believe these are not being remapped on purpose (based on ). I think currently the remapping only happens for diagnostics (and not things that end up in the binary). There's some more discussion in (and and to some degree). There's also concerns about how it can affect binary size (). also discusses it some.
These paths are also not being remapped even when explicitly requested with

Related discussion:
text: <ins> error[E0507]: cannot move out of `self.thread` which is behind a mutable reference --> remapped-tests-ui/errors/remap-path-prefix-sysroot.rs:LL:COL | LL |         self.thread.join().unwrap(); |         ^^^^^^^^^^^ ------ `self.thread` moved due to this method call |         | |         move occurs because `self.thread` has type `JoinHandle<()>`, which does not implement the `Copy` trait | note: `JoinHandle::<T>::join` takes ownership of the receiver `self`, which moves `self.thread` --> remapped/library/std/src/thread/mod.rs:LL:COL | LL |     pub fn join(self) -> Result<T> { |                 ^^^^ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0507`. </ins>