jiebi/CodeConvo huggingface dataset:
Code change:
While it's important to keep on top of regressions to the toolstate, most of the time these issues are fixed quickly, by the author of the PR that caused the regression, or someone else. With GitHub notifications being difficult enough to keep up with as it is, being mentioned on every toolstate change issue is mostly noise. The issues are already tagged T-compiler and nominated, so I think additionally pinging everyone is unnecessary. I think it would be sensible to change: to: cc
I think that's a good idea!
I agree that the pings are rarely useful. Nominating is probably sufficient.

Related discussion:
text: cc @{}, do you think you would have time to do the follow-up work? If so, that would be great! <del> cc @{}, the PR reviewer, and @rust-lang/compiler -- nominating for prioritization. </del> <ins> cc @{}, the PR reviewer, and nominating for compiler team prioritization. </ins> ''').format( relevant_pr_number, tool, status_description,
Code change:
The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.

Related discussion:
text: declare_lint! { pub CONST_ERR, Deny, <del> "constant evaluation detected erroneous expression" </del> <ins> "constant evaluation detected erroneous expression", report_in_external_macro: true </ins> } declare_lint! {
Code change:
The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.

Related discussion:
text: <ins> #![feature(allow_internal_unstable)] // Macro to help ensure CONST_ERR lint errors // are not silenced in external macros. // https://github.com/rust-lang/rust/issues/65300 #[macro_export] #[allow_internal_unstable(type_ascription)] macro_rules! static_assert { ($test:expr) => { #[allow(dead_code)] const _: () = [()][!($test: bool) as usize]; } } </ins>
Code change:
The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.

Related discussion:
text: <ins> // edition:2018 // aux-build:external_macro.rs // Ensure that CONST_ERR lint errors // are not silenced in external macros. // https://github.com/rust-lang/rust/issues/65300 extern crate external_macro; use external_macro::static_assert; fn main() { static_assert!(2 + 2 == 5); //~ ERROR } </ins>
Code change:
The following does not error locally / on the playground If I copy paste the macro into the same file, it errors as expected Checking other macros, error as expected.
This feels like it's related to a similar issue () I created a while back.
cc
This is probably because the "error" is just a lint. And we appear to silence it in external macros. We shouldn't do that. IIRC this is just a flag that needs to be set for the lint macro
Yes, we need to set reportinexternal_macro param on the lint I believe
Ah, that makes sense! Building locally with the parameter set to confirm. it does ^^ will check the samples in there too.

Related discussion:
text: <ins> error: any use of this value will cause an error --> $DIR/const-external-macro-const-err.rs:12:5 | LL |     static_assert!(2 + 2 == 5); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ index out of bounds: the len is 1 but the index is 1 | = note: `#[deny(const_err)]` on by default = note: this error originates in a macro outside of the current crate (in Nightly builds, run with -Z external-macro-backtrace for more info) error: aborting due to previous error </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! cc the PR reviewer, and nominating for compiler team prioritization.
Fix is on the way at

Related discussion:
text: <del> Subproject commit 5cb983338e924ec85898880d60e65f2a1291b7be </del> <ins> Subproject commit 52cebb1f8f8789b97d243c07bf4c961ca0017f7b </ins>
Code change:
Running Servo’s unit tests started failing on CI a couple nightlies ago. A customized CI task to add shows: The error message appears to come from here: Reading through the call sites of this function I quickly reach in , so I don’t understand how this message could be emitted while is not actually present in the command-line arguments given to rustc by Cargo. I have also not managed to reproduce this outside of the CI environment. I don’t have an exact regression range, but this started happening a couple days ago which is close to when landed. This PR updated Cargo, including whose description mentions using rustc’s JSON output more. I suspect this is what caused the issue to be uncovered, but it looks like the root cause is in rustc’s argument parsing.
Sorry for the noise! I managed to reproduce in a local docker container (in order to copy CI’s config exactly), the problem turned out to be using an old version of sccache:

Related discussion:
text: #[stable(feature = "rust1", since = "1.0.0")] impl fmt::Debug for RangeFull { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { <del> fmt::Debug::fmt("..", fmt) </del> <ins> write!(fmt, "..") </ins> } }
Code change:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.

Related discussion:
text: self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }
Code change:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] struct Struct<T>(T); impl<T, const N: usize> Struct<[T; N]> { fn f() {} fn g() { Self::f(); } } fn main() { Struct::<[u32; 3]>::g(); } </ins>
Code change:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>
Code change:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.

Related discussion:
text: <ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash struct S<T, const N: usize>([T; N]); fn f<T, const N: usize>(x: T) -> S<T, {N}> { panic!() } fn main() { f(0u8); //[cfail1]~^ ERROR type annotations needed } </ins>
Code change:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.

Related discussion:
text: <ins> // revisions:cfail1 #![feature(const_generics)] //[cfail1]~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash fn combinator<T, const S: usize>() -> [T; S] {} //[cfail1]~^ ERROR mismatched types fn main() { combinator().into_iter(); //[cfail1]~^ ERROR type annotations needed } </ins>
Code change:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.

Related discussion:
text: <ins> // revisions:rpass1 #![feature(const_generics)] pub struct Foo<T, const N: usize>([T; 0]); impl<T, const N: usize> Foo<T, {N}> { pub fn new() -> Self { Foo([]) } } fn main() { let _: Foo<u32, 0> = Foo::new(); } </ins>
Code change:
modify labels: E-easy
I think it is known that those are broken, it is tracked in the . I'm not sure if is still interested in updating the submodule. Is it in a passable state now?
Oops I know I was missing something! PR opened. Thanks

Related discussion:
text: <del> Subproject commit 941968db2fd9c85788a4f971c8e425d46b4cb734 </del> <ins> Subproject commit 75a5f9236c689a547fe207a10854f0775bce7937 </ins>
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing nomination label.

Related discussion:
text: "regex-syntax", "semver", "serde", <del> "smallvec 0.6.10", </del> <ins> "smallvec 1.0.0", </ins> "toml", "unicode-normalization", "url 2.1.0",
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing nomination label.

Related discussion:
text: let host_libs = builder .stage_out(compiler, Mode::ToolRustc) .join(builder.cargo_dir()); <ins> let target_libs = builder .stage_out(compiler, Mode::ToolRustc) .join(&self.host) .join(builder.cargo_dir()); </ins> cargo.env("HOST_LIBS", host_libs); <ins> cargo.env("TARGET_LIBS", target_libs); </ins> // clippy tests need to find the driver cargo.env("CLIPPY_DRIVER_PATH", clippy);
Code change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing nomination label.

Related discussion:
text: <del> Subproject commit c8e3cfbdd997839c771ca32c7ac860fe95149a04 </del> <ins> Subproject commit 3abdd2f1ced4cf3a44c7de88c5e39b3bb5037c4d </ins>
Code change:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.

Related discussion:
text: let result = match (&desc.should_panic, task_result) { (&ShouldPanic::No, Ok(())) | (&ShouldPanic::Yes, Err(_)) => TestResult::TrOk, (&ShouldPanic::YesWithMessage(msg), Err(ref err)) => { <del> if err </del> <ins> let maybe_panic_str = err </ins> .downcast_ref::<String>() .map(|e| &**e) <del> .or_else(|| err.downcast_ref::<&'static str>().map(|e| *e)) .map(|e| e.contains(msg)) .unwrap_or(false) { </del> <ins> .or_else(|| err.downcast_ref::<&'static str>().map(|e| *e)); if maybe_panic_str.map(|e| e.contains(msg)).unwrap_or(false) { </ins> TestResult::TrOk <ins> } else if desc.allow_fail { TestResult::TrAllowedFail } else if let Some(panic_str) = maybe_panic_str { TestResult::TrFailedMsg(format!( r#"panic did not contain expected string panic message: `{:?}`, expected substring: `{:?}`"#, panic_str, msg )) </ins> } else { <del> if desc.allow_fail { TestResult::TrAllowedFail } else { TestResult::TrFailedMsg( format!("panic did not include expected string '{}'", msg) ) } </del> <ins> TestResult::TrFailedMsg(format!( r#"expected panic with string value, found non-string value: `{:?}` expected substring: `{:?}`"#, (**err).type_id(), msg )) </ins> } } (&ShouldPanic::Yes, Ok(())) => {