jiebi/CodeConvo huggingface dataset:
Change:
The terminator conceptually moves out of the return place , but this is not currently reflected by the visitor infrastructure. This can lead to incorrect dataflow solutions for . For example, reports that is dead before a , which is wrong (it must always be live there). These don't currently cause any harm, since use of is fairly limited, but they are an issue for destination propagation / NRVO, which can propagate to arbitrary places in the function and needs to have correct information to do so soundly. The simple fix of calling from within has the problem that the receives a , but the local reads from can not be changed. This can be caught with an assertion, but maybe there is a better solution for this? cc
I think any alternative will be more complex than that simple assertion. Conceptually the should contain a which is always , but then we'd need to have assertions keeping that in place, so you don't gain anything. I don't think we can generalize returning to allow using different places than , which is the only way we'd get around having to assert something somewhere.

Discussion:
TerminatorKind::Goto { .. } | TerminatorKind::Resume | TerminatorKind::Abort | <del> TerminatorKind::Return | </del> TerminatorKind::GeneratorDrop | TerminatorKind::Unreachable | TerminatorKind::FalseEdges { .. } | TerminatorKind::FalseUnwind { .. } => { } <ins> TerminatorKind::Return => { // `return` logically moves from the return place `_0`. Note that the place // cannot be changed by any visitor, though. let $($mutability)? local = RETURN_PLACE; self.visit_local( & $($mutability)? local, PlaceContext::NonMutatingUse(NonMutatingUseContext::Move), source_location, ); assert_eq!( local, RETURN_PLACE, "`MutVisitor` tried to mutate return place of `return` terminator" ); } </ins> TerminatorKind::SwitchInt { discr, switch_ty,

} // Conservatively gives up if the dest is an argument, // because there may be uses of the original argument value. <del> if body.local_kind(dest_local) == LocalKind::Arg { </del> <ins> // Also gives up on the return place, as we cannot propagate into its implicit // use by `return`. if matches!( body.local_kind(dest_local), LocalKind::Arg | LocalKind::ReturnPointer ) { </ins> debug!("  Can't copy-propagate local: dest {:?} (argument)", dest_local); continue; }

*local = self.to; } } <ins> fn visit_terminator_kind(&mut self, kind: &mut TerminatorKind<'tcx>, location: Location) { match kind { TerminatorKind::Return => { // Do not replace the implicit `_0` access here, as that's not possible. The // transform already handles `return` correctly. } _ => self.super_terminator_kind(kind, location), } } </ins> } struct DerefArgVisitor<'tcx> {

} fn visit_terminator_kind(&mut self, kind: &mut TerminatorKind<'tcx>, loc: Location) { <del> self.super_terminator_kind(kind, loc); </del> <ins> // Don't try to modify the implicit `_0` access on return (`return` terminators are // replaced down below anyways). if !matches!(kind, TerminatorKind::Return) { self.super_terminator_kind(kind, loc); } </ins> match *kind { TerminatorKind::GeneratorDrop | TerminatorKind::Yield { .. } => bug!(),
Change:
--enable-debug should add -Z debug-info to RUSTFLAGS now that it has been somewhat fixed. Note that due to a bug in LLVM it is still broken on Windows so it should not be on Windows.
Blocked on ; at present, rustc can't be built with .
This is still blocked.
doesn't have a option any more. Is this issue still valid?
Updating title to reflect that is now
Yes. It's now . , Chris Wong :
Alias . I believe that long property names should be preferred in most cases, for the same reasons as you would name such a boolean variable or and not .

Discussion:
CFG_DISABLE_OPTIMIZE=1 CFG_DISABLE_OPTIMIZE_CXX=1 fi <del> CFG_ENABLE_LLVM_ASSERTIONS=1 </del> CFG_ENABLE_DEBUG_ASSERTIONS=1 CFG_ENABLE_DEBUG_JEMALLOC=1 <ins> CFG_ENABLE_DEBUGINFO=1 CFG_ENABLE_LLVM_ASSERTIONS=1 </ins> fi # OK, now write the debugging options
Change:
() Errors: Backtrace: modify labels: +I-hang +T-compiler +C-bug +A-lifetimes
somewhat minimized: To replicate this I needed: async two other arguments by ref at least one arg must not be bound to , compiles quickly the problematic argument must be contain an indirection: compiles fine. and also freeze. and a trait object containing at least one non marker trait explicitly bound to . and are both ok
repro is a regression in 1.43. It compiles immediately with 1.39 through 1.42.
I am currently bisecting this using
regression in modify labels: -E-needs-bisection
FYI who had context on .

Discussion:
} } <del> debug!("enforce_member_constraint: final least choice = {:?}", least_choice); if least_choice != member_lower_bound { </del> <ins> // (#72087) Different `ty::Regions` can be known to be equal, for // example, we know that `'a` and `'static` are equal in a function // with a parameter of type `&'static &'a ()`. // // When we have two equal regions like this `expansion` will use // `lub_concrete_regions` to pick a canonical representative. The same // choice is needed here so that we don't end up in a cycle of // `expansion` changing the region one way and the code here changing // it back. let lub = self.lub_concrete_regions(least_choice, member_lower_bound); debug!( "enforce_member_constraint: final least choice = {:?}nlub = {:?}", least_choice, lub ); if lub != member_lower_bound { </ins> *var_values.value_mut(member_vid) = VarValue::Value(least_choice); true } else {

self.tcx().mk_region(ReScope(lub)) } <del> (&ReEarlyBound(_), &ReEarlyBound(_) | &ReFree(_)) | (&ReFree(_), &ReEarlyBound(_) | &ReFree(_)) => { </del> <ins> (&ReEarlyBound(_) | &ReFree(_), &ReEarlyBound(_) | &ReFree(_)) => { </ins> self.region_rels.lub_free_regions(a, b) }

<ins> // Regression test for #72051, hang when resolving regions. // check-pass // edition:2018 pub async fn query<'a>(_: &(), _: &(), _: (&(dyn std::any::Any + 'a),) ) {} fn main() {} </ins>
Change:
[edit: better minified version in the next comment] With, in : (If I didn't make a mistake in the process, I haven't been able to reproduce by reproducing manually what the crate does, so I'd guess it's probably related to it actually being a proc macro) : Also failed with: <details<summary<strongBacktrace</strong</summary<p</p</details
I've just found a better minified version: Note that when removing the after the , the ICE vanishes (hence my originally thinking I couldn't simplify the example more, as my auto-format would remove the comma)

Discussion:
pub fn generate_fn_name_span(&self, span: Span) -> Option<Span> { let prev_span = self.span_extend_to_prev_str(span, "fn", true); <del> self.span_to_snippet(prev_span) .map(|snippet| { let len = snippet .find(|c: char| !c.is_alphanumeric() && c != '_') .expect("no label after fn"); prev_span.with_hi(BytePos(prev_span.lo().0 + len as u32)) }) .ok() </del> <ins> if let Ok(snippet) = self.span_to_snippet(prev_span) { debug!( "generate_fn_name_span: span={:?}, prev_span={:?}, snippet={:?}", span, prev_span, snippet ); if snippet.is_empty() { return None; }; let len = snippet .find(|c: char| !c.is_alphanumeric() && c != '_') .expect("no label after fn"); Some(prev_span.with_hi(BytePos(prev_span.lo().0 + len as u32))) } else { None } </ins> } /// Takes the span of a type parameter in a function signature and try to generate a span for
Change:
, where it should be "Arbitrary self types". CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
So what happened to them? I still consider them to be faulty code, but I assume there's a discussion that led to the removal of this error. There ought to be more information about that on the page.
I do not see that note for E0307 (but do see it for others, like E001). We do not remove documentation for error codes because people can use older compilers and might need help when googling for those errors they might see. As to what happened to them, they sometimes get superseded by other, more specific errors, and other times the compiler started accepting the code due to new features.
claim

