jiebi/CodeConvo huggingface dataset:
Change:
use crate::ffi::{CStr, CString}; use crate::fmt; use crate::io; <ins> use crate::marker::PhantomData; </ins> use crate::mem; use crate::num::NonZeroU64; use crate::num::NonZeroUsize;

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
| hir::ItemKind::Use(..) | hir::ItemKind::OpaqueTy(..) | hir::ItemKind::TyAlias(..) <del> | hir::ItemKind::Static(..) </del> | hir::ItemKind::Mod(..) | hir::ItemKind::ForeignMod { .. } | hir::ItemKind::Impl { .. }

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. --I couldn't I couldn't produce a single file example, as it seems the ICE is triggered when cross crate compilation is involved; i.e dumping the contents of into does not trigger the ICE. This seems like a regression of the feature as this previously worked on nightly of the 1.50 stable release. : : <!-- 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
While regression itself is related to the introduction of CTFE MIR, it seems this actually never worked correctly, with static ending up duplicated.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
I can't reproduce with the latest nightly and cargo. Are there any further instructions for reproducing this?
Apologies, forgot to mention you'll need to add Or build for a target that does not have panic unwinding enabled by default.
(discussed in T-compiler meeting. This is an issue on stable, and might get a backport via . Re-opening to investigate details of what worked, what stopped working, what is fixed, and what is still broken.)
In the case reported here, one crate references static from another crate. During mono item collection, based on reachability determines whether it will link to item from an upstream crate or codegen it locally. When decision is made to codegen locally, it is followed by an assertion that optimized MIR is available to do so. In 1.50 static is non-reachable and codegenned locally. In 1.51 and 1.52 static is non-reachable, but the assertion fails since statics no longer use optimized MIR. In nightly, since , the static is reachable and linked to. The change seems safe for backporting to me.
Closing as the .
Change:
<ins> // Regression test for issue #74918 // Tests that we don't ICE after emitting an error struct ChunkingIterator<T, S: 'static + Iterator<Item = T>> { source: S, } impl<T, S: Iterator<Item = T>> Iterator for ChunkingIterator<T, S> { type Item = IteratorChunk<T, S>; //~ ERROR missing lifetime fn next(&mut self) -> Option<IteratorChunk<T, S>> { //~ ERROR `impl` todo!() } } struct IteratorChunk<'a, T, S: Iterator<Item = T>> { source: &'a mut S, } impl<T, S: Iterator<Item = T>> Iterator for IteratorChunk<'_, T, S> { type Item = T; fn next(&mut self) -> Option<T> { todo!() } } 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. --(I know this is probably incorrect code, but this is what triggered the internal compiler error). <!-- 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
Assigning as and removing .
44 doesn't have the ICE.
shows that this can result in no user-facing error message. I suggest increasing priority to .
Change:
use crate::{lang_items, LangItem, LanguageItems}; use rustc_ast as ast; <del> use rustc_data_structures::fx::FxHashMap; </del> <ins> use rustc_data_structures::stable_map::StableMap; </ins> use rustc_span::symbol::{sym, Symbol}; use std::lazy::SyncLazy;

