jiebi/CodeConvo huggingface dataset:
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. fn main() { let f = |x| x * 3; let a = f(); //~ ERROR E0057 let b = f(4); let c = f(2, 3); //~ ERROR E0057 } </ins>

Discussion:
From: src/test/compile- Error E0057 needs a span_label, updating it from: To: Bonus 1: The note seems excessive. Check other E0057 errors. If it is not needed, remove the note. Bonus 2: The span for the error could likely focus on the parameters rather than the whole call.
I'm taking this one.
I think I've got most of this fix/working, but I'm having a problem fixing one of the unit test cases - issue- The other related test cases (issue-, issue-4935, method-call-err-msg, not-enough-arguments, overloaded-calls-bad and variadic-ffi-3) I was able to fix by following your blog guide. For some reason, issue-3044 is 'different' and I don't understand why. Not sure how to proceed...
- can you show the errors you get when you try to get issue-3044 to pass?
I think I fixed the problem. I'm now trying to get my code checked in and pushed to by fork. Having some ssh key/cert issues. I think once I do that, I can do a PR?
I just submitted a PR, but not sure if I did it correctly.
The note of and this one are printed by the same function, can I modify it to print the expected types directly in the label? I also did the bonus2 part for both E0060 and E0061.
Freeing this one up as part of the final push for .
Actually, according to the comments in maybe this is already closed? , can you confirm?
I think should be closed, and progress is under way in .
Change:
<ins> // check-pass // compile-flags: -C debug_assertions=yes -Zunstable-options #[allow(dead_code)] fn problematic_function<Space>() where DefaultAlloc: FinAllok<R1, Space>, { let e = Edge2dElement; let _ = Into::<Point>::into(e.map_reference_coords()); } impl<N> Allocator<N, R0> for DefaultAlloc { type Buffer = MStorage; } impl<N> Allocator<N, R1> for DefaultAlloc { type Buffer = MStorage; } impl<N, D> From<VectorN<N, D>> for Point where DefaultAlloc: Allocator<N, D>, { fn from(_: VectorN<N, D>) -> Self { unimplemented!() } } impl<GeometryDim, NodalDim> FinAllok<GeometryDim, NodalDim> for DefaultAlloc where DefaultAlloc: Allocator<Ure, GeometryDim>, DefaultAlloc: Allocator<Ure, NodalDim> { } impl FiniteElement<R1> for Edge2dElement { fn map_reference_coords(&self) -> VectorN<Ure, R1> { unimplemented!() } } type VectorN<N, R> = (N, R, <DefaultAlloc as Allocator<N, R>>::Buffer); struct DefaultAlloc; struct R0; struct R1; struct MStorage; struct Point; struct Edge2dElement; struct Ure; trait Allocator<N, R> { type Buffer; } trait FinAllok<GeometryDim, NodalDim>: Allocator<Ure, GeometryDim> + Allocator<Ure, NodalDim> + { } trait FiniteElement<Rau> where DefaultAlloc: FinAllok<Rau, Rau>, { fn map_reference_coords(&self) -> VectorN<Ure, Rau>; } fn main() {} </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
label +requires-debug-assertions
Reduced from 205 lines to 56 lines: Error output with :
Change:
<ins> // ignore-tidy-linelength #![feature(min_const_generics)] #![crate_name = "foo"] // @has foo/type.CellIndex.html '//pre[@class="rust typedef"]' 'type CellIndex<const D: usize> = [i64; D];' pub type CellIndex<const D: usize> = [i64; D]; </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. --The following code compiles just fine but when trying to run on it I get the error described below <!-- 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 --
Making this even more strange, this does not panic with instead.
<details<summaryBacktrace</summary</detailsRustdoc code:
The main function is not necessary, it also crashes on
Yeah this one is beyond me, I have no idea why this is breaking.
This never worked with ; on it says the feature isn't recognized and on it crashes.
Huh, I built that last code snippet in the Rust Playground and it compiled fine:
yes, it only crashes with rustdoc, which isn't available on the playground.
Oops, I missed that part. Sorry about that!
Feel free to ping me on all issues related to const generics claim
Thanks for fixing this!
Change:
self.resolve_pattern(pat, source, &mut bindings_list); } // This has to happen *after* we determine which pat_idents are variants <del> self.check_consistent_bindings(pats); </del> <ins> if pats.len() > 1 { self.check_consistent_bindings(pats); } </ins> } fn resolve_block(&mut self, block: &Block) {

