jiebi/CodeConvo huggingface dataset:
Change:
<ins> // revisions: current next //[next] compile-flags: -Ztrait-solver=next // check-pass #![feature(non_lifetime_binders)] //~^ WARN the feature `non_lifetime_binders` is incomplete and may not be safe fn trivial<A>() where for<B> dyn Fn(A, *const B): Fn(A, *const B), { } fn main() { trivial::<u8>(); } </ins>

Discussion:
The type is not inferred to be by the above mentioned nightly release, c.f. Using the stable, the code compiles with out issue. EDIT: It seems to be related to GAT, i.e. a more minimal reproducer is: which similarly fails on nightly and builds on stable. <details<summaryMore details</summaryon the above-mentioned nightly version whereas stable is happy Simply asserting that is via e.g. works on stable and nightly. </details
The reproducer wouldn't compile on stable though?
Sorry, I must have messed something up when trying to whittle it down as the reproducer I started with definitely did compile on stable. Will try to trace my steps backwards.
And indeed using instead of makes it compile on stable. (I wanted to avoid to avoid the standard library but indeed is closer to the original code in question.) I updated the reproducer in the OP accordingly.
Great, thank you. So I believe this to be a different manifestation of from cc -- and therefore also to be fixed by
Stumbled on this separately in my own code. The simplest reproduction I was able to come up with is Removing makes it compile on nightly as well. Putting a bound on does not help.
Change:
/// Returns a type metadata identifier for the specified FnAbi using the Itanium C++ ABI with vendor /// extended type qualifiers and types for Rust types that are not used at the FFI boundary. <ins> #[instrument(level = "trace", skip(tcx))] </ins> pub fn typeid_for_fnabi<'tcx>( tcx: TyCtxt<'tcx>, fn_abi: &FnAbi<'tcx, Ty<'tcx>>,

Discussion:
I've got a fix for this that I'll be uploading in a minute or two, I'm filing the issue to claim an issue number for the test. : </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This seems to be a duplicate of .
Change:
// conflicts with a new loan, as opposed to every issued loan.  This keeps us // down to O(n) errors (for n problem lines), instead of O(n^2) errors. <ins> // revisions: ast mir //[mir]compile-flags: -Z emit-end-regions -Z borrowck-mir </ins> fn main() { let mut x = 1; let mut addr; loop { match 1 { <del> 1 => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time 2 => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time _ => { addr = &mut x; } //~^ ERROR cannot borrow `x` as mutable more than once at a time </del> <ins> 1 => { addr = &mut x; } //[ast]~ ERROR [E0499] //[mir]~^ ERROR (Ast) [E0499] //[mir]~| ERROR (Mir) [E0499] 2 => { addr = &mut x; } //[ast]~ ERROR [E0499] //[mir]~^ ERROR (Ast) [E0499] //[mir]~| ERROR (Mir) [E0506] //[mir]~| ERROR (Mir) [E0499] //[mir]~| ERROR (Mir) [E0499] _ => { addr = &mut x; } //[ast]~ ERROR [E0499] //[mir]~^ ERROR (Ast) [E0499] //[mir]~| ERROR (Mir) [E0506] //[mir]~| ERROR (Mir) [E0499] //[mir]~| ERROR (Mir) [E0499] </ins> } } }

