jiebi/CodeConvo huggingface dataset:
Change:
/// Creates a new empty cell. #[unstable(feature = "once_cell", issue = "74465")] pub const fn new() -> SyncOnceCell<T> { <del> SyncOnceCell { once: Once::new(), value: UnsafeCell::new(MaybeUninit::uninit()) } </del> <ins> SyncOnceCell { once: Once::new(), value: UnsafeCell::new(MaybeUninit::uninit()), _marker: PhantomData, } </ins> } /// Gets the reference to the underlying value.

Discussion:
to in the implementation of . This is correct for simple types like , but when 's implementation accesses borrowed data, this might lead to accessing already dropped data:
and also use in their impl. But I can't reproduce this problem with either of those instead of . Not sure why only seems to have this problem. Edit: Probably because contains in a , which doesn't implement . Adding a should fix that. (Testing that now.)
I think the problem is that puts no lifetime constraint on , so you can write any arbitrarily short-lived to the cell. It would have to at least outlive the reference.
Cc likely this affects upstream once_cell as well?
That's also the case for a Vec: This compiles fine. (As it should.) Replacing with from above here does give an error though, like it should. Looks like dropck does understand that 's is going to drop s. Looks like is what made that work properly for Vec and Box:
Oh, yeah, you're right
Doesn't look like it: the crate uses instead of :
Change:
#[stable(feature = "rust1", since = "1.0.0")] pub struct File { inner: fs_imp::File, <del> path: Option<PathBuf>, </del> } /// Metadata information about a file.

Discussion:
takes a object as reference, although it only clones it afterwards. It's also impossible to re-use the allocation for the file path, because it's only dropped at the end.
It is pretty hard to not involve allocations because Rust-native strings will have to be converted into null terminated one to pass into the native API at some point anyway.
That's true.. Maybe we can avoid the double-allocation?
The path is cloned only so that it can later be used in error messages, which is a somewhat debatable use case. We could resolve this in the future by taking an bound (if we had a trait like that). cc
In that case it would probably be better to just take a PathBuf. But does it really justify an extra allocation just to provide error messages?
That would be a lot less ergonomic -- I want to be able to feed in a string literal with no extra steps. Probably not, hence why I said it was a "somewhat debatable use case." :)
What about a variable-length stack allocation?
allocating on stack comes with its own downsides. Also, it doesn’t guarantee a trailing null byte either, AFAIK?
If you had a stack allocation, you could just append a null byte.
As tbu- said. And the downsides of are nothing compared to linking in 195kB of jemalloc (the absolute minimum jemalloc size on OS X x86_64 with LTO).
Change:
optional namespacing), a dereference, an indexing expression or a field reference. <del> More details can be found here: https://doc.rust-lang.org/reference.html#lvalues-rvalues-and-temporaries </del> <ins> More details can be found in the [Expressions] section of the Reference. [Expressions]: https://doc.rust-lang.org/reference/expressions.html#lvalues-rvalues-and-temporaries </ins> Now, we can go further. Here are some erroneous code examples:

Discussion:
The fix is shown in , but I couldn't complete it because the line length linter doesn't like the long lines and didn't have enough time to adjust the tidy checker
Change:
use rustc_hir::{GeneratorKind, HirIdMap, Node}; use rustc_index::vec::{Idx, IndexVec}; use rustc_infer::infer::TyCtxtInferExt; <ins> use rustc_middle::middle::codegen_fn_attrs::CodegenFnAttrFlags; </ins> use rustc_middle::middle::region; use rustc_middle::mir::*; use rustc_middle::ty::subst::Subst;

