jiebi/CodeConvo huggingface dataset:
Code change:
} } <ins> /// Constructs a new locked handle to the standard output of the current /// process. /// /// Each handle returned is a guard granting locked access to a shared /// global buffer whose access is synchronized via a mutex. If you need /// more explicit control over locking, for example, in a multi-threaded /// program, use the [`io::stdout`] function to obtain an unlocked handle, /// along with the [`Stdout::lock`] method. /// /// The lock is released when the returned guard goes out of scope. The /// returned guard also implements the [`Write`] trait for writing data. /// /// ### Note: Windows Portability Consideration /// When operating in a console, the Windows implementation of this stream does not support /// non-UTF-8 byte sequences. Attempting to write bytes that are not valid UTF-8 will return /// an error. /// /// # Examples /// /// ```no_run /// #![feature(stdio_locked)] /// use std::io::{self, Write}; /// /// fn main() -> io::Result<()> { ///     let mut handle = io::stdout_locked(); /// ///     handle.write_all(b"hello world")?; /// ///     Ok(()) /// } /// ``` #[unstable(feature = "stdio_locked", issue = "none")] pub fn stdout_locked() -> StdoutLock<'static> { stdout().into_locked() } </ins> pub fn cleanup() { if let Some(instance) = STDOUT.get() { // Flush the data and disable buffering during shutdown

