jiebi/CodeConvo huggingface dataset:
Change:
/// Details of why a pointer had to be in-bounds. #[derive(Debug, Copy, Clone, TyEncodable, TyDecodable, HashStable)] pub enum CheckInAllocMsg { <ins> /// We are access memory. </ins> MemoryAccessTest, <ins> /// We are doing pointer arithmetic. </ins> PointerArithmeticTest, <ins> /// None of the above -- generic/unspecific inbounds test. </ins> InboundsTest, } impl fmt::Display for CheckInAllocMsg { /// When this is printed as an error the context looks like this <del> /// "{test name} failed: pointer must be in-bounds at offset..." </del> <ins> /// "{msg}pointer must be in-bounds at offset..." </ins> fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { write!( f, "{}", match *self { <del> CheckInAllocMsg::MemoryAccessTest => "memory access", CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic", CheckInAllocMsg::InboundsTest => "inbounds test", </del> <ins> CheckInAllocMsg::MemoryAccessTest => "memory access failed: ", CheckInAllocMsg::PointerArithmeticTest => "pointer arithmetic failed: ", CheckInAllocMsg::InboundsTest => "", </ins> } ) }

Discussion:
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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Some error message changes (cc ) broke Miri, but some "null pointer is not allowed for this operation" changes look... wrong? For example: (and many more) They are all not .
Yeah my patch makes no sense... working on a fix.
I don't think the toolstate is fixed: ! But it's just error message differences: claim
Change:
serde = { version = "1.0.82", features = ['derive'] } serde_json = { version = "1.0.31", features = ["raw_value"] } smallvec = { version = "0.6", features = ['union', 'may_dangle'] } <del> byteorder = { version = "1.2.7", features = ["i128"] } </del> [target.'cfg(not(windows))'.dependencies]

Discussion:
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.
triage: P-medium. Unnominating.
Change:
= note: macros cannot expand to enum variants error: unexpected token: `!` <del> --> $DIR/macro-expand-to-field.rs:39:14 </del> <ins> --> $DIR/macro-expand-to-field.rs:40:14 </ins> | <ins> LL |     Data { |     ---- while parsing this struct </ins> LL |         field!(x:u32), |              ^ unexpected token after this | = note: macros cannot expand to struct fields error: unexpected token: `!` <del> --> $DIR/macro-expand-to-field.rs:48:14 </del> <ins> --> $DIR/macro-expand-to-field.rs:49:14 </ins> | <ins> LL |     Named { |     ----- while parsing this struct </ins> LL |         field!(oopsies:()), |              ^ unexpected token after this | = note: macros cannot expand to struct fields error: unexpected token: `!` <del> --> $DIR/macro-expand-to-field.rs:52:14 | LL |         field!(oopsies2:()), |              ^ unexpected token after this | = note: macros cannot expand to struct fields error: unexpected token: `!` --> $DIR/macro-expand-to-field.rs:61:10 </del> <ins> --> $DIR/macro-expand-to-field.rs:60:10 </ins> | <ins> LL | union Union { |       ----- while parsing this union ... </ins> LL |     field!(oopsies:()), |          ^ unexpected token after this | = note: macros cannot expand to union fields error: unexpected token: `!` <del> --> $DIR/macro-expand-to-field.rs:66:10 </del> <ins> --> $DIR/macro-expand-to-field.rs:73:16 </ins> | <del> LL |     field!(recovers:()), |          ^ unexpected token after this </del> <ins> LL | pub struct Lazy { |            ---- while parsing this struct LL | LL |     unreachable!() |                ^ unexpected token after this </ins> | <del> = note: macros cannot expand to union fields </del> <ins> = note: macros cannot expand to struct fields </ins> <del> error: aborting due to 9 previous errors </del> <ins> error: aborting due to 7 previous errors </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2023-08-05 Regression in cc
This is probably because it recovers from it and gives the field no name. We should probably give it the macro's name instead I believe this is the offending line:
An alternative approach would be to directly throw an error instead of allowing the parser to continue, imo.
label -needs-triage
Change:
return Ok(None); } <ins> if !tcx.features().inherent_associated_types { tcx.sess .delay_span_bug(span, "found inherent assoc type without the feature being gated"); } </ins> // // Select applicable inherent associated type candidates modulo regions. //

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim
Change:
the compiler. They are accessible via the `--explain` flag. Each explanation comes with an example of how to trigger it and advice on how to fix it. <ins> Please read [RFC 1567](https://github.com/rust-lang/rfcs/blob/master/text/1567-long-error-codes-explanation-normalization.md) for details on how to format and write long error codes. </ins> * All of them are accessible [online](http://doc.rust-lang.org/error-index.html), which are auto-generated from rustc source code in different places: [librustc](https://github.com/rust-lang/rust/blob/master/src/librustc/diagnostics.rs), <ins> [libsyntax](https://github.com/rust-lang/rust/blob/master/src/libsyntax/diagnostics.rs), </ins> [librustc_borrowck](https://github.com/rust-lang/rust/blob/master/src/librustc_borrowck/diagnostics.rs), [librustc_const_eval](https://github.com/rust-lang/rust/blob/master/src/librustc_const_eval/diagnostics.rs), <del> [librustc_lint](https://github.com/rust-lang/rust/blob/master/src/librustc_lint/types.rs), </del> [librustc_metadata](https://github.com/rust-lang/rust/blob/master/src/librustc_metadata/diagnostics.rs), [librustc_mir](https://github.com/rust-lang/rust/blob/master/src/librustc_mir/diagnostics.rs), [librustc_passes](https://github.com/rust-lang/rust/blob/master/src/librustc_passes/diagnostics.rs), [librustc_privacy](https://github.com/rust-lang/rust/blob/master/src/librustc_privacy/diagnostics.rs), [librustc_resolve](https://github.com/rust-lang/rust/blob/master/src/librustc_resolve/diagnostics.rs), [librustc_trans](https://github.com/rust-lang/rust/blob/master/src/librustc_trans/diagnostics.rs), <ins> [librustc_plugin](https://github.com/rust-lang/rust/blob/master/src/librustc_plugin/diagnostics.rs), </ins> [librustc_typeck](https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/diagnostics.rs). * Explanations have full markdown support. Use it, especially to highlight code with backticks.

Discussion:
. It's been awhile since it's been updated. Here's two changes that haven't been merged into this document yet: Anything else?
Change:
pub const RUSAGE_THREAD: c_int = 1; } pub mod posix08 { <ins> use types::os::arch::c95::c_int; pub const O_CLOEXEC: c_int = 0x1000000; </ins> } pub mod bsd44 { use types::os::arch::c95::c_int;

Discussion:
After lands we will be setting on all file descriptors on unix in the standard library. Currently we do so in a nonatomic fashion, however, so it's possible to continue to leak file descriptors into children if a thread is concurrently forking. Many platforms have methods of creating file descriptors atomically, but many of the APIs are quite new and they need to be properly detected at runtime. For example, the current instances of that need to be migrated are listed below. A reminder of our minimum platform requirements are linux 2.6.18 and OSX 10.7. [x] - this should specify the flag. This flag was in linux 2.6.23 and appears to exist on OSX 10.7. [x] - this should be specify the flag in the argument (second). This flag was only in linux 2.6.27 and does not exist on OSX. [x] - this should be replaced with a call to . This system call was only in linux 2.6.28 and does not exist on OSX. [x] - this should be replaced with (linux 2.6.27, not on OSX) or (linux 2.6.24, appears to exist on OSX 10.7). [x] - this could be replaced with on linux 2.6.27 and perhaps on OSX (not confirmed). The hard part about this bug is figuring out if it's possible to avoid compile-time detection of these functions (and instead rely on runtime detection).
cc
I know this is closed, but I just have to comment on how well thought out and organised the original description was - how clearly the problem is captured and then it's solution tracked. Well done everyone.
Change:
<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. use std::fmt::Write; fn main() { println!(0); //~^ ERROR format argument must be a string literal eprintln!('a'); //~^ ERROR format argument must be a string literal let mut s = String::new(); writeln!(s, true).unwrap(); //~^ ERROR format argument must be a string literal } </ins>

Discussion:
The following all compile and run for example: I would expect them to produce "error: format argument must be a string literal." like does. This is because they use things like but accepts other literals not just . I assume this isn't intentional.
One way to fix this is to replace 's definition with I would prefer to force and friends to take strings but at least this keeps it consistent. EDIT: I honestly don't like how automatically stringifies, it seems kinda ugly and I feel like there should be a separate macro that does compile-time stringification. This would almost certainly be super backwards-incompatible though.
awesome! Why do the places that need 's stringifying functionality not use so doesn't duplicate functionality? That would solve this issue. EDIT: Turns out is different to , the latter only accepts literals whereas the former will verbatim stringify token trees, such as .
Seems like it'd be a breaking change to "fix" this.
For it is explicit and by design, so that part is no problem.
good point, actually has it's own unintuitive behaviour similar but different to .
Why do we consider that the code like works to be a bug? I understand that forbidding it will make more consistent and explicit but we're trading in some convenience here. The other option could be to make behave in same way.
it's not documented so technically something needs to fixed, even if it's just the documentation. If we make behave the same then surely we'd have to change and as well to keep things consistent and I don't think that's a good idea as this isn't even useful. I think this should either be fixed as a breaking change, I doubt it will break much if any real world code, or just depreciated.
thanks for the clarifications, thats makes sense now. I'm not sure and should behave exactly as and as the two groups of macros serve different purposes. Maybe one more special case doesn't worth it however.
Libs team consensus: while it may be desirable to clean this up, this is not breakage we're willing to take on during the Rust 1.x series. I've a new tag, closed-as-desirable-breakage, to help us track issues like this that we might want to revisit if we ever produce a 2.0 release.
related issue: accepts non-bools
Sadly, has been implemented with this bug, so is also affected: .
This would be improved by
Change:
<ins> error[E0658]: `impl Trait` in type aliases is unstable --> $DIR/ice-unhandled-type-122191.rs:1:12 | LL | type Foo = impl Send; |            ^^^^^^^^^ | = note: see issue #63063 <https://github.com/rust-lang/rust/issues/63063> for more information = help: add `#![feature(type_alias_impl_trait)]` to the crate attributes to enable = note: this compiler was built on YYYY-MM-DD; consider upgrading it if it is out of date error[E0425]: cannot find function `value` in this scope --> $DIR/ice-unhandled-type-122191.rs:6:20 | LL | const VALUE: Foo = value(); |                    ^^^^^ not found in this scope error[E0308]: mismatched types --> $DIR/ice-unhandled-type-122191.rs:11:9 | LL | type Foo = impl Send; |            --------- the expected opaque type ... LL |     match VALUE { |           ----- this expression has type `Foo` LL |         0 | 0 => {} |         ^ expected opaque type, found integer | = note: expected opaque type `Foo` found type `{integer}` note: this item must have the opaque type in its signature in order to be able to register hidden types --> $DIR/ice-unhandled-type-122191.rs:9:4 | LL | fn test() { |    ^^^^ error[E0308]: mismatched types --> $DIR/ice-unhandled-type-122191.rs:11:13 | LL | type Foo = impl Send; |            --------- the expected opaque type ... LL |     match VALUE { |           ----- this expression has type `Foo` LL |         0 | 0 => {} |             ^ expected opaque type, found integer | = note: expected opaque type `Foo` found type `{integer}` note: this item must have the opaque type in its signature in order to be able to register hidden types --> $DIR/ice-unhandled-type-122191.rs:9:4 | LL | fn test() { |    ^^^^ error: aborting due to 4 previous errors Some errors have detailed explanations: E0308, E0425, E0658. For more information about an error, try `rustc --explain E0308`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: unhandled type: {type error}', 'error: internal compiler error: unhandled type: {type error}' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirdropselaboratedandconst_checked] elaborating drops for [analysis] running analysis passes on this crate --
cc ^^
Change:
} let found_trait_ty = found_trait_ref.self_ty(); <del> let found_did = found_trait_ty.ty_to_def_id(); </del> <ins> let found_did = match found_trait_ty.sty { ty::TyClosure(did, _) | ty::TyForeign(did) | ty::TyFnDef(did, _) => Some(did), ty::TyAdt(def, _) => Some(def.did), _ => None, }; </ins> let found_span = found_did.and_then(|did| { self.tcx.hir.span_if_local(did) }).map(|sp| self.tcx.sess.codemap().def_span(sp)); // the sp could be an fn def

Discussion:
I don't know if this is really problem, but e.g. the reimplements this function (and yields a bunch of other s, too. This needs some looking at Mostly leaving this here so I don't forget
is probably a hack for cache keying, and should ideally be removed?
Change:
this.with_current_self_type(self_type, |this| { for method in methods.iter() { <ins> // If this is a trait impl, ensure the method exists in trait this.check_trait_method(&**method); </ins> // We also need a new scope for the method-specific type parameters. this.resolve_method(MethodRibKind(id, Provided(method.id)), &**method);

Discussion:
This code is wrong because ToStr does not define . But what's odd is that the compiler error does not happen in the block but in the : Error message: The expected error message would point to the block that needs to be split into two (one with ToStr and one without a trait).
Reproduced as of
Repro'd with -- but not critical for 0.6, de-milestoning
Appears to be fixed, as per this updated test case: fails with . Closing.
We've regressed: there's a test case (), but it's been xfailed since it was . With I see:
Aaaand, we've un-regressed! Removing all tags except for neesdtest.
Whoops, had the wrong code example, regression still here.
Change:
return ControlFlow::Continue(()); } <ins> // FIXME: Don't consider alias bounds on types that have escaping bound // vars. See #117455. if ty.has_escaping_bound_vars() { return ty.super_visit_with(self); } </ins> match ty.kind() { // We can prove that an alias is live two ways: // 1. All the components are live.

Discussion:
Check out ICU4X (tested on commit ), and build : However this started happening in our nightly CI since (one nightly before this one). The PR must have landed in the recent past. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Working on bisection, so far I have this
regressed commit: <detailsbash cargo bisect-rustc --start 2023-10-28 --end 2023-10-30 </details
Regression is , cc
Change:
) -> Cargo { let mut cargo = Command::new(&self.initial_cargo); let out_dir = self.stage_out(compiler, mode); <ins> // Run cargo from the source root so it can find .cargo/config. // This matters when using vendoring and the working directory is outside the repository. cargo.current_dir(&self.src); </ins> // Codegen backends are not yet tracked by -Zbinary-dep-depinfo, // so we need to explicitly clear out if they've been updated.

Discussion:
When downloading a tarball ( from ) and building it with file with , the build fails early with: I have this behaviour in beta since 2022-08-09, and with nightly since 2022-06-25. My file is: rustc and cargo binaries are 1.62.1-stable. The build is done on OpenBSD (but as it is failing at first cargo invocation, I think it is OS agnostic).
Which directory are you invoking from? Is it the source directory or somewhere else? I think the necessary for vendoring to work may be missed if you invoke it from another directory than the source directory. cc
is invoked from outside the source directory. I will check that
ok, I confirm that invoking from inside the source directory solves the problem. now I need to use and to keep my original behavior to build outside the source directory, but it isn't a big deal. it might be something to mention in changelog file. I think it is common in downstream dsitribution to use a different build and source directories. thanks for the help
I think we should support building outside the source directory again.
fixed a bunch of these issues - can you try with a tarball from the latest nightly and see if it's fixed there?
That PR only changes the rust code of rustbuild, not the python code. This issue is while compiling rustbuild. The problem is that is not in the current working directory when compiling rustbuild and as such ignored.
I confirm that the latest nightly doesn't build outside the directory. also, please note that currently the problem is in both beta and nightly channels.
Ah, I see. That seems possible to fix, we can run the command from the source root. The working directory of the build itself shouldn't affect any of the runtime configuration.
Change:
}); buf.push_str(&part.snippet); let cur_hi = sm.lookup_char_pos(part.span.hi()); <del> if prev_hi.line == cur_lo.line && cur_hi.line == cur_lo.line { </del> <ins> if cur_hi.line == cur_lo.line { </ins> // Account for the difference between the width of the current code and the // snippet being suggested, so that the *later* suggestions are correctly // aligned on the screen.

Discussion:
The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: also on stable: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Change:
const A: u8; //~ ERROR free constant item without body const B; //~ ERROR free constant item without body <ins> //~^ ERROR missing type for `const` item </ins>

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high