jiebi/CodeConvo huggingface dataset:
Change:
// Local js definitions: /* global addClass, getCurrentValue, onEachLazy, removeClass, browserSupportsHistoryApi */ <del> /* global updateLocalStorage */ </del> <ins> /* global updateLocalStorage, getVar */ </ins> "use strict"; (function() { <del> const rootPath = document.getElementById("rustdoc-vars").attributes["data-root-path"].value; </del> <ins> const rootPath = getVar("root-path"); </ins> const NAME_OFFSET = 0; const DIRS_OFFSET = 1;

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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.
Change:
use middle::subst; use middle::ty::{self, HasProjectionTypes, Ty}; use middle::ty_fold::TypeFoldable; <del> use middle::infer::{self, InferCtxt}; </del> <ins> use middle::infer::{self, fixup_err_to_string, InferCtxt}; </ins> use std::slice::Iter; use std::rc::Rc; use syntax::ast;

Discussion:
Attempting to compile with and yields the following ICE:
Reduced test case: Still ICEs with The ICE goes away if the on the is changed to a bare instead of a reference.
Slightly different test case: EDIT: Nevermind, it's the same but uses a closure instead of the more general .
I have bisected this issue to rust-lang/rust (from )
A workaround would be simply:
This doesn't help much if you need to call methods that are on the trait (which was on the original code).
cc me
This is blocking collect-rs from compiling.
This is interesting. The culprit is : it registers obligations from implementation's methods into an hybrid parameter environment which has trait's methods in it. In the example given in this issue, when the associate type is projected out, the implementation's method acquires an extra lifetime variable. The trait's method doesn't have it so the lifetime resolution fails in an ICE later on. I'm not sure how to fix that though.
This compiles so at first glance it looks like a viable workaround: But if one tries to really use as an , compiler panics on an assertion failure:
Getting this with some hashing code.

