jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-pass // compile-flags: --edition 2021 -Copt-level=3 -Cdebuginfo=2 -Zmir-opt-level=3 fn main() { TranslatorI.visit_pre(); } impl TranslatorI { fn visit_pre(self) { Some(()) .map(|_| self.flags()) .unwrap_or_else(|| self.flags()); } } struct TranslatorI; impl TranslatorI { fn flags(&self) {} } </ins>

Discussion:
When generating a variable debuginfo, rustc emits an expression describing the address of a source variable. Since , rustc also evaluates this expression. The expression can contain indirections, and it is not always valid to evaluate it. Consider a source variable that is described indirectly in terms of a base local. The source variable will be introduced at the beginning of a function, but at this point the base local might be uninitialized. For example: Note that has and metadata but loaded value is uninitialized. (This leads to end-to-end miscompilation with -Cdebuginfo=2). cc
A variant that demonstrates complete end-to-end miscompilation can be found in
Even without the metadata, this load could violate constraints. So just removing the metadata is not a proper fix. EDIT: Or does this always load from an that doesn't have any other pointers to it yet? Then it should be fine in terms of aliasing.
Change:
let seq_span = lo.to(self.prev_token.span); let mut err = self.struct_span_err(comma_span, "unexpected `,` in pattern"); if let Ok(seq_snippet) = self.span_to_snippet(seq_span) { <ins> const MSG: &str = "try adding parentheses to match on a tuple..."; let or_suggestion = gate_or == GateOr::No || !self.sess.gated_spans.is_ungated(sym::or_patterns); </ins> err.span_suggestion( seq_span, <del> "try adding parentheses to match on a tuple...", </del> <ins> if or_suggestion { MSG } else { MSG.trim_end_matches('.') }, </ins> format!("({})", seq_snippet), Applicability::MachineApplicable, <del> ) .span_suggestion( seq_span, "...or a vertical bar to match on multiple alternatives", seq_snippet.replace(",", " |"), Applicability::MachineApplicable, </del> ); <ins> if or_suggestion { err.span_suggestion( seq_span, "...or a vertical bar to match on multiple alternatives", seq_snippet.replace(",", " |"), Applicability::MachineApplicable, ); } </ins> } Err(err) }

Discussion:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma
Change:
<ins> #![crate_type = "lib"] #![feature(specialization)] #![feature(unsize, coerce_unsized)] #![allow(incomplete_features)] use std::ops::CoerceUnsized; pub struct SmartassPtr<A: Smartass+?Sized>(A::Data); pub trait Smartass { type Data; type Data2: CoerceUnsized<*const [u8]>; } pub trait MaybeObjectSafe {} impl MaybeObjectSafe for () {} impl<T> Smartass for T { type Data = <Self as Smartass>::Data2; default type Data2 = (); //~^ ERROR: the trait bound `(): std::ops::CoerceUnsized<*const [u8]>` is not satisfied } impl Smartass for () { type Data2 = *const [u8; 1]; } impl Smartass for dyn MaybeObjectSafe { type Data = *const [u8]; type Data2 = *const [u8; 0]; } impl<U: Smartass+?Sized, T: Smartass+?Sized> CoerceUnsized<SmartassPtr<T>> for SmartassPtr<U> where <U as Smartass>::Data: std::ops::CoerceUnsized<<T as Smartass>::Data> {} pub fn conv(s: SmartassPtr<()>) -> SmartassPtr<dyn MaybeObjectSafe> { s } </ins>

Discussion:
This snippet is found in . Reduced: :
Nitpick: There's no need to put the two into different functions, you can put them both in .
Like , when using an anonymous binding (), the above code :
No longer ICEs since

With specialization, it is possible to define a default associated type that does not fulfill its trait bounds. Here is a minimal example, that surely should not compile, but does with rustc 1.35.0-nightly: Unsurprisingly, adding the main function causes an ICE. Error message and backtrace (compiled at the playground):
Triage: the latest nightly rejects the code, marking as E-needs-test.

This code generates an ICE with this message. Replacing by makes the code to compile and run fine, which is strange because ! does not implements . By removing the specialization the compiler refuses to compile the code with the error:
The ICE has been fixed in the latest nightly, marked as E-needstest
Thanks Indeed, the example compiles fine in nightly ( 2019-11-12), however, replacing the main function by these two generates the same ICE.
ah, thanks for the update! I confirmed it ()
Triage: the ICE doesn't occur anymore with the latest nightly, marking as E-needs-test.

