jiebi/CodeConvo huggingface dataset:
Change:
Some(mul_div_u64(nanos, info.denom as u64, info.numer as u64)) } <del> fn info() -> &'static libc::mach_timebase_info { </del> <ins> fn info() -> libc::mach_timebase_info { </ins> static mut INFO: libc::mach_timebase_info = libc::mach_timebase_info { numer: 0, denom: 0, }; <del> static ONCE: Once = Once::new(); </del> <ins> static STATE: AtomicUsize = AtomicUsize::new(0); </ins> unsafe { <del> ONCE.call_once(|| { libc::mach_timebase_info(&mut INFO); }); &INFO </del> <ins> // If a previous thread has filled in this global state, use that. if STATE.load(SeqCst) == 2 { return INFO; } // ... otherwise learn for ourselves ... let mut info = mem::zeroed(); libc::mach_timebase_info(&mut info); // ... and attempt to be the one thread that stores it globally for // all other threads if STATE.compare_exchange(0, 1, SeqCst, SeqCst).is_ok() { INFO = info; STATE.store(2, SeqCst); } return info; </ins> } } }

Discussion:
I was trying to troubleshoot this issue: and eventually we figured out that on my machine parktimeout wasn't waking up. I wrote this simple test code which demonstrates the issue: Most of the time it will only print this: Every once in a while it will finish normally. This behavior happens on stable and nightly and I tried a handfull of stable versions all the way back to 1.12 and they all got stuck. Windows (both msvc and gnu appear to never get stuck (at least I couldn't reproduce the issue)). I was able to duplicate this an another mac as well (both running 10.14) If only a single thread is started (or the park happens on the main thread) then I can't reproduce. I'm on 10.14; uname:
This definitely seems broken. Here's dtruss output:
It's a deadlock on the ONCE here:
As a workaround, everything should work fine as long as you construct an at least once in your process before parking.
Doesn't seem to help :(
Oh right sorry, you actually have to subtract two Instants to force that Once to complete. If you instead do at the start of main, it prevents the deadlock.
Works perfectly now! Thanks!
Change:
/// creates and returns the associated items that correspond to each impl trait in return position /// of the implemented trait. query associated_types_for_impl_traits_in_associated_fn(fn_def_id: DefId) -> &'tcx [DefId] { <del> desc { |tcx| "creating associated items for impl trait in trait returned by `{}`", tcx.def_path_str(fn_def_id) } </del> <ins> desc { |tcx| "creating associated items for opaque types returned by `{}`", tcx.def_path_str(fn_def_id) } </ins> cache_on_disk_if { fn_def_id.is_local() } separate_provide_extern }

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
// emitting should be enabled. debuginfo::start_emitting_source_locations(&fcx); <ins> let dest = match fcx.llretptr.get() { Some(e) => {expr::SaveIn(e)} None => { assert!(type_is_zero_size(bcx.ccx(), block_ty)) expr::Ignore } }; </ins> // This call to trans_block is the place where we bridge between // translation calls that don't have a return value (trans_crate, // trans_mod, trans_item, et cetera) and those that do // (trans_block, trans_expr, et cetera). <del> if body.expr.is_none() || type_is_zero_size(bcx.ccx(), block_ty) { bcx = controlflow::trans_block(bcx, body, expr::Ignore); } else { let dest = expr::SaveIn(fcx.llretptr.get().unwrap()); bcx = controlflow::trans_block(bcx, body, dest); } </del> <ins> bcx = controlflow::trans_block(bcx, body, dest); </ins> match fcx.llreturn.get() { Some(_) => {

Discussion:
Was trying to find another bug, found this bug! That code will fail with
I'll take it
Different testcases: EDIT: Found more testcases
Interesting. I'm looking into it. Not sure what is causing this, though.
Another testcase: (The and are both necessary.)
Even simpler example: Debug Log EDIT: Making the block return doesn't raise this issue.
My final testcase:
Could this be related to the no-argument version of lambda block expressions that were used in syntax? Looking in , there's a comment to this form of lambda expressions used with . As far as why doesn't raise the issue, maybe that's parsed as a block expression instead?
I don't see how it could be related. The error here has to do with a (or just zero-sized? I'm not sure) result of a block being stored somewhere. I'm not even sure the assert needs to be that strict.
Yet another test case to consider:
thanks! I'll get back to debug this in a bit
Change:
} } } <del> _ => PatternKind::Wild </del> <ins> ref pats => { self.tcx.sess.delay_span_bug( pat.span, &format!("found bad range pattern `{:?}` outside of error recovery", pats), ); PatternKind::Wild } </ins> } }

