jiebi/CodeConvo huggingface dataset:
Change:
I tried this code: I expected to see this happen: Instead, this happened: This is caused by different quote handling. The first (correct) command line for the spawned process (as observed by ) is: The broken one is: The command for must be in additional set of quotes, as the first and last one are stripped. It works when there are no spaces in the arguments due to the exception rule, see Stable. It worked up until nightly-2021-11-20 nightly-2021-11-21 modify labels: +regression-from-stable-to-nightly -regression-untriaged
This is caused by Rust now handling finding the exe to run itself (for security reasons). The fix here would be. as you say, to detect or extensions and add the extra quotes. The underlying function call here is . As the documentation says, this can only be used to run files. However, an undocumented feature of is that it will do this for us if given a or file. Previously we used to leave the argument blank and let it guess the right application from the argument. So apparently it would fill in for the application name and add plus the extra quotes to . But now that we do fill in the ourselves, it will still change to and add to but evidentially doesn't add the extra quotes. Thus we need to do this ourselves.
That seems reasonable; could you or someone on the Windows team submit a PR adding the requisite quoting (since quoting is hard to get right)?
Oops, sorry! I had a PR lined up but forgot to submit.

Discussion:
let p = Command::new("cmd").args(&["/C", "exit 0"]).env_clear().spawn(); assert!(p.is_ok()); } <ins> // See issue #91991 #[test] #[cfg(windows)] fn run_bat_script() { let tempdir = crate::sys_common::io::test::tmpdir(); let script_path = tempdir.join("hello.cmd"); crate::fs::write(&script_path, "@echo Hello, %~1!").unwrap(); let output = Command::new(&script_path) .arg("fellow Rustaceans") .stdout(crate::process::Stdio::piped()) .spawn() .unwrap() .wait_with_output() .unwrap(); assert!(output.status.success()); assert_eq!(String::from_utf8_lossy(&output.stdout).trim(), "Hello, fellow Rustaceans!"); } </ins>

// Encode the command and arguments in a command line string such // that the spawned process may recover them using CommandLineToArgvW. let mut cmd: Vec<u16> = Vec::new(); <ins> // CreateFileW has special handling for .bat and .cmd files, which means we // need to add an extra pair of quotes surrounding the whole command line // so they are properly passed on to the script. // See issue #91991. let is_batch_file = Path::new(prog) .extension() .map(|ext| ext.eq_ignore_ascii_case("cmd") || ext.eq_ignore_ascii_case("bat")) .unwrap_or(false); if is_batch_file { cmd.push(b'"' as u16); } </ins> // Always quote the program name so CreateProcess doesn't interpret args as // part of the name if the binary wasn't found first time. append_arg(&mut cmd, prog, Quote::Always)?;

}; append_arg(&mut cmd, arg, quote)?; } <ins> if is_batch_file { cmd.push(b'"' as u16); } </ins> return Ok(cmd); fn append_arg(cmd: &mut Vec<u16>, arg: &OsStr, quote: Quote) -> io::Result<()> {
Change:
<!-- 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. --The following code: triggers a panic in the compiler (see below). All works as expected if I write . <!-- 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
Output on stable: (An awkward but correct error - without , the compiler uses autoref to resolve as which returns .) searched nightlies: from nightly-2021-10-16 to nightly-2021-11-28 regressed nightly: nightly-2021-11-10 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: </details label regression-from-stable-to-beta
Probably ?
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I think this is a duplicate of , and I also put up a fix in (along with both in and in ) which has been waiting for a review for quite some time.. Not sure which one of our PRs should be approved, but at least one of them should :^) -- re: , I agree with Aaron that this is the simpler and more targeted fix for the bug, so I'll just close mine after this gets approved probably. (edit: made it clearer who I was referring to in the original comment - lol, sorry)
thanks for the note! I'll also add (as a self-reminder) that in Aaron also that might be a better fix.

Discussion:
} } else { self.check_expr_has_type_or_error(base_expr, adt_ty, |_| { <del> let base_ty = self.check_expr(base_expr); </del> <ins> let base_ty = self.typeck_results.borrow().node_type(base_expr.hir_id); </ins> let same_adt = match (adt_ty.kind(), base_ty.kind()) { (ty::Adt(adt, _), ty::Adt(base_adt, _)) if adt == base_adt => true, _ => false,

<ins> #[derive(Clone)] struct P<T> { x: T, y: f64, } impl<T> P<T> { fn y(&self, y: f64) -> Self { P{y, .. self.clone() } } //~^ mismatched types [E0308] } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-92010-trait-bound-not-satisfied.rs:8:43 | LL |     fn y(&self, y: f64) -> Self { P{y, .. self.clone() } } |                                           ^^^^^^^^^^^^ expected struct `P`, found `&P<T>` | = note: expected struct `P<T>` found reference `&P<T>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
<!-- 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. --The fuchsia nightly toolchain rolls caught a binary size regression due to commit Limiting to just binary changes in the rust repo, following the instructions here: , we can see that on average the standard library is 3.5 times larger: <details<summaryClick to expand</summary</detailsI'm currently assuming that our setting of in the config of fuchsia rust builds is what causes this to be so noticeable. The effect on fuchsia is very noticeable: The binary size increases on our debug builds are large enough to prevent the binaries from fitting on the devices we're debugging. CC modify labels: +regression-from-stable-to-nightly -regression-untriaged
The regression comes from the inclusion of the section in the dylib for the fuchsia target. This section is quite large (3.4 MB, more than twice the size of the original binary). I'm actually confused about how this was working before. Clearly we need rustc metadata to compile against libstd or any other crate. The old DSO doesn't appear to have a section for metadata, but was compiling fine. Was this being shoved in another section (and somehow much smaller)? Or was rustc finding metadata from another libstd file, perhaps the rlib? cc
The section should not be getting included in dylibs (those should use with compressed metadata). This patch wasn't supposed to change handling of at all. I must have broken something while refactoring, though I don't immediately spot what.
Or did you mean above? I just checked the from a local (non-fuchsia) build and I see a section, but not an section.
Though I see now that is marked as rather than , that's not right.
Okay, that's because the section is created with , which assigns default flags: Probably it should use a debug section like does.
Thanks for the fix! and sorry yes, I did mean .

Discussion:
let section = file.add_section( file.segment_name(StandardSegment::Data).to_vec(), b".rustc".to_vec(), <del> SectionKind::Data, </del> <ins> SectionKind::ReadOnlyData, </ins> ); <ins> match file.format() { BinaryFormat::Elf => { // Explicitly set no flags to avoid SHF_ALLOC default for data section. file.section_mut(section).flags = SectionFlags::Elf { sh_flags: 0 }; } _ => {} }; </ins> let offset = file.append_section_data(section, &compressed, 1); // For MachO and probably PE this is necessary to prevent the linker from throwing away the
Change:
<!-- 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 --
This panic appears to be fixed in PR . Duplicate of ?
Perhaps worth adding a regression test for this issue in particular.
Sounds like a good idea- I'll get going on that
claim

Discussion:
<ins> // Regression test for #92105. // ICE when mutating immutable reference from last statement of a block. fn main() { let foo = Some(&0).unwrap(); *foo = 1; //~ ERROR cannot assign } </ins>

<ins> error[E0594]: cannot assign to `*foo`, which is behind a `&` reference --> $DIR/issue-92015.rs:6:5 | LL |     let foo = Some(&0).unwrap(); |         --- help: consider changing this to be a mutable reference: `&mut i32` LL |     *foo = 1; |     ^^^^^^^^ `foo` is a `&` reference, so the data it refers to cannot be written error: aborting due to previous error For more information about this error, try `rustc --explain E0594`. </ins>
Change:
Given the following code (): The current output is: <!-- The following is not always necessary. --Ideally the output should look like: and the compiler would preview the fix, by adding the commas in green. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This week I'm busier than I thought ;) release-assignment
label +A-parser
claim

Discussion:
} } <ins> /// Give appropriate suggestion when encountering `[("a", 0) ("b", 1)]`, where the /// likely intention is to create an array containing tuples. fn maybe_suggest_bad_array_definition( &self, err: &mut DiagnosticBuilder<'a>, call_expr: &'tcx hir::Expr<'tcx>, callee_expr: &'tcx hir::Expr<'tcx>, ) -> bool { let hir_id = self.tcx.hir().get_parent_node(call_expr.hir_id); let parent_node = self.tcx.hir().get(hir_id); if let ( hir::Node::Expr(hir::Expr { kind: hir::ExprKind::Array(_), .. }), hir::ExprKind::Tup(exp), hir::ExprKind::Call(_, args), ) = (parent_node, &callee_expr.kind, &call_expr.kind) { if args.len() == exp.len() { let start = callee_expr.span.shrink_to_hi(); err.span_suggestion( start, "consider separating array elements with a comma", ",".to_string(), Applicability::MaybeIncorrect, ); return true; } } false } </ins> fn confirm_builtin_call( &self, call_expr: &'tcx hir::Expr<'tcx>,

_ => Res::Err, }; <del> err.span_label(call_expr.span, "call expression requires function"); </del> <ins> if !self.maybe_suggest_bad_array_definition(&mut err, call_expr, callee_expr) { err.span_label(call_expr.span, "call expression requires function"); } </ins> if let Some(span) = self.tcx.hir().res_span(def) { let callee_ty = callee_ty.to_string();

error[E0618]: expected function, found `(char, char)` --> $DIR/issue-5100.rs:48:14 | <del> LL |       let v = [('a', 'b') |  ______________-^^^^^^^^^ LL | |              ('c', 'd'), | |_______________________- call expression requires function </del> <ins> LL |     let v = [('a', 'b') |              ^^^^^^^^^^- help: consider separating array elements with a comma: `,` </ins> error[E0308]: mismatched types --> $DIR/issue-5100.rs:55:19

<ins> fn main() { let _tmp = [ ("C200B40A82", 3), ("C200B40A83", 4) //~ ERROR: expected function, found `(&'static str, {integer})` [E0618] ("C200B40A8537", 5), ]; } </ins>

<ins> error[E0618]: expected function, found `(&'static str, {integer})` --> $DIR/array-diagnostics.rs:4:9 | LL |         ("C200B40A83", 4) |         ^^^^^^^^^^^^^^^^^- help: consider separating array elements with a comma: `,` error: aborting due to previous error For more information about this error, try `rustc --explain E0618`. </ins>
Change:
<!-- 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 to see this happen: print (from Debug impl) Instead, this happened: E0277, trait impl not found This was found by CI in the Ruffle Project: The issue is caused by the effective anti-bound of Drop, introduced by the manual impl of the trait, as well as the PR which introduced bounds for a number of functions in . It most recently worked on: rustc 1.59.0-nightly ( 2021-12-18) : modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc

Discussion:
pub type PolyTraitPredicate<'tcx> = ty::Binder<'tcx, TraitPredicate<'tcx>>; impl<'tcx> TraitPredicate<'tcx> { <ins> pub fn remap_constness(&mut self, tcx: TyCtxt<'tcx>, param_env: &mut ParamEnv<'tcx>) { if unlikely!(Some(self.trait_ref.def_id) == tcx.lang_items().drop_trait()) { // remap without changing constness of this predicate. // this is because `T: ~const Drop` has a different meaning to `T: Drop` param_env.remap_constness_with(self.constness) } else { *param_env = param_env.with_constness(self.constness.and(param_env.constness())) } } </ins> pub fn def_id(self) -> DefId { self.trait_ref.def_id }

let mut param_env = obligation.param_env; fresh_trait_pred = fresh_trait_pred.map_bound(|mut pred| { <del> param_env = param_env.with_constness(pred.constness.and(param_env.constness())); </del> <ins> pred.remap_constness(self.tcx(), &mut param_env); </ins> pred });

} let tcx = self.tcx(); let mut pred = cache_fresh_trait_pred.skip_binder(); <del> param_env = param_env.with_constness(pred.constness.and(param_env.constness())); </del> <ins> pred.remap_constness(tcx, &mut param_env); </ins> if self.can_use_global_caches(param_env) { if let Some(res) = tcx.selection_cache.get(&param_env.and(pred), tcx) {

let tcx = self.tcx(); let mut pred = cache_fresh_trait_pred.skip_binder(); <del> param_env = param_env.with_constness(pred.constness.and(param_env.constness())); </del> <ins> pred.remap_constness(tcx, &mut param_env); </ins> if !self.can_cache_candidate(&candidate) { debug!(?pred, ?candidate, "insert_candidate_cache - candidate is not cacheable");

<ins> // Regression test for #92111. // // The issue was that we normalize trait bounds before caching // results of selection. Checking that `impl NoDrop for S` requires // checking `S: !Drop` because it cannot overlap with the blanket // impl. Then we save the (unsatisfied) result from checking `S: Drop`. // Then the call to `a` checks whether `S: ~const Drop` but we normalize // it to `S: Drop` which the cache claims to be unsatisfied. // // check-pass #![feature(const_trait_impl)] #![feature(const_fn_trait_bound)] pub trait Tr {} #[allow(drop_bounds)] impl<T: Drop> Tr for T {} #[derive(Debug)] pub struct S(i32); impl Tr for S {} const fn a<T: ~const Drop>(t: T) {} fn main() { a(S(0)); } </ins>
Change:
<!-- 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
A "fix" for that code is to add however I don't want to get an ICE but a nice error.
The error comes from I think. If you weren't using hitting this case would be a genuine bug in rustc. Turning it from an ICE into a nice error would require special casing integer types to not ICE here. In general you should expect to see internal compiler errors when you mess up with . In some cases it is feasible to give nice errors but I think this is not such a case.
Thanks! You may close if you think there is nothing you can do.
I am by no means familiar with the relevant code, but this would seem more like a basis for making this a than closing it entirely. As in, it would be nice if there was a way to fix this, but we don't know what it is and it's not really a priority.
Triage: Fixed since nightly-2023-01-04, marking as .

Discussion:
<ins> #![feature(no_core)] #![feature(lang_items)] #![no_core] #[cfg(target_os = "linux")] #[link(name = "c")] extern {} #[lang = "start"] fn start<T>(_main: fn() -> T, _argc: isize, _argv: *const *const u8) -> isize { //~^ ERROR: incorrect number of parameters for the `start` lang item 40+2 } #[lang = "sized"] pub trait Sized {} #[lang = "copy"] pub trait Copy {} #[lang = "drop_in_place"] #[allow(unconditional_recursion)] pub unsafe fn drop_in_place<T: ?Sized>(to_drop: *mut T) { drop_in_place(to_drop) } #[lang = "add"] trait Add<RHS> { type Output; fn add(self, other: RHS) -> Self::Output; } impl Add<isize> for isize { type Output = isize; fn add(self, other: isize) -> isize { self + other } } fn main() {} </ins>

<ins> error: incorrect number of parameters for the `start` lang item --> $DIR/issue-92157.rs:11:1 | LL | fn start<T>(_main: fn() -> T, _argc: isize, _argv: *const *const u8) -> isize { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the `start` lang item should have four parameters, but found 3 = note: the `start` lang item should have the signature `fn(fn() -> T, isize, *const *const u8, u8) -> isize` error: aborting due to previous error </ins>
Change:
I tried this code: I expected to see this happen: It should compile successfully. Instead, this happened: The compiler doesn't realize that is implemented for all and reports an error. Interestingly enough, removing the bound makes this compile again. searched nightlies: from nightly-2021-12-01 to nightly-2021-12-25 regressed nightly: nightly-2021-12-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details modify labels: +regression-from-stable-to-nightly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
CC as the author of the relevant PR.
Fixed by , this one is more interesting than the test I in that PR, as it is stable code (but uses ), so I think we could add this one as an ui test as well.
I can confirm that this is fixed on the latest nightly.
It's E-needs-test because someone should add an ui test for this issue
I'm interested in working on this. Could you tell me where should the test be ? It seems to be somewhere inside .
I might go with . There isn't really much dark magic to picking which directory to file something under; there are a few directories that aren't really used anymore, but other than that, it's just a matter of picking something that makes sense.
claim

Discussion:
<ins> // check-pass use std::marker::PhantomData; pub struct MyGenericType<T> { _marker: PhantomData<*const T>, } pub struct MyNonGenericType; impl<T> From<MyGenericType<T>> for MyNonGenericType { fn from(_: MyGenericType<T>) -> Self { todo!() } } pub trait MyTrait { const MY_CONSTANT: i32; } impl<T> MyTrait for MyGenericType<T> where Self: Into<MyNonGenericType>, { const MY_CONSTANT: i32 = 1; } impl<T> MyGenericType<T> { const MY_OTHER_CONSTANT: i32 = <MyGenericType<T> as MyTrait>::MY_CONSTANT; } fn main() {} </ins>
Change:
I tried this code on a fresh git clone of rust-lang/rust: I expected to see this happen: setup works without errors. Instead, this happened: x.py gives an error: This feature was introduced in and worked at that time. do you have time to look into this? The original bug report was from Nazar Mokrynskyi , not sure their github username. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, I'll take a look over the next few days.
Hello. Is there a workaround for this issue for now? I got But when I ran , I got .
OK. After reading the zulip thread, I figured out how to work around it. After running , succeeded.
claim

Discussion:
use crate::TargetSelection; use crate::{t, VERSION}; <ins> use std::env::consts::EXE_SUFFIX; </ins> use std::fmt::Write as _; <del> use std::path::{Path, PathBuf}; </del> <ins> use std::fs::File; use std::path::{Path, PathBuf, MAIN_SEPARATOR}; </ins> use std::process::Command; use std::str::FromStr; use std::{

println!("`x.py` will now use the configuration at {}", include_path.display()); let build = TargetSelection::from_user(&env!("BUILD_TRIPLE")); <del> let stage_path = ["build", build.rustc_target_arg(), "stage1"].join("/"); </del> <ins> let stage_path = ["build", build.rustc_target_arg(), "stage1"].join(&MAIN_SEPARATOR.to_string()); </ins> println!();

return; } <ins> if !ensure_stage1_toolchain_placeholder_exists(stage_path) { println!( "Failed to create a template for stage 1 toolchain or confirm that it already exists" ); return; } </ins> if try_link_toolchain(&stage_path[..]) { println!( "Added `stage1` rustup toolchain; try `cargo +stage1 build` on a separate rust project to run a newly-built toolchain"

.map_or(false, |output| output.status.success()) } <ins> fn ensure_stage1_toolchain_placeholder_exists(stage_path: &str) -> bool { let pathbuf = PathBuf::from(stage_path); if fs::create_dir_all(pathbuf.join("lib")).is_err() { return false; }; let pathbuf = pathbuf.join("bin"); if fs::create_dir_all(&pathbuf).is_err() { return false; }; let pathbuf = pathbuf.join(format!("rustc{}", EXE_SUFFIX)); if pathbuf.exists() { return true; } // Take care not to overwrite the file let result = File::options().append(true).create(true).open(&pathbuf); if result.is_err() { return false; } return true; } </ins> // Used to get the path for `Subcommand::Setup` pub fn interactive_path() -> io::Result<Profile> { fn abbrev_all() -> impl Iterator<Item = ((String, String), Profile)> {
Change:
See the documentation for here and for here: In both cases, the documentation refers to the object the method is called for, not the type, so it should be using the lower case . (And maybe should be in backticks here?) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
label +A-docs +T-libs +E-easy
claim

Discussion:
self.drain_filter(|k, v| !f(k, v)); } <del> /// Moves all elements from `other` into `Self`, leaving `other` empty. </del> <ins> /// Moves all elements from `other` into `self`, leaving `other` empty. </ins> /// /// # Examples ///

self.drain_filter(|v| !f(v)); } <del> /// Moves all elements from `other` into `Self`, leaving `other` empty. </del> <ins> /// Moves all elements from `other` into `self`, leaving `other` empty. </ins> /// /// # Examples ///

} } <del> /// Moves all the elements of `other` into `Self`, leaving `other` empty. </del> <ins> /// Moves all the elements of `other` into `self`, leaving `other` empty. </ins> /// /// # Panics ///

} } <del> /// Appends elements to `Self` from other buffer. </del> <ins> /// Appends elements to `self` from other buffer. </ins> #[cfg(not(no_global_oom_handling))] #[inline] unsafe fn append_elements(&mut self, other: *const [T]) {