jiebi/CodeConvo huggingface dataset:
Change:
... LL | impl<T: Clone + ?Sized> Clone for Node<[T]> { | ------------------------------------------- first implementation here <ins> | = note: upstream crates may add new impl of trait `std::clone::Clone` for type `[_]` 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:
<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. type A = for<> fn(); type B = for<'a,> fn(); pub fn main() {} </ins>

Discussion:
Code: Compiles on 1.13-stable,beta, fails on 1.14-nightly.
(Forget that, see below).
Apart from that, this was introduced between and ().
I strongly suspect this is an unintended side effect of Prohibiting this deliberately doesn't make any sense, empty lists are allowed in () all other possible contexts.
Yeah, I probably mis-remembered :( I agree that this was probably a side effect of .
In fact, this fails too:
Change:
<ins> // normalize-stderr-test "loaded from .*libcore-.*.rlib" -> "loaded from SYSROOT/libcore-*.rlib" #![feature(lang_items)] #[lang="sized"] trait Sized { } //~ ERROR found duplicate lang item `sized` fn ref_Struct(self: &Struct, f: &u32) -> &u32 { //~^ ERROR `self` parameter is only allowed in associated functions //~| ERROR cannot find type `Struct` in this scope //~| ERROR mismatched types let x = x << 1; //~^ ERROR the size for values of type `{integer}` cannot be known at compilation time //~| ERROR cannot find value `x` in this scope } 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. --found via fuzzing <!-- 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
It seems that the ICE does not need and no_core feature. A little bit smaller example is:
Change:
<ins> error[E0624]: method `foo` is private --> $DIR/issue-53498.rs:16:5 | LL |     test::Foo::<test::B>::foo(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0624`. </ins>

Discussion:
I got this pretty weird ICE while in the middle of a refactor. I don't know how to turn this into a minimal example, so here's the offending code that reproduces this error:
What version of the compiler are you using?

I made a struct , and made two blocks for and ( and are unit structs.) Each block has a method with same name but different argument count. I accidentally made those methods private. [Link to the playground][playground] [playground]: I expected to get error about privacy, but with that, the compiler panicked. Backtrace: <details</details
A more minimal repro:
Interesting point: in this code, doesn't have method but the compiler reports that it exists but is private. However, with , the compiler reports error correctly.
CC , .
Change:
<ins> // Copyright 2015 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. // error-pattern: overflow representing the type `S` trait Mirror { type It; } impl<T> Mirror for T { type It = Self; } struct S(Option<<S as Mirror>::It>); fn main() { let _s = S(None); } </ins>

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
incremental = true # Print backtrace on internal compiler errors during bootstrap backtrace-on-ice = true <ins> # Make the compiler and standard library faster to build, at the expense of a ~20% runtime slowdown. lto = "off" </ins> [llvm] # Will download LLVM from CI if available on your platform.

Discussion:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?
Change:
// Hence there are `cfg` throughout this test to disable parts of it on those targets. // sparc64: https://github.com/rust-lang/rust/issues/115336 // mips64: https://github.com/rust-lang/rust/issues/115404 <del> // loongarch64: https://github.com/rust-lang/rust/issues/115509 </del> macro_rules! assert_abi_compatible { ($name:ident, $t1:ty, $t2:ty) => {

Discussion:
The types and do not have the same ABI, as demonstrated by this testcase: The first is The second is RISC-V had , so the fix will likely . I couldn't find an O-loongarch label. Cc'ing the people listed on
The loongarch ABI seems to be pretty much exactly like the RISC-V ABI, so I wonder if it would make sense to share some of that code so that bugs like this only have to be fixed once.
Thanks for the report! The LoongArch ABI is indeed closely modeled after that of RISC-V, so yeah the fix should look similar. should be able to follow up tomorrow.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
I don't think you meant to tag me. Don't know much about rust.
Doh, the correct Rust/LoongArch person is who happens to have another handle of "hev". Sorry for the noise!
Thanks for your pointing out. I don't think the types and would have the same ABI on LoongArch64. The key point of the problem is that is a , which is different from a : For types and , they are same ABI: The first is: The second is: And it seems that the current ABI of is the same as that of C language on LoongArch64: The first is: The second is:
I haven't studied the LoongArch psABI as closely, but from a Rust semantics perspective: is "a -sized area that may or may not hold an initialized ", so and really should behave the same when that's the case -- implying the two must have the same ABI. So this is something to look into and fix after all...
It's a Rust union, but it doesn't have , so whatever applies to C unions is completely irrelevant. For instance, many ABIs (e.g. x86) treat structs different from integers, and still has the same ABI as -- that's because is not a struct, so its ABI doesn't have to match that of a C struct. We promise that has the same ABI as for all on all targets, so this is really not optional. Your C example, when translated to Rust, needs on all types. The ABI of those types obviously needs to match the C types. But that's completely compatible with also treating types differently.

Thank you for your explanation. Hmm, I'm not familiar with Rust ABI, and it seems to have less relevance to psABI. OK, I will follow the RISC-V patches to fix LoongArch.
It's the same problem we have on all targets: there is a target ABI that is defined in terms of C types, and now every other language has to figure out how to map their types to C types to then compute the ABI from that. Unfortunately the Rust compiler has no central infrastructure for that (there's no function to "give me the C type that describes the ABI of a given Rust type"), and so each target has to implement that mapping itself, and they are all making similar mistakes...
label +O-loongarch
Change:
<ins> // revisions: default miropt //[miropt]compile-flags: -Z mir-opt-level=2 // ~^ This flag is for #77668, it used to be ICE. </ins> #![crate_type = "lib"] pub fn bar<P>( // Error won't happen if "bar" is not generic

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
Seems it regressed in , cc
This occurs in regex_syntax as well.
I think that this is a missing normalize call here:
?
Yeah, just checked and it fixes the issue, cc
has merged now
Change:
<ins> // revisions: default miropt //[miropt]compile-flags: -Z mir-opt-level=2 // ~^ This flag is for #77668, it used to be ICE. </ins> #![crate_type = "lib"] pub fn bar<P>( // Error won't happen if "bar" is not generic

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 think all of these happen since <!-- 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</detailsThe following samples also did not crash with -Zvalidate-mir with but do crash with  `
cc
Change:
cargo.rustflag("-Cembed-bitcode=yes"); } RustcLto::ThinLocal => { /* Do nothing, this is the default */ } <ins> RustcLto::Off => { cargo.rustflag("-Clto=off"); } } } else { if builder.config.rust_lto == RustcLto::Off { cargo.rustflag("-Clto=off"); </ins> } }

