jiebi/CodeConvo huggingface dataset:
Change:
fn set_dbg_loc(&mut self, dbg_loc: Self::DILocation) { self.location = Some(dbg_loc); } <ins> fn clear_dbg_loc(&mut self) { self.location = None; } </ins> } /// Generate the `debug_context` in an MIR Body.

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Setting a breakpoint on in rust-gdb results in gdb stopping before 's stack slot is initialized, and gdb dereferences it to print wrong values based on : Note the incorrect different values of as I step past initialization. The breakpoint should trigger just after that , not before it. The other functions in that program indeed do it correctly. Oddly, it seems like the operator is necessary for my repro, though maybe that has something to do with the hidden var. (Note that vs is necessary to actually avoid accidental correct values of due to stack reuse, so the other functions can't print wrong as written. But I'm just looking at where the breakpoint hits in disassembly.) Here's relevant llvm-dwarfdump from this binary, with a pointing at at the () rather than the : This looks pretty related to and Like , the repro hits on 1.71 but not 1.70. I'm filing separately because, unlike it, disabling SingleUseConsts doesn't seem to fix the breakpoint. I'm not 100% sure I'm disabling it right - you can see my command above. <!-- 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<summaryBacktrace</summary<p</p</details
I'm not familiar with github's notification rules, so pinging
Thanks for the tag, I wouldn't have seen this otherwise. From , we can see that the "prologue end" marker that tells the debugger where to stop is indeed placed on the mov I suspect this is due to the desugaring of the ? operator since the column number provided is 29.
label +A-debuginfo
Sure enough, ConstDebugInfo is in there.
I guess you probably saw, but does suggest that the bisect is somehow misleading.
Yes, getting the values wrong at function entry is especially bad because it messes up conditional breakpoints.
Disabling the pass doesn't do anything here because the is created by when it removes . Otherwise this is identical to .

