jiebi/CodeConvo huggingface dataset:
Change:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a malformed float error, so low priority. Affected versions: probably all versions since that panic was introduced, I tried nightly 2021-11-07 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsA quick inspection of the code shows that the similar case is handled the same as : So if I had to guess I would say that the match is missing this one case, so should be handled the same as : But no idea what does that code even do, it has a FIXME by so maybe he knows better. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Discussion:
[IdentLike(_), Punct('+' | '-')] | // 1e+2 | 1e-2 [IdentLike(_), Punct('+' | '-'), IdentLike(_)] | <ins> // 1.2e+ | 1.2e- [IdentLike(_), Punct('.'), IdentLike(_), Punct('+' | '-')] | </ins> // 1.2e+3 | 1.2e-3 [IdentLike(_), Punct('.'), IdentLike(_), Punct('+' | '-'), IdentLike(_)] => { // See the FIXME about `TokenCursor` above.

<ins> fn main() { a.5.2E+ //~^ ERROR: unexpected token: `5.2E+` //~| ERROR: expected one of `.`, `;`, `?`, `}`, or an operator, found `5.2E+` //~| ERROR: expected at least one digit in exponent } </ins>

<ins> error: expected at least one digit in exponent --> $DIR/issue-90728.rs:2:7 | LL |     a.5.2E+ |       ^^^^^ error: unexpected token: `5.2E+` --> $DIR/issue-90728.rs:2:7 | LL |     a.5.2E+ |       ^^^^^ error: expected one of `.`, `;`, `?`, `}`, or an operator, found `5.2E+` --> $DIR/issue-90728.rs:2:7 | LL |     a.5.2E+ |       ^^^^^ expected one of `.`, `;`, `?`, `}`, or an operator error: aborting due to 3 previous errors </ins>

// FIXME: The following limits should be reduced eventually. const ROOT_ENTRY_LIMIT: usize = 983; const ISSUES_ENTRY_LIMIT: usize = 2310; <del> const PARSER_LIMIT: usize = 1010; </del> <ins> const PARSER_LIMIT: usize = 1012; </ins> fn check_entries(path: &Path, bad: &mut bool) { let dirs = walkdir::WalkDir::new(&path.join("test/ui"))
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
<del> Subproject commit 9c18177cd36fe07a3c251234240a9c77a4e66785 </del> <ins> Subproject commit a8b976eb350acec83280a0cd1ca3ac99faff67bc </ins>
Change:
Looks like it's possible to for a stricter lifetime than the one used in the type: ... which allows to essentially transmute from to , leading to unsoundness: On my machine, it prints:
oops...
Looks like this regressed in 1.56.0.
introduced this
Re-opening to track beta/stable backport.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
(I'm investigating making a more limited version of this PR for backporting to beta/stable.)
we ended up backporting itself to the 1.57 release. So this is now closed.

Discussion:
ty::PredicateKind::ConstEvaluatable(a), ty::PredicateKind::ConstEvaluatable(b), ) => tcx.try_unify_abstract_consts((a, b)), <del> (ty::PredicateKind::TypeOutlives(a), ty::PredicateKind::TypeOutlives(b)) => { relator.relate(predicate.rebind(a.0), p.rebind(b.0)).is_ok() </del> <ins> ( ty::PredicateKind::TypeOutlives(ty::OutlivesPredicate(ty_a, lt_a)), ty::PredicateKind::TypeOutlives(ty::OutlivesPredicate(ty_b, lt_b)), ) => { relator.relate(predicate.rebind(ty_a), p.rebind(ty_b)).is_ok() && relator.relate(predicate.rebind(lt_a), p.rebind(lt_b)).is_ok() </ins> } _ => predicate == p, }

<ins> struct Wrapper<'a, T>(&'a T) where T: 'a; impl<'a, T> Drop for Wrapper<'a, T> where T: 'static, //~^ error: `Drop` impl requires `T: 'static` but the struct it is implemented for does not { fn drop(&mut self) {} } fn main() {} </ins>