Discussion:
Currently bootstrap supports LTO flavors thin-local (default), thin and fat. Adding the option to completely disable it can speed up develop cycles, especially with incremental compilation. See for benchmarks. When LTO is disabled the standard library still has to be built with so that it can be used by other crates which enable LTO. Disabling should become the default for the library and compiler profile templates. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim to not loose it to time, but feel free to claim it if you want, I might not start work on this until February.
Error: Parsing assign command in failed: ...' claim' ' to not lo'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim Shouldn't this bot be able to detect end of command and silently ignore the rest of the line ?
Change:
<ins> // pp-exact fn main() { } struct C { field: u8, } #[allow()] const C: C = C{ #[cfg(debug_assertions)] field: 0, #[cfg(not (debug_assertions))] field: 1,}; </ins>

Discussion:
If we have an attribute macro whose input contains attributes on fields of a struct-expression, those attributes all seem to disappear before the macro is invoked. The following repro compiles successfully if #[repro::repro] is removed, but fails with "error[E0062]: field  specified more than once" if the macro is present even though it does nothing. <details<summaryHere is a script that reproduces the behavior as of rustc 1.42.0-nightly ( 2020-01-30)</summary</details<details<summaryHere is the input token stream as received by the proc macro</summary</detailscc
I have a fix in The bug was in pretty printing (usually the case in these types of bugs).
Change:
// pretty-expanded FIXME #23616 <ins> #![allow(deref_nullptr)] </ins> use std::env; pub fn main() {