will output something along the lines of: Start hash BYTES: [69, 84, 87, 87, 100, 57, 118, 102, 80, 97, 122, 56, 100, 116, 80, 82, 74, 78, 104, 116, 109, 51, 88, 54, 56, 98, 56, 97, 66, 119, 105, 116, 90, 114, 50, 83, 107, 99, 51, 52, 89, 121, 121, 112, 86, 116, 57, 66, 120, 87, 86, 112, 88, 55, 66, 49, 76, 90, 86, 48, 49, 53, 56, 53, 52, 48, 56, 56, 49, 53, 54, 48, 51] lyra2 finished: CfV9jehQVXsVnx6Vrg5f9VgHVkWeatbrFGxKVz2knfEc Starting argon thread 'certificate::tests::checkcertdiff' panicked at 'index out of bounds: the len is 0 but the index is 31',
Change:
<ins> error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:7:17 | LL |     let _ = |x: x| x; |                 ^ not a type error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:8:26 | LL |     let _ = |x: bool| -> x { x }; |                          ^ not a type error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:9:28 | LL |     let _ = async move |x: x| x; |                            ^ not a type error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:10:37 | LL |     let _ = async move |x: bool| -> x { x }; |                                     ^ not a type error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:13:11 | LL | fn foo(x: x) {} |           ^ not a type error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:14:24 | LL | fn foo_ret(x: bool) -> x {} |                        ^ not a type error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:16:23 | LL | async fn async_foo(x: x) {} |                       ^ not a type error[E0573]: expected type, found local variable `x` --> $DIR/local-type-mix.rs:17:36 | LL | async fn async_foo_ret(x: bool) -> x {} |                                    ^ not a type error: aborting due to 8 previous errors For more information about this error, try `rustc --explain E0573`. </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
Doesn't ICE on stable or beta label: regression-from-stable-to-nightly
searched nightlies: from nightly-2020-11-25 to nightly-2020-11-29 regressed nightly: nightly-2020-11-27 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsMaybe ?
Assigning and removing as in the prioritization working group.
- would you be up for fixing this bug or temporarily reverting PR presuming it is the cause?
Change:
) else { return; }; <del> let in_scope_methods = self.probe_for_name_many( </del> <ins> let Ok(in_scope_methods) = self.probe_for_name_many( </ins> probe::Mode::MethodCall, path.ident, Some(expected),

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'', 'thread 'rustc' panicked at 'called on an value: NoMatch(NoMatchData { staticcandidates: [], unsatisfiedpredicates: [], outofscopetraits: [], similarcandidate: None, mode: MethodCall })'' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc ^^
claim
Change:
) } }; <del> Item::from_def_id_and_parts(local_did, Some(self.ident.name), inner, cx) </del> <ins> let what_rustc_thinks = Item::from_def_id_and_parts(local_did, Some(self.ident.name), inner, cx); let parent_item = cx.tcx.hir().expect_item(cx.tcx.hir().get_parent_item(self.hir_id)); if let hir::ItemKind::Impl(impl_) = &parent_item.kind { if impl_.of_trait.is_some() { // Trait impl items always inherit the impl's visibility -- // we don't want to show `pub`. Item { visibility: Inherited, ..what_rustc_thinks } } else { what_rustc_thinks } } else { panic!("found impl item with non-impl parent {:?}", parent_item); } </ins> }) } }

Discussion:
The trait on 1.49.0 (current stable) doesn't contain modifier in function declaration of that trait. ! However, on and nightly, there is modifier. ! This is wrong because you cannot use modifier for each method/function in Trait definition. Why is this important? People copy the method/function declaration in the documentation to their code and see the compiler error: . : cc I think this might relate to some changes in visibility around macros ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, this needs the same fix as (in particular should work).
Self-assigning because this is a beta regression.
Note that this also occurs for the impl's docs.
Removed since this was fixed.
, trait methods still rendered as : ! Is there something wrong to Rust release or the bug still exists ?
Hmm, maybe it was only fixed for items in the local crate. do you have time to come up with an MCVE? I expect it's related to cross-crate re-exports.
Your guess sounds right. With core link (), things are normal.
I don't think I'll have time to fix this second part soon, so unassigning myself.
Assigning and removing as in the prioritization working group.
Removing E-mentor + E-easy labels since we don't have guides for cross-crate linking: label -E-easy -E-mentor
I think is the cross-crate case.
Fix backported to 1.50.0 and landed in 1.51.0, closing this.
Please reopen. The issue is not entirely fixed for cross-crate trait reexport case.
The cross-crate issue is now on stable. label: +regression-from-stable-to-stable -regression-from-stable-to-beta
claim
Change:
</div> {#- -#} <form class="search-form"> {#- -#} <div class="search-container"> {#- -#} <ins> <span></span> {#- This empty span is a hacky fix for Safari - See #93184 -#} </ins> <input {# -#} class="search-input" {# -#} name="search" {# -#}

Discussion:
(desktop) Safari the search box here: a letter the letter another letter how the empty space below the search bar changes size cc – I think this is a recent regression; it's in nightly. I presume it has some connection to either your "All crates" change or your sidebar change. This bug is not present in beta.
Hm, I can't reproduce on desktop Safari 15.1. Can you share a video? I can observe a small change in the width of the sidebar between typing a letter and deleting. I'll investigate that.
I'm on Safari 15.2, though I'm not sure if it matters. I'll see if I can get a video sometime soon but I'm a bit busy right now.
https://user-
Thanks!
Thanks for the video that really helped me figure out what I was looking for. I was able to bisect it to (moving the crate dropdown onto the search page). Surprisingly, the minimum diff that causes the issue was not any of the CSS, but removing the dropdown element. So long as the search input has a previous sibling of any kind, the bumpiness does not happen. It's quite mysterious. I haven't been able to find a style that causes this.
Change:
!remaining_fields.is_empty() { span_err!(tcx.sess, span, E0063, <del> "missing field{}: {}", </del> <ins> "missing field{} {} in initializer of `{}`", </ins> if remaining_fields.len() == 1 {""} else {"s"}, remaining_fields.keys() .map(|n| format!("`{}`", n)) .collect::<Vec<_>>() <del> .join(", ")); </del> <ins> .join(", "), adt_ty); </ins> } }

Discussion:
E0063 doesn't specify which constructor the field is missing from, leading the user to guess in case of nested constructors. The printed output also fails to highlight the relevant constructor. On :
Change:
<ins> // AST-based macro attributes expanding to an empty expression produce an error and not ICE. #![feature(custom_test_frameworks)] #![feature(stmt_expr_attributes)] #![feature(test)] fn main() { let _ = #[test] 0; //~ ERROR removing an expression is not supported in this position let _ = #[bench] 1; //~ ERROR removing an expression is not supported in this position let _ = #[test_case] 2; //~ ERROR removing an expression is not supported in this position } </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
modify labels: +regression-from-stable-to-stable Had to uninstall ~20 gigs of rustc releases again but since this code does not ICE on 1.20 but ices on 1.48.0, this is a stable-to-stable ice.
This started ICE'ing in 1.30.0. Error message in 1.29.0:
This is not supposed to work yet and it gives a good error message saying so -P-low Assigning and removing as in the prioritization working group.
The error message is helpful but it still panics in nightly. Do we want to fix the ICE at least or keep it?
A possible duplicate.
Fixed in
Change:
.emitted_diagnostic_codes .iter() .filter_map(|x| match &x { <del> DiagnosticId::Error(s) if registry.find_description(s).is_some() => { Some(s.clone()) </del> <ins> DiagnosticId::Error(s) => { if let Ok(Some(_explanation)) = registry.try_find_description(s) { Some(s.clone()) } else { None } </ins> } _ => None, })

Discussion:
The functionality (does anyone still uses this now that it's ?) gives the same "no extended information" message for real error codes that don't have a "long" explanation written, and nonexistent codes. These messages should be disambiguated (as "no extended information for E0XXX" vs. "E0XXX does not exist" or similar). I thought this would be straightforward to implement: we (which get successfully , although the ), only to when macroexpanding the arrays . So this should, you would think, just be a matter of editing reflect that, and making the care. But when I actually do this (zackmdavis/rust ... my changes to seem to have absolutely no effect (!?!); we still get a even though I thought my code pretty clearly said otherwise, on more than one day that I've looked at this. I hereby give up in despair, bafflement, and tears. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The diagnostic registration is "just" a macrorules macro now so I suspect this is pretty simple to implement per the suggested path in the issue description; I'm going to mark as E-easy and E-mentor with myself as the mentor. You'll want to edit the array definitions to have the type or so and add in the short diagnostics. Once that's done, if you run you'll likely hit an error in the use site of from . Fixing that'll mostly involve fixing up the diagnostics registry in ; I would store the long diagnostics and short diagnostics separately, adding a field like . Once this is done, there might be a few more type errors to clean up but that should mostly be a matter of making types match up I would hope. Let me know if you have any questions; here on this issue or feel free to open up a PR with some initial work and I can try and provide feedback there.
One additional thing that we should probably add as part of this work is an error if the same diagnostic code is registered twice (cc ).

I imagine this would mostly be a matter of inserting all the codes into an FxHashSet and panicking if there's one inserted twice; an ICE here is fine since it'll definitely be caught in CI.
Hey, If this still needs fixed, I would love to work on this. I will probably be reaching out before to long for some guidance. claim
Shoot not sure if I read what was happening in this thread all the way. are you working on this already?
I'm not; go for it! (Although ... I thought I remembered seeing an issue recently where people were discussing moving away from the numeric error codes, but I can't find it. was that a real thing?)
Maybe you are referring to this conversation on Zulip? https://rust-
Change:
unsafe { let ccx = cx.fcx.ccx; let ty = val_ty(fn_); <del> let retty = if ty.kind() == llvm::Integer { </del> <ins> let retty = if ty.kind() == llvm::Function { </ins> ty.return_type() } else { ccx.int_type()

Discussion:
The following causes an LLVM assertion failure: Removing the panic! prevents the assertion failure.
I minimized it some more: The Option<and the #![no_std] don't matter, it's specifically attempting to call an extern fn pointer after a panic! that causes the crash.
Change:
<ins> // Copyright 2014 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 test<'x>(x: &'x int) { //~ NOTE the lifetime 'x as defined drop::< <'z>|&'z int| -> &'z int>(|z| { //~^ ERROR mismatched types //~^^ ERROR cannot infer an appropriate lifetime x }); } fn main() {} </ins>

Discussion:
Consider compilefail/regions-nested- When you run this, in addition to various error output, you will also see messages prefixed by . In those messages, when a lifetime is printed, it is printed with a leading in addition to the that is part of its name. For example: . In my opinion, this is confusing. is a lifetime, while are the first three characters of some (incomplete) type expression that is missing the pointed-to type (along with a potential qualifier). I suspect the leading is arising probably some artifact of how the code is implementing the trait; it might also involve the use of as the implementation of how lifetimes are printed (even though the former says it is for printing ptrs, not lifetimes). Also, there is an extra space between and above.
that's a holdover from the days before existed as a notation for lifetimes, definitely should be fixed
If no one else is working on this, I'll take it.
Apologies for how long this is taking, I'm still kind of learning the internals. I have a question, though. I have fixed this issue, but I'm now getting output like: The second is an int scoped to an anonymous lifetime, but the way I've implemented it there's no indication of this in the output. Is there a decided-upon notation for this case? Perhaps ?
I think those types should be written .
Or perhaps, better yet, or something like that. It'd be nice to indicate to the user that there are in fact two distinct lifetimes there, otherwise the message looks silly ("expected but found " -- wat??)
Given that work on this issue seems to have stagnated somewhat, would it be OK if I could take this issue? I was thinking that perhaps would be better than as it’s more descriptive, and matches with . Also, should all references be annotated thus? It seems slightly unnecessary to state the lifetime in an error like &'<anonintuinttype has no method `. This would probably complicate the implementation rather a lot, however.
On 5/19/2014 10:56 PM, P1start wrote:
Change:
[53033]: https://github.com/rust-lang/rust/pull/53033/ [53044]: https://github.com/rust-lang/rust/pull/53044/ [53165]: https://github.com/rust-lang/rust/pull/53165/ <ins> [53611]: https://github.com/rust-lang/rust/pull/53611/ </ins> [53213]: https://github.com/rust-lang/rust/pull/53213/ [53236]: https://github.com/rust-lang/rust/pull/53236/ [53272]: https://github.com/rust-lang/rust/pull/53272/

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
/// Compares two TokenStreams, checking equality without regarding span information. pub fn eq_unspanned(&self, other: &TokenStream) -> bool { <del> for (t1, t2) in self.trees().zip(other.trees()) { </del> <ins> let mut t1 = self.trees(); let mut t2 = other.trees(); for (t1, t2) in t1.by_ref().zip(t2.by_ref()) { </ins> if !t1.eq_unspanned(&t2) { return false; } } <del> true </del> <ins> t1.next().is_none() && t2.next().is_none() </ins> } /// Precondition: `self` consists of a single token tree.

Discussion:
I ran across a very curious case today... Given this procedural macro: and this expansion: when compiled I get: which is quite curious! -- er, just wrong thinking here cc cc cc
Seems similar to how also causes an inconsistency.
Ok I think I see what's going on here. This has to do with introduced in Basically I think this boils down to , we fundamentally cannot losslessly tokenize an AST item into a list of tokens to hand to a procedural macro. What's happening here is that all the tokens of the are saved off in the parser. This is the original source token stream which produced the struct. Later on when we tokenize the struct to hand off to a procedural macro we will use this cached token stream, if available, and tokenize it out and return it. When stringifying, however, we use the actual AST node itself (the source of truth). The bug is that cfg processing does indeed happen before the procedural macro runs. The cfg processing is modifying the AST item's internal fields but it's not invalidating the cached token stream or modifying it. Hence when the procedural macro runs the cached token stream is invalid wrt the internal state of the AST node, causing two different results to come out depending on how you look at it. Possible solutions here are: the cached list of tokens if the AST node is modified. This seems tricky to get right, are there other locations where a modification can happen? implemented , but holy cow that's a lot of work. the two results of tokenization (stringify + parse and the tokens themselves) and return the string one if they differ. None of them seem like great solutions :(