jiebi/CodeConvo huggingface dataset:
Change:
The following code () produces
Triage: still ICEs
This ICEs since modify labels: +regression-from-stable-to-stable

Discussion:
// Create an infcx, taking the predicates of impl1 as assumptions: tcx.infer_ctxt().enter(|infcx| { <del> // Normalize the trait reference. The WF rules ought to ensure // that this always succeeds. </del> let impl1_trait_ref = match traits::fully_normalize( &infcx, FulfillmentContext::new(),

impl1_trait_ref, ) { Ok(impl1_trait_ref) => impl1_trait_ref, <del> Err(err) => { bug!("failed to fully normalize {:?}: {:?}", impl1_trait_ref, err); </del> <ins> Err(_errors) => { tcx.sess.delay_span_bug( tcx.def_span(impl1_def_id), format!("failed to fully normalize {impl1_trait_ref}"), ); impl1_trait_ref </ins> } };

<ins> #![feature(specialization)] #![allow(incomplete_features)] trait X {} trait Y: X {} trait Z { type Assoc: Y; } struct A<T>(T); impl<T> Y for T where T: X {} impl<T: X> Z for A<T> { type Assoc = T; } // this impl is invalid, but causes an ICE anyway impl<T> From<<A<T> as Z>::Assoc> for T {} //~^ ERROR type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`) fn main() {} </ins>

<ins> error[E0210]: type parameter `T` must be used as the type parameter for some local type (e.g., `MyStruct<T>`) --> $DIR/issue-43037.rs:17:6 | LL | impl<T> From<<A<T> as Z>::Assoc> for T {} |      ^ type parameter `T` must be used as the type parameter for some local type | = note: implementing a foreign trait is only possible if at least one of the types for which it is implemented is local = note: only traits defined in the current crate can be implemented for a type parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0210`. </ins>

<ins> //~ ERROR overflow evaluating the requirement `T: Trait<_>` #![feature(specialization)] #![allow(incomplete_features)] pub trait Trait<T> {} default impl<T, U> Trait<T> for U {} impl<T> Trait<<T as Iterator>::Item> for T {} fn main() {} </ins>

<ins> error[E0275]: overflow evaluating the requirement `T: Trait<_>` | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_45814`) note: required because of the requirements on the impl of `Trait<_>` for `T` --> $DIR/issue-45814.rs:8:20 | LL | default impl<T, U> Trait<T> for U {} |                    ^^^^^^^^     ^ = note: 128 redundant requirements hidden = note: required because of the requirements on the impl of `Trait<_>` for `T` error: aborting due to previous error For more information about this error, try `rustc --explain E0275`. </ins>
Change:
The following error results from dereferencing a as in this code:
What’s the correct fix? Compiler error with a nice error message?
I think this should compile and UB, but a lint against this is probably a good idea.
Reduced test case:
I'm working on a fix for this. Progress on . The idea is to avoid the typing issues entirely by terminating the blocks with as soon as a -value is constructed. Currently the examples given here are fixed, but some more convoluted examples still crash.

