jiebi/CodeConvo huggingface dataset:
Code change:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to

Related discussion:
text: <ins> // only-x86_64 #[cfg(target_arch = "x86")] use std::arch::x86::*; #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; unsafe fn pclmul(a: __m128i, b: __m128i) -> __m128i { let imm8 = 3; _mm_clmulepi64_si128(a, b, imm8) //~ ERROR argument 3 is required to be a constant } fn main() {} </ins>
Code change:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to

Related discussion:
text: <ins> error: argument 3 is required to be a constant --> $DIR/const_arg_local.rs:10:5 | LL |     _mm_clmulepi64_si128(a, b, imm8) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to

Related discussion:
text: <ins> // only-x86_64 #[cfg(target_arch = "x86")] use std::arch::x86::*; #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; unsafe fn pclmul(a: __m128i, b: __m128i) -> __m128i { _mm_clmulepi64_si128(a, b, *&mut 42) //~ ERROR argument 3 is required to be a constant } fn main() {} </ins>
Code change:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to

Related discussion:
text: <ins> error: argument 3 is required to be a constant --> $DIR/const_arg_promotable.rs:9:5 | LL |     _mm_clmulepi64_si128(a, b, *&mut 42) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to

Related discussion:
text: <ins> // only-x86_64 #[cfg(target_arch = "x86")] use std::arch::x86::*; #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; unsafe fn pclmul(a: __m128i, b: __m128i, imm8: i32) -> __m128i { _mm_clmulepi64_si128(a, b, imm8) //~ ERROR argument 3 is required to be a constant } fn main() {} </ins>
Code change:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to

Related discussion:
text: <ins> error: argument 3 is required to be a constant --> $DIR/const_arg_wrapper.rs:9:5 | LL |     _mm_clmulepi64_si128(a, b, imm8) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>
Code change:
Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

Related discussion:
text: <ins> // check-pass trait Mirror { type Other; } #[derive(Debug)] struct Even(usize); struct Odd; impl Mirror for Even { type Other = Odd; } impl Mirror for Odd { type Other = Even; } trait Dyn<T: Mirror>: AsRef<<T as Mirror>::Other> {} impl Dyn<Odd> for Even {} impl AsRef<Even> for Even { fn as_ref(&self) -> &Even { self } } fn code<T: Mirror>(d: &dyn Dyn<T>) -> &T::Other { d.as_ref() } fn main() { println!("{:?}", code(&Even(22))); } </ins>
Code change:
Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

