jiebi/CodeConvo huggingface dataset:
Change:
} } } <ins> let exp_found = match exp_found { Mismatch::Variable(exp_found) => Some(exp_found), Mismatch::Fixed(_) => None, }; </ins> if let Some(exp_found) = exp_found { self.suggest_as_ref_where_appropriate(span, &exp_found, diag); }

Discussion:
Causes the following error: This is somewhat confusing, especially since is not a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This looks similar to what I reported in
Here we don't account for anything other than type mismatches which means that later we use the generic prefix We need to account for in the first snippet and ferry the prefix strings from there to the later (instead of what we do now).
I'd like to work on this claim
do not hesitate to reach out if you need help!
Do we need to get the correct prefix strings from the contents of or are they just ?
I believe they can be just "trait".
Change:
/// the operating system. Platform sources: /// /// - Unix-like systems (Linux, Android, Mac OSX): read directly from <del> ///   `/dev/urandom`. </del> <ins> ///   `/dev/urandom`, or from `getrandom(2)` system call if available. </ins> /// - Windows: calls `CryptGenRandom`, using the default cryptographic ///   service provider with the `PROV_RSA_FULL` type. /// - iOS: calls SecRandomCopyBytes as /dev/(u)random is sandboxed

Discussion:
This can just be done by attempting the system call and falling back if it fails at runtime.
IIRC, getrandom() is not about speed (I-slow label), but about security from file description exhaustion attacks. It uses the urandom pool. See patch:
I'm aware that it's the same pool. The I-slow label is sensible for an improvement that would reduce the number of system calls and necessary file descriptors.
thanks, now I got it. I'll try to fix it tomorrow if it'll still be open/untouched.
Relevant Go patch:
Change:
StatementKind::FakeRead(_, place) => check_place(tcx, place, span, def_id, body), // just an assignment <del> StatementKind::SetDiscriminant { .. } => Ok(()), </del> <ins> StatementKind::SetDiscriminant { place, .. } => check_place(tcx, place, span, def_id, body), </ins> | StatementKind::InlineAsm { .. } => { Err((span, "cannot use inline assembly in const fn".into()))