Discussion:
Since a few weeks we are getting an unrelated failure in a ui test where the order of two diagnostics changes. It is not entirely random, since it only changes if there are compiler changes, but we should still find and fix it <details<summary<iClick to see the possible cause of the failure (guessed by this bot)</i</summary</detailsOriginally posted by in
The first time I've seen it was in The second time in
This happened to me in too.
This could be happening because , declared here: is being traversed here: and thus we get non-determinism in the output... Two obvious solutions: change to a sorted map structure in the declaration, or normalize the order before traversing in the loop in
cc
Change:
ambient_variance, )?; <del> self.infcx.inner.borrow_mut().type_variables().instantiate(b_vid, b_ty); </del> <ins> // Constrain `b_vid` to the generalized type `b_ty`. if let &ty::Infer(TyVar(b_ty_vid)) = b_ty.kind() { self.infcx.inner.borrow_mut().type_variables().equate(b_vid, b_ty_vid); } else { self.infcx.inner.borrow_mut().type_variables().instantiate(b_vid, b_ty); } </ins> if needs_wf { self.obligations.push(Obligation::new(

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. -- <!-- --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
minimal repro of the error reported above <details<summaryBacktrace</summary</details
Same ICE with in  () cc searched nightlies: from nightly-2023-12-03 to nightly-2023-12-06 regressed nightly: nightly-2023-12-06 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Change:
panic!("not supported on this platform") } <del> pub fn getenv(_: &OsStr) -> io::Result<Option<OsString>> { Ok(None) </del> <ins> pub fn getenv(_: &OsStr) -> Option<OsString> { None </ins> } pub fn setenv(_: &OsStr, _: &OsStr) -> io::Result<()> {

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:
'outer: for (line_no, md_line) in md_lines.enumerate() { loop { <del> let source_line = src_lines.next().expect("could not find markdown in source"); </del> <ins> let source_line = src_lines.next()?; </ins> match source_line.find(md_line) { Some(offset) => { if line_no == starting_line {

Discussion:
: : I expected to see this happen: completes successfully with a "unresolved link to " warning Instead, this happened: <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
I bet the source span is wrong somehow.
The issue is that the documentation on the re-export is being combined with the original documentation. splits it up by the module it's scoped to, which is different for the two doc-comments; if you remove it works fine. needs to only pass the documentation for the current scope to , not the combined docs. Not sure why it needs a separate file.
The markdown range it comes up with is 3..13. Hmm, this is weird - I think this is actually the correct span because they both come from , which doesn't care about scoping and just works on strings. Maybe it is a bug in after all?
Aha, here we go: is trying to look at the rustc snippet instead of the text it was provided. Maybe it could just work with instead?
Hmm, there are some other bugs here too: normally rustdoc will resolve docs in the scope inside the module and to the scope of the parent. But since there are inner docs, it will resolve all of the links inside the module. I think the fix for both the issues is to separate outer docs from inner ones; not yet sure how to do that.
To add another test-case for what I believe is another instance of the same problem: This doesn't panic, but produces: For an even more confused case, split the module into its own file: Which yields this nonsensical warning: Essentially, the span of the unresolved link is misattributed to the wrong file. The line and column values are correct, it's just the wrong file that's used.
That's is assuming there is only inner or outer docs, not both.
Change:
<del> // Copyright 2015 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. struct Foo(bool); const NEW_FALSE: bool = false; const STATIC_FOO: Foo = Foo(NEW_FALSE); pub fn main() { match (Foo(false)) { STATIC_FOO => 3, _ => 11 }; } </del>

Discussion:
Attempting to compile  with results in:
This also affects 
Seems that is just a dupe of , too.
Closing as dupe of .
Change:
("avx512bw", Unstable(sym::avx512_target_feature)), ("avx512cd", Unstable(sym::avx512_target_feature)), ("avx512dq", Unstable(sym::avx512_target_feature)), <del> ("avx512er", Unstable(sym::avx512_target_feature)), </del> ("avx512f", Unstable(sym::avx512_target_feature)), ("avx512fp16", Unstable(sym::avx512_target_feature)), ("avx512ifma", Unstable(sym::avx512_target_feature)), <del> ("avx512pf", Unstable(sym::avx512_target_feature)), </del> ("avx512vbmi", Unstable(sym::avx512_target_feature)), ("avx512vbmi2", Unstable(sym::avx512_target_feature)), ("avx512vl", Unstable(sym::avx512_target_feature)),

Discussion:
For example, from (And many more.) I think this is due to Should we just drop these from ?
cc
Change:
<ins> // aux-crate:priv:equivalent=equivalent.rs // compile-flags: -Zunstable-options --extern equivalent // edition:2018 extern crate equivalent; #[derive(Clone, PartialEq, Eq, Debug)] pub struct LayoutError; </ins>

Discussion:
I was checking if exposed  and found these seemingly non existent methods
It looks like the search results are present on (and after), but not on (or before)
Seems that's when std's hashbrown was upgraded to that the trait -
Change:
<ins> trait Bug { type Item: Bug; const FUN: fn() -> Self::Item; } impl Bug for &() { existential type Item: Bug; //~ ERROR existential types are unstable //~^ ERROR the trait bound `(): Bug` is not satisfied //~^^ ERROR could not find defining uses const FUN: fn() -> Self::Item = || (); } fn main() {} </ins>

Discussion:
Another ICE that uses a nightly only feature, but still crashes on stable, beta and nightly without the flag. According to godbolt, this sneaked in with 1.34. 1.33 and lower are not affected. <details<summaryBacktrace:</summary
nevermind I was thinking of , which you also filed
I found this verry related:
Again this is kinda 2 issue's in 1, so I dont know if this should have it's own issue... After some more trying, I found this also panics, but only on nightly: Notice I removed the on the line <details<summaryBacktrace:</summary</details
Another one, stable, beta & nightly: <details<summaryBacktrace:</summary</details
triage: P-high due to ICE; removing nomination.
Likely duplicate from
Change:
<del> Subproject commit 34d8ec896db94ac7443541514653166ad5d38d3c </del> <ins> Subproject commit 4da2b2149ca1c6a3331260dfcbb2175c51f2842d </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
Reopening until the submodule is updated
triage: P-medium. looks like its on way to being fixed, anyway.
Change:
<ins> // Regression test for various ICEs inspired by // https://github.com/rust-lang/rust/issues/83921#issuecomment-814640734 // compile-flags: -Zdeduplicate-diagnostics=yes #[repr(packed())] //~^ ERROR: incorrect `repr(packed)` attribute format struct S1; #[repr(align)] //~^ ERROR: invalid `repr(align)` attribute struct S2; #[repr(align(2, 4))] //~^ ERROR: incorrect `repr(align)` attribute format struct S3; #[repr(align())] //~^ ERROR: incorrect `repr(align)` attribute format struct S4; // Regression test for issue #118334: #[repr(Rust(u8))] //~^ ERROR: invalid representation hint #[repr(Rust(0))] //~^ ERROR: invalid representation hint #[repr(Rust = 0)] //~^ ERROR: invalid representation hint struct S5; #[repr(i8())] //~^ ERROR: invalid representation hint enum E1 { A, B } #[repr(u32(42))] //~^ ERROR: invalid representation hint enum E2 { A, B } #[repr(i64 = 2)] //~^ ERROR: invalid representation hint enum E3 { A, B } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unrecognized representation hint', 'error: internal compiler error: unrecognized representation hint' 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: --
Regression in nightly-2023-08-26
Change:
// the file descriptor was closed or not, and if we retried (for // something like EINTR), we might close another valid file descriptor // opened after we closed ours. <ins> // However, this is usually justified, as some of the major Unices // do make sure to always close the FD, even when `close()` is interrupted, // and the scenario is rare to begin with. // Helpful link to an epic discussion by POSIX workgroup: // http://austingroupbugs.net/view.php?id=529 </ins> #[cfg(not(target_os = "hermit"))] { #[cfg(unix)]

Discussion:
While being strict to the letter of , this comment looks to me as a little too abstract and therefore unnecessarily fear-inducing. Maybe it would make sense to expand it by saying that at least some of the major Unix-like systems do make sure to always close the FD, even when is interrupted, and that this is a pretty rare situation anyway, because it may happen only if a custom signal handler is set by the process. Maybe even provide some illuminating links like . Making so might save time for people, who are not aware of the details of this issue, but nevertheless care enough about their FDs always being closed to start digging the Web for answers :) Thank you for reading. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Looks like this piece of code got moved over the last 4 years. Currently the comment in question resides here:
claim
Change:
continue; }; for obligation in obligations { <ins> debug!(?obligation); </ins> match obligation.predicate.kind().skip_binder() { <ins> // We need to register Projection oblgiations too, because we may end up with // an implied `X::Item: 'a`, which gets desugared into `X::Item = ?0`, `?0: 'a`. // If we only register the region outlives obligation, this leads to an unconstrained var. // See `implied_bounds_entailment_alias_var` test. </ins> ty::PredicateKind::Clause( <del> ty::ClauseKind::RegionOutlives(..) | ty::ClauseKind::TypeOutlives(..), </del> <ins> ty::ClauseKind::RegionOutlives(..) | ty::ClauseKind::TypeOutlives(..) | ty::ClauseKind::Projection(..), </ins> ) => ocx.register_obligation(obligation), ty::PredicateKind::Clause(ty::ClauseKind::WellFormed(arg)) => { if wf_args_seen.insert(arg) {

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. --can't compile linfa, please show me how to fix <!-- 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
this is due to . It turns out that skipping over projection goals that we get back from leads to unconstrained infer vars. It's pretty difficult to create a minimal repro of this, though. This isn't fixed by because the infer var is coming from within 's own normalization.
I'll take a look.
Pretty rough, but here's an MCVE. Still can probably minimize a bit more: (edit: updating as I minimize a bit more)
Okay, here's the simplest MCVE I can make:
WG-prioritization assigning priority (). label -I-prioritize +P-high -needs-triage
Change:
/// Used to determine the path to externally loaded source files mod_path_stack: @mut ~[@str], /// Stack of spans of open delimiters. Used for error message. <del> open_braces: @mut ~[Span] } #[unsafe_destructor] impl Drop for Parser { </del> <ins> open_braces: @mut ~[Span], </ins> /* do not copy the parser; its state is tied to outside state */ <del> fn drop(&mut self) {} </del> <ins> priv non_copyable: util::NonCopyable </ins> } fn is_plain_ident_or_underscore(t: &token::Token) -> bool {

Discussion:
The unit struct via , so it's the cleanest way to do this. This could potentially be a lint warning, with a suggestion.
A lint for empty drops is probably unnecessary, I wouldn't imagine that would be a common idiom once NonCopyable is well-known.
I only see one of these, in libsyntax.
Change:
LL |     fn is_str() -> bool { |     ^^^^^^^^^^^^^^^^^^^ = help: items from traits can only be used if the type parameter is bounded by the trait <del> help: disambiguate the method call for the candidate | LL |     ManyImplTrait::is_str(t) | help: the following trait defines an item `is_str`, perhaps you need to restrict type parameter `T` with it: | LL | fn param_bound<T: ManyImplTrait + ManyImplTrait>(t: T) -> bool { |                ^^^^^^^^^^^^^^^^^^ </del> error: aborting due to 3 previous errors

Discussion:
Given the following test and nightly 2020-01-12: I get that this is not supposed to work without const generics, but the error message suggestion is very funny: With const generics:
Weird suggestion is on current stable as well.
The ICE component is fixed by , the diagnostics issue remains ()
I think it's another example of now.
Change:
<ins> // Copyright 2014 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. fn main() { let mut my_stuff = std::collections::HashMap::new(); my_stuff.insert(0i, 42i); let mut it = my_stuff.iter(); my_stuff.swap(1, 43); //~ ERROR cannot borrow } </ins>

Discussion:
Sorry, I'm not sure how to describe this very well in a sentence. I am able to mutably borrow the innermost values of a , delete the values, then reference them after they were deleted. This code compiles, runs, and barfs out strange numbers.
Little bit shorter example, without mutable borrows. But still fails to freeze :
nominating for 1.0 P-backcompat-lang
though this may be a library issue
weird This code is also valid: This is because the hashmap iterator just wraps the rawtable iterator, which just defers to the RawBuckets iterator, which is just a wrapper around two *mut's. That is, literally none of these iterators actually borrows the hashmap. Presumably this is fixable by taking a useless reference somewhere. The other thing I'm seeing is that there's , but the signature for Hashmap's iterator function is . How is this lifetime being elided? Is it doing the same thing as , or is something else happening? CC
Yep, it's eliding !
So there's two bugs here: the iterator doesn't borrow the map, and the references are being yielded as .
Assigning P-backcompat-libs, 1.0
thanks for fixing this! Great job!