Discussion:
Given the example code: I get a really nice warning message about what I did wrong: However, if I change the main function to match multiple patterns: The error message is really confusing with no hint how to fix it: Please expand the error message for the second case to look a bit more like the first case.
Triage: no change. We need to supply the line in E0408.
so I thought I would implement the change you've proposed but have been thinking how best to restrict the kinds of cases where this help note would be appended to the error as I figured it may be rather noisy and/or confusing within the context of some false negatives. So during resolution we of course cannot look at the types to see if it's possible we're matching against an enum. But what do you think about having the help note kick in only if the binding starts with an upper case letter? I know this is a convention that should not really be a concern of the compiler but seeing that using it would only make the diagnostic note a bit more fine-grained, perhaps it's not a terrible idea?
we already do that in some places, like the parser to infer intent, but in this case how would you figure out that you want to suggest and without resolving ? I believe a more holistic solution would be to detect "variable not bound in all patterns" errors where all bindings are single idents, record that fact while throwing the current error and recovering as if there had been a single variable, and later when we have access to the machinery uses emit a warning suggesting and . It is a bit more involved but if we recover as if only had been present the current diagnostic should kick in suggesting (leaving without a suggestion). Edit: that won't work as things stand, as the warning won't be emitted today if there are errors, I think. That would also need to be changed to make it always be emitted :-/
no, I didn't mean to say we need to suggest possible variants. I too concluded that it's non-trivial with the current ordering of passes and the early bailout (indeed, type checking is impossible without resolution succeeding). I was going to add the help note you proposed back in May, just that I would make it dependent on bindings having a Variant-alike naming. From what you're saying there's a precedent in , so I guess this is an acceptable solution? I'll make a PR then.

