jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass // // Regression test for issue #86082 // // Checks that option_env! does not panic on receiving an invalid // environment variable name. fn main() { option_env!("0="); } </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:
impl<T, A: Allocator> Drop for DropGuard<'_, T, A> { fn drop(&mut self) { unsafe { <del> // `IntoIter::alloc` is not used anymore after this let alloc = ptr::read(&self.0.alloc); </del> <ins> // `IntoIter::alloc` is not used anymore after this and will be dropped by RawVec let alloc = ManuallyDrop::take(&mut self.0.alloc); </ins> // RawVec handles deallocation let _ = RawVec::from_raw_parts_in(self.0.buf.as_ptr(), self.0.cap, alloc); }

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'm trying out the allocator api with the goal of being able to track memory usage for parts of a program: I expected this to work (and print 0 at the end), but instead it fails by freeing an invalid pointer: Running with miri gives a bit more context:
This seems to be a problem with the implementation of because if I do: There is no crash and no Miri error, this to me indicate that there is a problem in the implementation of . Another interesting things is the message I have locally , I don't know what it means but it's certainly interesting. label +T-libs +I-unsound
The drop guard used in the implementation of IntoIter makes a raw copy of an allocator when reconstructing RawVec. The allocator is then dropped twice, once by RawVec drop and second time by IntoIter drop. cc .
Minimal reproduction of problem: Prints:
Change:
Keys { iter: self.iter().map(first) } } <del> /// Returns an iterator visiting all values in ascending order by the keys. </del> <ins> /// Returns an iterator visiting all values in ascending order of the keys. </ins> /// The iterator's element type is `&'r V`. #[stable] pub fn values<'r>(&'r self) -> Values<'r, V> {

Discussion:
cc I'm in the process of -ifying the collections, and I've discovered that the takes a instead of the convention of consuming the value. It's also marked stable, even though the type itself is marked unstable. Should this instead be a candidate for the method discussed in the collection reform trait?
Yeah this is just a mistake. Feel free to fix it to match conventions.
Just to be clear, the solution to this is to make consume the value and introduce a function (and iterator). Is this right or am I missing something?
Yep!
Change:
BUILTIN_ATTRIBUTE_MAP.get(&name).map_or(false, |attr| attr.only_local) } <ins> pub fn is_valid_for_get_attr(name: Symbol) -> bool { BUILTIN_ATTRIBUTE_MAP.get(&name).map_or(false, |attr| match attr.duplicates { WarnFollowing | ErrorFollowing | ErrorPreceding | FutureWarnFollowing | FutureWarnPreceding => true, DuplicatesOk | WarnFollowingWordOnly => false, }) } </ins> pub static BUILTIN_ATTRIBUTE_MAP: LazyLock<FxHashMap<Symbol, &BuiltinAttribute>> = LazyLock::new(|| { let mut map = FxHashMap::default();

Discussion:
currently happily ignores any additional attributes in case there are more than one. While this is fine for attributes which don't care about duplicates or emit a warning/error in case there are more than one, this isn't currently checked in the compiler, potentially causing bugs. similar to the check in we should check that the attr declaration in has an acceptable way of dealing with duplicates. in case there are any questions on how to implement this, feel free to open a thread on zulip and pinging me there. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
LL |     _ = partial[..3] == *string_ref; |                         + <del> error: aborting due to 22 previous errors </del> <ins> error[E0277]: no implementation for `i32 & str` --> $DIR/binary-op-suggest-deref.rs:78:17 | LL |     let _ = FOO & (*"Sized".to_string().into_boxed_str()); |                 ^ no implementation for `i32 & str` | = help: the trait `BitAnd<str>` is not implemented for `i32` = help: the following other types implement trait `BitAnd<Rhs>`: <i32 as BitAnd> <i32 as BitAnd<&i32>> <&'a i32 as BitAnd<i32>> <&i32 as BitAnd<&i32>> error[E0277]: the size for values of type `str` cannot be known at compilation time --> $DIR/binary-op-suggest-deref.rs:78:17 | LL |     let _ = FOO & (*"Sized".to_string().into_boxed_str()); |                 ^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `str` error: aborting due to 24 previous errors </ins> Some errors have detailed explanations: E0277, E0308, E0369. For more information about an error, try `rustc --explain E0277`.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'', 'thread 'rustc' panicked at 'range start index 2 out of range for slice of length 1'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Regression in cc sjwang05
claim
just to jump start, I just checked the contents of in the case presented: I'm checking what breaks in the test suite if we change the slicing to (which intuitively makes more sense but am still trying to piece things together). Edit: Ah, yeah, that won't work.
Thanks for the help, turns out I could've just used instead of slicing all along . I'll submit the PR once the test suite finishes running locally. As a side note, do you know why some binops seem to have 3 args? Intuitively it'd make sense to only have 2 args for the lhs and rhs tys--my guess is that the "extra" arg is something effects-related, but I'm not familiar at all with that part of the code.
Change:
<ins> // ICE: failed to get layout for [type error] // issue: rust-lang/rust#92979 use std::fs; use std::fs::File; use std::io::Read; use std::convert::TryInto; fn get_file_as_byte_vec(filename: &String) -> Vec<u8> { let mut f = File::open(&filename).expect("no file found"); let metadata = fs::metadata(&filename).expect("unable to read metadata"); let mut buffer = vec![0; metadata.len() as usize]; f.read(&mut buffer).expect("buffer overflow"); buffer } fn demo<T, const N: usize>(v: Vec<T>) -> [T; N] { v.try_into() .unwrap_or_else(|v: Vec<T>| panic!("Expected a Vec of length {} but it was {}", N, v.len())) } fn main() { // Specify filepath let file: &String = &String::from("SomeBinaryDataFileWith4ByteHeaders_f32s_and_u32s"); // Read file into a vector of bytes let file_data = get_file_as_byte_vec(file); // Print length of vector and first few values let length = file_data.len(); println!("The read function read {} bytes", length); println!("The first few bytes:"); for i in 0..20{ println!("{}", file_data[i]); } // Manually count just to make sure let mut n: u64 = 0; for data in file_data{ n += 1; } println!("We counted {} bytes", n); assert!(n as usize == length, "Manual counting does not equal len method"); // Simulation parameters const N: usize = 49627502;                // Number of Particles const bs: f64 = 125.0;                  // Box Size const HEADER_INCREMENT: u64 = 4*1; // Initialize index and counter variables let (mut j, mut pos, mut vel, mut id, mut mass): (u64, u64, u64, u64, u64) = (0, 0, 0, 0, 0); // Unpack Position Data j += HEADER_INCREMENT; let mut position: Vec<f32> = Vec::new(); while position.len() < N*3 { let p: Vec<u8> = Vec::new(); for item in 0i8..4 { let item = item; p.push(file_data[j as usize]); j += 1; } &mut position[position.len()] = f32::from_be_bytes(demo(p)); //~^ ERROR invalid left-hand side of assignment } // Ensure position data is indeed position by checking values for p in position { assert!((p > 0.) & (p < 125.), "Not in box") } } </ins>

Discussion:
: Same in 1.52.0-nightly, same in 1.51.0. : <details<summary<strongBacktrace</strong</summary<p</p</detailsGood luck! <3
This happens on top of too much code for me to take the time to minimalize this issue, sorry. Though I'll try to file the fixing patch.
Wait! I made it! This issue revolves around L.31. Comment to see the ice go away. Interestingly, comment L.40 (or the whole impl L.37-45) to see ice go away as well. Commenting L.47-56 does not make ice go away. Commenting L.13-22 should raise another error (as L.31 is supposed to go there), but doesn't. Actually, the real fix is to replace L.31 with: Have fun!
Minimized with , then a bit by hand: <details<summaryDetails</summary<pIcemelter version: v0.2.0 label +S-bug-has-mcve </p</details
fixed by . we previously used to eagerly error but did not consider them as part of the cache key. So using a cache key from an evaluation with different can result in buggy behavior
Change:
<ins> error[E0207]: the type parameter `Q` is not constrained by the impl trait, self type, or predicates --> $DIR/unconstrained-param-in-impl-ambiguity.rs:7:13 | LL | unsafe impl<Q: Trait> Send for Inner {} |             ^ unconstrained type parameter error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0207`. </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. --This is the least I've managed to reduce the code: <!-- 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. --: With nightly version the compiler asks me to change the as follows: and now the error no longer occurs. After running the command, I get the following: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOutput seems the same </p</details
Related if not duplicate of one of: , , . label -needs-triage T-rustdoc A-auto-traits A-synthetic-impls
I can't seem to reproduce the ICE with and
Me neither, seems to have been fixed. Potentially by err's “ PR” or by one of the PRs that made rustdoc execute more of rustc's stages. Fixed: ICE → errors (unsatisfied bounds).

<!-- 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
label A-synthetic-impls A-auto-traits T-compiler The bug originates in which lives in , so having both team labels is valid.
Bisection seems to point to nightly-2022-10-24, one of these:
Out of those, looks the most likely (from ).
I can no longer reproduce this. Fixed: ICE → errors. Probably fixed by one of those PRs that made rustdoc run more of rustc's passes.

Minimal example What I expected: works. What happens: (check & build work) No response No response
Thanks for the report! I have transferred this to rust-lang/rust as that is where rustdoc issues are tracked.
Seems to be a compiler bug. Adding the relevant tag.
Although the MCVE looks a bit esoteric, it actually comes from using  in an fairly straightforward way. I wouldn't be surprised if others have/will run into this.
Ran on this and found it regressed in The PR () states it's a revert of a previous commit. So maybe it was broken before the commit that needed reverting.
label A-auto-traits A-synthetic-impls
I can no longer reproduce this issue.
Change:
| LL | #[derive(inline)] |          ^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/macro-path-prelude-fail-4.rs:1:10 | LL | #[derive(inline)] |          ^^^^^^ = help: add as non-Derive macro `#[inline]` </ins> error: aborting due to previous error

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
return; } <ins> // For from_iter, check if the type actually implements FromIterator. // If we know it does not, we don't need to warn. if method_name.name == sym::from_iter { if let Some(trait_def_id) = self.tcx.get_diagnostic_item(sym::FromIterator) { if !self .infcx .type_implements_trait( trait_def_id, self_ty, InternalSubsts::empty(), self.param_env, ) .may_apply() { return; } } } </ins> // No need to lint if this is an inherent method called on a specific type, like `Vec::foo(...)`, // since such methods take precedence over trait methods. if matches!(pick.kind, probe::PickKind::InherentImplPick) {

Discussion:
(As I mentioned :) I tried out the migration lints on some of my own code, and ran into one false positive: A struct being used with This doesn't actually become ambiguous when FromIterator is imported, because Opt doesn't implement that. Niko :
(If we don't end up doing this, we should at least change the wording to say instead of .)
Which exact function on which type do you mean? Do you have some pointers here?
Maybe Niko meant evaluate-obligation ?
Okay I have an implementation that uh.. compiles. And seems to work, maybe? (:
Change:
#![feature(crate_visibility_modifier)] <ins> #![feature(once_cell)] </ins> #![feature(or_patterns)] #[macro_use]

Discussion:
After is merged, usage of in this module: should be replaced by . The dependency from corresponding can be removed afterwards. It might make sense to request a perf run, as version uses parkinglot, while the standard one uses std mutex, but I expect the difference to not matter -- fast path is equivalent for both.
claim
is done! Though, I am not unsure if we maybe should wait until it tickles down to beta? Not sure how bootstraping works with libstd, I guess, we can just try and see if the build fails.
The compiler always builds with the in-tree standard library, so cfg(bootstrap) should never be necessary (beyond lints, and other compiler-implemented rather than library-implemented) details.
ping this is ready to be implemented.
I'll start soon! Sorry I got a bit overwhelmed with work. If in the next couple of days I haven't replied feel free to re-assign.
On it!
once this is merged, should other sub-crates that depend on also be updated? Like for example. Also, what about ? Some usage can probably be replaced by .
We definitely should actively remove oncecell crate from all rustc’s crates, because having two difference sources of the same data structure feels bad. Replacing lazystatic with std::lazy would also be good!
I'll try to take of it once this issue is fixed :+1:
Change:
while buf.ends_with('n') { buf.pop(); } <del> (buf, substitution.parts, only_capitalization) </del> <ins> Some((buf, substitution.parts, only_capitalization)) </ins> }) .collect() }

Discussion:
I was using the latest version of  and tried to store a reference without a lifetime annotated in a macro-generated error. This shouldn't (and doesn't) work, but rustc should at least throw an error instead of blowing up, right? Code sample: I expected an error of some sort about lifetimes or macros, but instead, the compiler ed: thread 'rustc' panicked at 'called on an value: DistinctSources(DistinctSources { begin: (Real(""), BytePos(0)), end: (Macros("::quickerror::quickerror"), BytePos()) })', This rustc was compiled on Gentoo from a recent . $ rustc --version --verbose rustc 1.42.0-dev ( 2020-01-21) binary: rustc commit-hash: commit-date: 2020-01-21 host: x8664-unknown-linux-gnu release: 1.42.0-dev LLVM version: 9.0 Minimal example: Backtrace:
rustc in playpen isn't the latest compiler. reopen
cc
Backtrace:
triage: P-high, assigning to . (It would be good to confirm it is indeed due to the CC'ed PR via bisection...)
Full backtrace: From a quick look it seems like might tackle this. Rebuilding a recent master to confirm.
Change:
Ok(()) } } <ins> /// A draining iterator for `String`. #[unstable(feature = "collections_drain", reason = "recently added")] pub struct Drain<'a> { /// Will be used as &'a mut String in the destructor string: *mut String, /// Start of part to remove start: usize, /// End of part to remove end: usize, /// Current remaining range to remove iter: Chars<'a>, } unsafe impl<'a> Sync for Drain<'a> {} unsafe impl<'a> Send for Drain<'a> {} #[unstable(feature = "collections_drain", reason = "recently added")] impl<'a> Drop for Drain<'a> { fn drop(&mut self) { unsafe { // Use Vec::drain. "Reaffirm" the bounds checks to avoid // panic code being inserted again. let self_vec = (*self.string).as_mut_vec(); if self.start <= self.end && self.end <= self_vec.len() { self_vec.drain(self.start..self.end); } } } } #[unstable(feature = "collections_drain", reason = "recently added")] impl<'a> Iterator for Drain<'a> { type Item = char; #[inline] fn next(&mut self) -> Option<char> { self.iter.next() } fn size_hint(&self) -> (usize, Option<usize>) { self.iter.size_hint() } } #[unstable(feature = "collections_drain", reason = "recently added")] impl<'a> DoubleEndedIterator for Drain<'a> { #[inline] fn next_back(&mut self) -> Option<char> { self.iter.next_back() } } </ins>

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has