Discussion:
if let Some(expr) = expr { unpack!(block = this.into(destination, block, expr)); } else { <del> this.cfg.push_assign_unit(block, source_info, destination); </del> <ins> // If a block has no trailing expression, then it is given an implicit return type. // This return type is usually `()`, unless the block is diverging, in which case the // return type is `!`. For the unit type, we need to actually return the unit, but in // the case of `!`, no return value is required, as the block will never return. let tcx = this.hir.tcx(); let ty = destination.ty(&this.local_decls, tcx).to_ty(tcx); if ty.is_nil() { // We only want to assign an implicit `()` as the return value of the block if the // block does not diverge. (Otherwise, we may try to assign a unit to a `!`-type.) this.cfg.push_assign_unit(block, source_info, destination); } </ins> } // Finally, we pop all the let scopes before exiting out from the scope of block // itself.

ExprKind::Continue { .. } | ExprKind::Break { .. } | ExprKind::InlineAsm { .. } | <del> ExprKind::Return {.. } => { </del> <ins> ExprKind::Return { .. } => { </ins> unpack!(block = this.stmt_expr(block, expr)); this.cfg.push_assign_unit(block, source_info, destination); block.unit()

<ins> // Copyright 2018 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. #![feature(never_type)] #![allow(dead_code)] #![allow(path_statements)] #![allow(unreachable_patterns)] fn never_direct(x: !) { x; } fn never_ref_pat(ref x: !) { *x; } fn never_ref(x: &!) { let &y = x; y; } fn never_pointer(x: *const !) { unsafe { *x; } } fn never_slice(x: &[!]) { x[0]; } fn never_match(x: Result<(), !>) { match x { Ok(_) => {}, Err(_) => {}, } } pub fn main() { } </ins>
Change:
I encountered an internal compiler error (on stable, beta and nightly) in my code and i could reduce it to this: . I would expect that this program won't compile because of the non-const fn in a const declaration. Nightly rightly gives an error message to that effect and panics, stable just panics. Stacktrace:
No ICE in current stable
But using a random non-const-fn ICEs: cc
Ah, CTFE errors are supposed to be silently ignored.

Discussion:
let mut pcx = PatternContext::new(tcx, param_env_and_substs, tables); let result = pcx.lower_pattern(pat); if !pcx.errors.is_empty() { <del> span_bug!(pat.span, "encountered errors lowering pattern: {:?}", pcx.errors) </del> <ins> let msg = format!("encountered errors lowering pattern: {:?}", pcx.errors); tcx.sess.delay_span_bug(pat.span, &msg); </ins> } debug!("Pattern::from_hir({:?}) = {:?}", pat, result); result

<ins> // Copyright 2018 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. fn xyz() -> u8 { 42 } const NUM: u8 = xyz(); //~^ ERROR calls in constants are limited to constant functions, struct and enum constructors fn main() { match 1 { NUM => unimplemented!(), _ => unimplemented!(), } } </ins>
Change:
Code: Using versions (similar crash; ): rustc 1.20.0-nightly ( 2017-07-08) rustc 1.18.0 ( 2017-06-06) I don't know too much about the compiler internals, but a bug search for "layout_of" didn't bring up anything that seemed relevant. So here you go. Seems similar to but I'm not using impl Trait?
Minimized a bit (52 lines): <details<summary(expand) </summary</details
This showed up in the crate's
A smaller version of what I believe is the same ICE:
yeah now that I look at it is that on stable OP's example has a different ICE error than on nightly, very alike to , while the one on nightly matches your example.
Bisected the nightly ICE using bisect-rust to () -- cc
Looks like the projection cache is dropping normalization obligations on the floor at This causes problems with my new evaluation code because it causes an earlier call into evaluation, which allows the cache pollution to proceed (I think).
Actually, the problem is that the projection cache is incompatible with 1-pass evaluation. Not sure how to solve this.
do you have further thoughts on this? The regression is now on beta :(
cc
I don't have any specific knowledge of how the caches involved here interact. It seems like layout code triggers this but the problem could arise in a number of other ways.
I have to talk to about this.
I can look into this, but not until Saturday.
triage: P-high
So I have a fix pending in but I'm not sure what to use for a regression test, since I don't want to add a dependency on futures.
"reasonably sized" test case which reproduces the error here.
I've minimized 's example to roughly the half .
The nightly is out and I no longer run into that ICE! On the other hand compiling this simple program now takes 8 minutes. The previous commit (before I introduced the ICE) is up from 6s to 1m51s.
I suggest you file a separate bug report for this.
hm I can't seem to get the commit linked above to compile? What compiler are you using to compile it "pre ICE"?
I'm compiling using stable and the nightly from the 28th from rustup... not sure why this would fail for you?
sorry I still can't get the code to compile. Can you list the exact commands you're using, along with the exact toolchain in rustup-style syntax?
The toolchains I tried are and . Whatever your environment you can reproduce this from scratch in Docker with:
Ok thanks for the repro Want to open a new issue with that so we can be sure to track it?
Will do! [edit: ]

Discussion:
// but we have `T: Foo<X = ?1>` and `?1: Bar<X = // ?0>`). ty::Predicate::Projection(ref data) => <del> !infcx.any_unresolved_type_vars(&data.ty()), </del> <ins> infcx.any_unresolved_type_vars(&data.ty()), </ins> // We are only interested in `T: Foo<X = U>` predicates, whre // `U` references one of `unresolved_type_vars`. =)
Change:
While trying to figure out what the attribute did, I ran across this line of code. Near as I can tell, the reference to here doesn't do anything, and can be removed for clarity.
Marking as an easy issue since it seems that removing that line is all that would need to be done here, and then if CI passes, great, if not, then we shouldn't remove it. Willing to mentor as well.
I take this up
close?

Discussion:
// memory, which makes for some *confusing* logs. That's why these are here // instead of in std. <del> #![reexport_test_harness_main = "test_main"] </del> #![feature(libc, std_misc, duration)] extern crate libc;
Change:
I wonder if this shouldn't work? The failure is: expects a but is a . 's id is the same as ('s id). CC'ing because he's the borrowed pointer specialist.
I think this never should have worked, since the struct is declared to contain a managed box. The error message isn't the clearest, but is saying the compiler doesn't know that the lifetime of the contents of a node's field is the same as the lifetime of the contents of the node itself. I'll check in a modified run-pass test case (where the field contains a pointer with a lifetime annotation).
Pending
Doesn't look critical for 0.6
Yeah, this is working-as-intended. The associated test (which landed) shows how this needs to be written if you want to use borrowed pointers here. Closing.

Discussion:
<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. struct Node<'self, T> { val: T, next: Option<&'self Node<'self, T>> } impl<'self, T> Node<'self, T> { fn get(&self) -> &'self T { match self.next { Some(ref next) => next.get(), None => &self.val } } } fn main() {} </ins>
Change:
With rust nightly compiler, the result on the screen is even though the compiler warning that 11 case is unreachable. Link to rust playground:

Discussion:
Ok(true) } <del> fn range_covered_by_constructor(tcx: TyCtxt, span: Span, </del> <ins> fn constructor_covered_by_range(tcx: TyCtxt, span: Span, </ins> ctor: &Constructor, from: &ConstVal, to: &ConstVal, end: RangeEnd)

match *ctor { ConstantValue(ref value) => { let to = cmp_to(value)?; <del> let end = (to != Ordering::Greater) || (end == RangeEnd::Excluded && to == Ordering::Equal); </del> <ins> let end = (to == Ordering::Less) || (end == RangeEnd::Included && to == Ordering::Equal); </ins> Ok(cmp_from(value)? && end) }, ConstantRange(ref from, ref to, RangeEnd::Included) => { let to = cmp_to(to)?; <del> let end = (to != Ordering::Greater) || (end == RangeEnd::Excluded && to == Ordering::Equal); </del> <ins> let end = (to == Ordering::Less) || (end == RangeEnd::Included && to == Ordering::Equal); </ins> Ok(cmp_from(from)? && end) }, ConstantRange(ref from, ref to, RangeEnd::Excluded) => {

"unexpected const-val {:?} with ctor {:?}", value, constructor) }, _ => { <del> match range_covered_by_constructor( </del> <ins> match constructor_covered_by_range( </ins> cx.tcx, pat.span, constructor, value, value, RangeEnd::Included ) { Ok(true) => Some(vec![]),

} PatternKind::Range { ref lo, ref hi, ref end } => { <del> match range_covered_by_constructor( </del> <ins> match constructor_covered_by_range( </ins> cx.tcx, pat.span, constructor, lo, hi, end.clone() ) { Ok(true) => Some(vec![]),

<ins> // Copyright 2017 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. #![feature(exclusive_range_pattern)] fn main() { // These cases should generate no warning. match 10 { 1..10 => {}, 10 => {}, _ => {}, } match 10 { 1..10 => {}, 9...10 => {}, _ => {}, } match 10 { 1..10 => {}, 10...10 => {}, _ => {}, } // These cases should generate an "unreachable pattern" warning. match 10 { 1..10 => {}, 9 => {}, _ => {}, } match 10 { 1..10 => {}, 8...9 => {}, _ => {}, } match 10 { 1..10 => {}, 9...9 => {}, _ => {}, } } </ins>  No newline at end of file

<ins> warning: unreachable pattern --> $DIR/issue-43253.rs:36:9 | 36 |         9 => {}, |         ^ | = note: #[warn(unreachable_patterns)] on by default warning: unreachable pattern --> $DIR/issue-43253.rs:42:9 | 42 |         8...9 => {}, |         ^^^^^ warning: unreachable pattern --> $DIR/issue-43253.rs:48:9 | 48 |         9...9 => {}, |         ^^^^^ </ins>
Change:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.

Discussion:
use syntax::ast; use syntax::attr; use syntax::feature_gate::{AttributeGate, AttributeType, Stability, deprecated_attributes}; <del> use syntax_pos::Span; </del> <ins> use syntax_pos::{Span, SyntaxContext}; </ins> use syntax::symbol::keywords; use rustc::hir::{self, PatKind};

if let hir::ExprWhile(ref cond, ..) = e.node { if let hir::ExprLit(ref lit) = cond.node { if let ast::LitKind::Bool(true) = lit.node { <del> cx.span_lint(WHILE_TRUE, e.span, "denote infinite loops with loop { ... }"); </del> <ins> if lit.span.ctxt() == SyntaxContext::empty() { cx.span_lint(WHILE_TRUE, e.span, "denote infinite loops with loop { ... }"); } </ins> } } }

sp: Span, tts: &[tokenstream::TokenTree]) -> Box<base::MacResult + 'static> { <ins> let sp = sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)); </ins> let mut p = cx.new_parser_from_tts(tts); let cfg = panictry!(p.parse_meta_item());

} } } <ins> let sp = sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)); </ins> base::MacEager::expr(cx.expr_str(sp, Symbol::intern(&accumulator))) }

Box::new(Result { ident: res, <del> span: sp, </del> <ins> span: sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)), </ins> }) }

