jiebi/CodeConvo huggingface dataset:
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Compiler doesn't generate any warnings Instead, this happened: Rustc says that is unused, even though it is declared as in asm. Adding arrows () fixes it <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting bug! I used to determine that this bug has been around . and doing some debugging, I found that for all live nodes in , is never marked as being used in the RWU table. It only gets marked as read/written. , this is part of the information used to determine that is unused. That doesn't really make much sense though- does seem to fit the case where a variable is used as both an input and an output to some arbitrary assembly instruction. I'll go ahead and claim this. I have a solution in mind, just going to ask around zulip first before putting out a PR. claim

Related discussion:
text: <ins> // Ensure inout asm! operands are marked as used by the liveness pass // only-x86_64 // check-pass #![feature(asm)] #![allow(dead_code)] #![warn(unused_assignments)] #![warn(unused_variables)] // Test the single inout case unsafe fn f1(mut src: *const u8) { asm!("/*{0}*/", inout(reg) src); //~ WARN value assigned to `src` is never read } unsafe fn f2(mut src: *const u8) -> *const u8 { asm!("/*{0}*/", inout(reg) src); src } // Test the split inout case unsafe fn f3(mut src: *const u8) { asm!("/*{0}*/", inout(reg) src => src); //~ WARN value assigned to `src` is never read } unsafe fn f4(mut src: *const u8) -> *const u8 { asm!("/*{0}*/", inout(reg) src => src); src } // Tests the use of field projections struct S { field: *mut u8, } unsafe fn f5(src: &mut S) { asm!("/*{0}*/", inout(reg) src.field); } unsafe fn f6(src: &mut S) { asm!("/*{0}*/", inout(reg) src.field => src.field); } fn main() {} </ins>
Code change:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: Compiler doesn't generate any warnings Instead, this happened: Rustc says that is unused, even though it is declared as in asm. Adding arrows () fixes it <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting bug! I used to determine that this bug has been around . and doing some debugging, I found that for all live nodes in , is never marked as being used in the RWU table. It only gets marked as read/written. , this is part of the information used to determine that is unused. That doesn't really make much sense though- does seem to fit the case where a variable is used as both an input and an output to some arbitrary assembly instruction. I'll go ahead and claim this. I have a solution in mind, just going to ask around zulip first before putting out a PR. claim

Related discussion:
text: <ins> warning: value assigned to `src` is never read --> $DIR/liveness-asm.rs:13:32 | LL |     asm!("/*{0}*/", inout(reg) src); |                                ^^^ | note: the lint level is defined here --> $DIR/liveness-asm.rs:8:9 | LL | #![warn(unused_assignments)] |         ^^^^^^^^^^^^^^^^^^ = help: maybe it is overwritten before being read? warning: value assigned to `src` is never read --> $DIR/liveness-asm.rs:23:39 | LL |     asm!("/*{0}*/", inout(reg) src => src); |                                       ^^^ | = help: maybe it is overwritten before being read? warning: 2 warnings emitted </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rustfmt no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Hi can you please the command to replicate this bug? Thanks
with set in
won't be able to get to this myself in the next few days. To fix this we probably have to compile it with , find the place where we call and put a before that
Hi the error occurred where we just erasing regions by simply doing this (tcx.eraseregions(&traitref)) and provided assertion with (tcx.normalizeerasingregions(paramenv, traitref)). Is this scenario correct? Just want to confirm as you already mentioned to put a tcx.normalizeerasingregions. Thanks
yes, so we do not want to use in as that can be a bit costly but instead normalize eagerly before then. To detect cases where we are still using unnormalized values a debug assert there. If we look at the backtrace we can find out where the is coming from and normalize it there
okay, thanks for the update.
Hi as you mentioned can you please elaborate it please? As I can see the Instace::resolve in but don't get you point to put tcx.normalizeerasing_regions. Thanks
Can you post the resulting backtrace using ?
here it is:
So I think that the easiest fix is to add before this call. I am however surprised that isn't actually normalized here. cc do we want to instead normalize this in mir building?