Discussion:
Leaving this issue as a reminder for It should be as simple as adding a checkplace call to the <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This bug appears in as well: Might as well stop letting inline ASM through to MIRI while you're at it.
I'm taking this one :P
assign
Change:
Ok(()) } <ins> pub fn check_tys_might_be_eq<'tcx>( tcx: TyCtxt<'tcx>, canonical: Canonical<'tcx, (ParamEnv<'tcx>, Ty<'tcx>, Ty<'tcx>)>, ) -> Result<(), NoSolution> { let (infcx, (param_env, ty_a, ty_b), _) = tcx.infer_ctxt().build_with_canonical(DUMMY_SP, &canonical); let ocx = ObligationCtxt::new(&infcx); let result = ocx.eq(&ObligationCause::dummy(), param_env, ty_a, ty_b); // use `select_where_possible` instead of `select_all_or_error` so that // we don't get errors from obligations being ambiguous. let errors = ocx.select_where_possible(); if errors.len() > 0 || result.is_err() { Err(NoSolution) } else { Ok(()) } } </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</detailsThis occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
let recovered = self.recover_after_dot(); let token = recovered.as_ref().unwrap_or(&self.token); match token::Lit::from_token(token) { <del> Some(token_lit) => { match MetaItemLit::from_token_lit(token_lit, token.span) { </del> <ins> Some(lit) => { match MetaItemLit::from_token_lit(lit, token.span) { </ins> Ok(lit) => { self.bump(); Some(lit) } Err(err) => { <del> let span = token.span; let token::Literal(lit) = token.kind else { unreachable!(); }; </del> <ins> let span = token.uninterpolated_span(); </ins> self.bump(); report_lit_error(&self.sess, err, lit, span); // Pack possible quotes and prefixes from the original literal into

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-2022-11-18
label regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
<ins> trait SuperTrait { type A; type B; } trait Trait: SuperTrait<A = <Self as SuperTrait>::B> {} fn transmute<A, B>(x: A) -> B { foo::<A, B, dyn Trait<A = A, B = B>>(x) //~^ ERROR type mismatch resolving `<dyn Trait<A = A, B = B> as SuperTrait>::A == B` } fn foo<A, B, T: ?Sized>(x: T::A) -> B where T: Trait<B = B>, { x } static X: u8 = 0; fn main() { let x = transmute::<&u8, &[u8; 1_000_000]>(&X); println!("{:?}", x[100_000]); } </ins>

Discussion:
Found in () Errors: modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem and please add “I-unsound ”
cc - this looks like it might be related to some of your work.
Assigning as discussed as part of the and removing .
Without the keyword, the function type-checks since Rust 1.0.0. And a function like e.g. leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).
To me, this is the same root cause as : we unconditionally say that any type is well-formed and implements without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, already introduced some checks). Except that I was wrong in my saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, example shows that implied bounds for super traits play a role as well.
Change:
<ins> // run-pass // This file checks that `PhantomData` is considered structurally matchable. use std::marker::PhantomData; fn main() { let mut count = 0; // A type which is not structurally matchable: struct NotSM; // And one that is: #[derive(PartialEq, Eq)] struct SM; // Check that SM is #[structural_match]: const CSM: SM = SM; match SM { CSM => count += 1, }; // Check that PhantomData<T> is #[structural_match] even if T is not. const CPD1: PhantomData<NotSM> = PhantomData; match PhantomData { CPD1 => count += 1, }; // Check that PhantomData<T> is #[structural_match] when T is. const CPD2: PhantomData<SM> = PhantomData; match PhantomData { CPD2 => count += 1, }; // Check that a type which has a PhantomData is `#[structural_match]`. #[derive(PartialEq, Eq, Default)] struct Foo { alpha: PhantomData<NotSM>, beta: PhantomData<SM>, } const CFOO: Foo = Foo { alpha: PhantomData, beta: PhantomData, }; match Foo::default() { CFOO => count += 1, }; // Final count must be 4 now if all assert_eq!(count, 4); } </ins>

Discussion:
Given: results in: Is this intentional due to some soundness issue with having it otherwise? (I cannot think of any...) We could fix this by attaching to manually. While having be structurally matchable is quite boring and useless on its lonesome it prevents other types that contain it from being structurally matchable. (not likely to occur very often, but when it occur it seems like it would be annoying...) r? cc
Change:
<ins> // check-pass #[derive(Copy, Clone)] pub struct ChildStdin { inner: AnonPipe, } #[derive(Copy, Clone)] enum AnonPipe {} const FOO: () = { union Foo { a: ChildStdin, b: (), } let x = unsafe { Foo { b: () }.a }; let x = &x.inner; }; fn main() {} </ins>

Discussion:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect.

But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // ignore-test use std::io; </del> struct Point { x: f64, y: f64, } <del> impl ToStr for Point { //~ ERROR implements a method not defined in the trait </del> <ins> trait NewTrait { fn a(&self) -> String; } impl NewTrait for Point { </ins> fn new(x: f64, y: f64) -> Point { <ins> //~^ ERROR method `new` is not a member of trait `NewTrait` </ins> Point { x: x, y: y } } <del> fn to_str(&self) -> String { </del> <ins> fn a(&self) -> String { </ins> format!("({}, {})", self.x, self.y) } } fn main() { let p = Point::new(0.0, 0.0); <del> println!("{}", p.to_str()); </del> <ins> //~^ ERROR unresolved name `Point::new` //~^^ ERROR failed to resolve. Use of undeclared module `Point` println!("{}", p.a()); </ins> }

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:
prints: prints, cg: cg, color: color, <del> show_span: None, </del> externs: externs, crate_name: crate_name, alt_std_name: None,

Discussion:
Not a breaking change since it is an unstable option.
Is it already an unstable option?
this issue is saying that should be changed to . It is already an unstable option.
So can accept as arguments. How would those be specified if were changed to a ?
Hopefully exactly the same way, not sure how possible that is. If it is not possible right now, then this probably isn't an easy issue to fix. I can look into it next week.
We've got kinda our own syntax for the flags so where today you pass it could instead be
Change:
// ...ABCDEFGH. self.tail = self.head; <del> self.head = self.tail + len; </del> <ins> self.head = self.wrap_add(self.tail, len); </ins> } } else { // free is smaller than both head and tail,

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. --This is my first bug report, so please correct me s if I miss anything :-) I use VecDeque<u8in a toy application () which is handling external reads in a loop, and does possible partial handling of the input. My pattern is I call reserve(N) before pushback() N times, then makecontiguous(), then doing some popfront(). I noticed the app was behaving badly, and was able to generate a stand-alone test case which shows the bug. The code is pretty boring and repetitive, so I put it at to avoid spamming here. Just issue "cargo run" after cloning out that code, and look for the word "BUG" within the terminal output: According to the docs, popfront() on an empty VecDeque should return None. Instead, this happens: If I set the boolean "doreserve" to be false, thus getting rid of all the reserve() calls, I get the expected behavior: The same happens if I set "domake_contiguous" to false as well - so calling both functions is a prerequisite to trigger the bug. The same thing happens in debug and release builds. <!-- 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 below is the version I found it in, but thanks a lot to Steve Klabnik for also testing it on nightly and getting the same buggy behavior. :
I created a minimal sample:
Hmm, if it double-frees then why does Miri not catch it?
Assigning and removing as in the prioritization working group.
Some time ago I've read somewhere that Rust stdlib VecDeque is cursed. I didn't believe them. I'm changing opinion... -.-
This specific case doesn't double free (i32::drop is a noop), using a might have been a better example...
Still, this is memory-unsafe, right?
Yes, It's still a use-after-free regardless
claim
Based on my conversation with lcnr, jonas-schievink, and others , it seems that using with copy types is not UB (it still exhibits a bug though!) because copy types aren't freed. It is UB with non-copy types though (e.g. ).
Change:
42 } <del> // CHECK: .section </del> <ins> // CHECK: .text </ins>

Discussion:
Right now I have to run with applied, but when I do several tests fail, eg: tests/assembly/targets/targets- more are visible in
I think this test should check for instead of . I believe that currently this test is actually matching something like , which is not emitted on Solaris since I assume the intention was to look for , but that's one of the section types for which an explicit is normally omitted.
Okay, just looking for doesn't work, because apparently targets-elf, despite the name, currently also includes the MachO targets.
Change:
// two namespaces, so the target may be listed twice. Make sure we only // visit each node at most once. for &item in cx.tcx.item_children(did).iter() { <del> let def_id = item.res.def_id(); </del> if item.vis == ty::Visibility::Public { <del> if did == def_id || !visited.insert(def_id) { continue; </del> <ins> if let Some(def_id) = item.res.mod_def_id() { if did == def_id || !visited.insert(def_id) { continue; } </ins> } <del> if let Some(i) = try_inline(cx, item.res, item.ident.name, None, visited) { </del> <ins> if let Res::PrimTy(p) = item.res { // Primitive types can't be inlined so generate an import instead. items.push(clean::Item { name: None, attrs: clean::Attributes::default(), source: clean::Span::empty(), def_id: cx.tcx.hir().local_def_id_from_node_id(ast::CRATE_NODE_ID), visibility: clean::Public, stability: None, deprecation: None, inner: clean::ImportItem(clean::Import::Simple( item.ident.to_string(), clean::ImportSource { path: clean::Path { global: false, res: item.res, segments: vec![clean::PathSegment { name: clean::PrimitiveType::from(p).as_str().to_string(), args: clean::GenericArgs::AngleBracketed { args: Vec::new(), bindings: Vec::new(), }, }], }, did: None, }, )), }); } else if let Some(i) = try_inline(cx, item.res, item.ident.name, None, visited) { </ins> items.extend(i) } }

Discussion:
When re-exporting a primitive type, rustdoc ICEs. This was found when creating . Rustdoc also fails to link the re-export to the primitive docs. Reproduction: commands: Backtrace:
I plan on investigating this issue tomorrow, as it is likely a blocker for
-- this is blocking , and I was unable to come up with a simple patch to fix this. Is this a known-hard problem, or should I try to keep digging? contains my initial patch, but it fails tests (e.g., auto impls for primitives, among other problems).
I'll try to take a look shortly. And no, never heard of it before you opened this issue. Don't hesitate to ping me if I forget.
Change:
<ins> // Regression test for #107747: methods from trait alias supertraits were brought into scope // // check-pass #![feature(trait_alias)] use std::fmt; trait Foo: fmt::Debug {} trait Bar = Foo; #[derive(Debug)] struct Qux(bool); impl fmt::Display for Qux { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { self.0.fmt(f) } } fn main() {} </ins>

Discussion:
In-scope trait aliases bring into scope (methods of) the aliased trait and all of its supertraits. I can understand the rationale for bringing (methods of) the aliased trait into scope (namely to , but also bringing into scope (methods of) that trait's supertraits is both inconsistent (compared with bringing the aliased trait itself into scope) and surprising: . (For the avoidance of doubt, only the methods are brought into scope—not the trait itself: thus, in the above example with the alias uncommented, one cannot use an unqualified ). cc label A-resolve A-traits C-bug F-traitalias <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
From cursory inspection, the following (originally from , cc looks suspect:
claim
Change:
<ins> error: attribute should be applied to a function or static --> $DIR/linkage.rs:6:1 | LL | #[linkage = "weak"] | ^^^^^^^^^^^^^^^^^^^ LL | type InvalidTy = (); | -------------------- not a function definition or static error: attribute should be applied to a function or static --> $DIR/linkage.rs:9:1 | LL | #[linkage = "weak"] | ^^^^^^^^^^^^^^^^^^^ LL | mod invalid_module {} | --------------------- not a function definition or static error: attribute should be applied to a function or static --> $DIR/linkage.rs:12:1 | LL | #[linkage = "weak"] | ^^^^^^^^^^^^^^^^^^^ LL | struct F; | --------- not a function definition or static error: attribute should be applied to a function or static --> $DIR/linkage.rs:15:1 | LL |   #[linkage = "weak"] |   ^^^^^^^^^^^^^^^^^^^ LL | / impl F { LL | |     #[linkage = "weak"] LL | |     fn valid(&self) {} LL | | } | |_- not a function definition or static error: attribute should be applied to a function or static --> $DIR/linkage.rs:23:5 | LL |       #[linkage = "weak"] |       ^^^^^^^^^^^^^^^^^^^ LL | /     { LL | |         1 LL | |     }; | |_____- not a function definition or static error: attribute should be applied to a function or static --> $DIR/linkage.rs:39:13 | LL |     let _ = #[linkage = "weak"] |             ^^^^^^^^^^^^^^^^^^^ LL |     (|| 1); |     ------ not a function definition or static error: aborting due to 6 previous errors </ins>

Discussion:
I tried this code: I expected to see this happen: compilation failure because of attribute on an item where it makes no sense Instead, this happened: compiled successfully : cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
fn main() { let x: u8 = 256; //~^ error: literal out of range for `u8` <ins> for _ in 0..256u8 {} //~^ error: range endpoint is out of range for `u8` </ins> }

Discussion:
since
It is hitting the here: So I'm not quite sure why the error isn't being emitted yet.
It appears to be hitting this line of code which is cancelling the diagnostic:
this appears to be a stable-to-beta regression ()
triage: P-high. Assigning to self.
We need to change to not consider desugarings coming from loops as external. If that has regressions in our test suite, then we can add a new desugaring kind to differentiate between different parts of the for loop desugaring and target it further, but I do not expect that to be needed.
I've opened with a fix, based on comment.
Change:
<ins> // Test that we handle the case when a local variable is borrowed for `'static` // due to an outlives constraint involving a region in an incompatible universe pub trait Outlives<'this> {} impl<'this, T> Outlives<'this> for T where T: 'this {} trait Reference { type AssociatedType; } impl<'a, T: 'a> Reference for &'a T { type AssociatedType = &'a (); } fn assert_static_via_hrtb<G>(_: G) where for<'a> G: Outlives<'a> {} fn assert_static_via_hrtb_with_assoc_type<T>(_: &'_ T) where for<'a> &'a T: Reference<AssociatedType = &'a ()>, {} fn main() { let local = 0; assert_static_via_hrtb(&local); //~ ERROR `local` does not live long enough assert_static_via_hrtb_with_assoc_type(&&local); //~ ERROR `local` does not live long enough } </ins>

Discussion:
While I was trying to make a general impl, I came across this ICE. Note that inlining makes this ICE go away.
thanks for putting the stack-trace, I forgot about that This also works
Small repro: I'll try to have a PR up for this next week.
Another repro from
Change:
pub(crate) struct ImplStripper<'a> { pub(crate) retained: &'a ItemIdSet, pub(crate) cache: &'a Cache, <ins> pub(crate) is_json_output: bool, pub(crate) document_private: bool, </ins> } impl<'a> DocFolder for ImplStripper<'a> {

Discussion:
cc label +A-docs +A-rustdoc-ui +C-enhancement +T-rustdoc This is technically a regression, but it doesn't feel appropriate to label it as such.
Here is an example of a block that should be hidden when is not passed: