jiebi/CodeConvo huggingface dataset:
Change:
self } <ins> /// Add or update multiple environment variable mappings. /// /// # Examples /// /// Basic usage: /// ```no_run /// use std::process::{Command, Stdio}; /// use std::env; /// use std::collections::HashMap; /// /// let filtered_env : HashMap<String, String> = ///     env::vars().filter(|&(ref k, _)| ///         k == "TERM" || k == "TZ" || k == "LANG" || k == "PATH" ///     ).collect(); /// /// Command::new("printenv") ///         .stdin(Stdio::null()) ///         .stdout(Stdio::inherit()) ///         .env_clear() ///         .envs(&filtered_env) ///         .spawn() ///         .expect("printenv failed to start"); /// ``` #[unstable(feature = "command_envs", issue = "38526")] pub fn envs<I, K, V>(&mut self, vars: I) -> &mut Command where I: IntoIterator<Item=(K, V)>, K: AsRef<OsStr>, V: AsRef<OsStr> { for (ref key, ref val) in vars { self.inner.env(key.as_ref(), val.as_ref()); } self } </ins> /// Removes an environment variable mapping. /// /// # Examples

Discussion:
You can add a vector of command-line arguments to a Command object with , but there's no equivalent for environment variables. I'd like to be able to do things like let filteredenv : Vec<(String, String)= std::env::vars().filter( / criterion /).collect(); let status = Command::new("printenv") .stdin(Stdio::null()) .stdout(Stdio::inherit()) .envclear() .envs(filteredenv) .status(); Right now I have to do instead let mut cmd = Command::new("printenv"); (Stdio::null()); (Stdio::inherit()); cmd.envclear(); for (ref k, ref v) in filtered_env { (k, v); } let status = (); which breaks the builder pattern and extends the scope of the Command object.
This sounds reasonable to me considering . If you want to submit a PR for the feature go ahead.
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
I'm confused; hasn't this already been merged?
Yes, but it's currently . The FCP above starting means that the libs team believes the API is ready for stabilization.
Oh, ok. Thanks for the explanation.
The final comment period is now complete.
Change:
<ins> fn foo() { if true { } else false { //~^ ERROR expected `{`, found keyword `false` } } fn foo2() { if true { } else falsy() { //~^ ERROR expected `{`, found `falsy` } } fn foo3() { if true { } else falsy(); //~^ ERROR expected `{`, found `falsy` } fn foo4() { if true { } else loop{} //~^ ERROR expected `{`, found keyword `loop` {} } fn falsy() -> bool { false } fn main() {} </ins>

Discussion:
The error here is if is missing in else if but compiler reports: error:
already points out at the place where the should be, even if it doesn't suggest it:
: I still wish the parser to detect that the code immediately following is a binary operation followed by a block, so that we can instead emit
CC in case you might be interested in looking at the parser :)
this seems like a neat fix, i'll take a stab at it
Change:
<ins> error: higher-ranked subtype error --> $DIR/issue-111404-1.rs:10:1 | LL | fn bar(_: fn(Foo<for<'b> fn(Foo<fn(&'b ())>::Assoc)>::Assoc)) {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- 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 --
Hm, maybe not really a new (this month) regression but I also can't find any obvious duplicates right now...
searched toolchains nightly-2022-11-28 through nightly-2023-05-09 Regression in nightly-2022-12-05 Regression in cc
label F-inherentassociatedtypes
I'm pretty sure this can be fixed by erasing all regions no matter their de Bruijn index via instead of . This would "regress" but eh, I guess that's fine for now.
claim
Change:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn main(_: TokenStream, input: TokenStream) -> TokenStream { "fn main() { println!("Hello Tokyo!"); }".parse().unwrap() } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected an error, because the main attribute has never been available on stable, and had apparently been removed in . Instead, the program ran without error, although the attribute has no apparent effect. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked as expected (emitting an error) on Rust 1.52.1: <!-- Provide the version you are using that has the regression. --This stopped being an error in 1.53.0 (in which a warning was still emitted), and continues to be accepted in stable through the current 1.58.1 version (in which the warning has also disappeared).
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +T-compiler
Change:
let coverage_mapping_buffer = llvm::build_byte_buffer(|coverage_mapping_buffer| { mapgen.write_coverage_mapping(expressions, counter_regions, coverage_mapping_buffer); }); <del> debug_assert!( !coverage_mapping_buffer.is_empty(), "Every `FunctionCoverage` should have at least one counter" ); </del> <ins> if coverage_mapping_buffer.is_empty() { if function_coverage.is_used() { bug!( "A used function should have had coverage mapping data but did not: {}", mangled_function_name ); } else { debug!("unused function had no coverage mapping data: {}", mangled_function_name); continue; } } </ins> function_data.push((mangled_function_name, source_hash, is_used, coverage_mapping_buffer)); }

