jiebi/CodeConvo huggingface dataset:
Change:
let a = self.shallow_resolve(a); let b = self.shallow_resolve(b); <ins> // We should never have to relate the `ty` field on `Const` as it is checked elsewhere that consts have the // correct type for the generic param they are an argument for. However there have been a number of cases // historically where asserting that the types are equal has found bugs in the compiler so this is valuable // to check even if it is a bit nasty impl wise :( // // This probe is probably not strictly necessary but it seems better to be safe and not accidentally find // ourselves with a check to find bugs being required for code to compile because it made inference progress. self.probe(|_| { if a.ty() == b.ty() { return; } // We don't have access to trait solving machinery in `rustc_infer` so the logic for determining if the // two const param's types are able to be equal has to go through a canonical query with the actual logic // in `rustc_trait_selection`. let canonical = self.canonicalize_query( (relation.param_env(), a.ty(), b.ty()), &mut OriginalQueryValues::default(), ); if let Err(NoSolution) = self.tcx.check_tys_might_be_eq(canonical) { self.tcx.sess.delay_span_bug( DUMMY_SP, &format!("cannot relate consts of different types (a={:?}, b={:?})", a, b,), ); } }); </ins> match (a.kind(), b.kind()) { ( ty::ConstKind::Infer(InferConst::Var(a_vid)),

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</detailsThis occurred in code different from the above but this is a minimal example that causes this failure. I believe I am disobeying some rules in the manner in which is not bound in the underlying type of the trait. This bug appeared in my own code that worked with a previous nightly build. That code does bind into the underlying type and still fails. If I bind it in this example with the following changes: the error goes away. I will need to create a minimal example that produces an ICE closer to the failure in my own code but I was struggling to do this. This is at least one ICE of interest and perhaps the unbound should itself be prevented. I'm not entirely sure. Worthy of note, the following also compiles fine: which omits all of the stuff.
I've isolated it to the following commit range: ..
I determined it was due to the above linked-from PR.
Prior to this PR, the above code would emit the following warning instead of generating the ICE:
This is caused by the fact that acts sort of like a const item with a const param ty the references other generic parameters: . When we relate the in we constrain infer vars to be the same as eachother but do not end up actually resolving the infer vars before relating so the assertion that const param ty's are sees two different infer vars instead of the resolved ones.
Change:
<ins> #![feature(const_let)] static mut FOO: (u8, u8) = (42, 43); static mut BAR: () = unsafe { FOO.0 = 99; }; //~^ ERROR could not evaluate static initializer fn main() {} </ins>

Discussion:
https://crater-
cc Repro I'm going to fix the regression, but I just want to note that is very dangerous to use. This looks like another argument for
FWIW the code in question is some mechanically translated C with the translation performed by . I have pretty much abandoned that project.
triage: P-high.
Change:
<ins> // run-rustfix #![deny(unused_qualifications)] mod foo { pub fn bar() {} } mod baz { pub mod qux { pub fn quux() {} } } fn main() { use foo::bar; foo::bar(); //~^ ERROR unnecessary qualification use baz::qux::quux; baz::qux::quux(); //~^ ERROR unnecessary qualification } </ins>

Discussion:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .
Change:
&self, path: &[Segment], ) -> Option<(Span, &'static str, String, Applicability)> { <del> let ident = match path { [segment] => segment.ident, </del> <ins> let (ident, span) = match path { [segment] if !segment.has_generic_args => { (segment.ident.to_string(), segment.ident.span) } </ins> _ => return None, }; <del> match ( self.diagnostic_metadata.current_item, self.diagnostic_metadata.currently_processing_generics, ) { (Some(Item { kind: ItemKind::Fn(..), ident, .. }), true) if ident.name == sym::main => { </del> <ins> let mut iter = ident.chars().map(|c| c.is_uppercase()); let single_uppercase_char = matches!(iter.next(), Some(true)) && matches!(iter.next(), None); if !self.diagnostic_metadata.currently_processing_generics && !single_uppercase_char { return None; } match (self.diagnostic_metadata.current_item, single_uppercase_char) { (Some(Item { kind: ItemKind::Fn(..), ident, .. }), _) if ident.name == sym::main => { </ins> // Ignore `fn main()` as we don't want to suggest `fn main<T>()` } <del> (Some(Item { kind, .. }), true) => { </del> <ins> ( Some(Item { kind: kind @ ItemKind::Fn(..) | kind @ ItemKind::Enum(..) | kind @ ItemKind::Struct(..) | kind @ ItemKind::Union(..), .. }), true, ) | (Some(Item { kind, .. }), false) => { </ins> // Likely missing type parameter. if let Some(generics) = kind.generics() { <ins> if span.overlaps(generics.span) { // Avoid the following: // error[E0405]: cannot find trait `A` in this scope //  --> $DIR/typo-suggestion-named-underscore.rs:CC:LL //   | // L | fn foo<T: A>(x: T) {} // Shouldn't suggest underscore //   |           ^- help: you might be missing a type parameter: `, A` //   |           | //   |           not found in this scope return None; } </ins> let msg = "you might be missing a type parameter"; let (span, sugg) = if let [.., param] = &generics.params[..] { let span = if let [.., bound] = &param.bounds[..] {

Discussion:
Rustc should know that is not in the right direction because that still wouldn't make a valid thing to write; type parameters can't have type parameters (yet??). Separately, should also have prevented the suggestion in this case, but is an independent issue. cc who worked on this recently in .
Change:
<ins> #![feature(const_generics)] //~ WARN the feature `const_generics` is incomplete struct A<T = u32, const N: usize> { //~^ ERROR type parameters with a default must be trailing arg: T, } fn main() {} </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:
{ debug!("evaluate_stack({:?}) --> recursive", stack.fresh_trait_ref); let cycle = stack.iter().skip(1).take(rec_index + 1); let cycle = cycle.map(|stack| ty::Predicate::Trait(stack.obligation.predicate)); if self.coinductive_match(cycle) {

Discussion:
This is a regression between rustc 1.20.0 and 1.21.0. 20 correctly rejects this code with the following error.
Tagging P-high because this very much affects Serde.
Same issue using Serde traits: (One possible) output:
Even better, :
Perhaps we can bisect this regression? (e.g., with )
Bisected to correct behavior in nightly-2017-07-07 -- rustc 1.20.0-nightly ( 2017-07-06), incorrect behavior in nightly-2017-07-08 -- rustc 1.20.0-nightly ( 2017-07-07). That range is Looks like
visited for triage. Assigning to
thanks, very helpful!
I think the bug is here: In particular, I think the condition is not strong enough. doesn't consider region annotations, so we probably need to not use this logic if there are any regions. But I'm wondering if the whole concept is flawed. I'm a bit fearful of regions being introduced through associated type normalization.
I have a fix.
Of course, any approach that relies on any lifetimes in the affected trait-ref is fatally flawed - here's an example where the trait ref is the region-free .
I'm not really sure what your example is meant to illustrate. That said, running that on my branch gives an error: This seems like the error I would expect, more or less. We try to use the impl to prove that but we fail to do so (because of the side condition that it adds).
BTW, the check looks like it happened because I used there, and an explicit check when he changed in to note be made true by late-bound regions.
visited for triage. bug seems to be being dealt with, assuming that PR is eventually deemed as passing muster...
Yes, I think that the "no late-bound regions" check was basically a workaround for this same problem; I removed it in the PR since I think it has a "more correct" fix.
Change:
); let body_block = self.with_loop_scope(e.id, |this| this.lower_block(body, false)); <del> let body_expr = P(self.expr_block(body_block, ThinVec::new())); let body_stmt = self.stmt(body.span, hir::StmtKind::Expr(body_expr)); </del> <ins> let body_expr = self.expr_block(body_block, ThinVec::new()); let body_stmt = self.stmt_expr(body.span, body_expr); </ins> let loop_block = P(self.block_all( e.span,

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
actual_return_ty = fcx.next_diverging_ty_var( TypeVariableOrigin::DivergingFn(span)); } <del> fcx.demand_suptype(span, ret_ty, actual_return_ty); </del> <ins> fcx.demand_suptype(span, revealed_ret_ty, actual_return_ty); </ins> // Check that the main return type implements the termination trait. if let Some(term_id) = fcx.tcx.lang_items().termination() {

Discussion:
we’re stabilizing the combination of features that allows you to put in the return type of main as in . Amusing but unintended so it’s better to forbid this for now.
It's a bit late to change this. Does it cause any problem? AFAICT it just gives you a weird way to declare , but no new capability.
It doesn't give any new capability, I guess would even make sense in the return type of main. This bug could be considered a feature.
cc
Why this is an issue? returns and implements .
does not implement , which is required for the return type of .
Yea, it seems you can use any trait: Works on beta and nightly. So it'll probably work on this weeks stable You can't do anything stupid with this feature. The checks see right through the impl Trait to the real type (). I'd say adding a regression test that ensures that this corner case essentially ignores the anonymization of impl Trait is fine. We can add a deny by default lint that tells you that while this works, it's not pretty.
This seems fine to me and unless we care enough to stop the stable release we're not going to change this. cc though.
Hmm, I feel like we should just fix this. I doubt there are a lot of people taking advantage of it. I can put up some mentoring instructions. We can do a warning period if needed.
Fwiw I tried fixing by doing and got ICEs and stack oveflows which I couldn't debug so I gave up.
Hmm, I don't understand the stack overflows, but I think I would expect that patch to have no effect. The cause of the bug is that we are "instantiating" the impl Trait, here: In the process, we shadow the "original" with a new variable . This new will contain an inference variable used to find the "hidden" type underneath the . Later on, when we add the obligation that (where is the return type), we use this new variable: If we used the original (currently shadowed) , I think it would permit you to use but not other impl traits. (That said, it wouldn't be the end of the world if we just let this go, I suppose.)
As far as I understand we don't want to block 1.26 stable on this, right?

In that case I think we should go with a lint instead of an hard error, since both of the features will be stabilized now.
I probably borked the state of my clone or something. Thanks for the explanation, makes perfect sense, will make a patch.
Change:
<ins> error: constant expression depends on a generic parameter --> $DIR/issue-74634.rs:15:11 | LL | where (): If<{N == 0}> { |           ^^^^^^^^^^^^ | = note: this may fail depending on what value the parameter takes error: aborting due to previous error </ins>

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- 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 --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --Code from glacier: <!-- 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
NB: Only panics for me with the flag.
Change:
// Building with a static libstdc++ is only supported on linux right now, // not for MSVC or macOS if build.config.llvm_static_stdcpp && <ins> !target.contains("freebsd") && </ins> !target.contains("windows") && !target.contains("apple") { cargo.env("LLVM_STATIC_STDCPP",

Discussion:
Steps to reproduce, on my FreeBSD/amd64 11.0 system: , where is: It's not 100%, but it usually happens after a few tries at most. I'll skip all the debugging and source-diving and just say that it's the same basic problem as : threads A and B are both in , thread A gets to first and s a lambda, then thread B enters and blocks in with the global mutex held, then thread A calls reentrantly on a different and deadlocks. But there might be a nicer solution than for , because has this patch: , on all platforms where they use Clang (apparently x86, little-endian ARM, and PPC), and 10.x is now the . appears to have a self-contained that doesn't use , and emprically the Rust 1.18.0 package available via doesn't deadlock. So, it might be enough to upstream that patch and update the build environment to 10.x if it isn't already.
Looks like we're using 10.2 on ci:
Thanks for the pointer. I took a (much) closer look at this, and I've gotten the build more or less working using Ubuntu's regular Clang package, which can cross-compile out of the box. I'll send a PR once I've gotten things cleaned up and tested a bit more.
So I'm kind of stuck because, when I try to test locally, I run into unless I remove , which isn't maximally useful because I don't have Cargo and therefore can't build Cargo. This happens even without my changes, but the same container running on Travis CI seems to work, and I'm at a loss as to what differences there could be that would affect (apparently?) the type checker. I suppose I could just test what I can and send a PR and hope for the best, but if possible I'd prefer to understand what my local setup is doing wrong.
Noticed this on 12-CURRENT, compilers from rustup always lock up when compiling , but it usually succeeds after a couple tries. It's nearly always !
Hmm, the rust from ports (that doesn't have this problem IIRC??) is built with bundled llvm by default…
Change:
_ => false, } }) && (type_is_local || info.def_id.is_local()) <ins> && !self.tcx.trait_is_auto(info.def_id) </ins> && self .associated_value(info.def_id, item_name) .filter(|item| {

Discussion:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim
Change:
AssocConstraintKind, BlockCheckMode, GenericArg, GenericArgs, Generics, ParenthesizedArgs, Path, PathSegment, QSelf, }; <del> use rustc_errors::{Applicability, PResult}; </del> <ins> use rustc_errors::{Applicability, Diag, PResult}; </ins> use rustc_span::symbol::{kw, sym, Ident}; use rustc_span::{BytePos, Span}; use std::mem;

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.
Change:
} // Add spans for the stacktrace. Don't print a single-line backtrace though. if self.stacktrace.len() > 1 { <ins> // Helper closure to print duplicated lines. let mut flush_last_line = |last_frame, times| { if let Some((line, span)) = last_frame { err.span_label(span, &line); // Don't print [... additional calls ...] if the number of lines is small if times < 3 { for _ in 0..times { err.span_label(span, &line); } } else { err.span_label( span, format!("[... {} additional calls {} ...]", times, &line), ); } } }; let mut last_frame = None; let mut times = 0; </ins> for frame_info in &self.stacktrace { <del> err.span_label(frame_info.span, frame_info.to_string()); </del> <ins> let frame = (frame_info.to_string(), frame_info.span); if last_frame.as_ref() == Some(&frame) { times += 1; } else { flush_last_line(last_frame, times); last_frame = Some(frame); times = 0; } </ins> } <ins> flush_last_line(last_frame, times); </ins> } // Let the caller finish the job. emit(err)

Discussion:
Given the following code (): The current output is: <details<summaryMassive diagnostic</summary</detailsIdeally, the duplicate lines should be hidden: modify labels: +A-const-fn +D-verbose <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} else { trans_fn(ccx, &**decl, &**body, llfn, empty_substs, item.id, &item.attrs); } <ins> set_global_section(ccx, llfn, item); </ins> update_linkage(ccx, llfn, Some(item.id), if is_origin { OriginalTranslation } else { InlinedCopy });

Discussion:
I compile the code below: using compiler version 1.3.0-nightly ( 2015-07-27) with the following command line: As result I get the following symbol inside a produced rlib:
How'd you verify this? I tried a few variants myself and it looks like it works.
It's broken in Nightly release. Try the following code in after choosing 'Asm' and 'Nightly'.
Aha, looks like I was using an older nightly. cc some informal bisecting turns up as a suspicious commit
Yes, that bisection is correct; PR coming up.