jiebi/CodeConvo huggingface dataset:
Change:
// We are conservative with undef for integers, but try to // actually enforce the strict rules for raw pointers (mostly because // that lets us re-use `ref_to_mplace`). <del> let place = try_validation!( </del> <ins> let place = try_validation_pat!( </ins> self.ecx.ref_to_mplace(self.ecx.read_immediate(value)?), <ins> err_ub!(InvalidUndefBytes(..)), </ins> "uninitialized raw pointer", self.path );

Discussion:
The lint should fire on the following code, but it does not: (This testcase now exists in-tree as a FIXME in .) Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'd like to take this. claim
I have some plans to follow-up on with some cleanup. That might at least partially resolve this issue here. So it's probably best to wait until after that is done.
All right, landed, so what I planned here is done. The remaining issue is about associated consts. The issue there is that fails, or maybe we are hitting an , but I have not tried further. The issue is all yours, :)
Great! I'll start investigating.
Never mind, that one is already fixed on beta.
got reverted in , so we have to reopen this.
Change:
} } <del> pub fn getenv(k: &OsStr) -> io::Result<Option<OsString>> { let k = CString::new(k.as_bytes())?; </del> <ins> pub fn getenv(k: &OsStr) -> Option<OsString> { let k = CString::new(k.as_bytes()).ok()?; </ins> unsafe { let _guard = env_lock(); let s = libc::getenv(k.as_ptr()) as *const libc::c_char; <del> let ret = if s.is_null() { </del> <ins> if s.is_null() { </ins> None } else { Some(OsStringExt::from_vec(CStr::from_ptr(s).to_bytes().to_vec())) <del> }; Ok(ret) </del> <ins> } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Simplified. The other malformed-looking bytes don't matter, do they?
You are right, they don't. I should have simplified it before submit.
Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself. claim
Still working on this, but I figured an update may be helpful. My research indicates that the two characters that are potentially problematic are and . The work that needs to be done consists of 1) updating the macro expansion functions in to error in these cases; and 2) updating the macro documentation in to mention the new errors. Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I don't think just adding a check to raise error in these cases would be enough. The function shouldn't really panic (from the internals discussion). Another problem is when the OS supports this kind of environment variable. e.g. as key. would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) as this must be changes to which would take a while.
If this is going to be fixed upstream in in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.
Actually, simple solution: I'll do the fix.

Working on that now.
Was this fuzzer output? If so, which fuzzer were you using
Yes, I am using kira, a work-in-progress fuzzing tool
Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.
Yes, actually kira is structure-aware.
Change:
} TraitItemKind::Const(ty, body_id) => body_id .and_then(|body_id| { <del> is_suggestable_infer_ty(ty) .then(|| infer_placeholder_type(tcx, def_id, body_id, ty.span, item.ident, "constant",)) </del> <ins> is_suggestable_infer_ty(ty).then(|| { infer_placeholder_type( tcx, def_id, body_id, ty.span, item.ident, "constant", ) }) </ins> }) .unwrap_or_else(|| icx.to_ty(ty)), TraitItemKind::Type(_, Some(ty)) => icx.to_ty(ty),

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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
|     | |     help: parentheses are required to parse this as an expression: `({ 42 })` <del> error: expected expression, found `&&` --> $DIR/expr-as-stmt.rs:30:5 | LL |     if let Some(x) = a { true } else { false } |     ------------------------------------------ help: parentheses are required to parse this as an expression: `(if let Some(x) = a { true } else { false })` LL |     && |     ^^ expected expression </del> error: expected expression, found `>` <del> --> $DIR/expr-as-stmt.rs:37:7 </del> <ins> --> $DIR/expr-as-stmt.rs:31:7 </ins> | LL |     } > 0 |       ^ expected expression

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> use std::borrow::Cow; </ins> use std::iter::{FromIterator, repeat}; use std::mem::size_of;

Discussion:
Both Vec<Tand &[T] are missing From impls for Cow, unlike String/&str and PathBuf/&Path. Coherence is not (afaict) an issue, since the impl would be in the same crate as Cow. Is there some reason these don't exist (do they cause coherence issues in downstream crates or something)?
Whoa, I have no idea why these aren't implemented... Should be good to go ahead and add them! Want to send a PR?
Change:
Ok(self) } <ins> ty::Alias(ty::Inherent, _) => panic!("unexpected inherent projection"), </ins> _ => self.pretty_print_type(ty), } }

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 --
regression in cc
claim
another one `

<!-- 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 --
Regression in cc
Thanks :) claim
Change:
<ins> pub fn const_arg<const N: usize, T>() {} pub fn lt_arg<'a: 'a>() {} </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. --cc still crashes after <!-- 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 --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!
Change:
<ins> pub struct A; impl From<fn((), (), &())> for A { fn from(_: fn((), (), &mut ())) -> Self { //~^ error: method `from` has an incompatible type for trait loop {} } } pub struct B; impl From<fn((), (), u32)> for B { fn from(_: fn((), (), u64)) -> Self { //~^ error: method `from` has an incompatible type for trait loop {} } } fn main() {} </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. --: Also get this using stable: You can see it on the playground: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Can reproduce even without the type aliases: Edit: even smaller reproducer: Produces this output: () :
After some testing, this can be reproduced since 1.53, might have been introduced in
Change:
} /// Fetches the environment variable `key` from the current process, returning <del> /// [`None`] if the variable isn't set. /// /// # Panics /// /// This function may panic if `key` is empty, contains an ASCII equals sign /// `'='` or the NUL character `'0'`, or when the value contains the NUL /// character. </del> <ins> /// [`None`] if the variable isn't set or there's another error. </ins> /// /// Note that the method will not check if the environment variable /// is valid Unicode. If you want to have an error on invalid UTF-8, /// use the [`var`] function instead. /// <ins> /// # Errors /// /// Returns `[None]` if the variable isn't set. /// May return `[None]` if the variable value contains the NUL character. /// </ins> /// # Examples /// /// ```

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 --
Simplified. The other malformed-looking bytes don't matter, do they?
You are right, they don't. I should have simplified it before submit.
Going to have a go at this. If I can't figure it out, I'll either ask for help or unassign myself. claim
Still working on this, but I figured an update may be helpful. My research indicates that the two characters that are potentially problematic are and . The work that needs to be done consists of 1) updating the macro expansion functions in to error in these cases; and 2) updating the macro documentation in to mention the new errors. Edit: It just occurred to me that I also need to add UI tests. Haven't figured out where to do that yet, but I will.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I don't think just adding a check to raise error in these cases would be enough. The function shouldn't really panic (from the internals discussion). Another problem is when the OS supports this kind of environment variable. e.g. as key. would deny it while it can be valid i.e. a false positive. You should still keep your work though (and eventually open a PR) as this must be changes to which would take a while.
If this is going to be fixed upstream in in even the mid-term future, I'm not sure fixing it here makes sense. Sure, it generates an ICE, but the ICE has an unusually helpful error message.
Actually, simple solution: I'll do the fix.