Discussion:
} ``` <del> The nightly feature [Arbintrary self types][AST] extends the accepted </del> <ins> The nightly feature [Arbitrary self types][AST] extends the accepted </ins> set of receiver types to also include any type that can dereference to `Self`:
Change:
rustc panic when running . The crate otherwise seems to test, run & work fine. Checkout rev . Run . <!-- 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
somewhat minified:
Somewhat interesting: nightly-2018-01-17 gives me: and cargo check as gives me the same error message. On nightly-2019-01-17 on the other hand cargo doc panics and cargo check does not complain any more: Edit: nightly-2018-12-01 gives me exactly no output. No warning, no ICE. That is weird as well...
Regression in nightly-2018-12-08 (...) (nightly-2018-12-07 is not available) The "no output" regression (from rejecting the program as such and giving no output at all) is in nightly-2018-09-13 (...)
The latter is an intended change caused by
This is still occurring, the panic seems to come from . Updated info: : <details<summary<strongBacktrace</strong</summary<p</p</details
Assigning as and removing .

Discussion:
) -> Option<(ty::ParamEnv<'tcx>, ty::ParamEnv<'tcx>)> { let tcx = infcx.tcx; <ins> // Don't try to proess any nested obligations involving predicates // that are already in the `ParamEnv` (modulo regions): we already // know that they must hold. for predicate in param_env.caller_bounds() { fresh_preds.insert(self.clean_pred(infcx, predicate)); } </ins> let mut select = SelectionContext::with_negative(&infcx, true); let mut already_visited = FxHashSet::default();

<ins> // Regression test for issue #72213 // Tests that we don't ICE when we have projection predicates // in our initial ParamEnv pub struct Lines<'a, L> where L: Iterator<Item = &'a ()>, { words: std::iter::Peekable<Words<'a, L>>, } pub struct Words<'a, L> { _m: std::marker::PhantomData<&'a L>, } impl<'a, L> Iterator for Words<'a, L> where L: Iterator<Item = &'a ()>, { type Item = (); fn next(&mut self) -> Option<Self::Item> { unimplemented!() } } </ins>
Change:
In an obscure situation with a typo (where there is a comma instead of a period), rustc will suggest replacing the comma with a semicolon, which will fail to compile. Produces the following error and suggestion: Some observations: This must be a let binding. The method calls must be on separate lines (all on one line gives a different error). I would expect this to provide the same error if it is all on one line ("expected one of , , , or an operator"), possibly with a "maybe incorrect" suggestion to replace it with a period (maybe only if the following character is not whitespace?). Note: Feel free to close this. This is really obscure, and I suspect it is not trivial to change, and it is fairly obvious what is wrong. I just thought it was strange, and I was doubly puzzled that the indentation mattered. rustc 1.45.0-nightly ( 2020-05-10) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is because the error recovery tries to figure out if you typoed something when trying to write ; to end an expression. This is probably easy to fix.
claim
Thoughts about the better approach?: vs.
I would prefer something closer to what we already see in other syntax errors: We are not afraid of using vertical space to make errors clearer, but that vertical space still comes at a premium, as does verbosity. We try to lean towards the tersest possible output that can still convey the concept to the broadest set of people.
Merged. Thanks for a good learning issue And thanks for mentoring it I really appreciate your time!

Discussion:
return self.expect(&token::Semi).map(drop); } else if !sm.is_multiline(self.prev_token.span.until(self.token.span)) { // The current token is in the same line as the prior token, not recoverable. <ins> } else if [token::Comma, token::Colon].contains(&self.token.kind) && &self.prev_token.kind == &token::CloseDelim(token::Paren) { // Likely typo: The current token is on a new line and is expected to be // `.`, `;`, `?`, or an operator after a close delimiter token. // // let a = std::process::Command::new("echo") //         .arg("1") //         ,arg("2") //         ^ // https://github.com/rust-lang/rust/issues/72253 self.expect(&token::Semi)?; return Ok(()); </ins> } else if self.look_ahead(1, |t| { t == &token::CloseDelim(token::Brace) || t.can_begin_expr() && t.kind != token::Colon }) && [token::Comma, token::Colon].contains(&self.token.kind)

<ins> fn main() { let a = std::process::Command::new("echo") .arg("1") ,arg("2") //~ ERROR expected one of `.`, `;`, `?`, or an operator, found `,` .output(); } </ins>

<ins> error: expected one of `.`, `;`, `?`, or an operator, found `,` --> $DIR/issue-72253.rs:4:9 | LL |         .arg("1") |                  - expected one of `.`, `;`, `?`, or an operator LL |         ,arg("2") |         ^ unexpected token error: aborting due to previous error </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. --reduced 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc although I think they might've already seen this?
claim

Discussion:
} pub fn get_path_res(&self, id: NodeId) -> Res { <del> let hir_id = self.tcx.hir().node_id_to_hir_id(id); </del> <ins> // FIXME(#71104) let hir_id = match self.tcx.hir().opt_node_id_to_hir_id(id) { Some(id) => id, None => return Res::Err, }; </ins> match self.tcx.hir().get(hir_id) { Node::TraitRef(tr) => tr.path.res,

<ins> // compile-flags: -Z save-analysis fn main() { let _: Box<(dyn ?Sized)>; //~^ ERROR `?Trait` is not permitted in trait object types //~| ERROR at least one trait is required for an object type } </ins>

<ins> error: `?Trait` is not permitted in trait object types --> $DIR/issue-72267.rs:4:21 | LL |     let _: Box<(dyn ?Sized)>; |                     ^^^^^^ error[E0224]: at least one trait is required for an object type --> $DIR/issue-72267.rs:4:17 | LL |     let _: Box<(dyn ?Sized)>; |                 ^^^^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0224`. </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Miri fix:
This appears to be fixed
We fixed it in the Miri repo but have not yet updated the rustc repo for that. Let's keep the issue open until that happened.
Apologies! Where should I check in the future to be sure it's fixed?
No worries. :) You can check the toolstate page: https://rust-lang- (Or you can skip these miri issues if that's easier for you; I think I am taking care of them quite well -- though more eyes and more help are of course always appreciated.)
Thanks, gonna bookmark that. I was going through unlabeled issues which is how I stumbled here.
Hm, we could maybe have the bot that creates them also automatically apply "A-miri C-bug" or so... Cc

