jiebi/CodeConvo huggingface dataset:
Code change:
.expect("failed to read src/version"); let version = version.trim(); <del> let bootstrap_out = std::env::current_exe() </del> <ins> let mut bootstrap_out = std::env::current_exe() </ins> .expect("could not determine path to running process") .parent() .unwrap() .to_path_buf(); <ins> // Since bootstrap is hardlink to deps/bootstrap-*, Solaris can sometimes give // path with deps/ which is bad and needs to be avoided. if bootstrap_out.ends_with("deps") { bootstrap_out.pop(); } </ins> if !bootstrap_out.join(exe("rustc", config.build)).exists() && !cfg!(test) { // this restriction can be lifted whenever https://github.com/rust-lang/rfcs/pull/3028 is implemented panic!(

Related discussion:
text: Rust 1.70 build on Solaris sometimes files on some machines: I wonder whether it can do something with: ?!
are you running in parallel? that's not supported on solaris (you made the PR removing the build locking IIRC).
I see it does: . I think I should look once again if it's possible make to use fcntl locking (as it's now in `rustix... You can close the bug. Thank you!
Adding reference to main proble - isn't supported on Solaris due missing syscall).
I'm confused now. I have seen the same error even with (just one ocurance, not two as mentioned above). Also tried to dig closely how locking works and put into some debug prints with process id and lock file name. But later when I was inspecting still running process it didn't have any lock file open. No file descriptor no lock?!
did you clear the cache before running ? if the build directory gets into an inconsistent state we don't recover it automatically. i don't know what's going on with fd-lock, but the file that bootstrap locks is .
Everything is removed before new build...
exactly what command are you running and what is your
If I see it right, lock file is created/opened here: and the file descriptor for the lock file is closed on block exit here: Isn't it mean that locking isn't working even on Linux?
no, it's declared outside the block
Right. Unfortunatelly version 1.70.0 hasn't fix for this (my) regression. And the declaration is still insde the block.
we do not support old versions of rust. the only supported release is the latest stable release.
Isn't version 1.70.0 latest stable version? I'm just curious.
yes, you're right. i'm sorry. i think you should ask someone else for help on this issue. i am having trouble focusing today.
I run: and then: Where on some systems helps to run while on others it breaks it. When I look into the directory where rustc should be present:
i'm not sure why this is looking in . can you verify that exists? i wonder if is a hard-link to and that confuses on solaris.
It does: It's hardling. When I remove the asserion the build passes.
Code change:
.expect("failed to read src/version"); let version = version.trim(); <del> let bootstrap_out = std::env::current_exe() </del> <ins> let mut bootstrap_out = std::env::current_exe() </ins> .expect("could not determine path to running process") .parent() .unwrap() .to_path_buf(); <ins> // Since bootstrap is hardlink to deps/bootstrap-*, Solaris can sometimes give // path with deps/ which is bad and needs to be avoided. if bootstrap_out.ends_with("deps") { bootstrap_out.pop(); } </ins> if !bootstrap_out.join(exe("rustc", config.build)).exists() && !cfg!(test) { // this restriction can be lifted whenever https://github.com/rust-lang/rfcs/pull/3028 is implemented panic!(

Related discussion:
text: It wasn't true. It just didnt' hit the problem when the code was rebuilt. Now I'm trying following: It must execute sometime deps/bootstrap-[hash] instead of just bootstrap.
Code change:
} else { "items from traits can only be used if the trait is implemented and in scope" }); <del> let mut msg = format!( </del> <ins> let message = |action| format!( </ins> "the following {traits_define} an item `{name}`, perhaps you need to {action}  {one_of_them}:", traits_define = if candidates.len() == 1 {

Related discussion:
text: The following example code yields an error: It's unclear from this error message how to proceed - I'm not sure of the syntax, location, or where I should be putting the "GetString" trait bound. It should be shown with a better example or link when this error is presented, as the current message is not sufficient for a resolution to be arrived at.
cc
Fixing in . To fix your code write:
Thanks!
Code change:
<ins> #![crate_type="lib"] fn x<'a>(x: &mut 'a i32){} //~ ERROR lifetime must precede `mut` macro_rules! mac { ($lt:lifetime) => { fn w<$lt>(w: &mut $lt i32) {} //~^ ERROR lifetime must precede `mut` } } mac!('a); // avoid false positives fn y<'a>(y: &mut 'a + Send) { //~^ ERROR expected a path on the left-hand side of `+`, not `&mut 'a` //~| WARNING trait objects without an explicit `dyn` are deprecated //~| ERROR at least one trait is required for an object type let z = y as &mut 'a + Send; //~^ ERROR expected value, found trait `Send` //~| WARNING trait objects without an explicit `dyn` are deprecated } </ins>

Related discussion:
text: Expected result: a diagnostic suggests placing before Actual diagnostic output: <details</details
Output from rustc 1.43 (): The size of the output appears to be a recent regression.
: searched nightlies: from nightly-2020-03-09 to nightly-2020-06-21 regressed nightly: nightly-2020-03-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsLooks like ?
Further testing confirms , specifically  introduced the large number of diagnostics.
Assigning .
Code change:
// Do not ask for a passphrase while manually testing let mut passphrase = String::new(); if should_sign { <del> // `x.py` passes the passphrase via stdin. </del> t!(io::stdin().read_to_string(&mut passphrase)); }

Related discussion:
text: Seems like no nightly was released today. That might be related to Unfortunately I don't think I have access to the logs. Cc
Logs are missing on the server, let me start a manual release...
Well that is odd. You wouldn't know what commit is is using? ( file in the tarball, if I recall correctly.)
Is there a way for me to download the "dist" artifacts for better testing? Right now I am manually grabbing a bunch of files from https://s3-us-west- (and we only get dir listing for alt builds there it seems so I am using those). That's not very convenient at all.
Apparently not all commits are pushed to toolstate ( vs ), for example the latest one () is missing in toolstate .
Reverting the cause in the meantime --
Alternatively we could land which will just skip of the toolstate is not found. That installs a toolchain based on these artifacts, but I don't think it gives me access to the tarballs. FTR, for now I did So we are only committing when the toolstate changed? Ouch. That kills my entire approach :(
It should print the URLs it's downloading though, and you can use to avoid it actually downloading stuff.
Code change:
<ins> error[E0229]: associated type bindings are not allowed here --> $DIR/issue-102335-ty.rs:2:17 | LL |     type A: S<C<i32 = u32> = ()>; |                 ^^^^^^^^^ associated type not allowed here error: aborting due to previous error For more information about this error, try `rustc --explain E0229`. </ins>

Related discussion:
text: I expect the following code to be rejected by the compiler but it is actually accepted and compiles successfully: The associated constant does not have any generic parameters / associated items (constants cannot have those anyways in the current version of Rust) and thus the argument list should be flagged as erroneous. Interestingly, if you remove the , the compiler correctly identifies this as an error: . I think is to be interpreted as a nested equality constraint (and not as a “defaulted” parameter, i.e. a parameter with a default value). : label T-compiler requires-nightly (it now does) Hence, I am just going to mention its tracking issue: . CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Doesn't need assoc const equality: Let me take a quick stab at this. claim
On a related note, a slightly modified version of the code above leads to an ICE (I was about to create a separate issue for this, should I still do that?): <details<summarystderr (diagnostics & backtrace)</summary</detailsThis only leads to an ICE on the current nightly (2022-09-27) (e.g. on the playground) but not on older ones like (2022-09-21).
If you want to bisect it feel free, but I think fixing the original issue in this report will also fix this one.
Yeah, I think so, too. I guess I won't bisect this.
This regressed in the last day
Oh wait, I caused it: searched nightlies: from nightly-2022-08-01 to nightly-2022-09-26 regressed nightly: nightly-2022-09-26 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Code change:
) - visited elif item["kind"] == "variant": if item["inner"]["variant_kind"] == "tuple": <del> for ty in item["inner"]["variant_inner"]: check_type(ty) </del> <ins> for field_id in filter(None, item["inner"]["variant_inner"]): work_list.add(field_id) </ins> elif item["inner"]["variant_kind"] == "struct": <del> work_list |= set(item["inner"]["variant_inner"]) - visited </del> <ins> work_list |= set(item["inner"]["variant_inner"]["fields"]) - visited </ins> elif item["kind"] in ("function", "method"): check_generics(item["inner"]["generics"]) check_decl(item["inner"]["decl"])

Related discussion:
text: At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:
Code change:
// If this is due to a block, then maybe we forgot a `return`/`break`. if due_to_block && let Some(expr) = expression <del> && let Some((parent_fn_decl, parent_id)) = fcx .tcx .hir() .parent_iter(block_or_return_id) .find_map(|(_, node)| Some((node.fn_decl()?, node.associated_body()?.0))) </del> <ins> && let Some(parent_fn_decl) = fcx.tcx.hir().fn_decl_by_hir_id(fcx.tcx.local_def_id_to_hir_id(fcx.body_id)) </ins> { fcx.suggest_missing_break_or_return_expr( &mut err,

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)', 'error: internal compiler error: node HirId(DefId(0:7 ~ ice[9097]::readfield2).4) (type ) cannot be placed in TypeckResults with hirowner DefId(0:8 ~ ice[9097]::readfield2::FIELD2)' 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: [typeck] type-checking [checkwellformed] checking that is well-formed --
fyi
Code change:
tcx.sess.span_err(span, "`..` cannot be used in union patterns"); } } else if !etc { <del> let unmentioned_fields = variant.fields .iter() .map(|field| field.ident.modern()) .filter(|ident| !used_fields.contains_key(&ident)) .collect::<Vec<_>>(); </del> if unmentioned_fields.len() > 0 { let field_names = if unmentioned_fields.len() == 1 { format!("field `{}`", unmentioned_fields[0])

Related discussion:
text: With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .
Code change:
struct $crate {} //~ ERROR expected identifier, found reserved identifier `$crate` } <del> use $crate; // OK //~^ WARN `$crate` may not be imported </del> <ins> use $crate; //~ ERROR `$crate` may not be imported </ins> use $crate as $crate; //~ ERROR expected identifier, found reserved identifier `$crate` <del> //~^ WARN `$crate` may not be imported </del> <ins> //~^ ERROR `$crate` may not be imported </ins> } }

Related discussion:
text: The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.
Code change:
if let Some(ty) = crate::types::repr_nullable_ptr(cx, adt, ckind) { ty == primitive } else { <del> compare_layouts(a, b) </del> <ins> compare_layouts(a, b).unwrap_or(false) </ins> } } // Otherwise, just compare the layouts. This may fail to lint for some // incompatible types, but at the very least, will stop reads into // uninitialised memory. <del> _ => compare_layouts(a, b), </del> <ins> _ => compare_layouts(a, b).unwrap_or(false), </ins> } }) }

Related discussion:
text: <!-- 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 --
cc for ClashingExternDeclarations in backtrace.
claim
Thank you for fixing it! There is nothing better than software with only a few open issues.
Not a problem! Thank you for the report, and especially for taking the time to make a minimal example :)
Code change:
} pub enum timezone {} <ins> pub type sighandler_t = size_t; </ins> } pub mod bsd44 { use libc::types::os::arch::c95::{c_char, c_int, c_uint};

Related discussion:
text: Scripts to reproduce Steps to reproduce: Output:  Backtrace: None Exit code: 141 Version:
What are you expecting to happen? When you send a TERM signal to a process without a registered handler, it terminates promptly. The runtime currently doesn't register any TERM/INT handlers, that's up to you.
I was expecting the runtime to return some upon requesting an action from a defunct process. I also tried polling the state of the defunct process using (as mentioned in the ), but this returned as well. Even if the runtime dosn't "catch" the SIG{TERM,INT}, is it not possible at all to or return in any of the two cases mentioned above?
Oh whoops, sorry! I had my understanding backwards, and apparently this isn't a bug on OSX which caused more confusion for me. Anyway, closing as a dupe of , it's the same cause.
Oh wow, I've done it again. I'm sorry, again! I apologize for not investigating more thoroughly. This is indeed separate from
Code change:
UniqueBorrow, /// AddressOf for *const pointer. AddressOf, <ins> /// PlaceMention statement. /// /// This statement is executed as a check that the `Place` is live without reading from it, /// so it must be considered as a non-mutating use. PlaceMention, </ins> /// Used as base for another place, e.g., `x` in `x.y`. Will not mutate the place. /// For example, the projection `x.y` is not marked as a mutation in these cases: /// ```ignore (illustrative)

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: You need edition 2015 or 2018 to reproduce this. `
Looks to me like the problem is that doesn't realize that a makes the place not dead.
The bug is . is a nonuse, but should get the same treatment as a . I feel obligated to mention that I have repeatedly warned that these bugs are going to happen. We should really stop using in optimizations. It was written for borrowck. (To be clear: I am as much at fault for this as anyone, I originally wrote this code).
I was wondering why always has strangely unhelpful information for optimizations...
Why is this not just a bug in PlaceContext assignment?
See my comment in the PR - in general, my understanding is that the definition of placecontext is what it is because that's what makes sense in some other part of the compiler. If we start changing placecontext now to have the information that's useful to optimizations, I worry we'll just end up making those parts of the compiler buggy
Code change:
# Explicitly disabling ICE dump export RUSTC_ICE=0 $RUSTC src/lib.rs -Z treat-err-as-bug=1 1>$TMPDIR/rust-test-disabled.log 2>&1 <del> should_be_empty_tmp=$(ls -l $TMPDIR/rustc-ice-*.txt | wc -l) should_be_empty_dot=$(ls -l ./rustc-ice-*.txt | wc -l) </del> <ins> should_be_empty_tmp=$(ls -l $TMPDIR/rustc-ice-*.txt 2>/dev/null | wc -l) should_be_empty_dot=$(ls -l ./rustc-ice-*.txt 2>/dev/null | wc -l) </ins> echo "#### ICE Dump content:" echo $content

Related discussion:
text: slightly increased default binary size (checked on x8664-pc-windows-msvc), the reason is now code unconditionally includes File::open (~ 2kb out of 130) and friends. can be tracked back by new imports of , for where is Originally posted by in
cc
cc -- I'm surprised that didn't include any libs review in the first place, having modified the default panic hook. Maybe ought to be registering its own panic hook instead?
Size changed back to 123kb.
Code change:
/// If you need a [`&str`] instead of a `String`, consider /// [`str::from_utf8`]. /// <del> /// The inverse of this method is [`as_bytes`]. </del> <ins> /// The inverse of this method is [`into_bytes`]. </ins> /// /// # Errors ///

Related discussion:
text: This chunk was supposedly copy-pasted as is from It should read A String ([]) is made of bytes
Hi there. Can I pick this up as first-timer task?
Code change:
<ins> //@ run-rustfix #![allow(unused_mut)] use std::borrow::{Borrow, BorrowMut}; use std::convert::{AsMut, AsRef}; struct Bar; impl AsRef<Bar> for Bar { fn as_ref(&self) -> &Bar { self } } impl AsMut<Bar> for Bar { fn as_mut(&mut self) -> &mut Bar { self } } fn foo<T: AsRef<Bar>>(_: T) {} fn qux<T: AsMut<Bar>>(_: T) {} fn bat<T: Borrow<T>>(_: T) {} fn baz<T: BorrowMut<T>>(_: T) {} pub fn main() { let bar = Bar; foo(&bar); let _baa = bar; //~ ERROR use of moved value let mut bar = Bar; qux(&mut bar); let _baa = bar; //~ ERROR use of moved value let bar = Bar; bat(&bar); let _baa = bar; //~ ERROR use of moved value let mut bar = Bar; baz(&mut bar); let _baa = bar; //~ ERROR use of moved value } </ins>

Related discussion:
text: ... and trying to use afterwards, which triggers Example: currently yields I suggest that it should also contain
AsRef is a library trait, so IMO we should not do that. Also to me "value moved here" is pretty much the "you need to use this as reference".
While this might be obvious to us, I've had students struggling strongly with these errors. When I tell them "just add an ampersand", they're like "Oh, that makes total sense". I don't see that as reason not to do it. Could you elaborate?
This should also handle , , .
and aren't as clear, since the object will be modified, so the user might also want to , but that can later be signalled through and/or multiple suggestions
Obvious way of doing this would involve making a language item or otherwise special in some other way. To me it is pretty clear that language and the standard library should be as independent as possible and IME a diagnostic is a pretty minor gain for the special casing involved. One could imagine a similar diagnostic independent of library traits (e.g. always suggest a reference for "value moved here" if there’s a trait implementation for also), but then the problem of suggestion not being always correct kicks in. So, I will not oppose a change that implements this without making any more of the libstd/libcore special and is always correct, but I have no idea how anybody even begin approaching this problem.
I fully agree that that is not desirable In clippy we have similar diagnostics which in this case would simply check for (see for all the paths that we resolve manually).
Triage: this still produces the same error message. Given the concerns voiced above, should this issue stay open? I suppose we could leave this open should someone come up with a clever way to handle this without special casing , but that seems unlikely.
We have diagnostic items nowadays, so we can make a diagnostic item and detect in in these situations. Though I'm not sure how easy it is to detect. The error may get reported far too late
Current :
Code change:
use foo::bar; foo::bar(); //~ ERROR: unnecessary qualification bar(); <ins> let _ = || -> Result<(), ()> { try!(Ok(())); Ok(()) }; // issue #37345 macro_rules! m { () => { $crate::foo::bar(); } } m!(); // issue #37357 </ins> }

Related discussion:
text: When on latest rust nightly , you get an ICE when compiling .
Its a pretty recent regression, it can't be reproduced with .
Okay, managed to minimize it: Looks like a regression of . cc any ideas on this?
Yeah, this was caused by an oversight in -- fixed in .
Code change:
TyKind::Path(ref qself, ref path) => { self.diagnostic_metadata.current_type_path = Some(ty); self.smart_resolve_path(ty.id, qself.as_ref(), path, PathSource::Type); <ins> // Check whether we should interpret this as a bare trait object. if qself.is_none() && let Some(partial_res) = self.r.partial_res_map.get(&ty.id) && partial_res.unresolved_segments() == 0 && let Res::Def(DefKind::Trait | DefKind::TraitAlias, _) = partial_res.base_res() { // This path is actually a bare trait object.  In case of a bare `Fn`-trait // object with anonymous lifetimes, we need this rib to correctly place the // synthetic lifetimes. let span = ty.span.shrink_to_lo().to(path.span.shrink_to_lo()); self.with_generic_param_rib( &[], NormalRibKind, LifetimeRibKind::Generics { binder: ty.id, kind: LifetimeBinderKind::PolyTrait, span, }, |this| this.visit_path(&path, ty.id), ); self.diagnostic_metadata.current_type_path = prev_ty; return; } </ins> } TyKind::ImplicitSelf => { let self_ty = Ident::with_dummy_span(kw::SelfUpper);

Related discussion:
text: <!-- 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 with : I expected to see only warning without error, like this: Instead, this happened (extra error E0521 emitted, which is incorrect): If I add in line 3, it compiles without any error or warning: So the E0521 error emitted by the compiler is incorrect. The test code using should only produce warnings without an error. It most recently worked on: 1.63.0-nightly ( 2022-05-18) </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 --
labels:+T-compiler
label A-diagnostics
labels: +regression-from-stable-to-nightly
label -regression-untriaged Bisection: regressed nightly: nightly-2022-06-23 searched commit range: regressed commit: that’s , cc
Seems like, possibly, the code without the explicit (incorrectly) desugars to rather than Edit: Or perhaps it incorrectly desugars to
Here’s another kind of code example that reproduces the issue Which does confirm the idea that this appears to be interpreted like , rather than which would be correct.
WG-prioritization assigning priority (). label -I-prioritize +P-critical