Working on that now.
Was this fuzzer output? If so, which fuzzer were you using
Yes, I am using kira, a work-in-progress fuzzing tool
Have you considered sorry using structure-aware fuzzing? That could help find bugs not just in the lexer and parser, but also in the middle and back ends.
Yes, actually kira is structure-aware.
Change:
} pub fn report_unstable( <del> sess: &Session, feature: Symbol, reason: Option<Symbol>, issue: u32, is_soft: bool, span: Span </del> <ins> sess: &Session, feature: Symbol, reason: Option<Symbol>, issue: u32, is_soft: bool, span: Span, soft_handler: impl FnOnce(&'static lint::Lint, Span, &str), </ins> ) { let msg = match reason { Some(r) => format!("use of unstable library feature '{}': {}", feature, r),

Discussion:
Hi there, I'm updating rust-sgx-sdk (solving rust-sgx-sdk ) to use latest rust nightly compiler to help the error info more ergonomic by the help of . However, the compiler always panics. Your help would be very much helpful. The current code is at . To reproduce this bug, please checkout branch and build sgxtstd as follows: And the reproducible failure info is: : rustc 1.40.0-nightly ( 2019-10-03) binary: rustc commit-hash: commit-date: 2019-10-03 host: x8664-unknown-linux-gnu release: 1.40.0-nightly LLVM version: 9.0 Backtrace:
It'd be helpful to have a more minimal example here I suspect -- for example, at least reducing to a single crate. cc since this deals with diagnostic machinery
It seems like this was introduced a month ago in , CC
I think I find the solution on my side: the removal of .
A working branch is baidu/rust-sgx-sdk : test-2019-10. Failing branch is librustc-bug-report. After I enable , the compiler starts to fail.
The minimum sample is as follows: and compile by
Fixed in
Cool!
Change:
}; let vis = self.tcx.local_visibility(local_def_id); <del> let hir_id = self.tcx.hir().local_def_id_to_hir_id(local_def_id); </del> let span = self.tcx.def_span(self.item_def_id.to_def_id()); let vis_span = self.tcx.def_span(def_id); if self.in_assoc_ty && !vis.is_at_least(self.required_visibility, self.tcx) { let vis_descr = match vis { ty::Visibility::Public => "public", ty::Visibility::Restricted(vis_def_id) => { <del> if vis_def_id == self.tcx.parent_module(hir_id).to_local_def_id() { </del> <ins> if vis_def_id == self.tcx.parent_module_from_def_id(local_def_id).to_local_def_id() { </ins> "private" } else if vis_def_id.is_top_level_module() { "crate-private"

Discussion:
I tried this code: I expected to see this happen: The lint is allowed. Instead, this happened: The lint still triggers. (Applying to the entire module works). (I'm assuming that this is unintentional, thus reporting as a "bug". If this behavior is intentional, consider this a feature request to change it). Latest playground nightly:
The problem here is that the lint is associated with the private item, not the item which names it in its bounds:
cc
Change:
Scalar::from_f32(f) } ty::FloatTy::F64 => { <del> let rust_f = num .parse::<f64>() .unwrap_or_else(|e| panic!("f64 failed to parse `{}`: {:?}", num, e)); </del> <ins> let rust_f = match num.parse::<f64>() { Ok(f) => f, Err(_) => return None, }; </ins> let mut f = num.parse::<Double>().unwrap_or_else(|e| { panic!("apfloat::ieee::Double failed to parse `{}`: {:?}", num, e) });

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Note that slight modifications of the input fix the panic. For example using instead of results in no panic. Also there is no panic if compling only the string . Affected versions: I tried nightly 2021-11-30 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Might be related? Formatting of "1e-15" behavior seems to have changed on nightly for f64 and f32.
It may have a common cause, but you should open a separate issue because the pull request that fixes this doesn't fix your problem.
Change:
/// Sorts the slice with a key extraction function. /// <del> /// This sort is stable (i.e. does not reorder equal elements) and `O(n log n)` worst-case. </del> <ins> /// This sort is stable (i.e. does not reorder equal elements) and `O(m n log m n)` /// worst-case, where the key function is `O(m)`. /// /// For expensive key functions (e.g. functions that are not simple property accesses or /// basic operations), [`sort_by_cached_key`](#method.sort_by_cached_key) is likely to be /// significantly faster, as it does not recompute element keys. </ins> /// /// When applicable, unstable sorting is preferred because it is generally faster than stable /// sorting and it doesn't allocate auxiliary memory.

Discussion:
Where we would normally put "^^^ did you mean Up" under mistyped names, I noticed that we don't do that for enum variants. Here's an example I just saw: !
Taking a look.
Change:
} } <ins> pub struct CheckTypeWellFormedVisitor<'a, 'tcx: 'a> { tcx: TyCtxt<'a, 'tcx, 'tcx>, } impl<'a, 'gcx> CheckTypeWellFormedVisitor<'a, 'gcx> { pub fn new(tcx: TyCtxt<'a, 'gcx, 'gcx>) -> CheckTypeWellFormedVisitor<'a, 'gcx> { CheckTypeWellFormedVisitor { tcx, } } } </ins> impl<'a, 'tcx, 'v> Visitor<'v> for CheckTypeWellFormedVisitor<'a, 'tcx> { fn nested_visit_map<'this>(&'this mut self) -> NestedVisitorMap<'this, 'v> { NestedVisitorMap::None

Discussion:
At the moment WF checking is not done via a query. As a consequence, we cannot cache it during incremental compilation. Seems like an easy optimization. cc
I'm working on this.
Change:
<ins> // check-pass #![feature(const_generics)] #![allow(incomplete_features)] #![deny(dead_code)] // We previously incorrectly linted `L` as unused here. const L: usize = 3; fn main() { let p = Printer {}; p.print(); } trait Print<const N: usize> { fn print(&self) -> usize { 3 } } struct Printer {} impl Print<L> for Printer {} </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 this code: I expected to see this happen: no warning is emitted. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'm not sure this needs to block , but it affects it, so marking as blocking for now.
claim
This is actually not an issue related to const generics :sweat_smile: It does not look at trait impls even if they are used as long as they don't overwrite the relevant method.
Change:
vec![Some(false); n] } <ins> // CHECK-LABEL: @vec_option_i32 #[no_mangle] pub fn vec_option_i32(n: usize) -> Vec<Option<i32>> { // CHECK-NOT: call {{.*}}alloc::vec::from_elem // CHECK-NOT: call {{.*}}reserve // CHECK-NOT: call {{.*}}__rust_alloc( // CHECK: call {{.*}}__rust_alloc_zeroed( // CHECK-NOT: call {{.*}}alloc::vec::from_elem // CHECK-NOT: call {{.*}}reserve // CHECK-NOT: call {{.*}}__rust_alloc( // CHECK: ret void vec![None; n] } </ins> // Ensure that __rust_alloc_zeroed gets the right attributes for LLVM to optimize it away. // CHECK: declare noalias ptr @__rust_alloc_zeroed(i64, i64 allocalign) unnamed_addr [[RUST_ALLOC_ZEROED_ATTRS:#[0-9]+]]

Discussion:
I want to initialize a large with . Compiling with Rust 1.66 generates instructions. However, after initializing with the code gets vectorized as expected: The generated assembly contains instructions. Now, the weird thing is that if I have both functions in the same file, both get vectorized. See this . As long as is commented out, is not vectorized. As soon as you remove the comment, both functions are vectorized.
Easiest fix for specifically would be to update , I think. We don't guarantee a layout for it, but internally for optimizations I think we'd be safe doing this. (We can put some tests like in non-public stuff to help double-check it.)
When is , couldn't the part of the memory layout be anything since it shouldn't be accessed? Couldn't we use that for optimization? So for example, if sets the discriminator bit to 0, couldn't we always zero out the entire memory no matter what is? Or if the discriminator is represented with a non-zero value, couldn't the whole data structure be filled up with that value (or just left unitialized depending on which is faster)?
Unfortunately not, because there can be other niches than 0. For instance, has the value 0xffff_ffff on Unix platforms.
Can we at least assume that two -s will always have the same bytes in memory for any fixed ? If so, couldn't we vectorize filling up the with those bytes?
I think similar to . iirc the main issue is that LLVM's InstCombine removes the instructions before reaching the passes that could use this information to optimize - at this point, it generally becomes a series of stores with gaps between which LLVM no longer knows can be written to freely.
No, because something like is half , where "the same" isn't a meaningful question. That's exactly what I mention for -- you can use that to check that it's a value where it would be legal to zero out the whole thing, and if that function returns then uses a zeroing allocator instead of the needing initialize the memory.