Related discussion:
text: let func_ty = func.ty(body, tcx); if let ty::FnDef(callee, substs) = *func_ty.kind() { <del> let (callee, call_substs) = if let Ok(Some(instance)) = Instance::resolve(tcx, param_env, callee, substs) { (instance.def_id(), instance.substs) } else { (callee, substs) }; </del> <ins> let normalized_substs = tcx.normalize_erasing_regions(param_env, substs); let (callee, call_substs) = if let Ok(Some(instance)) = Instance::resolve(tcx, param_env, callee, normalized_substs) { (instance.def_id(), instance.substs) } else { (callee, normalized_substs) }; </ins> // FIXME(#57965): Make this work across function boundaries
Code change:
dilbert-feed is ICEing on beta with error: internal compiler error: could not fully normalize https://crater-
Full error log:
I'll bisect this one
Doesn't happen on the latest commit by on .
I can still reproduce with :
It may just be an instance of me not doing something right, I used:
gives me searched toolchains through regression in So this would have regressed in , cc
The PR did introduce some additional uses of inside specialized implementations. itself it is a stable function so I am not aware of any restrictions on its use. Perhaps this is some interaction with specialization?
Both sites where it is used are of this pattern: They're just there as hints to to let llvm DCE the dropinplace earlier. So if needed removing them should be safe.
Assigning as and removing .
Assigning myself to revert on beta (and potentially nightly, depending on if we can get a fix soon).
Do we know if removing fixes the problem? We also could use an MVCE, right?
MCVE would be good, yes.
I hit (what seems like) this ICE with in a pretty small experiment, would it be useful to try reducing that?
Yes, it would be -- even if it's a separate issue we can just open that :) MCVE is always useful.
ping cleanup This issue needs an MVCE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Here's my nightly MCVE: Interestingly, it goes away when putting all of the code into one crate. <details<summaryFull error message (with <codeRUST_BACKTRACE=1</code):</summary</details
Hmm, this may be a distinct problem, but maybe not. Hard to tell.
I'm re-adding the MCVE label because the crate on beta does not require features, so we should be able to come up with a non-nightly MCVE. (Also, it would be good to have a single-crate MCVE, but perhaps the multicrate nature is critical here?)
cc , which may be the same underlying bug (but pre-existing?)
hey , did you manage to land a revert of on beta (and nightly?)?
If reverting the PR proves difficult more targeted options would be either removing the use of or only removing / stubbing while leaving the rest of the machinery unchanged. But the former may be insufficient since it also uses similar methods such as and .
Do we think given that we're likely to fix the regression here at least in and we should close this bug? Neither of those PRs fixes the underlying issue (whatever it is) since the lack of normalization is almost certainly still present, but we also don't have (AFAIK) a good test case here for the bug.
I expect so.

Related discussion:
text: impl<T> Drop for InPlaceDrop<T> { #[inline] fn drop(&mut self) { <del> if mem::needs_drop::<T>() { unsafe { ptr::drop_in_place(slice::from_raw_parts_mut(self.inner, self.len())); } </del> <ins> unsafe { ptr::drop_in_place(slice::from_raw_parts_mut(self.inner, self.len())); </ins> } } }
Code change:
dilbert-feed is ICEing on beta with error: internal compiler error: could not fully normalize https://crater-
Full error log:
I'll bisect this one
Doesn't happen on the latest commit by on .
I can still reproduce with :
It may just be an instance of me not doing something right, I used:
gives me searched toolchains through regression in So this would have regressed in , cc
The PR did introduce some additional uses of inside specialized implementations. itself it is a stable function so I am not aware of any restrictions on its use. Perhaps this is some interaction with specialization?
Both sites where it is used are of this pattern: They're just there as hints to to let llvm DCE the dropinplace earlier. So if needed removing them should be safe.
Assigning as and removing .
Assigning myself to revert on beta (and potentially nightly, depending on if we can get a fix soon).
Do we know if removing fixes the problem? We also could use an MVCE, right?
MCVE would be good, yes.
I hit (what seems like) this ICE with in a pretty small experiment, would it be useful to try reducing that?
Yes, it would be -- even if it's a separate issue we can just open that :) MCVE is always useful.
ping cleanup This issue needs an MVCE
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Here's my nightly MCVE: Interestingly, it goes away when putting all of the code into one crate. <details<summaryFull error message (with <codeRUST_BACKTRACE=1</code):</summary</details
Hmm, this may be a distinct problem, but maybe not. Hard to tell.
I'm re-adding the MCVE label because the crate on beta does not require features, so we should be able to come up with a non-nightly MCVE. (Also, it would be good to have a single-crate MCVE, but perhaps the multicrate nature is critical here?)
cc , which may be the same underlying bug (but pre-existing?)
hey , did you manage to land a revert of on beta (and nightly?)?
If reverting the PR proves difficult more targeted options would be either removing the use of or only removing / stubbing while leaving the rest of the machinery unchanged. But the former may be insufficient since it also uses similar methods such as and .
Do we think given that we're likely to fix the regression here at least in and we should close this bug? Neither of those PRs fixes the underlying issue (whatever it is) since the lack of normalization is almost certainly still present, but we also don't have (AFAIK) a good test case here for the bug.
I expect so.

Related discussion:
text: } fn drop_remaining(&mut self) { <del> if mem::needs_drop::<T>() { unsafe { ptr::drop_in_place(self.as_mut_slice()); } </del> <ins> unsafe { ptr::drop_in_place(self.as_mut_slice()); </ins> } self.ptr = self.end; }
Code change:
When panicking, every line of stack traces contain instead of a code location. E.g. I'm on rustc 1.47.0 and FreeBSD 12.1: Possible duplicate of I've tried mounting /proc but it didn't fix the problem.
Can you test on old Rust stable version to see if this is a regression ? Edit: This is an expected regression
It worked on 1.46.0:
Do you know if there is a build farm for freebsd like gcc build farm ? Because we could fo find from which PR caused the regression. Otherwise, since freebsd is a tier-2 target, not everyone could investigate it. modify labels: T-compiler
Error: Label P-medium can only be set by Rust team members Please let know if you're having trouble with this bot.
Assigning as discussed as part of the and removing .) and removing .
For what it's worth, this problem occurs on iOS (x86_64-apple-ios) builds too: 1.47.0: 1.46.0:
Likely caused by . (switching from libbacktrace to gimli) It seems that is not implemented for FreeBSD: I think this means that it can't find the debuginfo for any libraries and the current executable.
For iOS it may or may not work to extend the condition at to include iOS too.
You're right! I submitted a PR to fix it for iOS. Thanks a lot!
You might want to file another PR to update backtrace-rs submodule in this repo.
Thanks!
It looks like , so I think we could just extend to cover FreeBSD
Hi, could you ( or ) use rustup- toolchain-install-master to install and try this build: for freebsd?
Looks good!
backtrace-rs issue: backtrace-rs PR for issue:
What's left to do here? Would a PR that updates the submodule for library/backtrace be sufficient?

Related discussion:
text: <del> Subproject commit af078ecc0b069ec594982f92d4c6c58af99efbb5 </del> <ins> Subproject commit 710fc18ddcb6c7677b3c96359abb35da37f2a488 </ins>
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: code_offset: usize, margin: Margin, ) { <ins> // Tabs are assumed to have been replaced by spaces in calling code. assert!(!source_string.contains('t')); </ins> let line_len = source_string.len(); // Create the source line we will highlight. let left = margin.left(line_len);
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: } let source_string = match file.get_line(line.line_index - 1) { <del> Some(s) => s, </del> <ins> Some(s) => replace_tabs(&*s), </ins> None => return Vec::new(), };
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: let file = annotated_file.file.clone(); let line = &annotated_file.lines[line_idx]; if let Some(source_string) = file.get_line(line.line_index - 1) { <del> let leading_whitespace = source_string.chars().take_while(|c| c.is_whitespace()).count(); </del> <ins> let leading_whitespace = source_string .chars() .take_while(|c| c.is_whitespace()) .map(|c| { match c { // Tabs are displayed as 4 spaces 't' => 4, _ => 1, } }) .sum(); </ins> if source_string.chars().any(|c| !c.is_whitespace()) { whitespace_margin = min(whitespace_margin, leading_whitespace); }
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: self.draw_line( &mut buffer, <del> &unannotated_line, </del> <ins> &replace_tabs(&unannotated_line), </ins> annotated_file.lines[line_idx + 1].line_index - 1, last_buffer_line_num, width_offset,
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: ); // print the suggestion draw_col_separator(&mut buffer, row_num, max_line_num_len + 1); <del> buffer.append(row_num, line, Style::NoStyle); </del> <ins> buffer.append(row_num, &replace_tabs(line), Style::NoStyle); </ins> row_num += 1; }
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: } } <ins> fn replace_tabs(str: &str) -> String { str.replace('t', "    ") } </ins> fn draw_col_separator(buffer: &mut StyledBuffer, line: usize, col: usize) { buffer.puts(line, col, "| ", Style::LineNumber); }
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: StyledBuffer { text: vec![], styles: vec![] } } <del> fn replace_tabs(&mut self) { for (line_pos, line) in self.text.iter_mut().enumerate() { let mut tab_pos = vec![]; for (pos, c) in line.iter().enumerate() { if *c == 't' { tab_pos.push(pos); } } // start with the tabs at the end of the line to replace them with 4 space chars for pos in tab_pos.iter().rev() { assert_eq!(line.remove(*pos), 't'); // fix the position of the style to match up after replacing the tabs let s = self.styles[line_pos].remove(*pos); for _ in 0..4 { line.insert(*pos, ' '); self.styles[line_pos].insert(*pos, s); } } } } </del> <ins> pub fn render(&self) -> Vec<Vec<StyledString>> { // Tabs are assumed to have been replaced by spaces in calling code. assert!(self.text.iter().all(|r| !r.contains(&'t'))); </ins> <del> pub fn render(&mut self) -> Vec<Vec<StyledString>> { </del> let mut output: Vec<Vec<StyledString>> = vec![]; let mut styled_vec: Vec<StyledString> = vec![]; <del> // before we render, replace tabs with spaces self.replace_tabs(); </del> for (row, row_style) in self.text.iter().zip(&self.styles) { let mut current_style = Style::NoStyle; let mut current_text = String::new();
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: <ins> // Test for #78438: ensure underline alignment with many tabs on the left, long line on the right // ignore-tidy-linelength // ignore-tidy-tab fn main() { let money = 42i32; match money { v @ 1 | 2 | 3 => panic!("You gave me too little money {}", v), // Long text here: TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT //~^ ERROR variable `v` is not bound in all patterns v => println!("Enough money {}", v), } } </ins>
Code change:
The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim

Related discussion:
text: <ins> error[E0408]: variable `v` is not bound in all patterns --> $DIR/tabs-trimming.rs:9:16 | LL | ...   v @ 1 | 2 | 3 => panic!("You gave me too little money {}", v), // Long text here: TTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTTT... |       -       ^   ^ pattern doesn't bind `v` |       |       | |       |       pattern doesn't bind `v` |       variable not in all patterns error: aborting due to previous error For more information about this error, try `rustc --explain E0408`. </ins>
Code change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Playground stable: Playground nightly: Somewhat similar to Edit: Actually, it's identical except this is with two lifetimes. Edit 2: And this one crashes stable, while the other does not. Also crashes without enabling features, and complains that However, constraining removes this error, but not the crash. Two lifetimes are required for the crash. <!-- 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. --: Also crashes on Rust Playground with stable <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
glacier ""
Seems related to
No longer ICEs since

Related discussion:
text: <ins> // check-pass #![feature(type_alias_impl_trait)] pub trait Trait { type A; fn f() -> Self::A; } pub trait Tr2<'a, 'b> {} pub struct A<T>(T); pub trait Tr { type B; } impl<'a, 'b, T: Tr<B = dyn Tr2<'a, 'b>>> Trait for A<T> { type A = impl core::fmt::Debug; fn f() -> Self::A {} } fn main() {} </ins>