The easiest way to fix this would be for DILocation to carry a "this is not a statement" flag that overrides LLVM's usual line based inference of statement markers. I'll run it by the LLVM folks and see what they say.
Actually, in this particular case, because the const is a ZST I think we can do better today without LLVM changes.
Thanks for reporting this. The linked PR will fix this particular degenerate case.
Change:
} pub fn write(&self, buf: &[u8]) -> io::Result<usize> { <ins> let len = cmp::min(buf.len(), <wrlen_t>::max_value() as usize) as wrlen_t; </ins> let ret = try!(cvt(unsafe { c::send(*self.inner.as_inner(), buf.as_ptr() as *const c_void, <del> buf.len() as wrlen_t, </del> <ins> len, </ins> 0) })); Ok(ret as usize)

Discussion:
In a few places in there are casts from to or for Windows APIs which causes breakage on 64-bit. Some examples I have found so far: () () (rust-lang-nursery/rand, ) There may be more.
Well I didn't find any more so I'll close this.
Change:
--> $DIR/issue-105330.rs:12:11 | LL |     foo::<Demo>()(); <del> |           ^^^^ types differ </del> <ins> |           ^^^^ expected `32`, found `<Demo as TraitWAssocConst>::A` </ins> | <ins> = note: expected constant `32` found constant `<Demo as TraitWAssocConst>::A` </ins> note: required by a bound in `foo` --> $DIR/issue-105330.rs:11:28 |

Discussion:
thread panicked at 'called on a value', <details<summaryBacktrace</summary</detailsRegression in nightly-2022-12-04, in rollup , likely from (
Change:
<ins> // Test that the 'static bound from the Copy impl is respected. Regression test for #29149. #[derive(Clone)] struct Foo<'a>(&'a u32); impl Copy for Foo<'static> {} fn main() { let s = 2; let a = (Foo(&s),); //~ ERROR `s` does not live long enough [E0597] drop(a.0); drop(a.0); } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried : I expected to see this: Instead, happens undefined behavior. Program successfully compiles in the Rust but fails to compile in (thats what I want).
Regressed in , likely cc
Visited in the compiler team triage meeting. It would be good to look into closing this ASAP. do you think you'll have time to investigate? If not, I'd want to find someone else.
We've assigned this speculatively to -- if you think you won't be able to investigate promptly, though, feel free to unassign and ping t-compiler for reassignment,
I expected the behavior to match that of this example (which still errors): I wonder if the gets erased somehow. Maybe an "user type annotation" is required on the from a , to give it a lifetime'd type?
Change:
return false; } <ins> if let DefKind::Static(_) = tcx.def_kind(def_id) { // We cannot monomorphize statics from upstream crates. return false; } </ins> if !tcx.is_mir_available(def_id) { bug!("no MIR available for {:?}", def_id); }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: generate Instead, this happened: <!-- 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<summaryBacktrace</summary<p</p</details
This is strange, Miri uses but statics seem to work fine for us?
Does the test case I gave work for Miri? I notice that produces much larger rmeta files than would, which are in turn larger than 's rmetas (as expected). It would be nice to have an option to make lone produce the same output as , and I was hoping that it would just be a matter of stabilizing , but they don't seem to be equivalent. Ideally they'd produce the same output, but I'd be happy with functionally interchangable - which is what this issue is about. Overall, I'm finding it hard to work out what controls what goes into a file. I audited all the places where either or both of and/or are checked, and unifying them does not produce an output where and together produce the same as . I guess I haven't confirmed that MIR is the only difference between the two cases.
Yes: when I set up a 2-crate workspace matching your 2 files and then do , it works as expected.
PR adds so that generates equivalent rmetas to .
Change:
struct S<T>(T); m!{ S<u8> } //~ ERROR unexpected generic arguments in path <del> //~| ERROR expected module, found struct `S` </del> <ins> //~| ERROR failed to resolve: `S` is a struct, not a module [E0433] </ins> mod m { m!{ m<> } //~ ERROR unexpected generic arguments in path

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
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
} } <ins> /// Checks that generic parameters are in the correct order, /// which is lifetimes, then types and then consts. (`<'a, T, const N: usize>`) </ins> fn validate_generic_param_order<'a>( sess: &Session, handler: &rustc_errors::Handler,

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details
It doesn't require feature flag.
I am currently working on this
my first idea was to fix this ICE locally by offsetting in line 1318 for each wrongly placed const param. This only moves the error further back. I currently think that it would be best to actually fix the param order if order fails. Is this a good approach? And how should this be done, as is used in , which only receives an immutable reference to .
I think the right fix for this would be to make sure we can handle generic parameters in any order — there's no technical reason the parameters should be in a fixed order; it's just historical. This would involve doing what you started with, and fixing each problem in turn. However, I don't know how many things still rely on this order, so it could be an involved task. For a shorter-term fix, we could just make sure that generics are sorted if they're in the wrong order. We could probably do this in and sort the before creating the . This might be more pragmatic, though we should leave a to address later if we do this. Thanks for looking into this
Change:
//! your code can detect errors in case the environment variable did //! not in fact contain valid Unicode data. //! <del> //! * [`OsStr`] represents a borrowed reference to a string in a //! format that can be passed to the operating system. It can be //! converted into a UTF-8 Rust string slice in a similar way to </del> <ins> //! * [`OsStr`] losslessly represents a borrowed reference to a platform string. //! However, this representation is not necessarily in a form native to the platform. //! It can be converted into a UTF-8 Rust string slice in a similar way to </ins> //! [`OsString`]. //! //! # Conversions