Related discussion:
text: is declared as follows: Because there is only one input lifetime (the elided lifetime of ), it is assigned to the output lifetime , which is why the lock can live at most as long as the temporary.
Thanks. I think this might be a bug in libstd (using instead of as the return type), but I'll file that separately. What I think is a diagnostic inaccuracy is that the error message refers to a borrow, when, by inspection of the library source code, no borrow is taking place in . (Unless I'm missing something?) What I think is happening is that the compiler is enforcing that lives no longer than the temporary produced by , and is misleadingly calling that a borrow in the error message.
As a simplified example: The error message refers to a borrow even when the output type of does not refer to at all!
that's because of the elision rules: on the declaration you're implicitly telling the compiler that the lifetime of the borrow matches the lifetime of the type. .
Thanks. I think the error messages could use a little more detail about how something that the borrow checker sees as a borrow may be an artifact of lifetime constraints in a function signature rather than an actual borrow in the function body. It certainly surprised me the first time I ran into it. (Maybe only in the explanatory text in the compiler error index. It looks like E0597 could also benefit from that detail, because it's a similar case, and an example in E0716 produces E0597.)
Shorter example, probably better suited for an example in the compiler error index:
Code change:
#![feature(inherent_associated_types)] #![allow(incomplete_features)] <ins> #![deny(single_use_lifetimes)] </ins> struct Foo<T>(T);

Related discussion:
text: <!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: : I expected to see this happen: explanation suggestion compiles: Instead, this happened: explanation Suggestion does not compile: ` <!-- 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. --:
Code change:
| help: try using `=` instead | <del> LL -     let x == 2; LL +     let x = 2; | </del> <ins> LL |     let x = 2; |           ~ </ins> error: aborting due to 1 previous error

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'', 'thread 'rustc' panicked at 'assertion failed: bpos.tou32() = () + as u32'' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --
cc
I suspect that we don't really need anymore, tbh.
Addressed in Every time I convince myself that "synthesizing a is ok this time", I'm proved wrong.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Code change:
use rustc::hir; use rustc::hir::itemlikevisit::ItemLikeVisitor; use rustc::hir::def_id::DefId; <del> use rustc::ty::{self, TyCtxt}; </del> <ins> use rustc::ty::{self, TyCtxt, TypeFoldable}; </ins> use rustc::ty::query::Providers; use rustc::util::nodemap::{FxHashMap, FxHashSet}; use std::collections::hash_map::Entry::{Occupied, Vacant};

Related discussion:
text: The second error in this snippet is "nonsense" because it says the type parameter is not constrained, while the real error was already reported — the actual type could not be imported. Found in: rustc 1.13.0-nightly ( 2016-09-26)
.
Code change:
match *seq_tt { TokenTree::MetaVarDecl(_, _, id) => id.name == "vis", TokenTree::Sequence(_, ref sub_seq) => <del> sub_seq.op == quoted::KleeneOp::ZeroOrMore, </del> <ins> sub_seq.op == quoted::KleeneOp::ZeroOrMore || sub_seq.op == quoted::KleeneOp::ZeroOrOne, </ins> _ => false, } }) {

Related discussion:
text: The following code will cause the compiler to fail: Playground link: It should error that the inner matcher can match an empty string and reject it, just as it does if is used in place of .
The fix should be very easy, since this was already fixed for repetitions in (original bug: ): Looks like just needs to be checked against , too.
cc
Note that with on the outside, this errors properly, although with inconsistent error messages: if the inner repetition uses only, the error is "repetition matches empty token tree", but it seems that if any of the repetitions are , then the error is "multiple successful parses".
The behaviour in my previous comment is because the check for "repetition matches empty token tree" is done at definition time, but does not catch ; this is caught at expansion time however. Ideally all of this will be moved to definition time and the expansion-time check should probably be a) corrected to address the first comment and b) possibly become an ICE, since it should never be encountered since the RFC 550 rules should eliminate all ambiguity at definition time?
Hmm... I don't really remember how most of this code works... Just grepping, but it looks like there are a couple of other places we might want to look at:
I've opened
Code change:
obj } <del> #[inline] </del> <ins> // See comment on do_try above for why #[inline(never)] is needed on bootstrap. #[cfg_attr(bootstrap, inline(never))] #[cfg_attr(not(bootstrap), inline)] </ins> fn do_call<F: FnOnce() -> R, R>(data: *mut u8) { unsafe { let data = data as *mut Data<F, R>;

Related discussion:
text: This is a regression from the last couple of days. Looks like the compiler for something forever. Curiously, the run with completes successfully. I'll investigate in more detail. The list of tests: All of the tests are supposed to report errors.
Here's the backtrace:
Looks like this is caused by the recent unwinding changes. cc
GCC toolchain version on which this reproduced:
Does this happen with stage 1 rustc or stage 2 rustc?
Stage 1, e.g. I'll check stage 2 now.
( is confirmed to be the cause, removing .)
I have a pretty good idea of what the problem might be. I'm traveling right now but I'll try to have a PR up by tonight.
The issue doesn't reproduce with a stage 2 compiler. That's great news long term, but broken stage 1 still makes any compiler work involving testing hard.
I don't have a Windows machine to test on right now, but can you try marking and with in to see if that fixes the issue?
can you try marking and with in to see if that fixes the issue? It does! Thanks for a workaround.
Code change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // aux-build:issue_41053.rs pub trait Trait { fn foo(&self) {} } pub struct Foo; impl Iterator for Foo { type Item = Box<Trait>; fn next(&mut self) -> Option<Box<Trait>> { extern crate issue_41053; impl ::Trait for issue_41053::Test { fn foo(&self) {} } Some(Box::new(issue_41053::Test)) } } fn main() { Foo.next().unwrap().foo(); } </ins>

Related discussion:
text: I was going through some refactoring and the compiler exploded. No unsafe. The last bits of code I was playing with can be found , before I tried to refactor the example, the tests were building and passing. The macro that might be to blame is . I parked a branch with the code that made it blew up, you can find it here works, blows up. a happy compiler, worst case an unhappy one a dead compiler : Backtrace:
Minimal example:
Thanks that was a quick fix. Do you have a workaround until the fix makes it to master?
The ICE occurs when you have an item referenced in an impl signature is imported from an statement occurs within an impl. To work around the ICE, you can move the call to to a different free function.
Got it, it works , thanks!
Code change:
<ins> error[E0220]: associated type `Assoc` not found for `Trait` --> $DIR/stranded-opaque.rs:8:31 | LL | fn produce<T>() -> impl Trait<Assoc = impl Trait> { |                               ^^^^^ associated type `Assoc` not found error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0220`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not unify with revealed type:', 'error: internal compiler error: could not unify with revealed type:' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
crashes since cc
Note: ICEs aren't crashes, we have a separate label for crashes (they mean segfaults and similar)
ungraceful exit of the compiler has been observed since :upsidedownface:
This has nothing to do with non-lifetime binders. I somewhat expect that when a "minimized" repro is tagged with a feature tag, there has been an attempt to check that the ICE is actually dependent on the feature, since that affects the prioritization of the issue.
Code change:
} let frame = &self.token_cursor.frame; <del> match frame.tree_cursor.look_ahead(dist - 1) { </del> <ins> looker(&match frame.tree_cursor.look_ahead(dist - 1) { </ins> Some(tree) => match tree { <del> TokenTree::Token(token) => looker(token), </del> <ins> TokenTree::Token(token) => token, </ins> TokenTree::Delimited(dspan, delim, _) => { <del> looker(&Token::new(token::OpenDelim(delim.clone()), dspan.open)) </del> <ins> Token::new(token::OpenDelim(delim), dspan.open) </ins> } }, <del> None => looker(&Token::new(token::CloseDelim(frame.delim), frame.span.close)), } </del> <ins> None => Token::new(token::CloseDelim(frame.delim), frame.span.close), }) </ins> } /// Returns whether any of the given keywords are `dist` tokens ahead of the current one.

Related discussion:
text: Between nightly-2020-09-05 and nightly-2020-09-06, libproc_macro stopped preserving the jointness of a trailing joint punctuation token in a TokenStream (likely ; This breaks some real-world code such as the following, though only with old versions of some libraries as far as I have found. I don't know which behavior above is correct but I would like it to be intentionally decided so that we know what behavior to implement in proc-macro2. fails to compile since nightly-2020-09-06:
This has also broken 's webrender-wrench, which relied on this behavior in one of the dependencies. -- do you think a revert makes sense perhaps? Is there a patch expected soon-ish?
Marking this as P-critical based on the
Code change:
} else { (None, &[][..], 0) }; <ins> let mut can_suggest_clone = true; </ins> if let Some(def_id) = def_id && let node = self.infcx.tcx.hir_node_by_def_id(def_id) && let Some(fn_sig) = node.fn_sig()

Related discussion:
text: ... and trying to use afterwards, which triggers Example: currently yields I suggest that it should also contain
AsRef is a library trait, so IMO we should not do that. Also to me "value moved here" is pretty much the "you need to use this as reference".
While this might be obvious to us, I've had students struggling strongly with these errors. When I tell them "just add an ampersand", they're like "Oh, that makes total sense". I don't see that as reason not to do it. Could you elaborate?
This should also handle , , .
and aren't as clear, since the object will be modified, so the user might also want to , but that can later be signalled through and/or multiple suggestions
Obvious way of doing this would involve making a language item or otherwise special in some other way. To me it is pretty clear that language and the standard library should be as independent as possible and IME a diagnostic is a pretty minor gain for the special casing involved. One could imagine a similar diagnostic independent of library traits (e.g. always suggest a reference for "value moved here" if there’s a trait implementation for also), but then the problem of suggestion not being always correct kicks in. So, I will not oppose a change that implements this without making any more of the libstd/libcore special and is always correct, but I have no idea how anybody even begin approaching this problem.
I fully agree that that is not desirable In clippy we have similar diagnostics which in this case would simply check for (see for all the paths that we resolve manually).
Triage: this still produces the same error message. Given the concerns voiced above, should this issue stay open? I suppose we could leave this open should someone come up with a clever way to handle this without special casing , but that seems unlikely.
We have diagnostic items nowadays, so we can make a diagnostic item and detect in in these situations. Though I'm not sure how easy it is to detect. The error may get reported far too late
Current :
Code change:
// For each token tree in `input`, parse the token into a `self::TokenTree`, consuming // additional trees if need be. <del> let mut trees = input.trees(); </del> <ins> let mut trees = input.trees().peekable(); </ins> while let Some(tree) = trees.next() { // Given the parsed tree, if there is a metavar and we are expecting matchers, actually // parse out the matcher (i.e., in `$id:ident` this would parse the `:` and `ident`). let tree = parse_tree(tree, &mut trees, parsing_patterns, sess, node_id, features, edition); match tree { TokenTree::MetaVar(start_sp, ident) if parsing_patterns => { <del> let span = match trees.next() { </del> <ins> // Not consuming the next token immediately, as it may not be a colon let span = match trees.peek() { </ins> Some(&tokenstream::TokenTree::Token( Token { kind: token::Colon, span: colon_span }, _, )) => { <ins> // Consume the colon first trees.next(); // It's ok to consume the next tree no matter how, // since if it's not a token then it will be an invalid declaration. </ins> match trees.next() { Some(tokenstream::TokenTree::Token(token, _)) => match token.ident() { Some((fragment, _)) => {