Discussion:
When compiling () The generated assembly includes a prologue with unexpected 's (as well as a trailing , already reported in ) Expected behaviour would be to have no prologue (and prevent compilation of a function that is not as this would require implementing an undefined ABI, contrarily to what seems to happen ). This is treacherous, as it dereferences some memory locations that may not be accessible, as happened to me and led to hours of debugging to finally figure out the compiled function was not the one defined. cc
IIRC this is invalid and rustc should reject such a function, naked functions can't take arguments and the compiler should probably enforce that.
Hmm, my understanding of the RFC (“The following variant is not an error because the C calling convention is well-defined and it is thus possible for the programmer to write a conforming function”, even if the example is not with an argument) would mean that if the function is declared , then the function can actually respect the said ABI, thus should be well-formed?
Is there an update on this? I was hit by this issue as well. I hit the problem when compiling a tock app (baremetal-ish and jumped to by the tock OS) A naked function with arguments would produce this prolog (RV32): Which would result in an invalid access as s0 would be 0. Removing the arguments would remove the prologue and fix the problem. Removing the naked cfg would also work as teh stack pointer was already setup by the OS and result in this. If arguments with naked functions aren't supported rustc should generate an error as this is a difficult problem to debug.
This is an LLVM bug. Has it been reported upstream?
Change:
<ins> // run-pass // aux-build:arc_wake.rs // edition:2018 #![feature(async_await)] extern crate arc_wake; use std::pin::Pin; use std::future::Future; use std::sync::{ Arc, atomic::{self, AtomicUsize}, }; use std::task::{Context, Poll}; use arc_wake::ArcWake; struct Counter { wakes: AtomicUsize, } impl ArcWake for Counter { fn wake(self: Arc<Self>) { Self::wake_by_ref(&self) } fn wake_by_ref(arc_self: &Arc<Self>) { arc_self.wakes.fetch_add(1, atomic::Ordering::SeqCst); } } struct WakeOnceThenComplete(bool, u8); impl Future for WakeOnceThenComplete { type Output = u8; fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<u8> { if self.0 { Poll::Ready(self.1) } else { cx.waker().wake_by_ref(); self.0 = true; Poll::Pending } } } fn wait(fut: impl Future<Output = u8>) -> u8 { let mut fut = Box::pin(fut); let counter = Arc::new(Counter { wakes: AtomicUsize::new(0) }); let waker = ArcWake::into_waker(counter.clone()); let mut cx = Context::from_waker(&waker); loop { match fut.as_mut().poll(&mut cx) { Poll::Ready(out) => return out, Poll::Pending => (), } } } fn base() -> WakeOnceThenComplete { WakeOnceThenComplete(false, 1) } async fn await1_level1() -> u8 { base().await } async fn await2_level1() -> u8 { base().await + base().await } async fn await3_level1() -> u8 { base().await + base().await + base().await } async fn await3_level2() -> u8 { await3_level1().await + await3_level1().await + await3_level1().await } async fn await3_level3() -> u8 { await3_level2().await + await3_level2().await + await3_level2().await } async fn await3_level4() -> u8 { await3_level3().await + await3_level3().await + await3_level3().await } async fn await3_level5() -> u8 { await3_level4().await + await3_level4().await + await3_level4().await } fn main() { assert_eq!(2, std::mem::size_of_val(&base())); assert_eq!(8, std::mem::size_of_val(&await1_level1())); assert_eq!(12, std::mem::size_of_val(&await2_level1())); assert_eq!(12, std::mem::size_of_val(&await3_level1())); assert_eq!(20, std::mem::size_of_val(&await3_level2())); assert_eq!(28, std::mem::size_of_val(&await3_level3())); assert_eq!(36, std::mem::size_of_val(&await3_level4())); assert_eq!(44, std::mem::size_of_val(&await3_level5())); assert_eq!(1,   wait(base())); assert_eq!(1,   wait(await1_level1())); assert_eq!(2,   wait(await2_level1())); assert_eq!(3,   wait(await3_level1())); assert_eq!(9,   wait(await3_level2())); assert_eq!(27,  wait(await3_level3())); assert_eq!(81,  wait(await3_level4())); assert_eq!(243, wait(await3_level5())); } </ins>

Discussion:
E.g. in and cc
I'd like to work on this :smile:
You've got it :)
Change:
<del> error[E0271]: type mismatch resolving `<[closure@$DIR/issue-63279.rs:6:5: 6:28] as std::ops::FnOnce<()>>::Output == ()` --> $DIR/issue-63279.rs:3:1 </del> <ins> error[E0271]: type mismatch resolving `<[closure@$DIR/issue-63279.rs:8:5: 8:28] as std::ops::FnOnce<()>>::Output == ()` --> $DIR/issue-63279.rs:5:1 </ins> | LL | type Closure = impl FnOnce(); | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found `()`