Discussion:
MIR borrowck ICEs when an error involving a region whose EndRegion is missing occurs (this occurs when a region can never end within the function). Instead it should emit a correct diagnostic. This can occur for both free regions (e.g. issue-): And for infinite loops: Causing this ICE:
The ICE here is caused by the assert in this function, : This function finds the (location in the input source code) that a region ends. If you look at the error that the AST borrowck (i.e., older style borrowck) emits, we are basically computing the point where to write that "immutable borrow ends here" message: Right now, there is a kind of complicated assertion. It is saying that one of two things should be: We are in non-lexical mode. In that case, there are no end-regions at all, so we just return . This causes us not to write "immutable borrow ends here". We are in lexical mode, in which case we should have found an statement. These are special statements we insert into the MIR (only in lexical mode) that tell us where the various lexical lifetimes end. The problem is that in cases where the region never properly ends, we won't find an statement. I think what we want to do is rewrite the function a bit. If we are in NLL mode (), then we should always return . Otherwise, check the as we are doing and return if we find something in there, as we are doing now. Otherwise, we want to return the span for the end of the function. This is the new part. As it happens, we can get this by returning : is the MIR for the function we are checking is the span in the source code where the function is defined returning its end point should, I think, give us the behavior we want. So, when we are done, if is , this function should always return for some span, but sometimes it will be the end of the function.
Hi, I want to work on this bug.
Change:
<ins> error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/bad-recursive-type-sig-infer.rs:1:11 | LL | fn a() -> _ { |           ^ not allowed in type signatures error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/bad-recursive-type-sig-infer.rs:6:11 | LL | fn b() -> _ { |           ^ not allowed in type signatures error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0121`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
That second function can be named anything, for the record. e.g.
Change:
<ins> // edition:2021 #[derive(Copy, Clone, PartialEq, Eq)] pub struct Opcode(pub u8); impl Opcode { pub const OP1: Opcode = Opcode(0x1); } pub fn example1(msg_type: Opcode) -> impl FnMut(&[u8]) { move |i| match msg_type { //~^ ERROR: non-exhaustive patterns: `Opcode(0_u8)` and `Opcode(2_u8..=u8::MAX)` not covered Opcode::OP1 => unimplemented!(), } } #[derive(Copy, Clone, PartialEq, Eq)] pub struct Opcode2(Opcode); impl Opcode2 { pub const OP2: Opcode2 = Opcode2(Opcode(0x1)); } pub fn example2(msg_type: Opcode2) -> impl FnMut(&[u8]) { move |i| match msg_type { //~^ ERROR: non-exhaustive patterns: `Opcode2(Opcode(0_u8))` and `Opcode2(Opcode(2_u8..=u8::MAX))` not covered Opcode2::OP2=> unimplemented!(), } } fn main() {} </ins>

Discussion:
The following ICE was found migrating . cc which was very similar, but has been fixed. Also found in: - https://crater- <!-- 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. --: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
<ins> error: expected identifier, found keyword `Self` --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:4:17 | LL |     fn foo(&mur Self) {} |                 ^^^^ expected identifier, found keyword error: expected one of `:`, `@`, or `|`, found keyword `Self` --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:4:17 | LL |     fn foo(&mur Self) {} |            -----^^^^ |            |    | |            |    expected one of `:`, `@`, or `|` |            help: declare the type after the parameter binding: `<identifier>: <type>` error: unexpected lifetime `'static` in pattern --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:8:13 | LL |     fn bar(&'static mur Self) {} |             ^^^^^^^ help: remove the lifetime error: expected identifier, found keyword `Self` --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:8:25 | LL |     fn bar(&'static mur Self) {} |                         ^^^^ expected identifier, found keyword error: expected one of `:`, `@`, or `|`, found keyword `Self` --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:8:25 | LL |     fn bar(&'static mur Self) {} |            -------------^^^^ |            |            | |            |            expected one of `:`, `@`, or `|` |            help: declare the type after the parameter binding: `<identifier>: <type>` error: expected one of `:`, `@`, or `|`, found keyword `Self` --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:14:17 | LL |     fn baz(&mur Self @ _) {} |                 ^^^^ expected one of `:`, `@`, or `|` error: the `Self` constructor can only be used with tuple or unit structs --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:4:17 | LL |     fn foo(&mur Self) {} |                 ^^^^ help: use curly brackets: `Self { /* fields */ }` error: the `Self` constructor can only be used with tuple or unit structs --> $DIR/issue-70549-resolve-after-recovered-self-ctor.rs:8:25 | LL |     fn bar(&'static mur Self) {} |                         ^^^^ help: use curly brackets: `Self { /* fields */ }` error: aborting due to 8 previous errors </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on nightly but not on beta or stable.
Report from : searched nightlies: from nightly-2020-03-09 to nightly-2020-03-30 regressed nightly: nightly-2020-03-16 searched commits: from to regressed commit:
looks like the probable culprit. cc
Will fix.
Was already looking at this hehe, I have a fix for you in
Change:
_ => {} } } <del> let lines = origtext.lines().filter_map(|l| map_line(l).for_html()); let text = lines.intersperse("n".into()).collect::<String>(); </del> let parse_result = match kind { CodeBlockKind::Fenced(ref lang) => {

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: text //! #..#.####.#....#.....##.. //! #..#.#....#....#....#..#. //! ####.###..#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.#....#....#....#..#. //! #..#.####.####.####..##.. //! I expected to see this happen: When I run , I expect to see ASCII art in the output that matches the above example. Instead, this happened: In the output, this actually appears: It appears that if a line starts with at least three s, one gets "swallowed" somehow. <!-- 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<summaryBacktrace</summary<p</p</details
It's because of how are handled for rust code blocks. I'll send a PR but we need to ensure that people are not relying on to hide a line for non-rust code blocks.
This is actually a regression. I haven't bisected, but it occurred sometime between 1.50.0 and 1.63.0 based on a quick test. In 1.50.0, the following code block markdown /// # Header /// rendered as , but in 1.63.0 it renders as a blank code block.
Thanks for the information !

The regression is in nightly-2021-07-15 Commits in range: commit[0] 2021-07-13UTC: Auto merge of - camsteffen:hash-lint-resolved, r=oli-obk commit[1] 2021-07-13UTC: Auto merge of - cjgillot:expnhash, r=petrochenkov commit[2] 2021-07-14UTC: Auto merge of - Mark-Simulacrum:edition-no-clone, r=petrochenkov commit[3] 2021-07-14UTC: Auto merge of - tlyu:option-result-overviews, r=joshtriplett commit[4] 2021-07-14UTC: Auto merge of - JohnTitor:rollup-8ltidsq, r=JohnTitor commit[5] 2021-07-14UTC: Auto merge of - michaelwoerister:const-in-debuginfo-type-names-fix, r=oli-obk,wesleywiser commit[6] 2021-07-14UTC: Auto merge of - GuillaumeGomez:rollup-pfz9jbk, r=GuillaumeGomez commit[7] 2021-07-14UTC: Auto merge of - cuviper:fuse-less-specialized, r=joshtriplett Maybe this happened in (merged by ) (cc
Change:
let map = Map { krate, dep_graph, crate_hash, map, hir_to_node_id, definitions }; sess.time("validate_HIR_map", || { <del> hir_id_validator::check_crate(&map); </del> <ins> hir_id_validator::check_crate(&map, sess); </ins> }); map

Discussion:
This code () produces ICE on current beta and nightly
Tagging as P-medium and "triaged" for async-await. Note that yield is unstable.
the feature is nightly but the ice doesn't require any feature gate to trigger.
searched nightlies: from nightly-2019-01-01 to nightly-2020-02-01 regressed nightly: nightly-2019-09-29 searched commits: from to regressed commit: source code: <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</p</details
thanks for the bisection! Annoyingly, it regressed in a rollup PR, which means there are many candidates: (Docs: slice elements are equidistant) -- (Include message on tests that should panic but do not) -- (Remove stray references to the old global tcx) -- (Remove unused DepTrackingMap) -- (Account for tail expressions when pointing at return type) -- (hir: Disallow on constants) -- (Fix divduration() marked as stable by mistake) -- (update rtpSpawn's parameters type(It's prototype has been updated in libc)) -- (Thou shallt not ) -- (Stabilize mapgetkeyvalue feature) -- ( fix links to primitives in documentation) -- (Upgrade envlogger to 0.7) -- (Add mailmap entry for Dustin Bensing by request) -- (check_match: improve diagnostics for with ) --
If I had to guess, I would guess (cc triggered this regression, but or are possibilities. I would guess because it caused the compiler to keep compiling when it might've aborted, and maybe it would've aborted in these cases and hence never reached the code that causes an ICE. If indeed I am correct, then this could be fixed by adding a call at the point of the ICE (i.e., basically asserting that some error has occurred but otherwise just try to not crash).
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // error-pattern:`break` outside of loop </del> struct Foo { t: ~str } <ins> fn cond() -> bool { true } fn foo(_: ||) {} </ins> fn main() { <del> let pth = break; </del> <ins> let pth = break; //~ ERROR: `break` outside of loop if cond() { continue } //~ ERROR: `continue` outside of loop </ins> <del> let rs: Foo = Foo{t: pth}; </del> <ins> while cond() { if cond() { break } if cond() { continue } do foo { if cond() { break } //~ ERROR: `break` inside of a closure if cond() { continue } //~ ERROR: `continue` inside of a closure } } let rs: Foo = Foo{t: pth}; </ins> }

Discussion:
As per comment before
I don't think this is backwards incompatible.
just a bug, removing milestone/nomination.
Change:
<del> Subproject commit 62046bf8b4eadd4fb398d59f1eebcc140506bf85 </del> <ins> Subproject commit 4fa9363ebba236f7c29ae11180db6051d7d2ce3b </ins>

Discussion:
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!
Change:
w.write_str("</h3></section>"); let heading_and_fields = match &variant_data.kind { <del> clean::VariantKind::Struct(s) => Some(("Fields", &s.fields)), </del> <ins> clean::VariantKind::Struct(s) => { // If there is no field to display, no need to add the heading. if s.fields.iter().any(|f| !f.is_doc_hidden()) { Some(("Fields", &s.fields)) } else { None } } </ins> clean::VariantKind::Tuple(fields) => { // Documentation on tuple variant fields is rare, so to reduce noise we only emit // the section if at least one field is documented.

Discussion:
While working on , I noticed that struct variants with no (visible) fields look kinda awkward. ! The Fields heading takes a lot of space without adding particularly much to the content. The easiest solution would be to just remove the heading, but that would show no indication that there exist private fields. The same issue exists in top-level structs as well, but there it is mitigated by having the definition in the code block just above, while for enums there can be a sizeable distance between the two. Any thoughts? Am I just overthinking the whole thing?
No this is a very good point. If there are no fields, we shouldn't add the "Fields" heading. Sending a fix.
Change:
<ins> // Issue 69130: character indexing bug in rustc_errors::CodeSuggestion::splice_lines(). enum F { M (§& u8)} //~^ ERROR unknown start of token //~| missing lifetime specifier fn main() {} </ins>

Discussion:
I'm seeing an internal compiler error on the following input (found by ): The error happens on and but not on .
Visited from compiler team triage meeting. Categorized as P-medium.
searched nightlies: from nightly-2020-01-01 to nightly-2020-02-10 regressed nightly: nightly-2020-01-22 searched commits: from to regressed commit: source code: <details<summaryICE backtrace</summary<p</p</detailsReproduce bisect report:
Interesting -- the regression report suggests this was caused by , cc
The problem is here: is a character index. It needs to be translated into a byte index before it can be used to slice . I've submitted a
Change:
<ins> fn get_pair(_a: &mut u32, _b: &mut u32) {} macro_rules! x10 { ($($t:tt)*) => { $($t)* $($t)* $($t)* $($t)* $($t)* $($t)* $($t)* $($t)* $($t)* $($t)* } } #[allow(unused_assignments)] fn main() { let mut x = 1; get_pair(&mut x, &mut x); //~^ ERROR: cannot borrow `x` as mutable more than once at a time x10! { x10!{ x10!{ if x > 0 { x += 2 } else { x += 1 } } } } } </ins>

Discussion:
This code is the protocol handler, and generated by one of the MAVLink specification. It is C/Rust mixed project, so to compile it you will need Rust , CC an any C compiler. To check how slow rustc is, , and run cargo test in the GroundControl/demo dir Exactly this project is compiled with error, cause the borrow checker complains in one place. But anyway, the problem is that compilation is unacceptably slow. Description generated API is generated sample of using generated API the test I generate variation of this project, with same functionality, in C, C++, C#.... They are the compiled in seconds ! What wrong with my Rust project? How can I speed up compilation? My PC Intel I7-7700K RAM 32G SSD Samsung 970 PRO cargo -V cargo 1.39.0-nightly ( 2019-09-25) rustc -V rustc 1.40.0-nightly ( 2019-09-30)
Please provide build instructions for that code. Running in gives: .
But I wrote and run cargo test in the GroundControl/demo dir
That gives the same error, since it just has a dependency on the crate in ...
Small bug fix in the file. Please try again. Thanks.
That didn't fix it
on my debian and windows 10 build script shown: cargo:warning=Starting search config.h in.... cargo:warning=/root/InRUST/GroundControl/demo/target/debug/build/blackbox-sys-/out cargo:warning=/root/InRUST/GroundControl/demo/target/debug/build/blackbox-sys- cargo:warning=/root/InRUST/GroundControl/demo/target/debug/build cargo:warning=/root/InRUST/GroundControl/demo/target/debug cargo:warning=/root/InRUST/GroundControl/demo/target cargo:warning=/root/InRUST/GroundControl/demo cargo:warning=<<< Find and use generated config.h in root/InRUST/GroundControl/lib/src/
made more platform specific fixes. check now please.
I've looked into this code and likely found the problem. The bright side: it compiles in under half a minute if the errors are removed. The part of the code causing this problem is a test function that tries to test everything at once and has about 8000 lines.

The function contains (as of commit ) 76 borrow checker errors and the part that takes 5 hours is generating the 3-point errors for them. The time is dominated by the for the function body.
A minimized reproduction looks like this On my laptop this code requires about 25 seconds to print the error for the 1000 statements generated above and scales with the cube of the statement count.
On the bright side, waiting 5 hours for borrowck errors is still faster than trying to debug a memory corruption in a language without borrowck. (edit: lol, why so serious, this was meant to be humorous and not a complaint about Rust…)
Thanks to for the report and helping us to work with it, and to for the quick analysis and fix!
Change:
|            ^^^^^^ help: try using one of the enum's variants | <del> LL |     if let std::prelude::v1::Option::None(_) = x { |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     if let std::prelude::v1::Option::Some(_) = x { |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> LL |     if let std::option::Option::None(_) = x { |            ^^^^^^^^^^^^^^^^^^^^^^^^^ LL |     if let std::option::Option::Some(_) = x { |            ^^^^^^^^^^^^^^^^^^^^^^^^^ </ins> error[E0532]: expected tuple struct/variant, found enum `Example` --> $DIR/issue-43871-enum-instead-of-variant.rs:27:12

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
", name = *myitem.name.as_ref().unwrap(), stab_docs = stab_docs, <del> docs = Markdown(&shorter(myitem.doc_value())), </del> <ins> docs = shorter(Some(&Markdown(doc_value).to_string())), </ins> class = shortty(myitem), stab = myitem.stability_class(), href = item_path(myitem),

Discussion:
There are times it's nice to be able to include a link in the description of a given item. At present, however, if you try to include a reference link, it fails. Rust: HTML for the item description: However, if you change the first line of the Rust to be an inline reference, the problem goes away. Rust: Generated HTML: It appears (I haven't had a chance to check the implementation yet) that rustdoc is only parsing the first Markdown block element, rather than only keeping the first block element. This probably slightly improves performance, but it produces unexpected results.
Change:
# Submodules pseudo-files inside git have the 160000 permissions, so when # those files are present in the diff a submodule was updated. echo "Executing the job since submodules are updated" <ins> elif git diff --name-only HEAD^ | grep --quiet src/tools/clippy; then # There is not an easy blanket search for subtrees. For now, manually list # clippy. echo "Executing the job since clippy subtree was updated" </ins> else echo "Not executing this job since no submodules were updated" ciCommandSetEnv SKIP_JOB 1

Discussion:
The PR CI runner currently does not seem to run clippy tests. Would be nice if it would. :) Cc
This had some unintended side-effects: in a rollup like that touches a clippy file, PR CI runs the "tools" builder, including Miri -- and then PR CI could fail because Miri is broken, even though the PR would land just fine as it is okay for Miri to be broken. (The PR did not update the Miri submodule.)