Discussion:
<del> Subproject commit 10419b3f2fc625bb9d746c16d768e433a894484d </del> <ins> Subproject commit a6c28f08458e15cead0e80f3b5b7009786bce4a4 </ins>
Change:
Gives: I think a better error message should suggest the usage of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This gets us to:
Format and help message revised to:
Merged. Thanks for the report!

Discussion:
} } <ins> // If this was a missing `@` in a binding pattern // bail with a suggestion // https://github.com/rust-lang/rust/issues/72373 if self.prev_token.is_ident() && &self.token.kind == &token::DotDot { let msg = format!( "if you meant to bind the contents of  the rest of the array pattern into `{}`, use `@`", pprust::token_to_string(&self.prev_token) ); expect_err .span_suggestion_verbose( self.prev_token.span.shrink_to_hi().until(self.token.span), &msg, " @ ".to_string(), Applicability::MaybeIncorrect, ) .emit(); break; } </ins> // Attempt to keep parsing if it was an omitted separator. match f(self) { Ok(t) => {

<ins> fn foo(c: &[u32], n: u32) -> u32 { match *c { [h, ..] if h > n => 0, [h, ..] if h == n => 1, [h, ref ts..] => foo(c, n - h) + foo(ts, n), //~^ ERROR expected one of `,`, `@`, `]`, or `|`, found `..` [] => 0, } } </ins>

<ins> error: expected one of `,`, `@`, `]`, or `|`, found `..` --> $DIR/issue-72373.rs:5:19 | LL |         [h, ref ts..] => foo(c, n - h) + foo(ts, n), |                   ^^ expected one of `,`, `@`, `]`, or `|` | help: if you meant to bind the contents of the rest of the array pattern into `ts`, use `@` | LL |         [h, ref ts @ ..] => foo(c, n - h) + foo(ts, n), |                    ^ error: aborting due to previous error </ins>
Change:
I'm running via on a small project with multiple crates via the workspaces feature, and I get the following error (I've sanitized the paths, project name and dependencies): ~ It always fails with random external dependencies or crates that are part of the workspace. It does succeed however for a crate without any dependencies. I've tried with Rust 1.43.0 and 1.43.1, on openSUSE Tumbleweed Linux, both from the distributions repository () and (). I've also tried with latest nightly with the same outcome. : ~ <details<summaryBacktrace</summary<p~ </p</details
I've tried to create a minimal example that would trigger the issue but failed to do so... Perhaps one of my dependencies generates the issue? (However in my workspace I also have one crate that depends only on another internal one (which itself has no further dependencies) and it still fails.) I'm willing to experiment if someone gives me some pointers!
OK, I've found the issue: create two libraries and , with nothing more than an edition 2018 and an empty as their code; make them part of the same workspace; make depend on ; add a in (the library that depends on ); At the following link there is a simple project that rebuilds all of the above: succeeds, meanwhile fails with the aforementioned error. It appears that by just adding (after the no implicit import prelude) is enough to make the documentation build. A second solution would be to add after the no import prelude annotation.
Possibly related to
Regression in nightly-2019-11-15 Most likely caused by <details<summaryFull bisection </summary</detailsThis also means you can't document librustdoc. <details<summaryBacktrace </summary</details
the cause is already known: But I don't know why you say librustdoc can't be documented, it's right here on the site: Make sure you're passing , it's stage 0 by default.
oh look, I knew I'd seen this bug before, apparently I just forgot. The fix for this is to turn the into a .

Discussion:
sess.time("load_extern_crates", || { for extern_name in &extern_names { debug!("loading extern crate {}", extern_name); <del> resolver </del> <ins> if let Err(()) = resolver </ins> .resolve_str_path_error( DUMMY_SP, extern_name, TypeNS, LocalDefId { local_def_index: CRATE_DEF_INDEX }.to_def_id(), <del> ) .unwrap_or_else(|()| { panic!("Unable to resolve external crate {}", extern_name) }); </del> <ins> ) { warn!("unable to resolve external crate {} (do you have an unused `--extern` crate?)", extern_name) } </ins> } }); });

