jiebi/CodeConvo huggingface dataset:
Code change:
I'm getting an internal compiler error on the following program (found by ): I'm seeing the error on stable, beta, and nightly. As with , the error occurs on () but not on (). , the proposed fix for , does not fix this error. cc

Related discussion:
text: <ins> error: expected identifier, found reserved identifier `_` --> $DIR/issue-62895.rs:4:5 | LL | mod _ { |     ^ expected identifier, found reserved identifier error: expected identifier, found reserved identifier `_` --> $DIR/issue-62895.rs:6:5 | LL | mod _ { |     ^ expected identifier, found reserved identifier error: missing `fn` for function definition --> $DIR/issue-62895.rs:7:4 | LL | pub    g() -> is |    ^^^^ help: add `fn` here to parse `g` as a public function | LL | pub fn g() -> is |     ^^ error: expected item, found `;` --> $DIR/issue-62895.rs:10:9 | LL | (), w20); |         ^ help: remove this semicolon error[E0412]: cannot find type `isizee` in this scope --> $DIR/issue-62895.rs:5:15 | LL | pub fn g() -> isizee { |               ^^^^^^ help: a builtin type with a similar name exists: `isize` error[E0308]: mismatched types --> $DIR/issue-62895.rs:3:11 | LL | fn v() -> isize { |    -      ^^^^^ expected isize, found () |    | |    this function's body doesn't return | = note: expected type `isize` found type `()` error: aborting due to 6 previous errors Some errors have detailed explanations: E0308, E0412. For more information about an error, try `rustc --explain E0308`. </ins>
Code change:
As seen in , when running the tests on Windows there are slightly different things in scope than when the tests are run normally. per
see also
Part of .
Closing, removed check-fast

Related discussion:
text: <ins> // Copyright 2013 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // check that the derived impls for the comparison traits shortcircuit // where possible, by having a type that fails when compared as the // second element, so this passes iff the instances shortcircuit. pub struct FailCmp; impl Eq for FailCmp { fn eq(&self, _: &FailCmp) -> bool { fail!("eq") } } impl Ord for FailCmp { fn lt(&self, _: &FailCmp) -> bool { fail!("lt") } } impl TotalEq for FailCmp { fn equals(&self, _: &FailCmp) -> bool { fail!("equals") } } impl TotalOrd for FailCmp { fn cmp(&self, _: &FailCmp) -> Ordering { fail!("cmp") } } #[deriving(Eq,Ord,TotalEq,TotalOrd)] struct ShortCircuit { x: int, y: FailCmp } fn main() { let a = ShortCircuit { x: 1, y: FailCmp }; let b = ShortCircuit { x: 2, y: FailCmp }; assert!(a != b); assert!(a < b); assert!(!a.equals(&b)); assert_eq!(a.cmp(&b), ::std::cmp::Less); } </ins>
Code change:
Any crate that uses fails to compile with a link error saying Test case on outputs: or from a bigger project: Nightly / works totally fine.
Is this reproducible after ?
Yes, happens on a fresh project I made for testing () and after
is the full commit range, which notably includes an LLVM upgrade -- cc Could you check with if is fine and is broken for you?
I can confirm that works fine but is broken. Also, that's a nifty tool.
Okay, LLVM update is then definitely at fault, cc
With default settings I'm not reproducing this locally with on . Do you have any rustflags set in your cargo config or environment variable? What is the full output of ?
Here is the full failing output from <details</detailsIndeed, my are set to Testing again without does not error, and compiles/runs fine.
If it helps, I'm on AMD Zen v1, or , and it looks like was introduced in the LLVM upgrade.
Fails the same way on Linux (GNU and musl) and Windows GNU using on Ryzen 2700X platform so it probably affects all the OSes. <details<summaryDetails</summary</details modify labels: -E-needs-bisection -O-windows-msvc +O-linux +O-windows +A-LLVM
This seems like LLVM's auto-detection of what CPU is on the host or what the target features your native CPU has may be broken. The next step for this is to probably use a build of Clang to reproduce and then report this upstream to LLVM itself.
Er sorry I have a guess as to where this is but I do not have time to investigate this right now, so I'm going to unassign myself since I can't take care of this.
Minimised: IR: I cannot build Clang/LLVM from master right now so I'm attaching IR from my code above. I'll try to find time tomorrow or somewhere next week.
Confirming that produces a call instead of a under .
I believe the cause is that the znver feature spec is missing (the 16B variant is listed).
LLVM bug reported at

Related discussion:
text: <del> Subproject commit f2b0c67661f19bb2564225d47aca424ad0449791 </del> <ins> Subproject commit 48818e9f5d0f2d5978a9b43ad1a2e8d0b83f6aa0 </ins>
Code change:
The idea behind was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in constprop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine. Even shouldn't show so many errors, but that will be harder to do for constprop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this). AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?
Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic
I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?
only prints when  is explicitly called -- somehow constprop must be triggering that. If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.
The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.
my guess is that the printing originates here: calls , but that line does not always result in an error to be shown, right?

Related discussion:
text: ecx.read_discriminant(op).unwrap().1 } <ins> /// Turn an interpreter error into something to report to the user. /// As a side-effect, if RUSTC_CTFE_BACKTRACE is set, this prints the backtrace. /// Should be called only if the error is actually going to to be reported! </ins> pub fn error_to_const_error<'mir, 'tcx>( ecx: &InterpCx<'mir, 'tcx, CompileTimeInterpreter<'mir, 'tcx>>, mut error: InterpErrorInfo<'tcx>,
Code change:
The idea behind was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in constprop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine. Even shouldn't show so many errors, but that will be harder to do for constprop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this). AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?
Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic
I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?
only prints when  is explicitly called -- somehow constprop must be triggering that. If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.
The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.
my guess is that the printing originates here: calls , but that line does not always result in an error to be shown, right?

Related discussion:
text: let r = match f(self) { Ok(val) => Some(val), Err(error) => { <del> let diagnostic = error_to_const_error(&self.ecx, error); </del> use rustc::mir::interpret::InterpError::*; <del> match diagnostic.error { </del> <ins> match error.kind { </ins> Exit(_) => bug!("the CTFE program cannot exit"), Unsupported(_) | UndefinedBehavior(_)
Code change:
The idea behind was that it should only show a backtrace (of where a Miri error originates) when an error is actually shown to the user. And that worked fine when I implemented it. But since then, something changed in constprop, and now I get thousands of backtraces even for crates with no errors, making the env var basically unusable. That is a big problem for debugging of the Miri engine. Even shouldn't show so many errors, but that will be harder to do for constprop which runs the CTFE engine on broken and non-monomorphized MIR (causing tons of problems, not just this). AFAIK you did a bunch of const_prop changes over the last few weeks/months; likely some of what you did is the culprit here. Any ideas?
Well. Const prop tries to eval things and if it fails it doesn't prop. The reason why there are many errors now is that we are actually using the interpcx instead of reimplementing its logic
I'm not sure how to reduce your noise. Maybe we can disable the env var before const prop and reenable after?
only prints when  is explicitly called -- somehow constprop must be triggering that. If that was fixed, things would still be slow because so many backtraces are captured, but at least the result should be readable.
The really fancy solution, but probably too magic, would be to determine if we are running inside a const_prop query and let that alter the behavior. AFAIK rustc uses thread-local storage so this could actually be done, but it might not be how that TLS is supposed to be used.
my guess is that the printing originates here: calls , but that line does not always result in an error to be shown, right?

Related discussion:
text: // Ignore these errors. } Panic(_) => { <ins> let diagnostic = error_to_const_error(&self.ecx, error); </ins> diagnostic.report_as_lint( self.ecx.tcx, "this expression will panic at runtime",
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and -- nominating for prioritization.
introduced an ICE (integer overflow) in the error emitting code, that Miri runs into.
will fix the issue on 's end, which should automatically fix this one.

Related discussion:
text: } else if self.label_right - self.span_left <= self.column_width { // Attempt to fit the code window considering only the spans and labels. let padding_left = (self.column_width - (self.label_right - self.span_left)) / 2; <del> self.computed_left = self.span_left - padding_left; </del> <ins> self.computed_left = self.span_left.saturating_sub(padding_left); </ins> self.computed_right = self.computed_left + self.column_width; } else if self.span_right - self.span_left <= self.column_width { // Attempt to fit the code window considering the spans and labels plus padding. let padding_left = (self.column_width - (self.span_right - self.span_left)) / 5 * 2; <del> self.computed_left = self.span_left - padding_left; </del> <ins> self.computed_left = self.span_left.saturating_sub(padding_left); </ins> self.computed_right = self.computed_left + self.column_width; } else { // Mostly give up but still don't show the full line. self.computed_left = self.span_left;
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! cc the PR reviewer, and -- nominating for prioritization.
introduced an ICE (integer overflow) in the error emitting code, that Miri runs into.
will fix the issue on 's end, which should automatically fix this one.

Related discussion:
text: }; let column_width = if let Some(width) = self.terminal_width { <del> width </del> <ins> width.saturating_sub(code_offset) </ins> } else if self.ui_testing { 140 } else { <del> term_size::dimensions().map(|(w, _)| w - code_offset).unwrap_or(140) </del> <ins> term_size::dimensions() .map(|(w, _)| w.saturating_sub(code_offset)) .unwrap_or(std::usize::MAX) </ins> }; let margin = Margin::new(
Code change:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.

Related discussion:
text: // Warn for non-block expressions with diverging children. match expr.node { ExprKind::Block(..) | ExprKind::Loop(..) | ExprKind::Match(..) => {}, <ins> ExprKind::Call(ref callee, _) => self.warn_if_unreachable(expr.hir_id, callee.span, "call"), ExprKind::MethodCall(_, ref span, _) => self.warn_if_unreachable(expr.hir_id, *span, "call"), </ins> _ => self.warn_if_unreachable(expr.hir_id, expr.span, "expression"), }
Code change:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.

Related discussion:
text: |         ^^^^^^ = note: `#[warn(unreachable_code)]` implied by `#[warn(unused)]` <del> warning: unreachable expression </del> <ins> warning: unreachable call </ins> --> $DIR/never-assign-dead-code.rs:10:5 | LL |     drop(x); <del> |     ^^^^^^^ </del> <ins> |     ^^^^ </ins> warning: unused variable: `x` --> $DIR/never-assign-dead-code.rs:9:9
Code change:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.

Related discussion:
text: LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ <del> error: unreachable expression </del> <ins> error: unreachable call </ins> --> $DIR/expr_call.rs:18:5 | LL |     bar(return); <del> |     ^^^^^^^^^^^ </del> <ins> |     ^^^ </ins> error: aborting due to 2 previous errors
Code change:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.

Related discussion:
text: LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ <del> error: unreachable expression --> $DIR/expr_method.rs:21:5 </del> <ins> error: unreachable call --> $DIR/expr_method.rs:21:9 </ins> | LL |     Foo.bar(return); <del> |     ^^^^^^^^^^^^^^^ </del> <ins> |         ^^^ </ins> error: aborting due to 2 previous errors
Code change:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.

Related discussion:
text: get_u8()); //~ ERROR unreachable expression } fn diverge_second() { <del> call( //~ ERROR unreachable expression </del> <ins> call( //~ ERROR unreachable call </ins> get_u8(), diverge()); }
Code change:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.

Related discussion:
text: LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ <del> error: unreachable expression </del> <ins> error: unreachable call </ins> --> $DIR/unreachable-in-call.rs:17:5 | <del> LL | /     call( LL | |         get_u8(), LL | |         diverge()); | |__________________^ </del> <ins> LL |     call( |     ^^^^ </ins> error: aborting due to 2 previous errors