Related discussion:
text: <ins> fn t7p<A, B, C>(f: impl Fn(B) -> C, g: impl Fn(A) -> B) -> impl Fn(A) -> C { move |a: A| -> C { f(g(a)) } } fn t8n<A, B, C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) -> impl Fn(A) -> (B, C) where A: Copy, { move |a: A| -> (B, C) { let b = a; let fa = f(a); let ga = g(b); (fa, ga) } } fn main() { let f = |(_, _)| {}; let g = |(a, _)| a; let t7 = |env| |a| |b| t7p(f, g)(((env, a), b)); let t8 = t8n(t7, t7p(f, g)); //~^ ERROR: expected a `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)> } </ins>
Code change:
Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

Related discussion:
text: <ins> error[E0277]: expected a `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)>` --> $DIR/issue-59494.rs:21:22 | LL | fn t8n<A, B, C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) -> impl Fn(A) -> (B, C) |                                             ---------- required by this bound in `t8n` ... LL |     let t8 = t8n(t7, t7p(f, g)); |                      ^^^^^^^^^ expected an `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)>` | = help: the trait `Fn<(_,)>` is not implemented for `impl Fn<(((_, _), _),)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

Related discussion:
text: <ins> // check-pass pub trait Trait1 { type C; } struct T1; impl Trait1 for T1 { type C = usize; } pub trait Callback<T: Trait1>: FnMut(<T as Trait1>::C) {} impl<T: Trait1, F: FnMut(<T as Trait1>::C)> Callback<T> for F {} pub struct State<T: Trait1> { callback: Option<Box<dyn Callback<T>>>, } impl<T: Trait1> State<T> { fn new() -> Self { Self { callback: None } } fn test_cb(&mut self, d: <T as Trait1>::C) { (self.callback.as_mut().unwrap())(d) } } fn main() { let mut s = State::<T1>::new(); s.test_cb(1); } </ins>
Code change:
Discovered a compiler panic, thought it might relate to , but was told to post a new issue. In minimizing, it seems the generic types are required to trigger the panic, I was unable to reproduce when inlining t7p or t8n. This code panics on 1.33 - 1.35, but does not panic on 1.32 (): On 1.32: On 1.35 nightly: --Bryan
triage: P-high. Removing nominated tag since there's little to discuss beyond its P-highness. (The fact its unassigned will be discussed regardless of nomination state.)
Bisection points to i.e. as the culprit. The backtrace in that commit looks very similar to the one reported here, and the parent commit () gives the same compiler error.
I spent some time looking at this a few weeks ago but did not manage to find anything conclusive. At this point I'm going to be taking a break for a few months, so I am unassigning myself from this issue.
triage: assigning self.
triage: downgrading to P-medium; this does not warrant revisiting every week.
I was able to minify it a bit further:
Triage: It's no longer ICE with the latest nightly.

Related discussion:
text: <ins> // check-pass fn any<T>() -> T { loop {} } trait Foo { type V; } trait Callback<T: Foo>: Fn(&T, &T::V) {} impl<T: Foo, F: Fn(&T, &T::V)> Callback<T> for F {} struct Bar<T: Foo> { callback: Box<dyn Callback<T>>, } impl<T: Foo> Bar<T> { fn event(&self) { (self.callback)(any(), any()); } } struct A; struct B; impl Foo for A { type V = B; } fn main() { let foo = Bar::<A> { callback: Box::new(|_: &A, _: &B| ()) }; foo.event(); } </ins>
Code change:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.

Related discussion:
text: <del> use errors::DiagnosticBuilder; </del> <ins> use errors::{Applicability, DiagnosticBuilder}; </ins> use syntax::ast::{self, *}; use syntax::source_map::Spanned; use syntax::ext::base::*; use syntax::ext::build::AstBuilder; use syntax::parse::token; <ins> use syntax::parse::parser::Parser; </ins> use syntax::print::pprust; use syntax::ptr::P; use syntax::symbol::Symbol;
Code change:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.

Related discussion:
text: return Err(err); } <del> Ok(Assert { cond_expr: parser.parse_expr()?, custom_message: if parser.eat(&token::Comma) { let ts = parser.parse_tokens(); if !ts.is_empty() { Some(ts) } else { None } } else { None }, }) </del> <ins> let cond_expr = parser.parse_expr()?; // Some crates use the `assert!` macro in the following form (note extra semicolon): // // assert!( //     my_function(); // ); // // Warn about semicolon and suggest removing it. Eventually, this should be turned into an // error. if parser.token == token::Semi { let mut err = cx.struct_span_warn(sp, "macro requires an expression as an argument"); err.span_suggestion( parser.span, "try removing semicolon", String::new(), Applicability::MaybeIncorrect ); err.note("this is going to be an error in the future"); err.emit(); parser.bump(); } // Some crates use the `assert!` macro in the following form (note missing comma before // message): // // assert!(true "error message"); // // Parse this as an actual message, and suggest inserting a comma. Eventually, this should be // turned into an error. let custom_message = if let token::Literal(token::Lit::Str_(_), _) = parser.token { let mut err = cx.struct_span_warn(parser.span, "unexpected string literal"); let comma_span = cx.source_map().next_point(parser.prev_span); err.span_suggestion_short( comma_span, "try adding a comma", ", ".to_string(), Applicability::MaybeIncorrect ); err.note("this is going to be an error in the future"); err.emit(); parse_custom_message(&mut parser) } else if parser.eat(&token::Comma) { parse_custom_message(&mut parser) } else { None }; if parser.token != token::Eof { parser.expect_one_of(&[], &[])?; unreachable!(); } Ok(Assert { cond_expr, custom_message }) } fn parse_custom_message<'a>(parser: &mut Parser<'a>) -> Option<TokenStream> { let ts = parser.parse_tokens(); if !ts.is_empty() { Some(ts) } else { None } </ins> }
Code change:
() Output: Version: 1.34.0 1.35.0 2019-04-15 nightly () Expected: Original report:
26.0 is the first version that accepts this. 1.25.0 rejects it with:
(not really a regression since more code now compiles)
Adding T-compiler since is a built-in.
Opened —it should fix the issue.
triage: P-medium. I'm going to assume we don't need any future-compat machinery for a bug of this nature, unless the crater run on PR indicates that there are occurrences of this mis-use of in the wild.

Related discussion:
text: <ins> // Ensure assert macro does not ignore trailing garbage. // // See https://github.com/rust-lang/rust/issues/60024 for details. fn main() { assert!(true some extra junk, "whatever"); //~^ ERROR expected one of assert!(true some extra junk); //~^ ERROR expected one of assert!(true, "whatever" blah); //~^ ERROR no rules expected assert!(true "whatever" blah); //~^ WARN unexpected string literal //~^^ ERROR no rules expected assert!(true;); //~^ WARN macro requires an expression assert!(false || true "error message"); //~^ WARN unexpected string literal } </ins>