<ins> // compile-flags: --extern zip=whatever.rlib #![deny(broken_intra_doc_links)] /// See [zip] crate. //~^ ERROR unresolved pub struct ArrayZip; </ins>

<ins> error: unresolved link to `zip` --> $DIR/unused-extern-crate.rs:3:10 | LL | /// See [zip] crate. |          ^^^ no item named `zip` in scope | note: the lint level is defined here --> $DIR/unused-extern-crate.rs:2:9 | LL | #![deny(broken_intra_doc_links)] |         ^^^^^^^^^^^^^^^^^^^^^^ = help: to escape `[` and `]` characters, add '' before them like `[` or `]` error: aborting due to previous error </ins>
Change:
Discovered when playing with new asm! macro with following code: asm! usage to building will result in error, because this is invalid register name ( this is 100% correct) back to (same code as in 1) build will result with ICE: disable incremental compilation : also fails on x86_64-pc-windows-gnu
cc
It looks like you're missing the modifier here:
That doesn't seem to work since isn't .
It looks like it's nececessary to declare in both and . The error is caused by the wrong trait being used (there are two - one for each crate that calls . Do you want to use your apporach, or should I open a PR with the arena changes?
I'm getting an ICE even after that looks like Is this caused by the same thing or do I submit a bug report?
It's the same issue.

Discussion:
[few] hir_definitions: rustc_hir::definitions::Definitions, [] hir_owner: rustc_middle::hir::Owner<$tcx>, [] hir_owner_nodes: rustc_middle::hir::OwnerNodes<$tcx>, <ins> // Note that this deliberately duplicates items in the `rustc_hir::arena`, // since we need to allocate this type on both the `rustc_hir` arena // (during lowering) and the `librustc_middle` arena (for decoding MIR) [decode] asm_template: rustc_ast::ast::InlineAsmTemplatePiece, </ins> ], $tcx); ) }

<ins> // revisions: rpass1 cfail1 rpass3 // only-x86_64 // Regression test for issue #72386 // Checks that we don't ICE when switching to an invalid register // and back again #![feature(asm)] #[cfg(any(rpass1, rpass3))] fn main() { unsafe { asm!("nop") } } #[cfg(cfail1)] fn main() { unsafe { asm!("nop",out("invalid_reg")_) //[cfail1]~^ ERROR invalid register } } </ins>