Discussion:
When running in the subdirectory, a call to with causes the following ICE: I'm not exactly sure what additional information to provide? I filed an issue with , and was forwarded here since it is an ICE.
I've minimized it a bit: It still uses external crates but the example itself is very small.
compile it with: Although is behind a feature gate it will ICE without the feature gate! modify labels: F-typealiasimpltrait ICE code:
Change:
<ins> error[E0277]: the trait bound `usize: Meow` is not satisfied --> $DIR/issue-99080.rs:10:16 | LL |     needs_meow(1usize); |     ---------- ^^^^^^ the trait `Meow` is not implemented for `usize` |     | |     required by a bound introduced by this call | = help: the following other types implement trait `Meow`: GlobalMeow LocalMeow note: required by a bound in `needs_meow` --> $DIR/issue-99080.rs:7:18 | LL | fn needs_meow<T: Meow>(t: T) {} |                  ^^^^ required by this bound in `needs_meow` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --There are two crates here, and (which depends on ). library: consumer: The current output is (when running on ): <!-- The following is not always necessary. --Ideally the output should look like: We should not be suggesting private types to users, since macro hygiene does mean they can't write This is on the latest nightly, This was ran into in
this only happens with items and not ?
I included examples of and , and it seems to happen for both (see: )
Oh, my bad. I didn't read closely, my eyes just went directly to the macro item. Sorry. :sweat_smile:
For the record, this is not a macro problem. See that does not use macros: /// fn needsmeow<T: playground::Meow(t: T) {} /// fn main() { needsmeow(1usize); } /// (uses a doc comment to emulate two crates on playground) The reason is that  does not do any filtering for type privacy.
Change:
if let Some(g) = g { write!(w, "{}", print_where_clause(g, cx, 0, false),) } <del> w.write_str(";"); </del> <ins> // We only want a ";" when we are displaying a tuple struct, not a variant tuple struct. if structhead { w.write_str(";"); } </ins> } CtorKind::Const => { // Needed for PhantomData.

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
<ins> // Regression test for #93054: Functions using uninhabited types often only have a single, // unreachable basic block which doesn't get instrumented. This should not cause llvm-cov to fail. // Since these kinds functions can't be invoked anyway, it's ok to not have coverage data for them. // compile-flags: --edition=2021 enum Never { } impl Never { fn foo(self) { match self { } make().map(|never| match never { }); } fn bar(&self) { match *self { } } } async fn foo2(never: Never) { match never { } } fn make() -> Option<Never> { None } fn main() { } </ins>