Discussion:
The [documentation for ] says— The [documentation for § "Representations of non-Rust strings"] says— These statements led me to understand that— on Microsoft Windows, an would represent its text as "arbitrary sequences of non-zero 16-bit values", and not as UTF-8, and thus on Windows, an would reference such a non-UTF-8 sequence, and thus [] — which returns an al that (by my imperfect understanding of Rust reference rules) would have to reference the same thing as the — almost always would return on Windows (except for, e.g., empty strings), because a Windows string could not validly be read as a Rust . However, tells me that— "OsStr::tostr on Windows will succeed most of the time", stores its text in WTF-8 on Windows, and it's more accurate [than what the documentation says] to say that OsStr represents an owned string in a representation capable of handling any string received from the operating system Was my misinterpretation of the documentation unreasonable? If not, could the documentation be clarified on this point? [documentation for ]: [documentation for § "Representations of non-Rust strings"]: []:
Agreed on pretty much all points here. In addition, it would be really useful to have some guidance on the best way to convert an OsStr(ing) to an LPWSTR so that it can be actually used with windows apis. Either here or in winapi-rs, not sure where the best fit would be.
I would like to be able to losslessly transcode between a [] and an []. A [] may contain zeros, however. []: []:
may also contain zeros.
Change:
{ let tcx = param_env.tcx; <del> match self_type.sty { </del> <ins> let did = match self_type.sty { </ins> ty::ty_struct(struct_did, substs) => { let fields = ty::struct_fields(tcx, struct_did, substs); for field in fields.iter() {

Discussion:
Basically, it's now possible to write: and have everything work. This unfortunately means that doing something like with a will zero b, but not move it. /cc
I noticed this possibility too and was debating if this is a problem. It's not clear to me. Probably best to disallow it for now.
at the very least, it's causing incorrect behaviour at runtime, since it's zeroing out types like a move, but not forbidding the use of them like a copy.
Looks unsafe to me: Program received signal SIGSEGV, Segmentation fault. 0x0000555555598e5c in ()
I agree that combining it with zeroing is unsafe. If zeroing did not occur, or we did not zero for types that were copy, there wouldn't necessarily be a problem.
Anyhow, it's easiest to forbid it for now. We can always make it legal later if someone comes up with a persuasive use case. Idempotent destructors seem like a bit of an odd thing.
Change:
} } <del> PatKind::Struct(_, ref field_pats, _) => { </del> <ins> PatKind::Struct(ref qpath, ref field_pats, _) => { </ins> // {f1: p1, ..., fN: pN} <ins> let def = self.tables.qpath_def(qpath, pat.id); let cmt = match def { Def::Err => { debug!("access to unresolvable pattern {:?}", pat); return Err(()) }, Def::Variant(variant_did) | Def::VariantCtor(variant_did, ..) => { self.cat_downcast_if_needed(pat, cmt, variant_did) }, _ => cmt }; </ins> for fp in field_pats { let field_ty = self.pat_ty(&fp.node.pat)?; // see (*2) let cmt_field = self.cat_field(pat, cmt.clone(), fp.node.name, field_ty);

Discussion:
I got panic with this code (): Backtrace: My rust version:
This code seems to be minimal example type Value = String; fn main() { let f = ""; Some("".into()).map(f); }
Change:
ast::TyKind::Ptr(ast::MutTy { ty: ref subty, .. }) | ast::TyKind::Rptr(_, ast::MutTy { ty: ref subty, .. }) | ast::TyKind::Paren(ref subty) => involves_impl_trait(subty), <del> ast::TyKind::Tup(ref tys) => tys.iter().any(|subty| involves_impl_trait(subty)), </del> <ins> ast::TyKind::Tup(ref tys) => any_involves_impl_trait(tys.iter()), ast::TyKind::Path(_, ref path) => path.segments.iter().any(|seg| { match seg.parameters.as_ref().map(|p| &**p) { None => false, Some(&ast::PathParameters::AngleBracketed(ref data)) => any_involves_impl_trait(data.types.iter()) || any_involves_impl_trait(data.bindings.iter().map(|b| &b.ty)), Some(&ast::PathParameters::Parenthesized(ref data)) => any_involves_impl_trait(data.inputs.iter()) || any_involves_impl_trait(data.output.iter()), } }), </ins> _ => false, } } <ins> fn any_involves_impl_trait<'a, I: Iterator<Item = &'a P<ast::Ty>>>(mut it: I) -> bool { it.any(|subty| involves_impl_trait(subty)) } </ins> involves_impl_trait(ty) } else { false

Discussion:
` rustc -V rustc 1.22.0-nightly ( 2017-09-18)
Similar cause as . Repro case for :
Change:
<ins> error[E0117]: only traits defined in the current crate can be implemented for arbitrary types --> $DIR/issue-99572-impl-trait-on-pointer.rs:7:1 | LL | impl fmt::Display for *mut LocalType { | ^^^^^^^^^^^^^^^^^^^^^^-------------- | |                     | | |                     `*mut LocalType` is not defined in the current crate because raw pointers are always foreign | impl doesn't use only types from inside the current crate | = note: define and implement a trait or new type instead help: consider introducing a new wrapper type | LL + struct WrapperType(*mut LocalType); LL + LL ~ impl fmt::Display for WrapperType { | error[E0117]: only traits defined in the current crate can be implemented for arbitrary types --> $DIR/issue-99572-impl-trait-on-pointer.rs:18:1 | LL | impl<T> marker::Copy for *mut T { | ^^^^^^^^^^^^^^^^^^^^^^^^^------ | |                        | | |                        `*mut T` is not defined in the current crate because raw pointers are always foreign | impl doesn't use only types from inside the current crate | = note: define and implement a trait or new type instead error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0117`. </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This could use some work, too, I think. Maybe "impl mentions type from outside the current crate" might be a sufficient replacement, though we should probably make sure that wording is compatible with current coherence rules. Though, in this case, for a non- self type like , we could then replace that^ message with something even more specific. I'm a bit skeptical of mentioning "try implementing on " when we have , since implementing something for and can have very different meanings depending on the signatures inside the trait.
Let's improve this case! claim
This was actually closer to my original error I got, it uses a type alias to create some extra confusion:
Amazing example :) thanks, I'm on it
This is a reproducible example without serde!
Change:
<ins> warning: `auto` traits are unstable --> $DIR/pre-cfg.rs:4:1 | LL | auto trait Foo {} | ^^^^ | = note: see issue #13231 <https://github.com/rust-lang/rust/issues/13231> for more information = help: add `#![feature(auto_traits)]` to the crate attributes to enable = warning: unstable syntax can change at any point in the future, causing a hard error! = note: for more information, see issue #65860 <https://github.com/rust-lang/rust/issues/65860> warning: 1 warning emitted </ins>

Discussion:
The following code builds on stable without even a warning: That is surprising since there was some effort recently to start ensuring that unstable syntax does not "leak" into stable Rust, so I expected at least a future-compatibility warning. (See e.g. ) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
from the code I'd expect a warning:
ah no, auto traits don't use that gating: When parsing an auto trait in the parser, we need to gate it's span and then in the feature gating pass gate it too. This will look similar to, for example, traitalias.
was just for syntax which was previously attempted to reverse stabilization and had the gating code there but disabled. Now that the plumbing exists, using that as a template to add this syntax to the warning should be fairly straightforward. It might make sense to go ahead and crater immediately making this a hard feature gate, though.
I can already tell you of one large regression, the . We should do the feature gating normally as a warning and worry about making it an error later. Once it's a warning, people adding uses get warnings and we should be fine.
A bit unrelated, but I think it would be useful to have docs somewhere that show how to resolve this issue if you have the feature behind a cfg, the easiest solution being a macro_rules macro. But that doesn't have to be fixed here.
Change:
enum PathKind { Trait, <del> StructEnumUnion, </del> <ins> /// Structs, Enums, Unions and Typedefs. /// /// This doesn't include trait's because traits are not types. Type, </ins> } impl<'a> Validator<'a> {

Discussion:
Produces json (abridged) which is correct, but fails for this modify labels: +A-rustdoc-json +A-testsuite +T-rustdoc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This was found while working on , as it causes jsondoclint to fail for core (in addition to it catching the linked issue)
Change:
fn get_parent_trait_ref( &self, code: &ObligationCauseCode<'tcx>, <del> ) -> Option<(String, Option<Span>)>; </del> <ins> ) -> Option<(Ty<'tcx>, Option<Span>)>; </ins> /// If the `Self` type of the unsatisfied trait `trait_ref` implements a trait /// with the same path as `trait_ref`, a help message about

Discussion:
Type errors (and others) use and similar to write types that are too long to disk, so the cli output is easier to read. Trait bound errors do not do that. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I created . What was not visible in the tweet but that you will see when you build the repo, is that the types in the error notes are even longer. That's a shame because hidden in that noise the compiler gives the solution to the error (pin).
You can just create a gist with the error generating logic line highlighted. Much more helpful?
I can give more context too. I was implementing a K8s operator using . I start by creating a and then running it with . This returns a . That stream yields an item every time the reconcile loops reconciles an item or returns an error. For testing, I iterate over the stream to check that it reconciles items the way I expect. . The solution is to pin the stream returned by .
how would i go about solving this? claim
you can look at how we do it here You have to do the same thing but at the very least in the places we print out types to string here:
You also need to ensure that the type-shortening is conditional, based on whether the user wants verbose output or not (similar to the existing logic for type errors).
already checks whether is enabled or not before shortening.
into: by the looks: is the same as and i can call the method on it, but in the formatting (that returns a tuple) im not sure how to call those functions (as t is a string, and calling the function returns a string and pathbuf. in the closure should i just ignore ? or is that a bad approach?
Change:
<ins> error[E0119]: conflicting implementations of trait `TraitWithAssoc` for type `((&str,),)` --> $DIR/unsound-overlap.rs:20:1 | LL | impl<T: A> TraitWithAssoc for T { | ------------------------------- first implementation here ... LL | impl TraitWithAssoc for ((&str,),) { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `((&str,),)` error: aborting due to previous error For more information about this error, try `rustc --explain E0119`. </ins>

Discussion:
() same code with an additional line of whitespace/comments where indicated: however, the playground seems to behave different from my local nightly here Tested on label T-compiler requires-nightly F-markertraitattr A-traits A-typesystem and someone please add “I-unsound ”
ACTUALLY… the error after adding the whitespace disappears again with . Which would explain why it isn’t reproducable in the playground. Might be related to label A-incr-comp.
This test doesn't seem to compile with the most recent nightly but I don't think the underlying issue has been fixed. Not sure how to retrigger this issue