Discussion:
I propose we add a lint that detects code like Some people seem to think that this is okay in contexts like or , but that is not the case -- on a NULL pointer is UB even as a place expression. To implement this, you can use the lint as a template: should check for  expressions with a operator, and then check the operand to be either a cast of to a pointer type, or a call to one of the methods. To detect the methods, make them "diagnostic items"; the lint does that e.g. for so it can again serve as a template here. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Ah, turns out clippy already has a lint for this: . So maybe we should just move that to rustc? Cc
claim
awesome. :) Let me know if you need any help.
Thanks :)
Did you mean something slightly different with your "okay in contexts like" examples, perhaps? Neither of those two actually compile as written, since they're just attempts to deference something that isn't even a pointer. You get: in both cases.
oops I screwed up the casts, should be fixed now.
Yeah, happy to have Clippy lints upstreamed to rust, let us know when it's done so we can deprecate it on our end
for detecting a call like you said to use . However I do not know what to use for the symbol argument. There is that defines symbol but nothing looks like creating a null ptr. Should I add one what should it look like ?
You first need to add the diagnostic item attribute to the relevant function inside , like so: This name must be globally unique, e.g. and . Then you add those names to the list in (please keep it alphabetically sorted), and then you can use them for .
Change:
// Get the struct fields from this struct-like enum variant. let class_fields = ty::lookup_struct_fields(tcx, variant_id); <del> check_struct_pat_fields(pcx, span, path, fields, class_fields, </del> <ins> check_struct_pat_fields(pcx, span, fields, class_fields, </ins> variant_id, substitutions, etc); } Some(&ast::DefStruct(..)) | Some(&ast::DefVariant(..)) => {

