jiebi/CodeConvo huggingface dataset:
Change:
match param.kind { GenericParamKind::Lifetime { .. } => { let (name, reg) = Region::early(&self.tcx.hir(), &mut index, &param); <ins> let def_id = if let Region::EarlyBound(_ ,def_id , _) = reg { def_id } else { bug!(); }; </ins> if let hir::ParamName::Plain(param_name) = name { if param_name.name == kw::UnderscoreLifetime { // Pick the elided lifetime "definition" if one exists // and use it to make an elision scope. <ins> self.lifetime_uses.insert(def_id.clone(), LifetimeUseSet::Many); </ins> elision = Some(reg); } else { lifetimes.insert(name, reg); } } else { <ins> self.lifetime_uses.insert(def_id.clone(), LifetimeUseSet::Many); </ins> lifetimes.insert(name, reg); } }

Discussion:
Async functions that take references seem to always trigger the lint (which is allow-by-default). Example: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I found which describes basically the same problem.
Seeing as this lint is not enabled by default, marking as deferred, though this would be good to fix and probably not too hard.
claim
Looks the same issue as . A little inelegant but if we can suppress the lint I think...
Change:
match param.kind { GenericParamKind::Lifetime { .. } => { let (name, reg) = Region::early(&self.tcx.hir(), &mut index, &param); <ins> let def_id = if let Region::EarlyBound(_ ,def_id , _) = reg { def_id } else { bug!(); }; </ins> if let hir::ParamName::Plain(param_name) = name { if param_name.name == kw::UnderscoreLifetime { // Pick the elided lifetime "definition" if one exists // and use it to make an elision scope. <ins> self.lifetime_uses.insert(def_id.clone(), LifetimeUseSet::Many); </ins> elision = Some(reg); } else { lifetimes.insert(name, reg); } } else { <ins> self.lifetime_uses.insert(def_id.clone(), LifetimeUseSet::Many); </ins> lifetimes.insert(name, reg); } }

Discussion:
<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Duplicate of
Change:
renamed: Option<Symbol>, glob: bool, please_inline: bool, <ins> path: &hir::UsePath<'_>, </ins> ) -> bool { debug!("maybe_inline_local res: {:?}", res);

Discussion:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.
Change:
<ins> // This is a regression test for #123630 // // Prior to #123703 this was resulting in compiler suggesting add a type signature // for `lit` containing path to a file containing `Select` - something obviously invalid. struct Select<F, I>(F, I); fn select<F, I>(filter: F) -> Select<F, I> {} //~^ 7:31: 7:43: mismatched types [E0308] fn parser1() { let lit = select(|x| match x { //~^ 11:23: 11:24: type annotations needed [E0282] _ => (), }); } fn main() {} </ins>

Discussion:
No response This error is very confusing and unreadable, and the compiler even proposes adding a type containing a local path into the code. That seems very problematic and incorrect. No response No response
Try updating your nightly compiler and checking if it's still like that? You're using a nightly compiler from January.
To second compiler-errors' comment, I know that there was a change in this suggestion sometime in the past month. Edit: nevermind
Output with the PR linked above: We still need a minimal repro to add a test to the test suite.
Needs test.
Minimized reproduction in 1.77 nightly
Change:
} } <ins> /// Give appropriate suggestion when encountering `[("a", 0) ("b", 1)]`, where the /// likely intention is to create an array containing tuples. fn maybe_suggest_bad_array_definition( &self, err: &mut DiagnosticBuilder<'a>, call_expr: &'tcx hir::Expr<'tcx>, callee_expr: &'tcx hir::Expr<'tcx>, ) -> bool { let hir_id = self.tcx.hir().get_parent_node(call_expr.hir_id); let parent_node = self.tcx.hir().get(hir_id); if let ( hir::Node::Expr(hir::Expr { kind: hir::ExprKind::Array(_), .. }), hir::ExprKind::Tup(exp), hir::ExprKind::Call(_, args), ) = (parent_node, &callee_expr.kind, &call_expr.kind) { if args.len() == exp.len() { let start = callee_expr.span.shrink_to_hi(); err.span_suggestion( start, "consider separating array elements with a comma", ",".to_string(), Applicability::MaybeIncorrect, ); return true; } } false } </ins> fn confirm_builtin_call( &self, call_expr: &'tcx hir::Expr<'tcx>,

Discussion:
Given the following code (): The current output is: <!-- The following is not always necessary. --Ideally the output should look like: and the compiler would preview the fix, by adding the commas in green. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This week I'm busier than I thought ;) release-assignment
label +A-parser
claim
Change:
define DEF_RUSTC_TARGET # $(1) == architecture <del> rustc-H-$(1): rustc-stage3-H-$(1) </del> <ins> rustc-H-$(1): rustc-stage2-H-$(1) </ins> endef $(foreach host,$(CFG_TARGET_TRIPLES),			

Discussion:
We're not comparing stage2 and stage3 at the moment, and the amount of bugs caught by that extra stage that wouldn't be caught in stage2 is probably very small. We could shave off some cycle time by only going to stage2, and doing a stage3 check only on checkpoints.
Fixed in .
Change:
Target { llvm_target: "powerpc64-unknown-linux-musl".into(), pointer_width: 64, <del> data_layout: "E-m:e-Fi64-i64:64-n32:64-S128-v256:256:256-v512:512:512".into(), </del> <ins> data_layout: "E-m:e-Fn32-i64:64-n32:64-S128-v256:256:256-v512:512:512".into(), </ins> arch: "powerpc64".into(), options: TargetOptions { endian: Endian::Big, mcount: "_mcount".into(), ..base }, }

Discussion:
(wrapped by hand to make the problem clear) The function pointer alignment is the same as our powerpc64-unknown-linux-gnu target, so the discrepancy must be in LLVM. While this is a tier 3 target, we are completely unable to generate code for it, so at some point this part of the target tier policy will become relevant (emphasis mine): If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (there are none, not even for the Tier 2 -gnu variant) (and potentially other people who have previously worked on the target), to check potential interest in improving the situation. I have trawled the issue tracker and I cannot find any evidence that this target is in use; all issues seem related to or the targets.
Does this also impact ppc64le? That's supported by Alpine, which uses musl. It looks like is the maintainer with musl. Not knowing anything about ppc, or very much about LLVM's data layouts, it looks like may be what broke this.
powerpc64le is not affected. Unfortunately looking at that diff I still can't figure out which of the targets is correct.
So I'm running into this in , the relevant code in LLVM is: () () We get rather than because of the musl-ness of the target. As far as I can tell, this would have been the case since , and the definition of hasn't changed . I think we just got this value wrong in .
Just as a side note – I am using it and I've hit this bug while building the current stable branch. Thank you for maintaining it.
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. #![feature(non_ascii_idents)] pub fn main () {} fn საჭმელად_გემრიელი_სადილი ( ) -> isize { } </ins>

Discussion:
has saying that the column info is provided in characters, not in bytes. However, the error emitter doesn't care about that at all and uses these like byte offsets all over the place. This leads to bugs like and . As an example, look how span printing varies with varying characters used: Correct case: Now add an emoji character: Note how its off by one char now. This can stack up: If I didn't use any spaces at all, I'd run into . Now this can be fixed by going through the emitter code and looking for all places where the pos is used in a byte position fashion. A much more proper fix instead is to stop trusting that people read comments and encode this via the type system. There is already a mechanism for that inside the compiler, its ! Just convert the types of , members of the and structs to , or maybe to if that's preferred.
cc
Change:
<ins> error: expected `{`, found keyword `false` --> $DIR/else-no-if.rs:3:12 | LL |     } else false { |       ---- ^^^^^ |       | |       expected an `if` or a block after this `else` | help: add an `if` if this is the condition to an chained `if` statement after the `else` | LL |     } else if false { |            ++ help: ... otherwise, place this expression inside of a block if it is not an `if` condition | LL |     } else { false } { |            +       + error: expected `{`, found `falsy` --> $DIR/else-no-if.rs:10:12 | LL |     } else falsy() { |       ---- ^^^^^ |       | |       expected an `if` or a block after this `else` | help: add an `if` if this is the condition to an chained `if` statement after the `else` | LL |     } else if falsy() { |            ++ help: ... otherwise, place this expression inside of a block if it is not an `if` condition | LL |     } else { falsy() } { |            +         + error: expected `{`, found `falsy` --> $DIR/else-no-if.rs:17:12 | LL |     } else falsy(); |            ^^^^^ expected `{` | help: try placing this code inside a block | LL |     } else { falsy() }; |            +         + error: expected `{`, found keyword `loop` --> $DIR/else-no-if.rs:23:12 | LL |     } else loop{} |            ^^^^ expected `{` | help: try placing this code inside a block | LL |     } else { loop{} } |            +        + error: aborting due to 4 previous errors </ins>

Discussion:
The error here is if is missing in else if but compiler reports: error:
already points out at the place where the should be, even if it doesn't suggest it:
: I still wish the parser to detect that the code immediately following is a binary operation followed by a block, so that we can instead emit
CC in case you might be interested in looking at the parser :)
this seems like a neat fix, i'll take a stab at it
Change:
// CHECK: ![[TYPE141]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NtC{{[[:print:]]+}}_51sanitizer_cfi_emit_type_metadata_id_itanium_cxx_abi3FooE"} // CHECK: ![[TYPE142]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NtC{{[[:print:]]+}}_51sanitizer_cfi_emit_type_metadata_id_itanium_cxx_abi3FooS_E"} // CHECK: ![[TYPE143]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NtC{{[[:print:]]+}}_51sanitizer_cfi_emit_type_metadata_id_itanium_cxx_abi3FooS_S_E"} <del> // CHECK: ![[TYPE144]] = !{i64 0, !"_ZTSFvu3refIu3refIvEEE"} // CHECK: ![[TYPE145]] = !{i64 0, !"_ZTSFvu3refIu3refIvEES0_E"} // CHECK: ![[TYPE146]] = !{i64 0, !"_ZTSFvu3refIu3refIvEES0_S0_E"} </del> <ins> // CHECK: ![[TYPE144]] = !{i64 0, !"_ZTSFvu3refIvEE"} // CHECK: ![[TYPE145]] = !{i64 0, !"_ZTSFvu3refIvES_E"} // CHECK: ![[TYPE146]] = !{i64 0, !"_ZTSFvu3refIvES_S_E"} // CHECK: ![[TYPE147]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NtC{{[[:print:]]+}}_51sanitizer_cfi_emit_type_metadata_id_itanium_cxx_abi3BarE // CHECK: ![[TYPE148]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NtC{{[[:print:]]+}}_51sanitizer_cfi_emit_type_metadata_id_itanium_cxx_abi3BarS_E // CHECK: ![[TYPE149]] = !{i64 0, !"_ZTSFvu{{[0-9]+}}NtC{{[[:print:]]+}}_51sanitizer_cfi_emit_type_metadata_id_itanium_cxx_abi3BarS_S_E </ins>

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:
self.token.is_path_start() // e.g. `MY_CONST`; || self.token == token::Dot // e.g. `.5` for recovery; || self.token.can_begin_literal_or_bool() // e.g. `42`. <ins> || self.token.is_whole_expr() </ins> } // Helper function to decide whether to parse as ident binding

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
// TestType, TrFailedMsg, TrIgnored, TrOk, }, }; <ins> use std::any::TypeId; </ins> use std::sync::mpsc::channel; use std::time::Duration;

Discussion:
When running this test (): the output is which makes it hard to spot the difference in whitespace characters. Would it be possible to change this to e.g.: This would improve the usability when running into these kinds of test failures and also make it more consistent with which outputs both the left and the right value too.
Agree with having them vertically aligned. I think we do want line endings to create a new line though for multi-line readability. Maybe we should say something like this: (The first difference at char line we might also want to add to assert_eq also?)
The message sounds good, but I am not sure how well it applies to the comparison, as it is not an equality, but a substring comparison. Maybe we could adjust the wording of the error message to e.g.: to make that easier to spot. I think the escaping is essential, take for instance which has no newlines, but contains : On many shells, this will produce this output: which makes it very hard for a user to figure out what's going on (let's assume the happens in a more obscure location). Maybe a more important reason is that escaping would be consistent with the behavior of , which for : outputs: The escaping avoids surprises which could occur depending on the user`s environment.
Ok I'm sold. Do you want to fork rust-lang/rust and submit this as a PR? (If you don't want to I can do the legwork).
Thanks for the offer, I'll try to write a PR and will add you as a reviewer once I have a first version ready.
Change:
} } <ins> pub fn suggest_remove_last_method_call( &self, err: &mut Diagnostic, expr: &hir::Expr<'tcx>, expected: Ty<'tcx>, ) -> bool { if let hir::ExprKind::MethodCall(hir::PathSegment { ident: method, .. }, recv_expr, &[], _) = expr.kind && let Some(recv_ty) = self.typeck_results.borrow().expr_ty_opt(recv_expr) && self.can_coerce(recv_ty, expected) { let span = if let Some(recv_span) = recv_expr.span.find_ancestor_inside(expr.span) { expr.span.with_lo(recv_span.hi()) } else { expr.span.with_lo(method.span.lo() - rustc_span::BytePos(1)) }; err.span_suggestion_verbose( span, "try removing the method call", "", Applicability::MachineApplicable, ); return true; } false } </ins> pub fn suggest_deref_ref_or_into( &self, err: &mut Diagnostic,

Discussion:
I tried this code (): I expected to see this happen: Instead, this happened: This is just a very specific instance where the suggestion to add some code, while "technically correct", is less useful than the better suggestion to remove some code. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
it seems that given an expression, you can generically check if removing the last method call if present would give you the right type, so this could be implemented in a very generic way instead of special casing &str/String.
This looks awesome, thank you so much!
This is how it looks now . Very cool.
Change:
_ => noop_visit_ty(ty, self), } } <ins> fn visit_block(&mut self, block: &mut P<ast::Block>) { noop_visit_block(block, self); for stmt in block.stmts.iter_mut() { if self.monotonic { assert_eq!(stmt.id, ast::DUMMY_NODE_ID); stmt.id = self.cx.resolver.next_node_id(); } } } </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. --Context: "regression" caught by future-proofing CI from After working on reducing the code, I've identified the root cause of the ICE. For context: this patterns stem from "old" Rust code wanting to support proc-macros emitting item definitions in "statement" position for Rust: the trick is to use the to wrap an item-defs-emitting proc-macro call inside a function so that Rust doesn't interpret it as a statement, refusing the then-unstable stmt-emitting proc-macro call (). <!-- 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. --: Bonus: the ICE seems to have been introduced in between today's () and yesterday's nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailscc I suspect this is up your alley
searched nightlies: from nightly-2021-08-01 to nightly-2021-08-10 regressed nightly: nightly-2021-08-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high +A-macros
Thanks nice job
Change:
<ins> error: type parameters with a default must be trailing --> $DIR/wrong-order.rs:3:10 | LL | struct A<T = u32, const N: usize> { |          ^ | = note: using type defaults and const parameters in the same parameter list is currently not permitted warning: the feature `const_generics` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/wrong-order.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information error: aborting due to previous error; 1 warning emitted </ins>

Discussion:
Should the following code be accepted? if so, we probably also want to accept the following: cc
So,how would the following be handled? That is (passing an identifier as a const argument).
should be equal to imo. rn literals which are in both the type and the value namespace are always used as type params though (see ). So this would fail to compile even if we get to work.
Change:
| Node::Block(..) | Node::Ctor(..) | Node::Pat(..) <del> | Node::PatField(..) | Node::ExprField(..) </del> | Node::Arm(..) | Node::Local(..) | Node::Crate(..)

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2022-08-16 commit[0] 2022-08-14: Auto merge of - GuillaumeGomez:merge-html-elements-together, r=notriddle commit[1] 2022-08-14: Auto merge of - matthiaskrgr:rollup-734hkpt, r=matthiaskrgr commit[2] 2022-08-15: Auto merge of - compiler-errors:as-a-treat, r=jackh726 commit[3] 2022-08-15: Auto merge of - austinabell:skip_optimization, r=Mark-Simulacrum commit[4] 2022-08-15: Auto merge of - ehuss:even-more-attribute-validation, r=cjgillot commit[5] 2022-08-15: Auto merge of - michaelwoerister:new-cpp-like-enum-debuginfo, r=wesleywiser commit[6] 2022-08-15: Auto merge of - matthiaskrgr:rollup-9450lzs, r=matthiaskrgr commit[7] 2022-08-15: Auto merge of - matthiaskrgr:rollup-f1zur58, r=matthiaskrgr
WG-prioritization assigning priority (). label -I-prioritize +P-medium
claim
Originates in PR . We are returning for although it does have an ident: The fix would be to start returning the ident. suffers from the same problem and may need the same treatment.
Change:
ty_param_bounds_and_ty { generics: ty::Generics { type_param_defs: @new_type_param_defs, <del> region_param_defs: @[], // fn items </del> <ins> region_param_defs: new_early_region_param_defs </ins> }, ty: ty });

Discussion:
cc I think this is related to . Here's the example code: It errors with:
I just got similar ICE with extern mod. a.rs: b.rs: Building b.rs gives (Yes, I was using .) It worked on rust revision but not on revision .
Another variant: produces:
Seems likely to be related, yes. I'll take a look today. Probably something funky in the handling of static methods. Possibly related to what was trying to address in (though maybe not -- I'm sad to say I ddn't fully understand the problem there, was too caught up in trying to finish with !)
Here's an example relevant to me:
So these examples are a mix of problems, but they are all related to . The only one of these examples I expect to not ICE is the first one. The others don't work because of . The basic problem is that you cannot have a function which has a lifetime parameter that appears in a trait bound (yet -- I want to fix this, see for details). Interestingly, the reason that we have this problem with the first example, is that static functions like get translated into functions with lifetime parameters that appear within a trait bound. That is, the type for looks to the compiler like: You can see here that appears in the bound for . Anyway, I have the fix for this. This is good because it got me thinking about and I think it's not too hard to extend the fix to cover that case as well. But I'll push the limited fix for just this bug for now.
Thanks for looking into this. I started playing around with your branch to fix this and I ran into another ICE. Is there something new, or is it also caused by ? Errors with:
On Sat, Nov 16, 2013 at 10:01:08PM -0800, Erick Tryzelaar wrote: . I will see how quickly I can prepare a fix for this. The key identifying point is: right here (I a comment)