jiebi/CodeConvo huggingface dataset:
Change:
rtabort!("thread result panicked on drop"); } // Book-keeping so the scope knows when it's done. <del> if let Some(scope) = self.scope { </del> <ins> if let Some(scope) = &self.scope { </ins> // Now that there will be no more user code running on this thread // that can use 'scope, mark the thread as 'finished'. // It's important we only do this after the `result` has been dropped,

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:
GenericParamKind, HirId, Node, }; use rustc_hir as hir; <ins> use rustc_hir::def::DefKind; </ins> use rustc_hir::def_id::DefId; use rustc_middle::ty::{self, TyCtxt}; use rustc_session::lint;

Discussion:
Compiling the  from failed on nightly due to lifetime error while it works on stable. The code in question looks like this and is in taken from On nightly, this failed with: :
modify labels: +regression-from-stable-to-beta
labels +E-needs-bisection
searched nightlies: from nightly-2022-12-06 to nightly-2022-12-10 regressed nightly: nightly-2022-12-10 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: </details labels -E-needs-bisection
searched nightlies: from nightly-2022-12-09 to nightly-2022-12-27 regressed nightly: nightly-2022-12-10 searched commit range: regressed commit: () <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Sorry, false positive in bisect labels -E-needs-bisection Also raced, sorry :(
You can manually bisect the PRs in that rollup, contains the list of each of their artifacts. I'd start by looking at though.
Yep, it's cc
Possible other examples from beta crater: https://crater- https://crater- https://crater-
Any update on this? I've tested the code on: and it still failed.
AFAICS your bug report has been acknowledged and has an assignee, looks like it's a regression in the beta channel (). The new stable will be out in a few weeks, might be fixed by then.
Thanks, so looks like it's going to take quite some time. I might go ahead and release without waiting for this one.
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
use rustc_middle::ty::query::Providers; use rustc_middle::ty::{self, Instance, Ty, TyCtxt}; use rustc_session::cgu_reuse_tracker::CguReuse; <del> use rustc_session::config::{self, EntryFnType, Lto}; </del> <ins> use rustc_session::config::{self, EntryFnType}; </ins> use rustc_session::Session; use rustc_span::Span; use rustc_symbol_mangling::test as symbol_names_test;

Discussion:
First compile is ok, after I modify some contents. It failed. I've to . Then works.
I don't know how to setup a minimal env to reproduce this. But I'd love to provide any info you needed.
cc Is this maybe related to ? (Although this sounds like the opposite of that, where it is missing the bit code.)
Some digging shows that this is a preexisting bug in rustc: I believe that this is only showing up now because Cargo is only just now passing
I've posted a fix for this at
Change:
} fn visit_enum_def(&mut self, enum_definition: &'ast hir::EnumDef, <del> generics: &'ast hir::Generics, item_id: ast::NodeId) { </del> <ins> generics: &'ast hir::Generics, item_id: ast::NodeId, _: Span) { </ins> self.populate_enum_discriminants(enum_definition); visit::walk_enum_def(self, enum_definition, generics, item_id); }

Discussion:
Namely: + maybe So, if I want to visit, for example, a and report an error, I can't do it and have to visit all its parents instead.
Change:
impl<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>> FunctionCx<'a, 'tcx, Bx> { pub fn codegen_coverage(&self, bx: &mut Bx, coverage: Coverage, scope: SourceScope) { // Determine the instance that coverage data was originally generated for. <del> let scope_data = &self.mir.source_scopes[scope]; let instance = if let Some((inlined_instance, _)) = scope_data.inlined { self.monomorphize(inlined_instance) } else if let Some(inlined_scope) = scope_data.inlined_parent_scope { self.monomorphize(self.mir.source_scopes[inlined_scope].inlined.unwrap().0) </del> <ins> let instance = if let Some(inlined) = scope.inlined_instance(&self.mir.source_scopes) { self.monomorphize(inlined) </ins> } else { self.instance };

Discussion:
This can be seen here: To reproduce:
Last passing run was so this regressed between 2022-06-30 and 2022-07-02.
Minimized a reproducer. : : Execution:
label regression-untriaged
Bisection says searched nightlies: from nightly-2022-06-29 to nightly-2022-07-03 regressed nightly: nightly-2022-07-03 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsSo,
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Unfortunately while this fixes the minimal reproducer, it doesn't fix the full case. Would you prefer I file a new bug, or should this one be re-opened? To reproduce:
It's not very minimized, but slightly better. : : Empty
searched nightlies: from nightly-2022-07-07 to nightly-2022-07-22 regressed nightly: nightly-2022-07-09 searched commits: from to regressed commit:
Interesting, I had assumed based on the matching panic message that it'd have the same regressing commit.
Happy to report that with the latest nightly we're back to green on nightly. Thanks much
Thanks the first fix was enough for Suricata :-)
Thanks so much, pydantic-core has been pinned to but is not back on nightly.
Change:
<ins> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. /* This test checks that nested comments are supported /* This should not fail */ */ pub fn main() { } </ins>

Discussion:
Currently we don't support nested block comments. This allows lexing to be regular, but it widely seen as an inconvenience. Modify the lexer to keep track of comment nesting. Nominating backcompat.
I thought we were going to grow a macro to handle block quotes. Did that ever get implemented?
I don't know what you mean by block quotes.
Accepted for feature-complete
Don't line comments address pretty much all uses of nested block comments?
by block quote, I mean in the style of CPP's to allow for nesting comments. Something like this:
From what I've gathered from the code, there are two implementations of the comment parsing, one of which supports nested comments, so I guess should be fixed before this bug.
That's pretty funny that the pretty printer already supports nested comments. I don't think they necessarily have to be merged to fix this bug, though our lexing is a bit of a mess.
Are you going to tackle this?
If there's no massive refactoring to do, I can try! Expect a PR soon.
The reference manual says "Comments in Rust code follow the general C++ style of line and block-comment forms, with no nesting of block-comment delimiters" ... right after production rules for nested comments.
looks like it was forgotten to be updated, thanks for noticing! (I opened )
Change:
}; let use_softfp = sess.opts.debugging_opts & session::USE_SOFTFP != 0; <ins> // FIXME: #11906: Omitting frame pointers breaks retrieving the value of a parameter. let no_fp_elim = sess.opts.debuginfo; </ins> let tm = sess.targ_cfg.target_strs.target_triple.with_c_str(|T| { sess.opts.target_cpu.with_c_str(|CPU| { sess.opts.target_feature.with_c_str(|Features| {

Discussion:
We currently build C++ code and Rust with frame pointers on, though we don't actually use them for anything (intended for GC). This is overhead that C and C++ don't usually have so it would be nice to turn on elimination.
I think we'll need them for gc, fwiw
on Linux x86_64 we should be using the DWARFv3 Call Frame Information for walking the stack, although I have no idea if we're emitting it correctly right now (likely on OS X and FreeBSD too). We might be, because gdb uses it and seems to work.
We'll leave it off until we have solutions for GC, which will probably end up being platform specific. libunwind should make it easy on linux and freebsd.
Reopening because this caused a regression in , so reverted in
Change:
if line.annotations.len() == 1 { if let Some(ref ann) = line.annotations.get(0) { if let AnnotationType::MultilineStart(depth) = ann.annotation_type { <del> if source_string[0..ann.start_col].trim() == "" { </del> <ins> if source_string.chars() .take(ann.start_col) .all(|c| c.is_whitespace()) { </ins> let style = if ann.is_primary { Style::UnderlinePrimary } else {

Discussion:
has saying that the column info is provided in characters, not in bytes. However, the error emitter doesn't care about that at all and uses these like byte offsets all over the place. This leads to bugs like and . As an example, look how span printing varies with varying characters used: Correct case: Now add an emoji character: Note how its off by one char now. This can stack up: If I didn't use any spaces at all, I'd run into . Now this can be fixed by going through the emitter code and looking for all places where the pos is used in a byte position fashion. A much more proper fix instead is to stop trusting that people read comments and encode this via the type system. There is already a mechanism for that inside the compiler, its ! Just convert the types of , members of the and structs to , or maybe to if that's preferred.
cc
Change:
rustc_trait_selection = { path = "../rustc_trait_selection" } rustc_ty_utils = { path = "../rustc_ty_utils" } serde_json = "1.0.59" <del> time = { version = "0.3", default-features = false, features = ["formatting", ] } </del> <ins> time = { version = "0.3", default-features = false, features = ["alloc", "formatting"] } </ins> tracing = { version = "0.1.35" } # tidy-alphabetical-end

Discussion:
While investigating the ICE in , I saw that every attempt at writing the ICE details to a file (first implemented in ) would fail on my Windows machine with error messages of this kind: The timestamp format used for the file name separates time components with colons, and Windows is generally finicky about having colons in file names since it is already employed as the drive unit delimiter. Could there be a change in the file name format for better compatibility, at least when running rustc on a Windows host? : </p</details
cc
Yes, we can change the format.
Change:
self.step.set(self.step.get() + 1); } <del> /// Returns `true` if quadratic backoff has completed and parking the thread is advised. #[inline] pub fn is_completed(&self) -> bool { self.step.get() > SPIN_LIMIT } </del> }

Discussion:
Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Done in I believe
assign
Change:
<del> //@ known-bug: rust-lang/rust#129850 pub trait Foo2 { fn bar<'a: 'a>(&'a mut self) -> impl Sized + use<'static>; } impl Foo2 for () { fn bar<'a: 'a>(&'a mut self) -> impl Sized + 'a {} } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' File: --auto-reduced (treereduce-rust): original: 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
tcx: TyCtxt<'tcx>, canonicalized: Canonical<'tcx, ParamEnvAnd<'tcx, ProvePredicate<'tcx>>>, ) -> Result<&'tcx Canonical<'tcx, QueryResponse<'tcx, ()>>, NoSolution> { <del> tcx.infer_ctxt().enter_canonical_trait_query(&canonicalized, |infcx, fulfill_cx, key| { type_op_prove_predicate_with_cause(infcx, fulfill_cx, key, ObligationCause::dummy()); Ok(()) }) </del> <ins> // HACK This bubble is required for this test to pass: // impl-trait/issue-99642.rs tcx.infer_ctxt().with_opaque_type_inference(DefiningAnchor::Bubble).enter_canonical_trait_query( &canonicalized, |infcx, fulfill_cx, key| { type_op_prove_predicate_with_cause(infcx, fulfill_cx, key, ObligationCause::dummy()); Ok(()) }, ) </ins> } /// The core of the `type_op_prove_predicate` query: for diagnostics purposes in NLL HRTB errors,

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. -- Regressed between ( 2022-07-17) .. ( 2022-07-21). ~Probably ~. Cc Edit: Regressed in Minimized from . Cc label regression-from-stable-to-nightly A-impl-trait <!-- 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 --
Duplicate of
No wait, huh? That's another issue
This must've been broken before. That revert should not be able to cause a stable to nightly regression
I was wrong, bisection points to . I guess it is . Cc
claim
Change:
span, span, ast::Ident::with_empty_ctxt(Symbol::gensym("decls")), <del> vec![], </del> <ins> vec![doc_hidden], </ins> vec![krate, decls_static], ).map(|mut i| { i.vis = respan(span, ast::VisibilityKind::Public);

Discussion:
crates, when compiled with , generate invalid warnings about missing documentation. The following simple crate demonstrates the error. : : I expect this to compile cleanly since there is a crate-level doc comment and a doc comment for the public function. Instead, compiling gives: which makes no sense since line 1 is a comment. Compiler version - latest stable, but fails on yesterday's nightly (2017-05-14) too: :
cc (tracking issue)
I am hitting the same problem. This issue is preventing for proc-macro crates (I haven't found a work around). That's pretty annoying :-/ Rust 1.24.1.
Same here. Is there a fix for this?
Seems to still be happening.
Fails on stable, beta, and nightly still.
On a proc-macro crate in , I'm getting two warnings: and with no line numbers.
shows that the compiler is inserting a with a . I didn't find the code that does the insertion in a very brief search.
So I guess the low-effort fix here is slapping on that ? EDIT: Looks like the code that generates that is ?
Thanks Turns out my working copy wasn't updated like I thought so searching through it didn't work. PR just submitted.
Change:
//! This pass is overloaded and runs two different lints. //! <del> //! - MISSING_DOC_CODE_EXAMPLES: this looks for public items missing doc-tests //! - PRIVATE_DOC_TESTS: this looks for private items with doc-tests. </del> <ins> //! - MISSING_DOC_CODE_EXAMPLES: this lint is **UNSTABLE** and looks for public items missing doc-tests //! - PRIVATE_DOC_TESTS: this lint is **STABLE** and looks for private items with doc-tests. </ins> use super::{span_of_attrs, Pass}; use crate::clean;

Discussion:
As of , the lint is no longer working. /// let x = 1; /// I expected to see this happen: should issue Instead, this happened: No warnings emitted. This appears to have changed in . I don't see any discussion there about this, so I'm guessing it was unintentional. cc
This was definitely unintentional. I thought I a test for this ...
Hmm, it tests with but not with . Maybe the name_ of the lint wasn't registered?
The issue is . Compiletest runs with RUSTC_BOOTSTRAP set. I don't recall off the top of my head how to force a test to be stable.
Wait now I'm confused. I thought the point of this lint was that it only runs on nightly, because we're not sure if we want to stabilize it. cc
are you sure this used to work?
The lint has been on stable since 1.32. It is documented .
Got it, I mixed it up with . Yeah this is a bug then - the two lints should be treated differently.
Actually it looks like I introduced the opposite bug for - it now runs on beta when it shouldn't.
Assigning as and removing .
Change:
impl<'a> fmt::Debug for ArgsInnerDebug<'a> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.write_str("[")?; let mut first = true; for i in self.args.range.clone() { if !first { f.write_str(", ")?; } first = false; // Here we do allocation which could be avoided. fmt::Debug::fmt(&unsafe { os_string_from_ptr(*self.args.cur.offset(i)) }, f)?; } f.write_str("]")?; Ok(()) </del> <ins> self.args.parsed_args_list.as_slice().fmt(f) </ins> } }

Discussion:
An showed that removing the dependency from LLVM speed up its test suite by a huge amount. For us libstd doesn't depend on directly but it does depend on which depends on (according to the blog post). Specificaly it looks like , the same function as LLVM, is used by us! It'd be great to investigate removing the shell32 dependency from libstd (may be a few other functions here and there). We should run some tests on Windows to see if this improves rustc cycle times!
Based on my limited investigation, it's likely that replacing with a pure Rust equivalent should be good enough to get rid of the gdi32 dependency in things that only use libstd. So really someone just needs to write that pure Rust implementation which should be easy to do.
It would be nice to get rid of this in the compiler too. We spawn a lot of compiler instances during bootstrapping.
So now that the change has been implemented, have we actually investigated how much of an impact the change made?
Perf, an lolbench are both linux only. So nether help with this question. So don't waste your time like I did.
Here are just number for on 8 cores / 16 threads on Windows 10 v1809: Without the dependency: 333.012 325.587 320.650 With : 310.852 319.165 323.645
For what it's worth, though there's no good way to differentiate PR-to-PR due to very high variance, it does look like there was a recent regression in PR build times: <img width="1409" alt="image" src="https://user-"
I see that the CPU usage averages about 40% when running , so maybe we'd see some real improvements if we got rid of in the compiler too. Something is certainly holding things back.
Yeah, I saw that the compiler doesn't load . So there's probably some other reason why doesn't load all the cores.
Change:
<ins> // check-pass #![feature(generic_associated_types)] trait Foo<T> { type Type<'a> where T: 'a; } impl<T> Foo<T> for () { type Type<'a> where T: 'a, = (); } fn foo<T>() { let _: for<'a> fn(<() as Foo<T>>::Type<'a>, &'a T) = |_, _| (); } pub fn main() {} </ins>

Discussion:
() <details<summaryBacktrace (click to expand)</summary` </details label requires-nightly, F-genericassociatedtypes, A-traits, A-lifetimes, A-associated_items, A-typesystem, T-compiler I'm not whether I'd expect this code to fail or to compile successfully (though I might be leaning towards expecting the latter).
No longer ICEs since
GATs issue triage: not blocking. Fixed and needs test.

Source: It is worth noting that this code should not compile. This bug occurs in both beta and nightly. : <details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since
Change:
.chain(std::iter::repeat(" yada").take(100)) .collect::<String>(); <ins> fn set_thread_name(name: &CStr) -> i32 { #[cfg(target_os = "linux")] return unsafe { libc::pthread_setname_np(libc::pthread_self(), name.as_ptr().cast()) }; #[cfg(target_os = "macos")] return unsafe { libc::pthread_setname_np(name.as_ptr().cast()) }; } </ins> let result = thread::Builder::new().name(long_name.clone()).spawn(move || { // Rust remembers the full thread name itself. assert_eq!(thread::current().name(), Some(long_name.as_str()));

Discussion:
Specifically, this manifested with indexing into a dvec. Not all of the code that was manipulating s was handling the case. Already fixed it, about to check in a fix. Thanks to for the test case.

It's currently ignored on Windows.
The code in question looks like: When I commented-out the ignore and a then this test passed on my Windows machine (Mingw32 + 64 bit Windows 7). So perhaps this particular issue is no more?
Fixed in

A comment suggests the type should be something richer, perhaps, than just .
Blocked on or something similar
Definitely not backwards incompatible for 1.0 if this depends on Rust 2.0 features. Renominating.
Nominating for "far-future" (does that require nomination?)
FIXME is gone, bug is too vague, closing

as per a FIXME.
Ok, so, the strings "globalenv" and "getglobalenvchan" don't appear in the source anymore, so I'm going to close this bug...
Change:
</a> </span> </span> <del> <span class="in-band">List of all items</span> </del> </h1>", ); // Note: print_entries does not escape the title, because we know the current set of titles

Discussion:
As can be seen when going to , the "List of all items" page generated by rustdoc has a header saying "List of all items List of all items": ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Mentoring instructions: remove this line:
I think this regressed in cc do you have time to take a look?
How did that happen... Whoops, I'll fix asap As an aside, that bug should've been "List of List of all items" for a bit of wikipedia-plagiarism. claim