jiebi/CodeConvo huggingface dataset:
Change:
//! obtained from the wrapper's name as the first two arguments. //! On Windows it spawns a `..rust-lld.exe` child process. <ins> use std::env::{self, consts::EXE_SUFFIX}; </ins> use std::fmt::Display; use std::path::{Path, PathBuf}; <del> use std::{env, process}; </del> <ins> use std::process; </ins> trait UnwrapOrExitWith<T> { fn unwrap_or_exit_with(self, context: &str) -> T;

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: and this happened: I expected to see this happen: it would compile my crate. Instead, this happened: lld failed. <!-- 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. --: fixed the problem that I reported in There seems to be a new problem with an unknown linker name. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
Could you post the list of files in the directory in Rust distribution?
I found in the clang invocation:
It looks like maybe clang replaces and changes it from to when calling lld-wrapper?
I can't confirm whether that's the case right now, but if that's true then the fix would be as simple as adding the alternative to in lld-wrapper.
Apple ships its linker as . I couldn't find a file.
I believe the issue is with the usage of in the PR, see: You probably meant to use . Wait. is because of Windows? is the only one that does not play well with it. One solution is to normalise the string or before the match statement.
This is not happening only on osx. I can reproduce this. The path is correct and unchanged by clang, but it's indeed the call that trims too much on unixes because of the weird executable name with a dot. I'll fix it.
The problem still exists, but the error changed to on macos. Need more investigation..
Change:
diag_builder.note(&rationale.as_str()); } } <del> LintSource::CommandLine(_) => { </del> <ins> LintSource::CommandLine(_, _) => { </ins> diag_builder.note("`forbid` lint level was set on command line"); } }

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:
let pat = self.recover_parens_around_for_head(pat, begin_paren); <ins> // Recover from missing expression in `for` loop if matches!(expr.kind, ExprKind::Block(..)) && !matches!(self.token.kind, token::OpenDelim(token::Delimiter::Brace)) && self.may_recover() { self.sess .emit_err(errors::MissingExpressionInForLoop { span: expr.span.shrink_to_lo() }); let err_expr = self.mk_expr(expr.span, ExprKind::Err); let block = self.mk_block(vec![], BlockCheckMode::Default, self.prev_token.span); return Ok(self.mk_expr( lo.to(self.prev_token.span), ExprKind::ForLoop(pat, err_expr, block, opt_label), )); } </ins> let (attrs, loop_block) = self.parse_inner_attrs_and_block()?; let kind = ExprKind::ForLoop(pat, expr, loop_block, opt_label);