Discussion:
Between nightly versions 2022-01-14 and 2022-01-15, 0.8.2 lost track of 82% of the coverage of when using the LLVM coverage option (). Other projects of mine continue to have code coverage correctly measured. I'm not where to start narrowing this down, as I'm not getting any errors or warnings printed. Here are the steps to get good code coverage reports out of 2022-01-14: If you look at the report in the coverage folder, the html report will show 80% coverage. Now, test with the next nightly: If you look at the report again, the html report now shows < 1% coverage. The quantity of profraw files are the same, and the sizes of the files are more or less equivalent. I'm not quite sure where to start narrowing this down since it's a unique issue to this project of mine -- but the only unique part I'm aware of is its size :sweat_smile:. For now I'll pin our CI to the last working nightly. Thank you in advance for any suggestions or help!
We noticed the same when upgrading rustc in our project from (December) to . Code coverage measured with and inexplicably dropped . Some crates that are clearly running don't show up at all in the reports. suggests that this is probably caused by
^ says is also affected.
cc label +requires-nightly +A-code-coverage
Thanks for the report! I've tried reproducing locally and I'm able to see the same behavior. Running the LLVM tools directly, I see this when trying to process coverage data for the various binaries: which seems to be the same issue as was reported in a comment on . I'm continuing to investigate ...
The minimal repro seems to be I think I'll have a fix for this within the next few days.
Change:
} } <ins> ty::PredicateKind::ConstEvaluatable(data) => { if predicate.references_error() || self.is_tainted_by_errors() { return; } let subst = data.substs.iter().find(|g| g.has_infer_types_or_consts()); if let Some(subst) = subst { let err = self.emit_inference_failure_err( body_id, span, subst, ErrorCode::E0284, true, ); err } else { // If we can't find a substitution, just print a generic error let mut err = struct_span_err!( self.tcx.sess, span, E0284, "type annotations needed: cannot satisfy `{}`", predicate, ); err.span_label(span, &format!("cannot satisfy `{}`", predicate)); err } } </ins> _ => { if self.tcx.sess.has_errors().is_some() || self.is_tainted_by_errors() { return;

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Based on the example in , which after the changes in would output an error. The following code, however, does not output such an error, although I believe it should. Given the following code: <!-- Please provide a link to --The current output is: This only happens if the is included. This also compiles if you don't include the call of in main. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
dont think this is related to adtconstparams as this has the same error:
the reason this happens is because from we don't infer the value for . The error message should be improved by using in this branch for that the predicates should be searched for a relevant inference variable.
going to mentor this issue in case someone wants to fix this
claim
Change:
<ins> diff --git a/include/libunwind.h b/include/libunwind.h index c5b9633..1360eb2 100644 --- a/include/libunwind.h +++ b/include/libunwind.h @@ -151,8 +151,8 @@ enum { UNW_X86_ECX = 1, UNW_X86_EDX = 2, UNW_X86_EBX = 3, -  UNW_X86_EBP = 4, -  UNW_X86_ESP = 5, +  UNW_X86_ESP = 4, +  UNW_X86_EBP = 5, UNW_X86_ESI = 6, UNW_X86_EDI = 7 }; </ins>

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo
Change:
<ins> // Regression test for #69307 // // Having a `async { .. foo.await .. }` block appear inside of a `+=` // expression was causing an ICE due to a failure to save/restore // state in the AST numbering pass when entering a nested body. // // check-pass // edition:2018 fn block_on<F>(_: F) -> usize { 0 } fn main() {} async fn bar() { let mut sum = 0; sum += { block_on(async { baz().await; let mut inner = 1; inner += block_on(async { baz().await; 0 }) }) }; } async fn baz() {} </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. --: Same issue still exists in : and also in : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
T-compiler triage: P-high. Leaving nomination label in place, since I don't want to disrupt WG-async-await workflow.
This does already ICE on 1.39.0
I could further simplify the code as:
However, this code does not cause ICE:
If you can reproduce this without depending on tokio that would be great.
How abot this?
Minimized:
in T-compiler meeting. Keeping as P-high but removing nomination.
OK so I've been investigating this a bit. I am not quite able to write-up mentoring instructions yet because I don't really understand what's going on, but I can leave a few notes. First off, the ICE occurs in the code that is attempting to approximate what values may be live across an . It occurs specifically when you have a structure. The nested async blocks etc are not really needed. For example, this also fails in the same way; The ICE occurs in this match arm: It appears to be related to some logic that is attempting to figure out a "worst case" execution order for instructions: I confess I don't quite follow this logic anymore, but the problem has to do with entering a distinct async block. This code for example does not trigger the failure:
Ah, I think maybe I see the problem here actually -- I suspect the problem is that we need to clear (and then restore) the flag when we recurse into a closure body.
Change:
let s = "foo bar"; <del> assert_eq!("foon        bar", s); </del> <ins> assert_eq!("foon    bar", s); </ins> ``` The second, with a ``, trims the spaces and the newline:

Discussion:
When using multiline string literal in doctest, rustdoc pads spaces after the newline. The doc renders perfectly fine: ! I tried this code: //! Hello world. //! //! # Examples //! //! //! //! fn main() { println!("hello world!"); } I expected to see this happen: The test should pass. Instead, this happened: The test failed. Did you notice it? : : Backtrace (I don't know if it'd be useful, but):
I hit this issue today as well with a similar case
Triaging: This is still happening on
Change:
None, ); // Attach the crate's exported macros to the top-level module: <del> module .macros .extend(krate.exported_macros.iter().map(|def| self.visit_local_macro(def, None))); </del> <ins> module.macros.extend(krate.exported_macros.iter().map(|def| (def, None))); </ins> module.is_crate = true; self.cx.renderinfo.get_mut().exact_paths = self.exact_paths;

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
), // Entry point: <del> ungated!(main, Normal, template!(Word), WarnFollowing), </del> ungated!(start, Normal, template!(Word), WarnFollowing), ungated!(no_start, CrateLevel, template!(Word), WarnFollowing), ungated!(no_main, CrateLevel, template!(Word), WarnFollowing),

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected an error, because the main attribute has never been available on stable, and had apparently been removed in . Instead, the program ran without error, although the attribute has no apparent effect. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked as expected (emitting an error) on Rust 1.52.1: <!-- Provide the version you are using that has the regression. --This stopped being an error in 1.53.0 (in which a warning was still emitted), and continues to be accepted in stable through the current 1.58.1 version (in which the warning has also disappeared).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Change:
let Some(clause) = clause.as_projection_clause() else { return ControlFlow::Continue(()); }; <ins> if clause.projection_def_id() != obligation.predicate.def_id { return ControlFlow::Continue(()); } </ins> let is_match = selcx.infcx.probe(|_| selcx.match_projection_projections(obligation, clause, true));

Discussion:
I have a linear algebra based project () which has a set of Scalar, Vector and Matrix traits that refer to each other via associated traits. On stable (rustc 1.77.1) this builds fine, but on beta (1.78.0) and nightly (1.79.0) the build hangs (). A MRE is: If I look at the compiler log with RUSTCLOG=TRACE I see an endless repitition of text like: Note that if I remove the trait everything builds fine. The bug does not exist in stable: : The bug exists in beta and nightly: : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<phere is some more of the logs: </p</details
IIUC that's from cc (it also only happens with the old solver ofc)
I'm fascinated that this wasn't fixed by . Perhaps there's somewhere else we need to be calling instead of in the solver...
Oh lol, I found the bug.
Change:
// so add an empty section. if file.format() == object::BinaryFormat::Coff { file.add_section(Vec::new(), ".text".into(), object::SectionKind::Text); <ins> // We handle the name decoration of COFF targets in `symbol_export.rs`, so disable the // default mangler in `object` crate. file.set_mangling(object::write::Mangling::None); </ins> } for (sym, kind) in symbols.iter() {

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: It seems like is not working anymore. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --: <!-- Provide the version you are using that has the regression. --: </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Probably another issue with stdcall symbol name mangling uncovered by cc cc
Hmm, seems that we would have to replicate the name decoration scheme in Rust?
claim