Discussion:
This is one of those bugs where an earlier error is leading to poor error reporting later on in the output. So it should not be considered high priority. Nonetheless, it would be nice if we could strive for error messages to be sane when considered in isolation, which this example violates: Transcript: The issue is that the second message claims that does not have a field named , but it clearly does. I could understand this message if it said vec2 does not have a field named .
Change:
}; } <del> let binding = if let Some(module) = module { self.resolve_ident_in_module( module, ident, ns, parent_scope, record_used, path_span, ) } else if ribs.is_none() || opt_ns.is_none() || opt_ns == Some(MacroNS) { let scopes = ScopeSet::All(ns, opt_ns.is_none()); self.early_resolve_ident_in_lexical_scope( ident, scopes, parent_scope, record_used, record_used, path_span, ) } else { let record_used_id = if record_used { crate_lint.node_id().or(Some(CRATE_NODE_ID)) } else { None }; match self.resolve_ident_in_lexical_scope( ident, ns, parent_scope, record_used_id, path_span, &ribs.unwrap()[ns], ) { // we found a locally-imported or available item/module Some(LexicalScopeBinding::Item(binding)) => Ok(binding), // we found a local variable or type param Some(LexicalScopeBinding::Res(res)) if opt_ns == Some(TypeNS) || opt_ns == Some(ValueNS) => { record_segment_res(self, res); return PathResult::NonModule(PartialRes::with_unresolved_segments( res, path.len() - 1, )); </del> <ins> enum FindBindingResult<'a> { Binding(Result<&'a NameBinding<'a>, Determinacy>), PathResult(PathResult<'a>), } let find_binding_in_ns = |this: &mut Self, ns| { let binding = if let Some(module) = module { this.resolve_ident_in_module( module, ident, ns, parent_scope, record_used, path_span, ) } else if ribs.is_none() || opt_ns.is_none() || opt_ns == Some(MacroNS) { let scopes = ScopeSet::All(ns, opt_ns.is_none()); this.early_resolve_ident_in_lexical_scope( ident, scopes, parent_scope, record_used, record_used, path_span, ) } else { let record_used_id = if record_used { crate_lint.node_id().or(Some(CRATE_NODE_ID)) } else { None }; match this.resolve_ident_in_lexical_scope( ident, ns, parent_scope, record_used_id, path_span, &ribs.unwrap()[ns], ) { // we found a locally-imported or available item/module Some(LexicalScopeBinding::Item(binding)) => Ok(binding), // we found a local variable or type param Some(LexicalScopeBinding::Res(res)) if opt_ns == Some(TypeNS) || opt_ns == Some(ValueNS) => { record_segment_res(this, res); return FindBindingResult::PathResult(PathResult::NonModule( PartialRes::with_unresolved_segments(res, path.len() - 1), )); } _ => Err(Determinacy::determined(record_used)), </ins> } <del> _ => Err(Determinacy::determined(record_used)), } </del> <ins> }; FindBindingResult::Binding(binding) }; let binding = match find_binding_in_ns(self, ns) { FindBindingResult::PathResult(x) => return x, FindBindingResult::Binding(binding) => binding, </ins> }; match binding { Ok(binding) => { if i == 1 {

Discussion:
Given this code (): I expected that would indicate that is not function but is. Instead, I got: A diagnostic along the lines of isn't a function, but is would be helpful. <!-- 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. --: </p</details
I tried to resolve this issue with The error message now is Any informative error message suggestions?
Thanks for trying to address this. I'll comment on the PR you opened.
Change:
| LL | fn bar<T, K, Z: Default>(t: T, k: K) -> Bar<T, K, Z> { |                 ^^^^^^^ required by this bound in `bar` <del> help: consider giving `bar` an explicit type, where the type for type parameter `Z` is specified | LL |     let bar: Bar<i32, &str, Z> = bar(1, ""); |            +++++++++++++++++++ </del> help: consider specifying the type arguments in the function call | LL |     let bar = bar::<T, K, Z>(1, "");

Discussion:
Gives (rustc 1.60.0-nightly 2022-01-30): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
// WF and (b) the trait-ref holds.  (It may also be // normalizable and be WF that way.) let trait_ref = data.trait_ref(self.infcx.tcx); <del> self.compute_trait_ref(&trait_ref); </del> <ins> self.compute_trait_ref(&trait_ref, Elaborate::None); </ins> if !data.has_escaping_regions() { let predicate = trait_ref.to_predicate();

Discussion:
First reported in cc - let's discuss this when you are back from vacation (unless can come up with a solution?)
Associated types variant, which bypasses some fixes based only on supertraits:
Chalk's strategy will solve this, but I guess that shouldn't be extremely difficult to fix even with the current strategy. The first impl is valid: since indeed implies that . The second however, is not: the impl declaration should be able to prove that holds (ok because of the first impl), but also that is well-formed, i.e. that holds. Same thing in the second example, this impl declaration: should prove that (ok) and that is well-formed, i.e. . The latter is not being proved currently.
triage: P-high -- has pending fix
Change:
return document.getElementById("theme-picker"); } <ins> // Returns the current URL without any query parameter or hash. function getNakedUrl() { return window.location.href.split("?")[0].split("#")[0]; } </ins> // Sets the focus on the search bar at the top of the page function focusSearchBar() { getSearchInput().focus();

Discussion:
mdbook v4.6+ has a feature that pressing ESC removes query components from URLs (for example ). The feature was implemented in rust-lang/mdBook. It would be nice if rustdoc offers the same kind of that feature. This is, for example, an URL that contains query components in rustdoc: When users share URLs to an API, they don't have to remove the query manually.
could you share some thoughts about this feature request? If possible, could you mentor contributors how to implement this ?
I think it's a good idea. Gonna take a look at how to do it.
Can we reopen this issue ? I think only removes the query component when we remove keywords in search bar. This issue is about adding a keyboard shortcut.
Oh I see, my bad. Reopening!
Change:
/// returns, regardless of whether the timeout elapsed or not. /// /// [`wait`]: #method.wait <ins> /// [`wait_timeout_until`]: #method.wait_timeout_until </ins> /// [`WaitTimeoutResult`]: struct.WaitTimeoutResult.html /// /// # Examples

Discussion:
Yes, another incarnation of . and also have this issue. Note that is an error and has a test for it. cc
Does this also date back to 1.0, like did?
Yes. The fix would be technically a breaking change.