Discussion:
Spot the bug: Unfortunately, instead of pointing to the missing iterator, rust points to the 1: I'd love it to instead say 'missing iterator for loop': Other variants of this with less than ideal errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Well, it thinks the block is the iterator.
Yes, I understand, but a) is not an iterator, and b) since there's no body of the loop I was hoping the parser could recover somehow and understand that the block expression was intended to be the body.
Yes, I just wanted to make sure we were on the same page :)
I could have sworn there was an old ticket for this already but I can't find it
claim
Change:
in_body: bool, span: Span, empty_tables: &'a ty::TypeckTables<'tcx>, <ins> visited_anon_tys: FxHashSet<DefId> </ins> } impl<'a, 'tcx> TypePrivacyVisitor<'a, 'tcx> {

Discussion:
I guess this should be erroring with or E0666 (nested impl trait is not allowed).
Continues crashing in 1.26 stable.
This does not crash:
Particularly unfortunate because of and . <strikeWhat is going on here: There is a syntactical check to forbid nested impl Trait, but the default sneaks past that check, so we probably have to check for that substitution after lowering from HIR in type collection. Though it can also be done in the syntax check with some contortion.</strikeI was thinking that this shouldn't be allowed because it's like nested impl Trait, but is not at all like because the latter allows the inner type to be different from the outer one, while the former doesn't. So it might just be a case of fixing the overflow itself . I can take this myself but someone looking for mentorship or who is just faster is welcome.
Change:
} } <ins> pub fn borrow_nested_obligations_mut(&mut self) -> &mut [N] { match self { ImplSource::UserDefined(i) => &mut i.nested, ImplSource::Param(n, _) => n, ImplSource::Builtin(i) => &mut i.nested, ImplSource::AutoImpl(d) => &mut d.nested, ImplSource::Closure(c) => &mut c.nested, ImplSource::Generator(c) => &mut c.nested, ImplSource::Future(c) => &mut c.nested, ImplSource::Object(d) => &mut d.nested, ImplSource::FnPointer(d) => &mut d.nested, ImplSource::TraitAlias(d) => &mut d.nested, ImplSource::TraitUpcasting(d) => &mut d.nested, ImplSource::ConstDestruct(i) => &mut i.nested, } } </ins> pub fn map<M, F>(self, f: F) -> ImplSource<'tcx, M> where F: FnMut(N) -> M,

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: This is modification of with the difference being ` Rust OOM'd here after eating at least 20 gb of memory :sweat_smile: I expected to see this happen: explanation NO OOM, maybe an error Instead, this happened: explanation OOM <!-- 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. --:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} } ItemKind::TyAlias(self_ty, _) => icx.to_ty(self_ty), <del> ItemKind::Impl(hir::Impl { self_ty, .. }) => { match self_ty.find_self_aliases() { spans if spans.len() > 0 => { let guar = tcx.sess.emit_err(crate::errors::SelfInImplSelf { span: spans.into(), note: () }); tcx.ty_error(guar) }, _ => icx.to_ty(*self_ty), </del> <ins> ItemKind::Impl(hir::Impl { self_ty, .. }) => match self_ty.find_self_aliases() { spans if spans.len() > 0 => { let guar = tcx.sess.emit_err(crate::errors::SelfInImplSelf { span: spans.into(), note: (), }); tcx.ty_error(guar) </ins> } <ins> _ => icx.to_ty(*self_ty), </ins> }, ItemKind::Fn(..) => { let substs = InternalSubsts::identity_for_item(tcx, def_id.to_def_id());

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
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in
aaah shit, the commit only modified the backtrace :laughing: so "panicked at" no longer triggers before that..
`
maybe
Change:
"unexpected const-val {:?} with ctor {:?}", value, constructor) }, _ => { <del> match range_covered_by_constructor( </del> <ins> match constructor_covered_by_range( </ins> cx.tcx, pat.span, constructor, value, value, RangeEnd::Included ) { Ok(true) => Some(vec![]),

Discussion:
With rust nightly compiler, the result on the screen is even though the compiler warning that 11 case is unreachable. Link to rust playground:
Change:
if self.alloc_map.contains_key(&alloc) { // Not yet interned, so proceed recursively self.intern_static(alloc, mutability)?; <ins> } else if self.dead_alloc_map.contains_key(&alloc) { // dangling pointer return err!(ValidationFailure( "encountered dangling pointer in final constant".into(), )) </ins> } } Ok(())

Discussion:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.
Change:
*self.value.get() = value; } } <ins> /// Get a reference to the underlying `UnsafeCell`. /// /// This can be used to circumvent `Cell`'s safety checks. /// /// This function is `unsafe` because `UnsafeCell`'s field is public. #[inline] #[experimental] pub unsafe fn as_unsafe_cell<'a>(&'a self) -> &'a UnsafeCell<T> { &self.value } </ins> } #[unstable = "waiting for `Clone` trait to become stable"]

Discussion:
This would be useful in cases where we mostly want to enforce guarantees but need to break the rules in one place. (e.g. the Servo interface to html5ever which needs to GC-trace a mutably-borrowed parser)
Similarly, this would be useful for RAII classes that need to be fail-proof in the face of task failure while there are outstanding RefCell borrows.
I don't think that case should be an issue; the / destructors have to run before their 's. They don't right now in some cases due to some unsoundness problems but that will be fixed: .
Same for , please, for
Does the accessor itself need to be ? I don't think so, because the relevant ops are and we're only handing out shared references to it.
Change:
name_finder.ident_accumulator } <del> //fn expand_and_resolve(crate_str: @str) -> ast::crate { //let expanded_ast = expand_crate_str(crate_str); // println!("expanded: {:?}n",expanded_ast); //mtwt_resolve_crate(expanded_ast) //} //fn expand_and_resolve_and_pretty_print (crate_str: @str) -> String { //let resolved_ast = expand_and_resolve(crate_str); //pprust::to_string(&resolved_ast,fake_print_crate,get_ident_interner()) //} </del> #[test] fn macro_tokens_should_match(){ expand_crate_str( "macro_rules! m((a)=>(13)) fn main(){m!(a);}".to_string());

Discussion:
I believe this should output the string : But I get this error: Rust version:
Note that standard recursive macros work fine, e.g., And outputs . Maybe the bug here is that expanding macros within other macros is using an older environment that doesn't include the name ?
It's even worse than that. only uses the compiler built-in macros:
I think this might be a dupe of
Does fixing mean that also gets fixed? I wouldn't assume so, but it might be possible depending on the implementation. (Sorry I missed that issue. I searched for 'recursive macro' instead of 'nested macro'!)
both and use , which doesn't work with non-builtin macros.
Right. I'm referring to the recursive aspect. Wasn't sure if that would make a difference. (I just don't know enough about how macros are expanded to know. Pure guesswork on my part.)
Change:
--build=x86_64-unknown-linux-gnu  --save-toolstates=/tmp/toolstate/toolstates.json <ins> ENV HOST_TARGET x86_64-unknown-linux-gnu </ins> ENV SCRIPT /tmp/checktools.sh ../x.py &&  NODE_PATH=`npm root -g` python3 ../x.py test tests/rustdoc-gui --stage 2  --test-args "'--no-sandbox --jobs 1'"

Discussion:
We currently run Miri on tests a few select targets: However, that's not all tier 1 targets, so e.g. x8664-apple-darwin is not covered, and today's nightly contains a Miri where some APIs are broken on x8664-apple-darwin. It'd be great if we could run (some) Miri tests on all tier 1 targets. Note that Miri tests can be run on any host so this does not require running on more hosts. However we'd probably not want to test all targets on all hosts, so we need some way in to determine which host we are on, and spread the test jobs across the hosts. Also, depending on how tight our time budget is here, we might want to not run all tests -- just running the "pass" tests should generally be sufficient and can save a bunch of time. Cc -- in particular, (a) how can I check for the host in , and (b) how tight is our time budget for the "tools" builders?
Change:
<del> Subproject commit e1dabb48f0f898d1a808b3de3a26f5ee3735c7dd </del> <ins> Subproject commit f5f1ffea207b6b380127ff34f14015ae005d1413 </ins>

Discussion:
This code Will generate this IR under Yes, that is a of length 7. I have no idea why this is getting generated, I'm trying to narrow down which pass is generating this, but that is absolutely awful code to generate for such a simple operation. I would expect this function to generate two stores, one of the discriminant and one of the value. Now change the program to have in front of the enum, and we get this code:
cc
I would expect similar code generation with as well as with no annotation. Is this because we're attempting to zero-out the discriminant padding?
Look at the asm. This may actually not be so bad unless the is getting lowered to a true .
Here is the asm. It is not actually generating a call to :
the equivalent to no in this case would be , fwiw.
I agree that the assembly doesn't look that bad, but this is still completely unnecessary, no? I was looking at assembly with huge waterfalls of moving al/ax/eax/rax over and over again. I don't think this is a closed bug because this is a real problem. This may not be a high priority bug, but our assembly is certainly doing things that it doesn't need to do.
Is this ?
Aha, I see the problem: SROA happened, split up our struct into 3 elements, one of which is the padding, and stored the padding. The solution is to add , like . Closing again as a dupe.
It may be, but I don't know enough about LLVM's optimizations to know whether that would help or not.
It would be possible to make the type , and that might make the code seen here less bad, but I don't know if LLVM would be less able to optimize code that accesses the discriminant in that case. It would also be possible to make more complex and have it avoid filling in alignment padding for bytes where none of the variants have fields (so → , → ). We might need this information anyway for .
Patch has been submitted to LLVM upstream.
Change:
None => { let data = &m[0].data; for &(ref ident, ref value_ptr) in &m[0].bound_ptrs { <del> let llmatch = data.bindings_map[*ident].llmatch; call_lifetime_start(bcx, llmatch); Store(bcx, *value_ptr, llmatch); </del> <ins> let binfo = data.bindings_map[*ident]; call_lifetime_start(bcx, binfo.llmatch); if binfo.trmode == TrByRef && type_is_fat_ptr(bcx.tcx(), binfo.ty) { expr::copy_fat_ptr(bcx, *value_ptr, binfo.llmatch); } else { Store(bcx, *value_ptr, binfo.llmatch); } </ins> } match data.arm.guard { Some(ref guard_expr) => {

Discussion:
I've tried to write: The line above gives LLVM assertion. I think this must show some syntax error.
Change:
cp foo.rs $(TMPDIR)/+foo+bar $(RUSTC) $(TMPDIR)/+foo+bar 2>&1  | grep "invalid character.*in crate name:" <ins> cp foo.rs $(TMPDIR)/-foo.rs $(RUSTC) $(TMPDIR)/-foo.rs 2>&1  | grep "crate name cannot start with a hyphen:" </ins>

Discussion:
passes the crate name to verbatim, so the leading hyphen is treated as an option. I think the best solution would be to ban leading hyphens altogether, since there's no real use case for these shenanigans.
I believe we can handle crate names starts with hyphen properly, so we don't have to ban leading hyphens.
Do you have a concrete use case for them?
no, but I'd love to make Rust to handle corner cases, as people may argue Rust don't even need to work on Windows. I made a patch to fix it but failed, I'm finding the reason, hope I can make a PR today or tomorrow.
Change:
rustc.arg("-Zsimulate-remapped-rust-src-base=/rustc/FAKE_PREFIX"); rustc.arg("-Ztranslate-remapped-path-to-local-path=no"); <del> // Hide Cargo dependency sources from ui tests to make sure the error message doesn't // change depending on whether $CARGO_HOME is remapped or not. If this is not present, // when $CARGO_HOME is remapped the source won't be shown, and when it's not remapped the // source will be shown, causing a blessing hell. rustc.arg("-Z").arg(format!( "ignore-directory-in-diagnostics-source-blocks={}", home::cargo_home().expect("failed to find cargo home").to_str().unwrap() )); </del> <ins> // #[cfg(not(bootstrap))]: After beta bump, this should **always** run. if !(self.config.stage_id.starts_with("stage1-") && self.config.suite == "ui-fulldeps") { // Hide Cargo dependency sources from ui tests to make sure the error message doesn't // change depending on whether $CARGO_HOME is remapped or not. If this is not present, // when $CARGO_HOME is remapped the source won't be shown, and when it's not remapped the // source will be shown, causing a blessing hell. rustc.arg("-Z").arg(format!( "ignore-directory-in-diagnostics-source-blocks={}", home::cargo_home().expect("failed to find cargo home").to_str().unwrap() )); } </ins> // Optionally prevent default --sysroot if specified in test compile-flags. if !self.props.compile_flags.iter().any(|flag| flag.starts_with("--sysroot"))

Discussion:
When I run locally, I get errors: (Same for 27 ui-fulldeps tests in total.) I assume this happened after cc
Since CI isn't running into these issues, I'm guessing it only happens with and works fine with .
Yup, it works fine with here.
Ugh, this keeps happening to when we add new flags.
I think we should just test in CI to make sure this doesn't keep happening. See the description of to understand why ui-fulldeps actually builds with stage0, which means that modifications to the UI test code adding new flags need to make sure they're properly gating their code.
Either that, or we need something like and pass that just to the ui-fulldeps suite on stage1. That seems more like a hack though :s
should be pretty easy to extend with a --stage=1 for ui-fulldeps.
Cool, will do when I get home.
Change:
/// Checks if current token is one of tokens which cannot be nested like `kw::Enum`. In case /// it is, we try to parse the item and report error about nested types. fn recover_nested_adt_item(&mut self, keyword: Symbol) -> PResult<'a, bool> { <del> if self.token.is_keyword(kw::Enum) || </del> <ins> if (self.token.is_keyword(kw::Enum) || </ins> self.token.is_keyword(kw::Struct) || <del> self.token.is_keyword(kw::Union) </del> <ins> self.token.is_keyword(kw::Union)) && self.look_ahead(1, |t| t.is_ident()) </ins> { let kw_token = self.token.clone(); let kw_str = pprust::token_to_string(&kw_token);

Discussion:
Initially reported in and then My best guess is ; cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Interesting note: this does not apply to when in mode.
Regression introduced in . My bad... should have remembered that is contextual! The fix should be to make changes around here: You'll want to use look-ahead to ensure that an identifier follows . Also, add a regression test for , , and .
claim
Error: Parsing assign command in failed: claim Please let know if you're having trouble with this bot.
assign
You'll need to change to something along the lines of
Change:
/// # Examples /// /// ``` <del> /// #![feature(future_poll_fn)] </del> /// # async fn run() { /// use core::future::poll_fn; /// use std::task::{Context, Poll};

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --The feature gate for the issue is . <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR () [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- Should this be named instead? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial implementation in - closed as it's ambiguous, see the discussion on that PR
This exists in futures-lite, and people use it. It seems worth having available in the standard library. The naming discussion doesn't seem likely to change, and all else being equal there's a history for the name . Shall we stabilize this? merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [x] [x] [x] [ ] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), 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:
The final comment period, with a disposition to merge, as per the , is now complete.

As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. This will be merged soon.
There are some soundness issues with (not strictly speaking a soundness bug, but we might still want to do a breaking change now before there are too many people relying on this): the fact that is always is a problem. It should require for that. See for details, in particular .
I am proposing to change the impl in
Change:
/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::max_by_key(-2, 1, |x: &i32| x.abs()), -2);

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at