I was attempting to figure out the feature landscape for , and I found this ICE when playing with it and specialization:
The given code builds fine on current nightly.
This is still an ICE on current nightly when not .
This code compiles without a problem whether I do or using current nightly: . Tested on Windows 10 x64 and Ubuntu x64.
Really? But on the playground, the ICE still appears. Can you check the above link?
Yes, I get an ICE in the playground when I just build.
It does ICE when using instead of .
You need or , not . It seems like a still ICE to me.
Triage: the latest nightly rejects the code without an ICE. Marking as E-needs-test.
Change:
<ins> // Copyright 2012 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. // Test that we don't ICE when translating a generic impl method from // an extern crate that contains a match expression on a local // variable lvalue where one of the match case bodies contains an // expression that autoderefs through an overloaded generic deref // impl. // aux-build:issue-18514.rs extern crate "issue-18514" as ice; use ice::{Tr, St}; fn main() { let st: St<()> = St(vec![]); st.tr(); } </ins>

Discussion:
I hit an internal compiler error in rustc 0.12.0-nightly ( 2014-10-02 01:22:20 +0000). Notes: trying to compile ncollide / nphysics. It wasn't finding crates, possibly because of ncollide recently switching to use cargo's 'feature' feature, so I was randomly prodding the files trying to get it working. The internal error appears to happen when it's trying to abort after a legitimate error. This is on OSX 10.9.5. Could not compile .
Still happening consistently as of rustc 0.12.0-nightly ( 2014-10-04 23:42:07 +0000). Also, it's not caused by task abort as I speculated above; it happens consistently when trying to compile nphysics's even in the absence of other errors.
Do you have a reduced testcase?
I do not really have a reduced testcase, though, somehow, I was able to work around the ICE on this commit: What I did is to remove explicit calls to and explicitely dereference anything that had the type or before I call . For example, if has the type , I changed to . Note thit this fix is done on . The ICE seems to happend only when is used by another library/binary (and not during the compilation of itself).
Change:
use rustc_middle::ty::fold::TypeFoldable; use rustc_middle::ty::visit::TypeVisitable; use rustc_middle::ty::{ <del> self, AdtKind, CanonicalUserType, DefIdTree, EarlyBinder, GenericParamDefKind, ToPolyTraitRef, ToPredicate, Ty, UserType, </del> <ins> self, AdtKind, CanonicalUserType, DefIdTree, EarlyBinder, GenericParamDefKind, ToPredicate, Ty, UserType, </ins> }; use rustc_middle::ty::{GenericArgKind, InternalSubsts, SubstsRef, UserSelfTy, UserSubsts}; use rustc_session::lint;

Discussion:
Repro: Output:
cc
What's causing this is that we currently inspect the obligations in scope for obligations, but in this case the obligation is (which implies a obligation as a supertrait). This is expected but unfortunate, yes. We could probably fix this particular case in a relatively straightforward way by trying to upcast each pending obligation to a obligation.
I imagine that atm this could be worked around by changing: to
Today, this gives a completely different error about not implementing ...
Updated code to not give the unrelated error (by removing bounds everywhere), still gives the type must be known error.
This comes up for me fairly regularly. It would be really nice to fix it. (e.g., it came up recently in )
We discussed this in the types team 'backlog bonanza' meeting today. Our conclusion was that this is a "nice to have" and that directly fixing this issue felt like a types team FCP, because it's a tweak to the inference rules. TL;DR right now we say If there is some trait obligation , then we take the args from it seems reasonable to say If there is some trait obligation that implies (through the "invariants", in terms) , then we take the args from that would fix this example (types team FCP would be required). However, I believe that beyond this specific example, most people who wind up here are trying to do something a bit more sophisticated, such as having an argument that might be a closure but might not, or have extended varieties of closures (). It is possible that just making the above change would fix those problems, but it's likely that further changes would be required. Those scope feels like a lang-team initiative. Still may be worth making this change just to screen out the easy cases, mind you!
Change:
unsafe { let mut wfd = mem::zeroed(); let find_handle = c::FindFirstFileW(path.as_ptr(), &mut wfd); if find_handle != c::INVALID_HANDLE_VALUE { Ok(ReadDir { handle: FindNextFileHandle(find_handle),

Discussion:
This was reported on discord by who pointed out that the C++ STL has a similar issue. Example: prints: It should return success but the returned iterator will have no items. Basically if you use on a completely empty volume then it will return . Rust should interpret this as being an empty iteration and not return an error to the user. Note that empty directories do not return an error so this behaviour was overlooked. We need to add some extra logic to this : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
This is fixed in C++ STL after this PR:
Change:
/// The different kinds of types recognized by the compiler pub enum Ty_ { TyVec(P<Ty>), <del> /// A fixed length array (`[T, ..n]`) </del> <ins> /// A fixed length array (`[T; n]`) </ins> TyFixedLengthVec(P<Ty>, P<Expr>), /// A raw pointer (`*const T` or `*mut T`) TyPtr(MutTy),

Discussion:
This isn't a big deal but the documentation is slightly out of date for the variant of . Reference: The comment should read: I will fix this if I have time, otherwise it is a small tweak that someone looking to contribute could make. cc
I've taken the liberty of fixing that comment :)
can you open up a pull request please?
Yep, done! Is this the right way to do it?
Change:
// has anchors for the line numbers that we're linking to. } else if self.item.def_id.is_local() { self.cx.local_sources.get(&PathBuf::from(&self.item.source.filename)).map(|path| { <del> format!("{root}src/{krate}/{path}.html#{href}", </del> <ins> format!("{root}src/{krate}/{path}#{href}", </ins> root = self.cx.root_path, krate = self.cx.layout.krate, path = path,

Discussion:
rustdoc source links end in as can be seen here at the moment (the [src] link) Source link is: (Which is a dead link) Also reproduced locally using rustc 1.9.0-nightly ( 2016-03-07)
Change:
unsafe { let llcx = llvm::LLVMRustContextCreate(tcx.sess.fewer_names()); let llmod_raw = context::create_module(tcx, llcx, mod_name) as *const _; <del> ModuleLlvm { llmod_raw, llcx, tm: create_target_machine(tcx, mod_name) } </del> <ins> ModuleLlvm { llmod_raw, llcx, tm: ManuallyDrop::new(create_target_machine(tcx, mod_name)), } </ins> } }

Discussion:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with
Change:
} pub fn stat(path: &Path) -> io::Result<FileAttr> { <del> metadata(path, ReparsePoint::Follow) </del> <ins> match metadata(path, ReparsePoint::Follow) { Err(err) if err.raw_os_error() == Some(c::ERROR_CANT_ACCESS_FILE as i32) => { if let Ok(attrs) = lstat(path) { if !attrs.file_type().is_symlink() { return Ok(attrs); } } Err(err) } result => result, } </ins> } pub fn lstat(path: &Path) -> io::Result<FileAttr> {

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: The API should report the given path exists. Instead, this happened: When passed a path to a UNIX domain socket on Windows, I get: <!-- 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. --: I think this is simply an unintended consequence of supporting symlinks on Windows. It is interesting that seems to be producing a correct result here (IMO this metadata should be returned by ). The differences between () and () is the flag. On Windows, UNIX domain sockets are implemented as reparse points just like symlink. However Rust is only setting the flag when we are testing for symlink. Without this flag is going to return the access error above. I think the issue is that, the standard library didn't consider that the possibility to have other type of files that are reparse points but not symlinks. I'm not sure what is the best fix for this, but this is kinda surprising. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is indeed a long standing issue. You also get the same thing with app aliases, etc. The fix I've been considering would be to add a fallback to stat so that if is encountered then it uses . Though it would then need to discard the result if the reparse point tag has the name surrogate bit set (which, incidentally, is what  tests for). If anyone is interested in trying to implement this then feel very free. I'd be happy to provide guidance if you as the reviewer of your PR.
I can give this a try. claim
Change:
<ins> error: argument never used --> $DIR/issue-92267.rs:3:34 | LL | pub fn main() { println!("🦀%%%", 0) } |                                   ^ argument never used | note: format specifiers use curly braces, and the conversion specifier ` ` is unknown or unsupported --> $DIR/issue-92267.rs:3:30 | LL | pub fn main() { println!("🦀%%%", 0) } |                               ^^ = note: printf formatting not supported; see the documentation for `std::fmt` error: aborting due to previous error </ins>

Discussion:
rustc crashes on the following input, found by :
searched nightlies: from nightly-2021-01-01 to nightly-2021-12-24 regressed nightly: nightly-2021-10-02 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
The regression happened in . cc
label regression-from-stable-to-stable
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
I've been taking a look at this. It's pretty interesting. I'm not entirely sure I'll be able to work it out, but I figure I may as well assign myself for the time being while I attempt to solve it.
Another test case:
The problem seems to reside within the crate , in the files and . The function in has a macro, , which is in charge of looking for foreign substitutions - that is, someone using printf or shell style formatting rather than Rust's style. It's a macro so it can be generic over the two types of substitution. The first time this macro is called, for printf substitutions, it finds two (I think "%%" and "%", though I'm not sure it's exactly that). The code that actually detects the substitutions is in . When parsing the substitution, in the function , it is somehow finding that the second substitution has a boundary in the middle of the character. I'm not sure exactly how yet. This gets turned into a span in . The span is malformed, as it splits a character in two, so the second the code tries to use it for anything it trips an assertion and causes this ICE. The remaining problem is figuring out what's going wrong in . This sort of string manipulation is not my forte. I'll probably take another few cracks at it though.
Something is broken about . This change makes the ICE go away (but probably breaks other things):
When returns here: it seems like we should increment by , but we actually only increment it by 2:
yes, I get the exact same error. . The error disappears if you add a new line after the , so maybe your text editor did that automatically.

That was it, thanks. I'm going to unassign myself from this. I do hope my exploration ends up being helpful to whoever fixes it though. if you want to fix this yourself, you certainly seem further along than I was, though you shouldn't feel any pressure to do so if you don't want to.
I put up a PR for a
I opened a new issue for your bug, because it's not exactly the same as this one.
Change:
<ins> macro_rules! imp { ($name:ident) => { pub struct $name { pub op: usize, } impl $name { pub fn op() {} pub fn cmp() {} pub fn map() {} pub fn pop() {} pub fn ptr() {} pub fn rpo() {} pub fn drop() {} pub fn copy() {} pub fn zip() {} pub fn sup() {} pub fn pa() {} pub fn pb() {} pub fn pc() {} pub fn pd() {} pub fn pe() {} pub fn pf() {} pub fn pg() {} pub fn ph() {} pub fn pi() {} pub fn pj() {} pub fn pk() {} pub fn pl() {} pub fn pm() {} pub fn pn() {} pub fn po() {} } }; ($name:ident, $($names:ident),*) => { imp!($name); imp!($($names),*); }; } macro_rules! en { ($name:ident) => { pub enum $name { Ptr, Rp, Rpo, Pt, Drop, Dr, Dro, Sup, Op, Cmp, Map, Mp, } }; ($name:ident, $($names:ident),*) => { en!($name); en!($($names),*); }; } imp!(Ot, Foo, Cmp, Map, Loc, Lac, Toc, Si, Sig, Sip, Psy, Psi, Py, Pi, Pa, Pb, Pc, Pd); imp!(Pe, Pf, Pg, Ph, Pj, Pk, Pl, Pm, Pn, Po, Pq, Pr, Ps, Pt, Pu, Pv, Pw, Px, Pz, Ap, Bp, Cp); imp!(Dp, Ep, Fp, Gp, Hp, Ip, Jp, Kp, Lp, Mp, Np, Op, Pp, Qp, Rp, Sp, Tp, Up, Vp, Wp, Xp, Yp, Zp); en!(Place, Plac, Plae, Plce, Pace, Scalar, Scalr, Scaar, Sclar, Salar); pub struct P; </ins>

Discussion:
I was trying to find in rustdoc, but that doesn't show up anywhere if I just search for : It does show up if I search for () so there's a workaround, but I think it'd be nice if when I type an exact name, things with that exact name show up at the top, or something.
It's supposed to, so some adjustments need to be done on the "search engine". I'll take a look.
Change:
} if let Some(ty::subst::GenericArgKind::Type(_)) = subst.map(|subst| subst.unpack()) <ins> && let Some(body_id) = self.tcx.hir().maybe_body_owned_by(obligation.cause.body_id) </ins> { <del> let body_id = self.tcx.hir().body_owned_by(obligation.cause.body_id); </del> let mut expr_finder = FindExprBySpan::new(span); expr_finder.visit_expr(&self.tcx.hir().body(body_id).value);

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
Correction: () (cc I'm not sure I'll be able to figure it out. searched nightlies: from nightly-2022-06-01 to nightly-2023-04-11 regressed nightly: nightly-2023-03-11 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details