Some(v) => v, }; <ins> let sp = sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)); </ins> let e = match env::var(&*var.as_str()) { Err(..) => { cx.expr_path(cx.path_all(sp,

fn main() { while true {} //~ ERROR: infinite loops } <ins> #[deny(while_true)] fn bar() { while cfg!(unix) {} // no error } </ins>
Change:
Rustc used to be able to replace with a constant when optimizing, not at the moment. It simply looks like a Layout method that is not inlinable. (This is a regression strictly speaking — stable & beta can do this optimization, but not nightly.) Code to reproduce:
Are there any ways to write automated tests to check for "regressions" like this? Assertions against LLVM bitcode?
Yes can be used for this, e.g. Assuming this is run against the bitcode after optimization, that is.
cc -- seems LLVM related
Nope. Just () that is not marked as inline.
cc
I didn't confirm that making Layout::repeat as inline fixes this, so please confirm that/add a test before closing.

Discussion:
/// of each element in the array. /// /// On arithmetic overflow, returns `None`. <ins> #[inline] </ins> pub fn repeat(&self, n: usize) -> Option<(Self, usize)> { let padded_size = match self.size.checked_add(self.padding_needed_for(self.align)) { None => return None,

<ins> // Copyright 2017 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. // // no-system-llvm // compile-flags: -O #![crate_type="lib"] #[no_mangle] pub fn sum_me() -> i32 { // CHECK-LABEL: @sum_me // CHECK-NEXT: {{^.*:$}} // CHECK-NEXT: ret i32 6 vec![1, 2, 3].iter().sum::<i32>() } </ins>
Change:
The following code compiles, but causes a segmentation fault when run: This is using master on Ubuntu.
I'll look at this, since I was working on something similar.
I cannot duplicate this on Mac OS X.
Note that in , I was testing against an "updated" version of the code that may not be faithful to the original bug scenario. But if that is the case, it may also be the case that this bug has gone away with type-checker changes since it was filed...
Seems to be fixed; pending for the test case. (I chose to add the original test case, except with stdin changed to stdout so we don't have a test case reading input, for fidelity to the original bug.)
Test case merged in - closing

Discussion:
<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. fn main() { let stdout = &io::stdout() as &io::WriterUtil; stdout.write_line("Hello!"); } </ins>
Change:
ICE occurs whether we use or . cc
The no longer ICEs.
this can be closed as it no longer ICEs.
Actually, presumably, E-needstest.

Discussion:
<ins> // run-pass #![feature(core_intrinsics)] #![feature(repr128)] #[repr(i128)] enum Big { A, B } fn main() { unsafe { println!("{} {:?}", std::intrinsics::discriminant_value(&Big::A), std::mem::discriminant(&Big::B)); } } </ins>
Change:
(edit: see below) The first error is sensical: But the knock-on errors are not:
Minimized:

Discussion:
pub fn impls_are_allowed_to_overlap(self, def_id1: DefId, def_id2: DefId) -> Option<ImplOverlapKind> { <ins> // If either trait impl references an error, they're allowed to overlap, // as one of them essentially doesn't exist. if self.impl_trait_ref(def_id1).map_or(false, |tr| tr.references_error()) || self.impl_trait_ref(def_id2).map_or(false, |tr| tr.references_error()) { return Some(ImplOverlapKind::Permitted); } </ins> let is_legit = if self.features().overlapping_marker_traits { let trait1_is_empty = self.impl_trait_ref(def_id1) .map_or(false, |trait_ref| {

<ins> struct ErrorKind; struct Error(ErrorKind); impl From<nope::Thing> for Error { //~ ERROR failed to resolve fn from(_: nope::Thing) -> Self { //~ ERROR failed to resolve unimplemented!() } } impl From<ErrorKind> for Error { fn from(_: ErrorKind) -> Self { unimplemented!() } } fn main() {} </ins>

<ins> error[E0433]: failed to resolve: use of undeclared type or module `nope` --> $DIR/conflicting-impl-with-err.rs:4:11 | LL | impl From<nope::Thing> for Error { |           ^^^^ use of undeclared type or module `nope` error[E0433]: failed to resolve: use of undeclared type or module `nope` --> $DIR/conflicting-impl-with-err.rs:5:16 | LL |     fn from(_: nope::Thing) -> Self { |                ^^^^ use of undeclared type or module `nope` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0433`. </ins>
Change:
When attempting to build rustc without optimzations, linking of fails because: I guess this can be fixed by either compiling as PIC or by making it not depend on . Which would be the correct fix? Intuitively I would say that should not have any dependencies.
The submodule still needs to be updated

Discussion:
<del> Subproject commit 5e49856003f33aa5781a0edca148be21025e18e7 </del> <ins> Subproject commit 6b9281d2b2f0ebb94838814b1e8ace2de4b7035b </ins>