sorry, I misunderstood. Go ahead, it sounds good.
no, it's likely me who wasn't clear enough. :) I submitted a PR.
Change:
let indeterminate_imports = mem::take(&mut self.indeterminate_imports); for (is_indeterminate, import) in determined_imports <del> .into_iter() </del> <ins> .iter() </ins> .map(|i| (false, i)) <del> .chain(indeterminate_imports.into_iter().map(|i| (true, i))) </del> <ins> .chain(indeterminate_imports.iter().map(|i| (true, i))) </ins> { <del> let unresolved_import_error = self.finalize_import(import); </del> <ins> let unresolved_import_error = self.finalize_import(*import); </ins> // If this import is unresolved then create a dummy import // resolution for it so that later resolve stages won't complain. <del> self.import_dummy_binding(import, is_indeterminate); </del> <ins> self.import_dummy_binding(*import, is_indeterminate); </ins> if let Some(err) = unresolved_import_error { if let ImportKind::Single { source, ref source_bindings, .. } = import.kind {

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: () I expected to see an error that only says that " is unresolved". But the error says that all uses of items from the module with glob import ( in this case) are unresolved too: This may lead to extremely long and unreadable errors. The issue was originally found while developing where it caused . <!-- 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<summaryOutput on 1.38:</summary</details label A-diagnostics A-resolve regression-from-stable-to-stable
why do you think it's a "regression-from-stable-to-stable"? IMO the output from is even worse
The error is much shorter, and only points at the actual problem. The unused import warnings, of course, wouldn't be there if those imports were actually used.
From those rollups, looks relevant.
ah, you are right, I've misread the output thinking that the warnings were errors too.
I spent some time trying to debug this last week and I'm fairly sure is the PR that introduced this. I wasn't aware of that PR at the time but I spent a lot of time trying to understand what is "determinate" vs. "indeterminate" (which is unfortunately not documented) and I remember finding out that with glob import the import is becoming "indeterminate" while it's normally (without the glob import) it is "determinate", which is one of the things we check elsewhere when generating these warnings.
Assigning as and removing .
Change:
fn visit_operand(&mut self, operand: &mut Operand<'tcx>, _: Location) { if let Operand::Move(place) = *operand <del> && let Some(local) = place.as_local() && self.reused_locals.contains(local) </del> <ins> && !place.is_indirect_first_projection() && self.reused_locals.contains(place.local) </ins> { *operand = Operand::Copy(place); }

Discussion:
Right: Wrong: The first argument to is partially moved. GVN causes the second argument to use the partially moved value:
I can't provoke the miscompilation on beta using this example (just had to replace with to make it build), so I don't think there's any need to rush to fix this. (Some part of GVN is used in the beta that's about to become stable, but it looks like it doesn't have this bug in it)
Cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium
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. //! A test to ensure that helpful `note` messages aren't emitted more often //! than necessary. // Although there are three errors, we should only get two "lint level defined // here" notes pointing at the `warnings` span, one for each error type. #![deny(warnings)] fn main() { let theTwo = 2; let theOtherTwo = 2; println!("{}", theTwo); } </ins>

Discussion:
Example: Adding to a crate will point out the location of this line for every time the lint fires (). This should be listed only once. It should be reasonably easy to deduplicate these based upon equal span and message.
I think this is a good "E-easy" candidate. Relevant code is in . Using a as a field on should work, so that we only emit a note the first time we encounter it.
Question -- in , we get only "lint level defined here" per , even if it applies to multiple lints (e.g., ). Do people think it'd be better to have it like this, or would you rather see different messages for (say) and , even if they both apply to the same ?
Can someone with perms close this? I forgot to use the in .
Great! Fixed in
Change:
<ins> // run-pass // aux-build:static_init_aux.rs extern crate static_init_aux as aux; static V: &u32 = aux::V; static F: fn() = aux::F; fn v() -> *const u32 { V } fn main() { assert_eq!(aux::v(), crate::v()); F(); } </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. --I couldn't I couldn't produce a single file example, as it seems the ICE is triggered when cross crate compilation is involved; i.e dumping the contents of into does not trigger the ICE. This seems like a regression of the feature as this previously worked on nightly of the 1.50 stable release. : : <!-- 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
While regression itself is related to the introduction of CTFE MIR, it seems this actually never worked correctly, with static ending up duplicated.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
I can't reproduce with the latest nightly and cargo. Are there any further instructions for reproducing this?
Apologies, forgot to mention you'll need to add Or build for a target that does not have panic unwinding enabled by default.
(discussed in T-compiler meeting. This is an issue on stable, and might get a backport via . Re-opening to investigate details of what worked, what stopped working, what is fixed, and what is still broken.)
In the case reported here, one crate references static from another crate. During mono item collection, based on reachability determines whether it will link to item from an upstream crate or codegen it locally. When decision is made to codegen locally, it is followed by an assertion that optimized MIR is available to do so. In 1.50 static is non-reachable and codegenned locally. In 1.51 and 1.52 static is non-reachable, but the assertion fails since statics no longer use optimized MIR. In nightly, since , the static is reachable and linked to. The change seems safe for backporting to me.
Closing as the .
Change:
<ins> error[E0700]: hidden type for `impl Trait` captures lifetime that does not appear in bounds --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ | note: hidden type `&'<empty> str` captures lifetime smaller than the function body --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ error[E0477]: the type `&'<empty> str` does not fulfill the required lifetime --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ | note: type must outlive the lifetime `'a` as defined on the item at 5:23 --> $DIR/issue-85113.rs:5:23 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                       ^^ error[E0495]: cannot infer an appropriate lifetime for lifetime parameter `'a` due to conflicting requirements --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ | = note: first, the lifetime cannot outlive the empty lifetime... note: ...but the lifetime must also be valid for the lifetime `'a` as defined on the item at 5:23... --> $DIR/issue-85113.rs:5:23 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                       ^^ note: ...so that the types are compatible --> $DIR/issue-85113.rs:5:29 | LL | type OpaqueOutputImpl<'a> = impl Output<'a> + 'a; |                             ^^^^^^^^^^^^^^^^^^^^ = note: expected `Output<'a>` found `Output<'_>` error: aborting due to 3 previous errors Some errors have detailed explanations: E0477, E0495, E0700. For more information about an error, try `rustc --explain E0477`. </ins>

Discussion:
I was playing around with existential types in nightly, forgot to update some code, and hit this ICE. <!-- 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
label: +requires-nightly
I'm not sure, if it's the same cause, but this ICE seems related (found in by so I'll post it here instead of in a new issue:
The original ICE has been fixed by but hasn't, could you open a new issue if it hasn't been reported yet?
Change:
<ins> // run-rustfix struct S { field_name: (), } fn main() { match (S {field_name: ()}) { S {ref field_name: _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {mut field_name: _foo} => {} //~ ERROR expected `,` } match (S {field_name: ()}) { S {ref mut field_name: _foo} => {} //~ ERROR expected `,` } // Verify that we recover enough to run typeck. let _: usize = 3u8; //~ ERROR mismatched types } </ins>

Discussion:
When changing a pattern binding from something like to something like it's easy to end up with which yields an unhelpful syntax error message (). I don't believe it's obvious why and are valid, but is not. The same holds for bindings, of course. It would be nice if rustc's parser accepted the invalid syntax and provided one of its helpful "did you mean to write ?" error messages.
Current output:
Change:
<ins> error[E0425]: cannot find value `fina` in this scope --> $DIR/suggestion-raw-68962.rs:7:5 | LL |     fina; |     ^^^^ help: a local variable with a similar name exists: `r#final` error[E0425]: cannot find function `f` in this scope --> $DIR/suggestion-raw-68962.rs:10:5 | LL | fn r#fn() {} | --------- similarly named function `r#fn` defined here ... LL |     f(); |     ^ help: a function with a similar name exists: `r#fn` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

Discussion:
Incorrect hint for variable with a similar name defined using raw identifiers () Errors: Should be <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I've fixed this issue and will try to find and fix more similarly incorrect suggestions before submitting a PR.
claim I would love to take this up. It would help to know where I should begin.
Sorry for dropping this, my exams are around the corner.
claim
Hi I'm in the middle of the implementation of this issue. Would it be possible to assign it back to me?
claim
Unfortunately, I'm extremely busy right now, therefore I will unassign me so that someone else can work on it.
Change:
[autolabel."S-waiting-on-review"] new_pr = true <ins> [autolabel."needs-triage"] new_issue = true </ins> [autolabel."WG-trait-system-refactor"] trigger_files = [ "compiler/rustc_trait_selection/src/solve",

Discussion:
The GitHub issue for https://rust- so I can nominate it for the teams. I've noticed that we have many issues inside rust-lang/rust that are completely untriaged with no interactivity. I don't believe that this is due to lack of time, but simply due to lack of organization. I propose that every new issue gets the label. Then, members can see the issues with that label and triage them. That includes labeling the issues and maybe replying to them if there's a specific request, for example answering a question or asking for a reproduction. Ideally triage is done by someone with knowledge in the issue's area but that's of course not a hard requirement. The person can then just remove the label. The label can also be settable via rustbot so anyone can do this. I'm confident that we'd have enough time to triage all issues with that labeling system (I would certainly participate, as I've been doing for a while now). I'm not entirely sure about the best process for deciding this. The reception on Zulip was positive, but I want to make sure that everyone here is on aware and on board. Given the shared team ownership of this repo I'm going to nominate this issue for the three major teams, compiler, libs and rustdoc (rustdoc doesn't have a nomination label apparently, so I'll just here :D) . If they all agree with the change, we can implement it (by using the triagebot feature I : ).
cc
Sounds good. Libs team is on board.
:+1:
Discussed in T-compiler meeting on Zulip (): looks like a really good idea. label -I-compiler-nominated
it's working!
I think we shouldn't add <kbdneeds-triage</kbdif it's a tracking issue. What's your opinion? IIUC, this can be accomplished by
sounds good
Change:
} // Seed implemeneted trait methods <del> let mut trait_method_seeder = TraitMethodSeeder { </del> <ins> let mut life_seeder = LifeSeeder { </ins> worklist: worklist }; <del> visit::walk_crate(&mut trait_method_seeder, crate, ()); </del> <ins> visit::walk_crate(&mut life_seeder, crate, ()); </ins> <del> return trait_method_seeder.worklist; </del> <ins> return life_seeder.worklist; </ins> } fn find_live(tcx: ty::ctxt,

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.
Change:
return RawTable { size: 0, capacity: 0, <del> hashes: Unique::null(), </del> <ins> hashes: ptr::null_mut(), </ins> marker: marker::CovariantType, }; }

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!