Discussion:
This code demonstrates the problem (): With stable-1.32.0 it prints . With beta-1.33.0 it wrongly prints . Beta also produces these wrong warnings: It seems that Rustc decides, that the first arm covers the whole range of a and optimizes out the other arms before they even reach MIR. The code is very similar to this . But the testcase does not test that the other arms can be reached. I was able to bisect the regression to . (This issue seems similar to , but the reduced testcase there does not use any associated consts)
Not the same as
triage: P-high, A-NLL, NLL-complete, assigning to self.
cc
I have confirmed that the bug appears to be specifically injected by commit (I've skimmed over that commit several times and still can't see the problem, but I'm going to try again now. Maybe the actual issue is that we are miscompiling downstream, but that pattern is not sufficiently exercised elsewhere in the compiler today...)
Well this is making my spidey-sense tingle: but even when that returns false, it seems like that would only imply that we fall through to presumably more general purpose code here: (still looking. Going to add a bit of instrumentation to these parts of the compiler.)
I don't mean to step on any toes, but I looked into this a little as an earlier PR of mine introduced it. I've got a fix up at but if that's not the approach we want to take then I can leave this to you.
Change:
/// Capture a [closure]'s environment by value. /// /// `move` converts any variables captured by reference or mutable reference <del> /// to owned by value variables. The three [`Fn` trait]'s mirror the ways to capture /// variables, when `move` is used, the closures is represented by the `FnOnce` trait. </del> <ins> /// to owned by value variables. </ins> /// /// ```rust /// let capture = "hello";

Discussion:
states: The second half of the second sentence is plain wrong and . modify labels: T-doc, T-libs, C-enhancement. (Is tagging T-doc ?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Yes, it allows for easy searching of doc issue (at least for me), with .
Change:
<ins> // check-pass pub struct VecNumber<'s> { pub vec_number: Vec<Number<'s>>, pub auxiliary_object: &'s Vec<usize>, } pub struct Number<'s> { pub number: &'s usize, } impl<'s> VecNumber<'s> { pub fn vec_number_iterable_per_item_in_auxiliary_object( &self, ) -> impl Iterator<Item = (&'s usize, impl Iterator<Item = &Number<'s>>)> { self.auxiliary_object.iter().map(move |n| { let iter_number = self.vec_number.iter(); (n, iter_number) }) } } fn main() {} </ins>

Discussion:
This is an attempt to reproduce a minimal example of a regression problem (backwards compatibility not assured) from a closed-source company codebase. I tried this code: - I expected to see the code building (This code is old and was building for years on rust 1.54, and builds on rust 1.63. the code works as intended in the proprietary codebase) Instead, this happened: It most recently worked on: 1.63 (from my repo, commit : ) It does not work anymore on version 1.64: (from my repo, commit : ) Including the backtrace by setting does not change anything to the error message. I do not know why this problem occured though. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-01 regressed nightly: nightly-2022-08-11 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: </detailsOut of the rollup, this was probably caused by ?
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reopening to track backports.
can this be closed? was backported to stable, right? cc (unsure who to ping)
I have no involvement with this whatsoever.^^ is usually doing backports.
was beta backported to 1.65, which is now released. We won't be having a 1.64.1 release. So this should be considered "fixed", since it is resolved on the current stable release of Rust.
Change:
use rustc_middle::dep_graph::WorkProduct; use rustc_middle::middle::dependency_format::Dependencies; use rustc_middle::ty::query::{ExternProviders, Providers}; <ins> use rustc_serialize::{opaque, Decodable, Decoder, Encoder}; </ins> use rustc_session::config::{CrateType, OutputFilenames, OutputType, RUST_CGU_EXT}; use rustc_session::cstore::{self, CrateSource}; use rustc_session::utils::NativeLibKind;

Discussion:
This allows giving a better error when attempting to use the original source file with -Zlink-only rather than crashing and allows rejecting rlink files produced by a different rustc version.
To clarify: here's what I thought you had to do: But that gives an inscrutable error like this: The correct way to invoke is actually this If the file has a header, the code that reads it can check for that header. If it's not present (e.g. because somebody passed a file by mistake) then it can give a nice error message like "this doesn't look like a .rlink file".
I tried to look at this. is a struct that is serialized to files using the machinery. I tried to create a wrapper struct that would serialize and deserialize a header to provide nicer messages, but it's not really easy to provide a custom message if decoding of the header fails currently, since you removed the s from methods :sweat_smile: I see several solutions to this: 1) Catch panic that could be caused by invalid decoding of the header and provide a nicer message in that case (seems dubious). 2) Implement serialization and deserialization of the header using manual byte writes/reads, going around the traits. 3) Return sto methods (probably not worth it because of this). What do you suggest, solution 2)?
The crate metadata encodes and decodes the header separately from the contents. For crate metadata the header is of the form "rust" + 32bit be version number (currently 5 I believe) + 32bit offset of the crate root + rustc version string. During decoding the header is checked for "rust", the right version number and then the right rustc version. Only after that is a created to decode the contents. The rlink header could work the same way except omitting the offset of the crate root and using say "rsld" (rust ld) or "rustlink" as start instead of "rust" like the crate metadata.
Thanks for the hint. I checked rmeta decoding and it basically decodes the magic header byte slice with , which should be easy, but then it uses for decoding the rustc version, which will panic if the version is missing. So with this approach we could have a nice error if header magic is missing, nice error if rust version is wrong, but weird error if rust version if missing.

That is basically the same that we get for parsing, so I suppose that's ok?
Yeah, the header magic is supposed to be changed every time the rustc version needs to be decoded in a different way. IMO it is ok.
Change:
Next, } <del> impl Default for Polonius { fn default() -> Self { Polonius::Off } } </del> impl Polonius { /// Returns whether the legacy version of polonius is enabled pub fn is_legacy_enabled(&self) -> bool {

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
<ins> // 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. fn main() { const _C: &'static Fn() = &||{}; } </ins>

Discussion:
Doesn't seem to ICE as of rustc 1.4.0-beta.3 ( 2015-10-16)
Yes, it's fixed, and there's a testcase in the tree; I just forgot to close it.
Change:
deadline: u64, } <del> unsafe impl Send for TcpAcceptor {} unsafe impl Sync for TcpAcceptor {} </del> struct AcceptorInner { listener: TcpListener, abort: Event,

Discussion:
There are quite few os-specific types definitions whose traits implementations are not consistent. With the work happening in OIBIT, I've tried to keep the implementations of built-in traits consistent for both and . Unfortunately, the test suite for these implementations is not unified, therefore there's a high chance that some types for 's implementation may have some traits implemented, whereas the 's implementation doesn't. In theory, we can assume that common types for these implementations should implement the same built-in types, therefore there should be tests that enforce this guarantee in a common place. Some examples may be found in This bug is to track the work there which impacts the of our standard library.
I can mentor on this bug, tagging with
seems interesting. Can i take this bug? :)
it's all yours, lemme know if you need help/reviews
This should be closed now right?
correct. Thanks!
Change:
--> $DIR/complex-unord-param.rs:8:41 | LL | struct NestedArrays<'a, const N: usize, A: 'a, const M: usize, T:'a =u32> { <del> |                    ---------------------^----------------------^--------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, A: 'a, T: 'a, const N: usize, const M: usize>` </del> <ins> |                    ---------------------^----------------------^--------- help: reorder the parameters: lifetimes, then types, then consts: `<'a, A: 'a, T: 'a = u32, const N: usize, const M: usize>` </ins> error: aborting due to previous error

Discussion:
results in: when it should be: This should be easy to fix: just replace in the following line with an appropriate format string. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
For the record, it's not quite this simple, as doing so results in incorrect output when the parameter also has bounds. For example, it would render as because bounds are printed after the
Change:
return; } <ins> let unused_macro = self.unused_macros.iter().find_map(|(def_id, (_, unused_ident))| { if unused_ident.name == ident.name { Some((def_id.clone(), unused_ident.clone())) } else { None } }); if let Some((def_id, unused_ident)) = unused_macro { let scope = self.local_macro_def_scopes[&def_id]; let parent_nearest = parent_scope.module.nearest_parent_mod(); if Some(parent_nearest) == scope.opt_def_id() { err.subdiagnostic(self.dcx(), MacroDefinedLater { span: unused_ident.span }); err.subdiagnostic(self.dcx(), MacroSuggMovePosition { span: ident.span, ident }); return; } } </ins> if self.macro_names.contains(&ident.normalize_to_macros_2_0()) { err.subdiagnostic(self.dcx(), AddedMacroUse); return;

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
<ins> // Test variance computation doesn't explode when we leak unnameable // types due to `-> _` recovery. pub struct Type<'a>(&'a ()); pub fn g() {} pub fn f<T>() -> _ { //~^ ERROR the placeholder `_` is not allowed within types on item signatures g } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' 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: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim
Change:
<ins> // 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. pub trait Subscriber { type Input; } pub trait Processor: Subscriber<Input = Self::Input> { //~^ ERROR unsupported cyclic reference between types/traits detected [E0391] type Input; } fn main() {} </ins>

Discussion:
Example (reduced by from something reported on IRC):
Is that allowed syntax? As RFC 195 states . I tried to express something like but thought I have to wait until where clauses on associated type definitions land.
Nevermind, got it. Only is not in scope for the trait header, but is a path to it, so it is valid syntax. Keep up your excellent work :)
The code snippet above now causes the following error: Changing the trait to: yields
I'd like to nominate this, I don't think we can remove oldimplcheck without it.
This currently reports . The cycle can be broken by explicit UFCS notation:
Change:
assert!(p.is_ok()); } <ins> #[test] #[cfg(not(windows))] #[cfg_attr(any(target_os = "emscripten", target_env = "sgx"), ignore)] fn main() { const PIDFD: &'static str = if cfg!(target_os = "linux") { "    create_pidfd: false,n" } else { "" }; let mut command = Command::new("some-boring-name"); assert_eq!(format!("{command:?}"), format!(r#""some-boring-name""#)); assert_eq!( format!("{command:#?}"), format!( r#"Command {{ program: "some-boring-name", args: [ "some-boring-name", ], {PIDFD}}}"# ) ); command.args(&["1", "2", "3"]); assert_eq!(format!("{command:?}"), format!(r#""some-boring-name" "1" "2" "3""#)); assert_eq!( format!("{command:#?}"), format!( r#"Command {{ program: "some-boring-name", args: [ "some-boring-name", "1", "2", "3", ], {PIDFD}}}"# ) ); crate::os::unix::process::CommandExt::arg0(&mut command, "exciting-name"); assert_eq!( format!("{command:?}"), format!(r#"["some-boring-name"] "exciting-name" "1" "2" "3""#) ); assert_eq!( format!("{command:#?}"), format!( r#"Command {{ program: "some-boring-name", args: [ "exciting-name", "1", "2", "3", ], {PIDFD}}}"# ) ); let mut command_with_env_and_cwd = Command::new("boring-name"); command_with_env_and_cwd.current_dir("/some/path").env("FOO", "bar"); assert_eq!( format!("{command_with_env_and_cwd:?}"), r#"cd "/some/path" && FOO="bar" "boring-name""# ); assert_eq!( format!("{command_with_env_and_cwd:#?}"), format!( r#"Command {{ program: "boring-name", args: [ "boring-name", ], env: CommandEnv {{ clear: false, vars: {{ "FOO": Some( "bar", ), }}, }}, cwd: Some( "/some/path", ), {PIDFD}}}"# ) ); } </ins> // See issue #91991 #[test] #[cfg(windows)]

Discussion:
currently only outputs the program and it's arguments. It should also output the environment variables and the current path, as set by , and . This would help with figuring out what's going on :-)
We also currently have no way to extract most of this information without utilizing Debug, so out of tree implementations can't be implemented.
Would/should this be the specific additions to the environment set by , or the actual environment? The most straightforward implementation of this (debug-printing the individual fields of the internal struct) seems to do the latter. That is, this patch (in )— results in program behavior like this (scroll right to see the very bulky output; should be verbose, but how verbose is too verbose??):
I'd be fine with the verbose output. The debug output is only meant for debug purposes and generating the full environment saves us from oh-that's-why-it's-not-working-this-stupid-thing moments
Seems reasonable. I would be ready to consider a PR implementing this.
Triage: no changes here. I've actually wanted this too, but don't have the bandwidth to work on it, personally.
Change:
} } <ins> if let Stability { level: Unstable { .. }, feature } = stab { if ACCEPTED_FEATURES.iter().find(|f| f.name == feature).is_some() { self.tcx .dcx() .emit_err(errors::UnstableAttrForAlreadyStableFeature { span, item_sp }); } } </ins> if let Stability { level: Unstable { implied_by: Some(implied_by), .. }, feature } = stab { self.index.implications.insert(implied_by, feature); } <ins> if let Some(ConstStability { level: Unstable { .. }, feature, .. }) = const_stab { if ACCEPTED_FEATURES.iter().find(|f| f.name == feature).is_some() { self.tcx.dcx().emit_err(errors::UnstableAttrForAlreadyStableFeature { span: const_span.unwrap(), // If const_stab contains Some(..), same is true for const_span item_sp, }); } } </ins> if let Some(ConstStability { level: Unstable { implied_by: Some(implied_by), .. }, feature,

Discussion:
This should probably not be accepted: is already stable, so having an unstable function under this feature makes no sense. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Should we also reject features that don't exist? Right now, this test would fail (because it would compile without problems)
"unstable" attributes is how library features come into existence. So yes we should accept features that do not yet exist.