<ins> error[E0367]: `Drop` impl requires `T: 'static` but the struct it is implemented for does not --> $DIR/relate_lt_in_type_outlives_bound.rs:7:8 | LL |     T: 'static, |        ^^^^^^^ | note: the implementor must specify the same requirement --> $DIR/relate_lt_in_type_outlives_bound.rs:1:1 | LL | / struct Wrapper<'a, T>(&'a T) LL | | where LL | |     T: 'a; | |__________^ error: aborting due to previous error For more information about this error, try `rustc --explain E0367`. </ins>
Change:
<!-- 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- (which has a zero width space between the and its ending ) The current output is: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --If there are any non-printing characters, show where they are (debug unicode representation on the whole string, maybe?), and if there's only one printing character, make a suggestion to remove everything but the printing character. <!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

Discussion:
Applicability::MachineApplicable, ); } <ins> } else { let printable: Vec<char> = lit .chars() .filter(|&x| { unicode_width::UnicodeWidthChar::width(x).unwrap_or(0) != 0 && !x.is_whitespace() }) .collect(); if let [ch] = printable.as_slice() { has_help = true; handler.span_note( span, &format!( "there are non-printing characters, the full sequence is `{}`", lit.escape_default(), ), ); handler.span_suggestion( span, "consider removing the non-printing characters", ch.to_string(), Applicability::MaybeIncorrect, ); } </ins> } if !has_help {

<ins> // This tests that the error generated when a character literal has multiple // characters in it contains a note about non-printing characters. fn main() { let _hair_space_around = ' x​'; //~^ ERROR: character literal may only contain one codepoint //~| NOTE: there are non-printing characters, the full sequence is `u{200a}xu{200b}` //~| HELP: consider removing the non-printing characters //~| SUGGESTION: x } </ins>

<ins> error: character literal may only contain one codepoint --> $DIR/whitespace-character-literal.rs:5:30 | LL |     let _hair_space_around = ' x​'; |                              ^--^ |                               | |                               help: consider removing the non-printing characters: `x` | note: there are non-printing characters, the full sequence is `u{200a}xu{200b}` --> $DIR/whitespace-character-literal.rs:5:31 | LL |     let _hair_space_around = ' x​'; |                               ^^ error: aborting due to previous error </ins>

// FIXME: The following limits should be reduced eventually. const ROOT_ENTRY_LIMIT: usize = 1102; const ISSUES_ENTRY_LIMIT: usize = 2310; <del> const PARSER_LIMIT: usize = 1004; </del> <ins> const PARSER_LIMIT: usize = 1005; </ins> fn check_entries(path: &Path, bad: &mut bool) { let dirs = walkdir::WalkDir::new(&path.join("test/ui"))
Change:
I tried this code: () I expected to see this happen: the code compiles fine. Instead, this happened: and fails to type check, and although the error message is not related to type inference, annotating the type parameter fixes the problem. the same thing happens when removing the bound , but then for all . Seems to be related to . cc <details<summaryError message</summary<p</p</details Tested on nightly branches of playground: Nightly version: 1.58.0-nightly (2021-11-09 )
label T-compiler, A-typesystem, A-lifetimes, A-inference, A-closures, A-traits
Prior to v1.56, closures and functions all fail alike with the same error message and adding type annotations didn't help either. So my guess is that (edit: and ) introduced an (incomplete?) fix, so I think this now needs to: address the inconsistency improve error message to require type annotations label A-diagnostics
While changing the error message could improve the situation, this is clearly not exclusively a diagnostics issue, AFAICT. To avoid potential confusion, let me remove the A-diagnostics label, which is commonly applied to issues that are purely diagnostics issues. label -A-diagnostics. In case it is decided that this is only a diagnostics issue after all, the label can be reapplied. In case the inconsistency is somehow fixed and diagnostics issues remain, a new A-diagnostics issue can be opened.
I've just been aware of the version differences and recent efforts to solve this. So here is a summary: Prior to 1.56, all cases failed even with type annotations. On 1.56 (due to ??), all cases still fail but type annotation workaround now works. On nightly (due to ??), closures (rather than functions) no longer require type annotation. A duplicate of .
closed as a dupe, there are additional testcases in that issue that should probably be checked when fixing this.

Discussion:
fn main() { foo::<Vec<u32>>(vec![]); } <ins> mod another { use std::ops::Deref; fn test<T, TDeref>() where T: Deref<Target = TDeref>, TDeref: ?Sized, for<'a> &'a TDeref: IntoIterator, for<'a> <&'a TDeref as IntoIterator>::IntoIter: Clone, { } fn main() { test::<Vec<u8>, _>(); } } </ins>

<ins> // check-pass trait Variable<'a> { type Type; } impl Variable<'_> for () { type Type = (); } fn check<F, T>(_: F) where F: Fn(T), // <- if removed, all fn_* then require type annotations F: for<'a> Fn(<T as Variable<'a>>::Type), T: for<'a> Variable<'a>, { } fn test(arg: impl Fn(())) { fn fn_1(_: ()) {} let fn_2 = |_: ()| (); let fn_3 = |a| fn_1(a); let fn_4 = arg; check(fn_1); // Error check(fn_2); // Ok check(fn_3); // Ok check(fn_4); // Error } fn main() {} </ins>
Change:
Running the tests from run-make-fulldeps, I found this one falling It is complaining that , and indeed this file is not in the set in the second one found after . A simple reveals that this file is present in that is included in the first . The second one have , that contains a different , with a different hash () I am not sure if the bug is that the second is missing this directory, or we are calling the wrong that indeed requires the with a different hash.
Do you happen to have any settings? I can't reproduce this with the given command. Does it happen even after an ?
There is a , that once removed comments and empty lines is like: Seems that is reproducible after a clean: Do you think that can be something in the I can experiment dropping features from there.
You are totally correct here. Is the and the parameter. If I set it to I get the error, and I a remove the line I get a succeed. Not clear why.
Hmm, I wonder if is related.

Discussion:
# ignore-cross-compile include ../tools.mk <ins> export LD_LIBRARY_PATH := $(HOST_RPATH_DIR) </ins> all: $(RUSTC) foo.rs -g -O RUSTC="$(RUSTC_ORIGINAL)" $(call RUN,foo)
Change:
I tried this code: I expected to see this happen: returns os error 3 () Instead, this happened: it returns os error 123 () This is problematic as doesn't become but , which isn't useful for most users. Other platforms like Linux return so the former behavior should be correct here. : The issue doesn't happen on , I think the regression was introduced by .
Thanks for finding and fixing that! I do think that should be mapped to an . It means "The filename, directory name, or volume label syntax is incorrect". So a syntax error basically. But I don't think that should block your current PR.
Sounds good, maybe it should be ? (EDIT: Opened )
is it intentional that E-medium is instead of P-medium?
Oh oops.

Discussion:
// This will fail if the path isn't converted to verbatim. path.push("a"); fs::create_dir(&path).unwrap(); <ins> // #90940: Ensure an empty path returns the "Not Found" error. let path = Path::new(""); assert_eq!(path.canonicalize().unwrap_err().kind(), crate::io::ErrorKind::NotFound); </ins> }

const UNC_PREFIX: &[u16] = &[SEP, SEP, QUERY, SEP, U, N, C, SEP]; let mut path = to_u16s(path)?; <del> if path.starts_with(VERBATIM_PREFIX) || path.starts_with(NT_PREFIX) { // Early return for paths that are already verbatim. </del> <ins> if path.starts_with(VERBATIM_PREFIX) || path.starts_with(NT_PREFIX) || path == &[0] { // Early return for paths that are already verbatim or empty. </ins> return Ok(path); } else if path.len() < LEGACY_MAX_PATH { // Early return if an absolute path is less < 260 UTF-16 code units.

// Make sure opening a drive will work. check("Z:", "Z:"); <del> // An empty path or a path that contains null are not valid paths. assert!(maybe_verbatim(Path::new("")).is_err()); </del> <ins> // A path that contains null is not a valid path. </ins> assert!(maybe_verbatim(Path::new("0")).is_err()); }
Change:
This code on the playground produces the following error Note how the 2nd note is dangling: no span is shown after it says 'could also refer to the enum defined here'. I was not able to reproduce this locally, so this might also have to do with something special the playground is doing -- Cc
I’d guess it has something to do with the number of crates and their types available by default. For example, just typing by itself says:
I think the standard library is not always distributed with sources, which sometimes causes weird diagnostics. That could be what's happening here.
Yes, the playground , which doesn't include the component. As an example:

Discussion:
fn binding_description(&self, b: &NameBinding<'_>, ident: Ident, from_prelude: bool) -> String { let res = b.res(); <del> if b.span.is_dummy() { </del> <ins> if b.span.is_dummy() || self.session.source_map().span_to_snippet(b.span).is_err() { </ins> // These already contain the "built-in" prefix or look bad with it. let add_built_in = !matches!(b.res(), Res::NonMacroAttr(..) | Res::PrimTy(..) | Res::ToolMod);
Change:
We have a Rust-2015 doc test which has an which started failing to build on nightly 2021-11-21 (but passes on stable/2021-11-20). It now fails with
Probably caused by (; no rollup?).
That seems unlikely, is more plausible. doesn't affect doctests.
Oh, I think I got misled by the "rustdoc" bit.
I can't reproduce this. I tried /// extern crate inner; /// and running , but all the tests passed fine. can you link the original code?
The failure is You can see the first failure in CI at
The following seems like a minimal reproduction when used with 2015: /// extern crate mycrate; /// mycrate::foo(); /// Bisected to .
cc , I think it might make sense to revert temporarily unless you already have an idea for a fix.

Discussion:
Ok(P(T::recovered(Some(QSelf { ty, path_span, position: 0 }), path))) } <del> pub(super) fn maybe_consume_incorrect_semicolon(&mut self, items: &[P<Item>]) -> bool { </del> <ins> pub fn maybe_consume_incorrect_semicolon(&mut self, items: &[P<Item>]) -> bool { </ins> if self.eat(&token::Semi) { let mut err = self.struct_span_err(self.prev_token.span, "expected item, found `;`"); err.span_suggestion_short(

<del> use rustc_ast::{self as ast, token}; </del> <ins> use rustc_ast as ast; </ins> use rustc_data_structures::fx::{FxHashMap, FxHashSet}; use rustc_data_structures::sync::Lrc; use rustc_errors::{ColorConfig, ErrorReported, FatalError};

use rustc_errors::emitter::{Emitter, EmitterWriter}; use rustc_errors::Handler; use rustc_parse::maybe_new_parser_from_source_str; <ins> use rustc_parse::parser::ForceCollect; </ins> use rustc_session::parse::ParseSess; use rustc_span::source_map::FilePathMapping;

} }; <del> match parser.parse_mod(&token::Eof) { Ok((_attrs, items, _span)) => { for item in items { </del> <ins> loop { match parser.parse_item(ForceCollect::No) { Ok(Some(item)) => { </ins> if !found_main { if let ast::ItemKind::Fn(..) = item.kind { if item.ident.name == sym::main {

break; } } <ins> Ok(None) => break, Err(mut e) => { e.cancel(); break; } </ins> } <del> Err(mut e) => { e.cancel(); } </del> <ins> // The supplied slice is only used for diagnostics, // which are swallowed here anyway. parser.maybe_consume_incorrect_semicolon(&[]); </ins> } // Reset errors so that they won't be reported as compiler bugs when dropping the

<ins> // no-prefer-dynamic #![crate_type = "lib"] pub fn empty() {} </ins>

<ins> // compile-flags: --test --crate-name=empty_fn --extern=empty_fn --test-args=--test-threads=1 // aux-build:empty-fn.rs // check-pass // normalize-stdout-test: "src/test/rustdoc-ui" -> "$$DIR" // normalize-stdout-test "finished in d+.d+s" -> "finished in $$TIME" // edition:2021 /// <https://github.com/rust-lang/rust/issues/91134> /// /// ``` /// extern crate empty_fn; /// empty_fn::empty(); /// ``` pub struct Something; </ins>

<ins> running 1 test test $DIR/issue-91134.rs - Something (line 10) ... ok test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in $TIME </ins>
Change:
() <details<summaryBacktrace (click to expand)</summary` </details label requires-nightly, F-genericassociatedtypes, A-traits, A-lifetimes, A-associated_items, A-typesystem, T-compiler I'm not whether I'd expect this code to fail or to compile successfully (though I might be leaning towards expecting the latter).
No longer ICEs since
GATs issue triage: not blocking. Fixed and needs test.

Discussion:
<ins> // check-pass pub trait Associate { type Associated; } pub struct Wrap<'a> { pub field: &'a i32, } pub trait Create<T> { fn create() -> Self; } pub fn oh_no<'a, T>() where Wrap<'a>: Associate, <Wrap<'a> as Associate>::Associated: Create<T>, { <Wrap<'a> as Associate>::Associated::create(); } pub fn main() {} </ins>

<ins> // check-pass #![feature(generic_associated_types)] trait Foo<T> { type Type<'a> where T: 'a; } impl<T> Foo<T> for () { type Type<'a> where T: 'a, = (); } fn foo<T>() { let _: for<'a> fn(<() as Foo<T>>::Type<'a>, &'a T) = |_, _| (); } pub fn main() {} </ins>
Change:
For example, I can't click any links (i.e., when I click them, nothing happens) in header. Likewise, I can't click any links for , but I can click links in , which has no tag. This same behavior occurs in the docs, though every method is documented and thus has a tag, so there's no comparison to non- methods. This is a regression in nightly 1.58.0. I'm using Safari on macOS; I don't know if this reproduces on other browsers.
This is probably ; I don't know why that change was made or if this is intentional. cc
I can't imagine this part of the behavior is intentional, since it breaks a lot of rustdoc's UI.
We really need more GUI tests so this can't happen again...
Can confirm, that wasn't intentional. I manually checked during development to make sure that wouldn't happen, but it must have broken. Sorry for that, and sorry for not adding a GUI test for it. I'll post a fix in a moment.
Assigning priority as in the prioritization working group.

Discussion:
onEachLazy(document.querySelectorAll(".rustdoc-toggle > summary:not(.hideme)"), function(el) { el.addEventListener("click", function(e) { <del> if (e.target.tagName != "SUMMARY") { </del> <ins> if (e.target.tagName != "SUMMARY" && e.target.tagName != "A") { </ins> e.preventDefault(); } });

assert-attribute: (".impl-items .rustdoc-toggle", {"open": ""}) click: ".impl-items .rustdoc-toggle summary::before" // This is the position of "[-]" next to that pub fn. assert-attribute-false: (".impl-items .rustdoc-toggle", {"open": ""}) <ins> // Click the "Trait" part of "impl Trait" and verify it navigates. click: "#impl-Trait h3 a:first-of-type" assert-text: (".fqn .in-band", "Trait lib2::Trait") </ins>
Change:
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.

Discussion:
i += 1; } <del> while i < j && lines[i].trim().is_empty() { i += 1; } </del> // like the first, a last line of all stars should be omitted if j > i && !lines[j - 1].is_empty() && lines[j - 1].chars().all(|c| c == '*') { j -= 1; } <del> while j > i && lines[j - 1].trim().is_empty() { j -= 1; } </del> if i != 0 || j != lines.len() { Some((i, j)) } else { None } }

<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

<ins> <div class="docblock"><p>Par 1</p> <p>Par 2</p> </div> </ins>  No newline at end of file

#[doc = "Goodbye!"] /// Hello again! pub struct S2; <ins> // @has 'foo/struct.S3.html' // @snapshot S3_top-doc - '//details[@class="rustdoc-toggle top-doc"]/div[@class="docblock"]' /** Par 1 */ /// /// Par 2 pub struct S3; </ins>
Change:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting another error, so low priority. Affected versions: I tried nightly 2021-11-25 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will give this a try claim

Discussion:
// We've encountered an `AnonConst` in some path, so we need to // figure out which generic parameter it corresponds to and return // the relevant type. <del> let (arg_index, segment) = path </del> <ins> let filtered = path </ins> .segments .iter() .filter_map(|seg| seg.args.map(|args| (args.args, seg)))

.filter(|arg| arg.is_const()) .position(|arg| arg.id() == hir_id) .map(|index| (index, seg)) <del> }) .unwrap_or_else(|| { bug!("no arg matching AnonConst in path"); </del> }); <ins> let (arg_index, segment) = match filtered { None => { tcx.sess.delay_span_bug( tcx.def_span(def_id), "no arg matching AnonConst in path", ); return None; } Some(inner) => inner, }; </ins> // Try to use the segment resolution if it is valid, otherwise we // default to the path resolution.

<ins> fn main() { 0: u8<e<5>=e> //~^ ERROR: cannot find type `e` in this scope [E0412] //~| ERROR: associated type bindings are not allowed here [E0229] //~| ERROR: mismatched types [E0308] } </ins>

<ins> error[E0412]: cannot find type `e` in this scope --> $DIR/issue-91267.rs:2:16 | LL |     0: u8<e<5>=e> |                ^ |                | |                not found in this scope |                help: maybe you meant to write an assignment here: `let e` error[E0229]: associated type bindings are not allowed here --> $DIR/issue-91267.rs:2:11 | LL |     0: u8<e<5>=e> |           ^^^^^^ associated type not allowed here error[E0308]: mismatched types --> $DIR/issue-91267.rs:2:5 | LL | fn main() { |           - expected `()` because of default return type LL |     0: u8<e<5>=e> |     ^^^^^^^^^^^^^ expected `()`, found `u8` error: aborting due to 3 previous errors Some errors have detailed explanations: E0229, E0308, E0412. For more information about an error, try `rustc --explain E0229`. </ins>