jiebi/CodeConvo huggingface dataset:
Change:
use rustc_hir as hir; use rustc_hir::def_id::{DefId, LocalDefId}; use rustc_infer::traits::FulfillmentError; <del> use rustc_middle::ty::{self, suggest_constraining_type_param, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, suggest_constraining_type_param, AssocItem, AssocKind, Ty, TyCtxt}; </ins> use rustc_session::parse::feature_err; use rustc_span::edit_distance::find_best_match_for_name; use rustc_span::symbol::{sym, Ident};

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
<ins> struct Qux; trait Foo { fn foo(); } trait FooBar { fn foo() {} } fn main() { Qux.foo(); //~^ ERROR no method named `foo` found for struct `Qux` in the current scope } </ins>

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'', 'thread 'rustc' panicked at 'index out of bounds: the len is 0 but the index is 0'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
/ ping
Change:
... LL | impl MyTrait for lib::MyStruct<MyType> { } | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `lib::MyStruct<MyType>` <ins> | = note: upstream crates may add new impl of trait `lib::MyCopy` for type `lib::MyStruct<MyType>` in future versions </ins> error: aborting due to previous error

Discussion:
PR had removed the notes from the tests for the upstream/downstream printing logic, so now that logic is not tested: Plus, the new error messages are worse: an upstream impl can indeed be , even if the crate is private. I think that even in the OP case, some sort of note should be , unless we change coherence. Again, the test case: There, the error message is a coherence conflict for , where this impl conflicts with the libcore impl, because the compiler can't prove that . Now, the error message says that the reason that the compiler can't prove is because of a possible downstream impl. Of course, no downstream impl can exist as the trait is private, however, I don't think we want to change coherence to account for that, especially not without an RFC. Maybe a wording change is in order? I don't think the "upstream" message needs to change any (see the test diff), it's still good in the private case. Maybe it should try to mention a non-private trait, but that would be some work. Say, for non-exported trait, change the note to say: I'm not even sure the note is a problem, I personally like the state before the PR the best. cc
Actually, I think the version of the note I came up with is even more confusing than the "downstream crate" note, and the current version is worse than both.
That PR was also submitted with no "positive" test to see that it fixes the error message it is purported to fix. That feels clearly wrong to me.
Change:
"opt",           // used to optimize LLVM bytecode ]; <ins> /// LLD file names for all flavors. const LLD_FILE_NAMES: &[&str] = &["ld.lld", "ld64.lld", "lld-link", "wasm-ld"]; </ins> pub const VERSION: usize = 2; /// Extra --check-cfg to add when building

Discussion:
lld-wrapper is unhappy. I tried this code: Instead, this happened: <!-- 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</detailsNote that this worked for months. This is a regression for me.
Is this issue related to ?
I found no traces of the last working nightly.
Is this issue related to It's certainly somehow related because didn't exist before that, but I don't know how it can happen, is in fact passed as snipped posted in the original message shows.
Do you need more information?
Do you need more information? Yes, output of lld-wrapper with inserted here (You don't need whole compiler build to rebuild lld-wrapper, it's a single-file standalone program, it can be built with directly or with , and then temporarily put into the directory.)
Note that main:rs73 is the failure case.
I see. The command line is to long so it's moved to a temporary file and passed with . Neither lld-wrapper nor original (flavorless) lld support specifying the flavor inside the file. Due to the way in which and work for naked LLD never gets into the file, we should do something similar with too.
I don't know whether rustc has utilities for handling response files
Ok, it's actually clang that packs the command line into a , not rustc, so we cannot control or predict when it happens. That's pretty bad. I guess we'll have to partially revert and use something based on file names, like
Fixed in Sorry for the delay, I should have fixed this two months ago. could you test the fix on Darwin?
Change:
/// negative minimal value for the type); this is equivalent /// to `-MIN`, a positive value that is too large to represent /// in the type. In such a case, this function returns `MIN` <del> /// itself.. </del> <ins> /// itself. </ins> #[stable(feature = "num_wrapping", since = "1.2.0")] #[inline(always)] pub fn wrapping_div(self, rhs: Self) -> Self {

Discussion:
Using Google I can find lots of old arguments over how integer division should work in Rust, but I cannot find anything in the reference, the API docs for the integer types, or the API docs for the trait that says what was actually decided. (And the documentation seems to imply that , , and may not all do the same thing.) This is further confused by the integer type documentation apparently sometimes using to refer to integer division and sometimes to mathematical division. (I can't come up with out any other reasonable interpretation of in the documentation.) It would be nice if this were clearly documented somewhere, since this varies between languages and is one of the main confusions with integer arithmetic.
talks about 'overflow' and mentions wrapping, but you're right that we can surface this better.
This is about rounding, not wrapping. We use LLVM's , which rounds towards zero (and has the same sign as the dividend). We should document this (the documentation for currently lies_, claiming that it rounds towards negative infinite).
This should also leave a warning, because integer / integer is not always desired and happens by accident. Just a thought if anyone is reading this.
Change:
/// Allows to modify `Self` to enable or disable the `ui_testing` flag. /// /// If this is set to true, line numbers will be normalized as `LL` in the output. <del> // FIXME(#59346): This method is used via the public interface, but setting the `ui_testing` // flag currently does not anonymize line numbers. We would have to add the `maybe_anonymized` // method from `emitter.rs` and implement rust-lang/annotate-snippets-rs#2 in order to // anonymize line numbers. </del> pub fn ui_testing(mut self, ui_testing: bool) -> Self { self.ui_testing = ui_testing; self

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
<ins> // Copyright 2018 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(never_type)] fn main() { // The `if false` expressions are simply to // make sure we don't avoid checking everything // simply because a few expressions are unreachable. if false { let _: ! = { //~ ERROR mismatched types 'a: while break 'a {}; }; } if false { let _: ! = { while false { //~ ERROR mismatched types break } }; } if false { let _: ! = { while false { //~ ERROR mismatched types return } }; } } </ins>

Discussion:
Having the following main function results in an illigal instruction on stable, beta and nighlty. It should be noted that when is not used after the loop, the illigal instruction does not occur Interestingly putting the same while-loop in a function works fine:
Update: A more simple version that also results in an illigal instruction: after some more trying, it can be shortened to this (and works for functions other than in main, as shown here: ) : adding a statement at the end of main seems to 'fix' the problem
Checking with godbolt, 1.25 and above: results in undefined instruction (this issue) 1.18 to 1.24: ICE with broken MIR 1.17: becomes no-op 1.16 and below: Error "use of undeclared label "
Err the last example is even featured in (introduced in ), but why this seems not tested at all . Edit: It generates an at MIR level. <details<summaryThe initial MIR already contains an unreachable.</summary</details<details<summary-Zunpretty=hir,typed</summary</details
It's because in the example that is tested, there's no semicolon: Why that makes a difference, I haven't determined yet.
The problem is, for some reason, the type checker inferred to have type , and thus the rest of the block is . However, without the the inferred type is just as expected.
Maybe slightly off-topic, but why are references to the label even allowed in the condition, rather than solely the body? You don't achieve extra expressiveness, as it's equivalent to returning false in the condition, and it makes things more complicated.
having code like this results in an ICE:
Because it is consistent with the desugaring of the while loop to a which is a valid and fairly sensible code.
I think the bug in in the type-checker then: it should not be giving the type of , clear. — you interested in fixing? I can give a few tips...
Marking as P-medium: technically a regression, but a very old one, and kind of a corner case. Still, I'll try to leave some notes on how to fix.
yeah, I can have a look into this. Might be a little delayed, but definitely within the next couple of weeks.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-102964.rs:5:41 | LL | fn bar_function<T>(function: Foo<T>) -> RcFoo<T> { |    ------------                         ^^^^^^^^ expected struct `Rc`, found `()` |    | |    implicitly returns `()` as its body has no tail or `return` expression | = note: expected struct `Rc<&dyn for<'a> Fn(&'a T)>` found unit type `()` help: consider returning the local binding `rc` | LL ~     let rc = Rc::new(function); LL +     rc | error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems that the ICE does not occur on latest nightly.
Yes indeed. I was told to still submit bugs even when they only occur on newest Beta.
label +E-needs-test
claim To add the test
If someone finds out which nightly pr fixed it I guess we could consider a backport to beta?
I fixed this in . I'll beta nominate it.
Change:
<ins> # ignore-cross-compile because we run the compiled code # needs-unwind because #[bench] and -Cpanic=abort requires -Zpanic-abort-tests include ../tools.mk NORMALIZE=sed 's%[0-9,]{1,} ns/iter (+/- [0-9,]{1,})%?? ns/iter (+/- ??)%' | sed 's%finished in [0-9.]{1,}%finished in ??%' all: $(RUSTC) --test tests.rs $(call RUN,tests) --test-threads=1 | $(NORMALIZE) > "$(TMPDIR)"/test.stdout $(RUSTC_TEST_OP) "$(TMPDIR)"/test.stdout test.stdout $(call RUN,tests) --test-threads=1 --bench | $(NORMALIZE) > "$(TMPDIR)"/bench.stdout $(RUSTC_TEST_OP) "$(TMPDIR)"/bench.stdout bench.stdout </ins>

Discussion:
libtest output recently started indenting some but not all test results: Seems like benchmarks are indented but regular tests are not.
Cc any idea which change might have caused this? I think this must be fairly recent but haven't tried bisecting yet.
Is this still reproducable?
With this can no longer be tested using x.py, since bootstrap now does test output formatting itself. So this now needs a little cargo project with a test and a benchmark, to check what libtest actually does.
It is because benches are dynamic, and they always use padding (and tests are static): I'm not sure why padding is different for static vs dynamic. Here is a repro:
Seems like that could use context if the bench is only being run as a test, then don't pad. The padding is desirable for benchmark output so the numeric values line up, for easier visual comparison. You could argue either way about tests -- maybe ok/FAILED would stand out even more with padded alignment.
PR with regression tests and a fix (in that order):
Change:
_ => &[], }; let lt_def_names = parent_generics.iter().filter_map(|param| match param.kind { <del> hir::GenericParamKind::Lifetime { .. } => Some(param.name.ident().modern()), </del> <ins> hir::GenericParamKind::Lifetime { .. } => Some(param.name.modern()), </ins> _ => None, }); self.in_scope_lifetimes.extend(lt_def_names);

Discussion:
The following breaks on nightly (see ) With: CC: dtolnay/async-trait
Reduced:
Forgot to mention in case this helps, giving the inner fn a matching lifetime avoids this issue for some reason:
The reason this is happening is that the desugared version of applies all in-scope lifetimes to the returned existential type, which in this case is creating , which is invalid. I'm not sure exactly what the best fix is for this, though, since elided lifetimes in the impl signature are intentionally unnameable. The closest idea I have would be to create some special new lifetime that is but can refer to lifetimes originating from the impl header. cc who may have opinions.
Hmm wouldn't you expect the nested to not inherit anything from its enclosing scopes? Seems like a bug to me that it does? Am I confused about something?
The function in the middle is actually a bit of a source of confusion here, although it does indicate that there's a second bug since we shouldn't be inheriting generics since the nested isn't part of the . The bug I was focusing on is better illustrated by this example: which produces this error: This is because the code is transformed into and in that case does not refer back to the usage from the header.
I see. Indeed, I would expect that, internally, we'd have some way to refer back to the from the impl header. I believe this should be possible, no? In particular, the in impls expands (internally) to for some integer N, which I believe is basically treated like any other named lifetime.
Yep, I would've expected so as well-- I'm not sure why that isn't working, I'd have to take a look.
I was looking and I think the bug lies here: Probably needs to be a instead, or we need to use something else for this purpose.
A closer reading suggests I was mistaken. The lifetimes from the impl should show up in -- includes only the explicitly declared lifetimes written by the user on the impl. I'm not quite sure what the problem is yet.
OK, no, I was correct. When processing impl items, we convert the lifetimes into entries. EDIT: Er, I'm still not entirely sure. Reading more. =)
OK, I have a fix for the method issue, but not the nested async fn item issue.

I forked off for the method issue
I didn't prep a fix for this one yet. It seems obvious that some internal state is not being reset when we enter a new item.
but if you have a chance to investigate, would be appreciated
Presumably the problem is that doesn't "reset" the vector -- it only seems to extend it...
Indeed, in-band lifetimes are broken in the same way. This fails to compile ():
Working on a possible fix
Yep, have a fix.
Inband lifetimes looks similar to fwiw
thanks
Change:
let param = self.param_at(param.index as usize, tcx); match param.kind { GenericParamDefKind::Lifetime => param, <del> _ => bug!("expected lifetime parameter, but found another generic parameter"), </del> <ins> _ => { bug!("expected lifetime parameter, but found another generic parameter: {param:#?}") } </ins> } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
err.set_primary_message( "cannot initialize a tuple struct which contains private fields", ); <ins> if !def_id.is_local() && self .r .tcx .inherent_impls(def_id) .iter() .flat_map(|impl_def_id| { self.r.tcx.provided_trait_methods(*impl_def_id) }) .any(|assoc| !assoc.fn_has_self_parameter && assoc.name == sym::new) { // FIXME: look for associated functions with Self return type, // instead of relying only on the name and lack of self receiver. err.span_suggestion_verbose( span.shrink_to_hi(), "you might have meant to use the `new` associated function", "::new".to_string(), Applicability::MaybeIncorrect, ); } </ins> // Use spans of the tuple struct definition. self.r.field_def_ids(def_id).map(|field_ids| { field_ids

Discussion:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.
Change:
[[package]] name = "gccjit_sys" version = "0.0.1" <del> source = "git+https://github.com/antoyo/gccjit.rs#eefb8c662d61477f34b7c32d26bcda5f1ef08432" </del> <ins> source = "git+https://github.com/antoyo/gccjit.rs#fe242b7eb26980e6c78859d51c8d4cc1e43381a3" </ins> dependencies = [ <del> "libc 0.1.12", </del> <ins> "libc", </ins> ] [[package]]

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
// xfail-fast // xfail-android <del> #[feature(quote_expr)]; </del> <ins> #[feature(quote)]; </ins> #[deny(unused_variable)]; extern mod syntax;

Discussion:
These all are only useful in the compiler, aren't hygienic, etc. Nominating.
What hygiene issues do they still have? The hygiene issue I'm aware of was fixed by . They'll be very useful for externally defined syntax extensions. I'm okay with feature gating it though.
The only thing I recall is that they require an to be in scope. Perhaps that's not technically a hygiene problem.
Accepted for 1.0, P-backcompat-lang.
I would like to look at this, but I am not familiar to quasi-quoting. Can you list some quasi-quoting macros, or point out the directory of the source tree to look up? What I have found related to quasi-quoting lies on .
All of the quasi-quoting macros live there.
Their .