Related discussion:
text: Here's some code incorrectly defining a macro, because it's missing a fragment specifier. Here's the error message rustc gives me: It's potentially confusing that the error points to the source after the name with the missing fragment specifier. Especially in a complicated macro, it would be better if it pointed to the item which was actually missing the fragment specifier. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Some more context at
Code change:
let arenas = ty::CtxtArenas::new(); let hir_map = driver::make_map(&sess, &mut hir_forest); <del> abort_on_err(driver::phase_3_run_analysis_passes(&sess, </del> <ins> let krate_and_analysis = abort_on_err(driver::phase_3_run_analysis_passes(&sess, </ins> &cstore, hir_map, &arenas, &name, resolve::MakeGlobMap::No, <del> |tcx, _, analysis, _| { </del> <ins> |tcx, _, analysis, result| { // Return if the driver hit an err (in `result`) if let Err(_) = result { return None } </ins> let _ignore = tcx.dep_graph.in_ignore(); let ty::CrateAnalysis { access_levels, .. } = analysis;

Related discussion:
text: Any of the following uses of cause an ICE in , but not in : Use of in a local is fine; these all simply report the error without an ICE.
I believe this may be a regression caused by . Working on a fix. Edit: Maybe not, actually. Either way I'm looking into it.
Code change:
CFG_DISABLE_UNSTABLE_FEATURES=1 endif ifeq ($(CFG_RELEASE_CHANNEL),beta) <del> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta </del> <ins> CFG_RELEASE=$(CFG_RELEASE_NUM)-beta$(CFG_PRERELEASE_VERSION) </ins> # When building beta distributables just reuse the same "beta" name # so when we upload we'll always override the previous beta. This # doesn't actually impact the version reported by rustc - it's just

Related discussion:
text: current beta is 'rustc 1.1.0-beta' but it should be 'rustc 1.1.0-beta.1'
Code change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // no-prefer-dynamic #![crate_type = "proc-macro"] #![feature(proc_macro, proc_macro_lib)] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(Foo)] pub fn derive_foo(input: TokenStream) -> TokenStream { input } #[proc_macro_derive(Bar)] pub fn derive_bar(input: TokenStream) -> TokenStream { panic!("lolnope"); } </ins>

Related discussion:
text: Inlined from Another issue. If a struct has two different custom derives on it and the second one panics, the error span will point to the first one, not the one which panicked. Reproduction Script
was "Reproduction Script" supposed to be a link? I'm spinning this off from as I don't think it's going to block stabilization and/or closing that issue.
Reproduction script there is a summary tag
<details<summaryReproduction Script</summaryIn a crate called In another crate The error will highlight even though panicked. </details
This seems to be fixed now, so this issue can be closed.
I ran this as a test, and got the following output:
Code change:
original_path, target_place, span, <ins> use_spans, </ins> ) } IllegalMoveOriginKind::InteriorOfTypeWithDestructor { container_ty: ty } => {

Related discussion:
text: gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler
Code change:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'', 'thread 'rustc' panicked at 'unexpected inference var std::option::Option<&'?16 [i32; ?0c: usize]'' File: --snippet, probably from Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<perror[E0261]: use of undeclared lifetime name -- | 2 | fn constchunksexact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; | ^^ undeclared lifetime | help: consider introducing lifetime here | 2 | fn constchunksexact<'a, const N: usize(&self) -ConstChunksExact<'a, T, { N }; | +++ help: consider introducing lifetime here | 1 | trait ConstChunksExactTrait<'a, T{ | +++ error[E0261]: use of undeclared lifetime name -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | - ^^ undeclared lifetime | help: consider introducing lifetime here: error[E0046]: not all trait items implemented, missing: -- | 2 | fn constchunks_exact<const N: usize(&self) -ConstChunksExact<'a, T, { N }; |
from trait . 5 | impl<TConstChunksExactTrait<Tfor [T] {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing in implementation error[E0392]: lifetime parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^^^^ unused lifetime parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0392]: type parameter is never used -- | 7 | struct ConstChunksExact<'rem, T: 'a, const N: usize{} | ^ unused type parameter | = help: consider removing , referring to it in a field, or using a marker such as error[E0207]: the const parameter is not constrained by the impl trait, self type, or predicates -- | 9 | impl<'a, T,
Code change:
<ins> // Regression test for https://github.com/rust-lang/rust/issues/122549 // was fixed by https://github.com/rust-lang/rust/pull/122749 trait ConstChunksExactTrait<T> { fn const_chunks_exact<const N: usize>(&self) -> ConstChunksExact<'a, T, { N }>; //~^ ERROR undeclared lifetime } impl<T> ConstChunksExactTrait<T> for [T] {} //~^ ERROR not all trait items implemented, missing: `const_chunks_exact` struct ConstChunksExact<'rem, T: 'a, const N: usize> {} //~^ ERROR use of undeclared lifetime name `'a` //~^^ ERROR lifetime parameter //~^^^ ERROR type parameter impl<'a, T, const N: usize> Iterator for ConstChunksExact<'a, T, {}> { //~^ ERROR the const parameter `N` is not constrained by the impl trait, self type, or predicates //~^^ ERROR mismatched types type Item = &'a [T; N]; } fn main() { let slice = &[1i32, 2, 3, 4, 5, 6, 7, 8, 9, 10]; let mut iter = [[1, 2, 3], [4, 5, 6], [7, 8, 9]].iter(); for a in slice.const_chunks_exact::<3>() { assert_eq!(a, iter.next().unwrap()); } } </ins>

Related discussion:
text: const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^^^^^^^^^^^^^ unconstrained const parameter | = note: expressions using a const parameter must map each value to a distinct output value = note: proving the result of expressions other than the parameter are unique is not supported error[E0308]: mismatched types -- | 9 | impl<'a, T, const N: usizeIterator for ConstChunksExact<'a, T, {}{ | ^^ expected , found thread 'rustc' panicked at unexpected inference var std::option::Option<&'?16 [i32;