Discussion:
Between nightly versions 2022-01-14 and 2022-01-15, 0.8.2 lost track of 82% of the coverage of when using the LLVM coverage option (). Other projects of mine continue to have code coverage correctly measured. I'm not where to start narrowing this down, as I'm not getting any errors or warnings printed. Here are the steps to get good code coverage reports out of 2022-01-14: If you look at the report in the coverage folder, the html report will show 80% coverage. Now, test with the next nightly: If you look at the report again, the html report now shows < 1% coverage. The quantity of profraw files are the same, and the sizes of the files are more or less equivalent. I'm not quite sure where to start narrowing this down since it's a unique issue to this project of mine -- but the only unique part I'm aware of is its size :sweat_smile:. For now I'll pin our CI to the last working nightly. Thank you in advance for any suggestions or help!
We noticed the same when upgrading rustc in our project from (December) to . Code coverage measured with and inexplicably dropped . Some crates that are clearly running don't show up at all in the reports. suggests that this is probably caused by
^ says is also affected.
cc label +requires-nightly +A-code-coverage
Thanks for the report! I've tried reproducing locally and I'm able to see the same behavior. Running the LLVM tools directly, I see this when trying to process coverage data for the various binaries: which seems to be the same issue as was reported in a comment on . I'm continuing to investigate ...
The minimal repro seems to be I think I'll have a fix for this within the next few days.
Change:
check_no_run("build-pass"); Some(PassMode::Build) } else if config.parse_name_directive(ln, "run-pass") { <del> if config.mode != Mode::Ui { panic!("`run-pass` header is only supported in UI tests") } </del> <ins> check_no_run("run-pass"); </ins> Some(PassMode::Run) } else { None

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: code originally from <!-- 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. --: When compile with , there is a which does not occur with `
Due to inlining of :
does the no_mangle attr have done kind of effect? can't check on mobile right now
I think it's more likely the struct's being ignored when performing that field access. cc
A slightly simplified example: It only arises when inlining a generic function (in this case ) that bitcasts a .
The difference seems to be that bitcasts a pointer to a vector, while the inlined bitcasts a vector directly. I suspect that the extra move that happens when is inlined causes vector value to be stored behind a pointer. I can reproduce the crash using just to force an extra move. As for why puts the vector behind a pointer, the default rust abi passes vector types by-ref to ensure that changing target features doesn't change the abi.
With that crashes at and without it gives the following LLVM ir:
It's interesting that the failure (in my example) required to be generic—that shouldn't affect the ABI of the monomorphized function, should it?
Indeed. It shouldn't affect the ABI.
The original no longer crashes since , but still does
Triage: The above mentioned example now compiles fine with the latest nightly, I guess is related. Marking as .
Change:
try_run_suppressed(cmd) } <ins> /// Runs a command, printing out nice contextual information if it fails. /// Returns false if do not execute at all, otherwise returns its /// `status.success()`. fn check_run(&self, cmd: &mut Command) -> bool { if self.config.dry_run { return true; } self.verbose(&format!("running: {:?}", cmd)); check_run(cmd, self.is_verbose()) } </ins> pub fn is_verbose(&self) -> bool { self.verbosity > 0 }

Discussion:
I just cloned this rust repo and attemped to build it by calling It initialized submodules, started downloading and failed repeatedly: Waiting longer causes messages above to repeat. It's not connection issue, because it always fails after ~30 seconds of downloading (Messages above repeat in ~2 minutes). I also tried changing to here: What caused download to succeed in a few (1-2) minutes. So I assume it's to blame. version:
I got x.py to test libcore once, but after I updated my local clone of rust, I started getting this repeatedly:
I am nuking my entire rust clone in case changes to the bootstrap are incompatible to previous artifacts produced by previous versions. Why does x.py need to download submodules like and if I am only trying to test ? edit: apparently, this is expected
Nope, I am still getting the DownloadFile exception after refreshing everything, including updating MSYS2 to get curl to 7.65.1, trying the MSYS2 that comes along with git, and messing with
your issue is different and there is no involved (it downloads file through PowerShell). You can see this MSYS2 patch how to make it use instead:
Thank you, it works now
original issue (from comment 0) is not resolved. reported another issue that isn't solved either, there is only workaround available.
We should probably fallback to trying curl if the powershell invocation fails. Reopening. I think a PR would work best here.
For some reason, the powershell download is working again on both my MSYS2 install and from git bash. We still want that fallback though. I couldn't PR a fix though, because I don't know how the exception handling is working in that Python script.
Actually, since I should learn Python anyway, should I PR a fix? Is it as simple as detecting an exception occurred and refactoring the if-else statement in a way that it would also run ?
That's what I would suggest -- we can make it pretty simple and if anything goes wrong with the powershell call then fallback to curl
It might also make sense to try curl before using powershell, as suggested by in label: +E-easy
Change:
}) .collect(); <del> let end = if candidates.len() <= 9 { candidates.len() } else { 8 }; </del> <ins> let end = if candidates.len() <= 9 || self.tcx.sess.opts.verbose { candidates.len() } else { 8 }; </ins> err.help(format!( "the following {other}types implement trait `{}`:{}{}", trait_ref.print_trait_sugared(), candidates[..end].join(""), <del> if candidates.len() > 9 { </del> <ins> if candidates.len() > 9 && !self.tcx.sess.opts.verbose { </ins> format!("nand {} others", candidates.len() - 8) } else { String::new()

Discussion:
When emitting an error like the following Allow the flag () to print the whole list by modifying There are other places where we limit output where we don't currently listen to this flag to expand the output. For type name shortening I believe we already do, but we should look for all of them and make the appropriate change for them too. Originally reported at
Hi, I am interested in this easy issue. Can I submit a PR to fix it?
of course!
Can you help me review this PR?
Change:
<ins> // build-pass #![allow(incomplete_features)] #![feature(inline_const, half_open_range_patterns, exclusive_range_pattern)] fn main() { const N: u32 = 10; let x: u32 = 3; match x { 1 ..= const { N + 1 } => {}, _ => {}, } match x { const { N - 1 } ..= 10 => {}, _ => {}, } match x { const { N - 1 } ..= const { N + 1 } => {}, _ => {}, } match x { .. const { N + 1 } => {}, _ => {}, } match x { const { N - 1 } .. => {}, _ => {}, } match x { ..= const { N + 1 } => {}, _ => {} } } </ins>

Discussion:
As soon as I've seen the new inline_const feature, I've tried to find some use cases for it in my code, and I did find only very few of them, unfortunately, and one of the two uses cases could be reduced to this: That gives errors: So I am not sure if this is a bug report or an enhancement request.
Note that this does work in expressions ():
Support for ranges in patterns ( or ) needs to be separately, to and respectively.
Ohh I've just realized that we had this issue opened, I've fixed this in Going to adjust description of the PR accordingly so it closes this issue when merged.
Change:
constant .map(|val| { let field_ty = ty.builtin_index().unwrap(); <del> let fields = match ty.kind { ty::Array(_, n) => n.eval_usize(bx.tcx(), ty::ParamEnv::reveal_all()), _ => bug!("invalid simd shuffle type: {}", ty), }; </del> let c = ty::Const::from_value(bx.tcx(), val, ty); <del> let values: Vec<_> = (0..fields) </del> <ins> let values: Vec<_> = bx .tcx() .destructure_const(ty::ParamEnv::reveal_all().and(&c)) .fields .into_iter() </ins> .map(|field| { <del> let field = bx.tcx().const_field( ty::ParamEnv::reveal_all().and((&c, mir::Field::new(field as usize))), ); if let Some(prim) = field.try_to_scalar() { </del> <ins> if let Some(prim) = field.val.try_to_scalar() { </ins> let layout = bx.layout_of(field_ty); let scalar = match layout.abi { Abi::Scalar(ref x) => x,

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
coroutine_kind, coroutine_for_closure, is_type_alias_impl_trait, <del> find_field, </del> ..*providers }; }

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'forcing query with already existing '', 'thread 'rustc' panicked at 'forcing query with already existing '' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [findfield] find the index of maybe nested field in [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to :thinking:
WG-prioritization assigning priority (). cc: + for label -I-prioritize +P-medium
I'm going to fix it in (still WIP), where the query will be removed.
Testing out on this issue:
I seems like does not have proper or impls, possibly due to the differing . Are you familiar with that part of spans?
Change:
<del> <div class="docblock"><p>Hello world! Goodbye! </del> <ins> <div class="docblock"><p>Hello world!</p> <p>Goodbye! </ins> Hello again!</p> </div>  No newline at end of file

Discussion:
See the test in . This code: renders as: rather than the expected: Meanwhile, changing some s to s and vice versa causes it to render as expected. cc
This is the expected behaviour actually: it converts the into a directly. So if you don't put empty doc comments between, it's as expected.
But why are the newlines in the stripped?
Oh, I didn't see that. I think it's because we use to remove whistespaces which also removes backlines. We should instead merge all doc comments before doing anything.
Change:
where F: FnMut(MovePathIndex, DropFlagState) { let move_data = &ctxt.move_data; <del> let param_env = ctxt.param_env; </del> debug!("drop_flag_effects_for_location({:?})", loc); // first, move out of the RHS

Discussion:
MIR borrowck considers variables still initialized after their storage ends, so if an immutable variable is defined and used in a loop, this causes an error. e.g.: Which causes:
working on it
Change:
kind: ast::VisibilityKind::Inherited, tokens: None, }, <del> span: ecx.with_def_site_ctxt(sp), </del> <ins> span: sp, </ins> tokens: None, })]) } else {

Discussion:
Similar to how deny(unsafecode) prevents from being used, it should also prevent blocks from being allowed. If misused, they can do any number of strange and horrible thing simply by being within the crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
label +C-bug +T-compiler
I suppose it's probably too late to actually make it require ?
that isn't even currently possible from a syntax perspective because blocks only work as expressions, you can't just put them around a top level item. It would take a whole RFC thing, even separately from global_asm already being stable.
Change:
<ins> const fn hey() -> usize { panic!(123); //~ ERROR argument to `panic!()` in a const context must have type `&str` } fn main() { let _: [u8; hey()] = todo!(); } </ins>

Discussion:
Playground: <details<summaryOutput</summary</detailscc
Ah, yes, array lengths... this is like
Cc
This ICEs on stable: I thought we have an issue for this somewhere? Basically, array lengths (and patterns) side-step all prior checks, including stability checks, and try to evaluate this constant anyway.
Hmm
No longer ICEs since
Change:
<ins> Future incompatibility report: Future breakage date: None, diagnostic: warning: this method call currently resolves to `<&[T; N] as IntoIterator>::into_iter` (due to autoref coercions), but that might change in the future when `IntoIterator` impls for arrays are added. --> $DIR/issue-78660-cap-lints-future-compat.rs:9:12 | LL |     ["hi"].into_iter(); |            ^^^^^^^^^ help: use `.iter()` instead of `.into_iter()` to avoid ambiguity: `iter` | = note: `-D array-into-iter` implied by `-D warnings` = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #66145 <https://github.com/rust-lang/rust/issues/66145> </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --Simply building the rusty-xinput crate in the dependency chain seems to have triggered it. See <!-- 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. --Rust version from the build <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pI'm sorry - I don't have access to a windows environment to reproduce this! </p</details
I think is the cause, cc Note that you should set to reproduce it. I don't feel this is Windows-specific but it just depends on the Windows-specific crate, marking . <details<summary<strongBacktrace</strong</summary</details
MCVE: run on:
Assigning and removing .
I got the same error on Linux while compiling lazy_static. https://cirrus- .
This will be fixed by
Change:
<ins> #[allow(unused_macros)] macro_rules! foo { () => { } () => { //~^ ERROR expected `;`, found `(` } } fn main() {} </ins>

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// /// ### Example of auto-trait /// <del> /// ```rust,compile_fail </del> <ins> /// ```rust,edition2018,compile_fail </ins> /// #![deny(rust_2021_incompatible_closure_captures)] /// use std::thread; ///

Discussion:
Given the following code: The current output is: Ideally the output should look like: The code is already being compiled for the 2021 edition, there's no need to issue any warnings about behaviour that was different in 2018. The compiler should assume that the code is working as expected. This might affect other warnings in the same category, I'm not sure. Tested in 1.63, beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
So, it seems that there are 3 warnings in this category and the issue only affects the closure one: is not affected because it checks that auto-ref happens, which doesn't in rust 2021 is not affected because the linted code simply doesn't compile in rust 2021 is affected
seems to be needed, because is marked with and the lint wants a significant impl MRE: