jiebi/CodeConvo huggingface dataset:
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: The link resolves to . Instead, this happened: rustdoc can't resolve the link <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: and <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
Maybe I shouldn't have used pretty printing after all ... I'll try reverting and see if it helps.
Assigning and removing as in the prioritization working group.

Discussion:
// FIXME(jynelson): this shouldn't go through stringification, rustdoc should just use the DefId directly let self_name = self_id.and_then(|self_id| { <ins> use ty::TyKind; </ins> if matches!(self.cx.tcx.def_kind(self_id), DefKind::Impl) { <del> // using `ty.to_string()` directly has issues with shortening paths </del> <ins> // using `ty.to_string()` (or any variant) has issues with raw idents </ins> let ty = self.cx.tcx.type_of(self_id); <del> let name = ty::print::with_crate_prefix(|| ty.to_string()); debug!("using type_of(): {}", name); Some(name) </del> <ins> let name = match ty.kind() { TyKind::Adt(def, _) => Some(self.cx.tcx.item_name(def.did).to_string()), other if other.is_primitive() => Some(ty.to_string()), _ => None, }; debug!("using type_of(): {:?}", name); name </ins> } else { let name = self.cx.tcx.opt_item_name(self_id).map(|sym| sym.to_string()); debug!("using item_name(): {:?}", name);

<ins> #![deny(broken_intra_doc_links)] pub mod r#impl { pub struct S; impl S { /// See [Self::b]. // @has raw_ident_self/impl/struct.S.html // @has - '//a[@href="../../raw_ident_self/impl/struct.S.html#method.b"]' 'Self::b' pub fn a() {} pub fn b() {} } } </ins>
Change:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great!
Oops, race condition! Noticed you self-assigned this right as I sent a PR for this. ^^
You can assign me if needed.

Discussion:
<del> Subproject commit 47acece7aa25d7b5edfae0bfd4b94e6e55a7b4b0 </del> <ins> Subproject commit e54c5db4f0edbe51db42d2c3e63e9821537ed4f4 </ins>
Change:
It used to (on stable and beta) look like this: ! But on nightly it looks like: ! The source code for the snippet is: rust /// if let _ = 123 { /// println!("always runs!"); /// } /// `` This is true for other code snippets in the lint listing, though the rest of the book (and other books) don't have the issue.
cc since you're the only one who's since September
Assigning and removing as in the prioritization working group.

Discussion:
Some((lineno, line)) => { let line = line.trim(); if let Some(text) = line.strip_prefix("/// ") { <del> doc_lines.push(text.trim().to_string()); } else if line.starts_with("///") { </del> <ins> doc_lines.push(text.to_string()); } else if line == "///" { </ins> doc_lines.push("".to_string()); } else if line.starts_with("// ") { // Ignore comments.
Change:
In I tried to create a new testcase that runs doctests. However having the substring in a doctest comment injected an invalid into the code generated for the doctest. Turns out this here is a bit too aggressive: It looks like compiletest actually gave the crate the name , perhaps because it was defined in a file, and having a doctest such as this triggers the this auto-injection, resulting in a failed doctest run: /// // ^ line 10 /// assert_eq!(1, 1); /// `
I think rustdoc needs to check if the crate name is a keyword and add if so. Actually it's probably enough to unconditionally add since it works for things that aren't keywords.
there is actually two bugs here. not being properly escaped is one thing, the other is probably the way that rustdoc is invoked, or not quite sure. Basically it infers the crate name from the file name if not explicitly given, and then just assumes that a crate with that name exists, which it doesn’t.
that's an issue with compiletest, not rustdoc - it needs to compile the crate itself before running rustdoc on it: I don't know how to fix that, I think compiletest needs to add support for this maybe?

Discussion:
// compiler. if !already_has_extern_crate && !opts.no_crate_inject && cratename != Some("std") { if let Some(cratename) = cratename { <del> // Make sure its actually used if not included. </del> <ins> // Don't inject `extern crate` if the crate is never used. // NOTE: this is terribly inaccurate because it doesn't actually // parse the source, but only has false positives, not false // negatives. </ins> if s.contains(cratename) { <del> prog.push_str(&format!("extern crate {};n", cratename)); </del> <ins> prog.push_str(&format!("extern crate r#{};n", cratename)); </ins> line_offset += 1; } }

let input = "use asdf::qwop; assert_eq!(2+2, 4);"; let expected = "#![allow(unused)] <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { use asdf::qwop; assert_eq!(2+2, 4);

let input = "use asdf::qwop; assert_eq!(2+2, 4);"; let expected = "#![feature(sick_rad)] <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { use asdf::qwop; assert_eq!(2+2, 4);

opts.attrs.push("feature(hella_dope)".to_string()); let expected = "#![feature(sick_rad)] #![feature(hella_dope)] <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { use asdf::qwop; assert_eq!(2+2, 4);

let expected = "#![allow(unused)] extern crate hella_qwop; <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { assert_eq!(asdf::foo, 4); }"

pub fn dummy() {} // ensure that `extern crate foo;` was inserted into code snips automatically: <del> // @matches foo/index.html '//a[@class="test-arrow"][@href="https://example.com/?code=%23!%5Ballow(unused)%5D%0Aextern%20crate%20foo%3B%0Afn%20main()%20%7B%0Ause%20foo%3A%3Adummy%3B%0Adummy()%3B%0A%7D&edition=2015"]' "Run" </del> <ins> // @matches foo/index.html '//a[@class="test-arrow"][@href="https://example.com/?code=%23!%5Ballow(unused)%5D%0Aextern%20crate%20r%23foo%3B%0Afn%20main()%20%7B%0Ause%20foo%3A%3Adummy%3B%0Adummy()%3B%0A%7D&edition=2015"]' "Run" </ins>
Change:
<!-- 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. --You can find it at : <!-- 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
cc
Hi, is there any updates on this? We met this problem in with on too:
This is a bug in incremental compilation. Do you have both the last compiling version and the failing version?
Sorry I didn't understand the sentence. The simplest way to reproduce this ICE:
We're sincerely longing for the merge of your bug fix.

Discussion:
struct SourceFileIndex(u32); #[derive(Copy, Clone, Debug, Hash, Eq, PartialEq, Encodable, Decodable)] <del> pub struct AbsoluteBytePos(u32); </del> <ins> pub struct AbsoluteBytePos(u64); </ins> impl AbsoluteBytePos { fn new(pos: usize) -> AbsoluteBytePos { <del> debug_assert!(pos <= u32::MAX as usize); AbsoluteBytePos(pos as u32) </del> <ins> AbsoluteBytePos(pos.try_into().expect("Incremental cache file size overflowed u64.")) </ins> } fn to_usize(self) -> usize {
Change:
I tried this code: and I expected to see this happen: the compiler complained was missing, or on nightly, after adding , compiled successfully, just like . Instead, this happened: the assertion failed. The compiler gave an empty as to the procedural macro: Edit: I found this in the compiler's log: I tried this with: nightly-2020-12-08 () nightly-2020-12-07 () beta () stable () cc
The pretty-print/reparse check has been removed, so this should hopefully be fixed on the latest nightly.
Confirmed that this is fixed in latest nightly, thanks! :heart: Do I need to leave this issue open (possibly for a regression test)?
That sounds like a good idea.

Discussion:
<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_attribute] pub fn assert_input(args: TokenStream, input: TokenStream) -> TokenStream { assert_eq!(input.to_string(), "trait Alias = Sized ;"); assert!(args.is_empty()); TokenStream::new() } </ins>

<ins> // check-pass // aux-build:issue-79825.rs #![feature(trait_alias)] extern crate issue_79825; #[issue_79825::assert_input] trait Alias = Sized; fn main() {} </ins>

<ins> // check-pass // aux-build:test-macros.rs #![feature(stmt_expr_attributes, proc_macro_hygiene)] extern crate test_macros; use test_macros::identity_attr; #[identity_attr] fn main() { let _x; let y = (); #[identity_attr] _x = y; } </ins>
Change:
The following code snippet should light the pin 13 LED when compiled for the atmega328 and run on an arduino. It does not. This is possibly related to , and potentially also avr-rust/rust-legacy-fork. I initially found this while trying to implement a , so it is not restricted to compiler-generated vtables - any function pointers which are stored in the data segment are affected. Attempting to simplify further (such as using a single function pointer) tends to end up with pointers which are passed entirely in code and never loaded from the data segment. These appear to be compiled correctly. Built + Flashed with: Stepping through the execution in simavr/gdb makes the failure obvious - the vtable contains the byte-address of the implementation function, but the instruction (and indeed the instruction pointer of the AVR in general) uses word-addresses. As can be seen from the GDB output, after loading the VTable entry the Z register (the combination of r30 and r31) contains "0x00A8", and execution jumps to "0x0150". The vtable should instead include "0x0054", which when treated as a word-address will jump to the expected "0x00A8".
For the sake of confirming expected behavior of vtables, I tested the following snippet in avr-gcc, which generates a manual vtable in the data segment: This emits pretty much what I would have expected, with the vtable containing 0x004B for a function which is at byte-address 0x0096: I have no idea if the version of clang on my
I was able to narrow this down a bit further. Building my example rust code as a static lib, I was able to inspect the relocations in the vtable. For my C code built by avr-gcc: It looks like the wrong relocation type is being selected for the vtable entries.
Followup 3: This is supposedly fixed by , which appears to have stalled. I can't find an actual issue on that's tracking this, though.
Committed D87631 upstream in llvm/llvm-project
llvm/llvm-project seems to fix it, although it's not worth cherry-picking it until lands, as currently we hit on the master build for the reproduction example on this issue.
has the llvm fix trickled into our LLVM fork yet?
Yeah, it's part of LLVM 13. The commit:

Discussion:
<del> Subproject commit fc10370ef7d91babf512c10505f8f2176bc8519d </del> <ins> Subproject commit 593484fc1596707406b0b0b45b97feb08d2a1bfc </ins>
Change:
https://crater- modify labels: +regression-from-stable-to-beta I-ICE
searched nightlies: from nightly-2020-09-24 to nightly-2020-12-11 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details
cc -- seems like this one might be an actual bug
Small case that I think shows this issue, it incorrectly fails to compile on beta/nightly.
N.B. I haven't gotten it to ICE, so I can't add it to the

Discussion:
fn vtable_impl( &mut self, impl_def_id: DefId, <del> mut substs: Normalized<'tcx, SubstsRef<'tcx>>, </del> <ins> substs: Normalized<'tcx, SubstsRef<'tcx>>, </ins> cause: ObligationCause<'tcx>, recursion_depth: usize, param_env: ty::ParamEnv<'tcx>,

// relying on projections in the impl-trait-ref. // // e.g., `impl<U: Tr, V: Iterator<Item=U>> Foo<<U as Tr>::T> for V` <del> substs.obligations.append(&mut impl_obligations); </del> <ins> impl_obligations.extend(substs.obligations); </ins> <del> ImplSourceUserDefinedData { impl_def_id, substs: substs.value, nested: substs.obligations } </del> <ins> ImplSourceUserDefinedData { impl_def_id, substs: substs.value, nested: impl_obligations } </ins> } fn confirm_object_candidate(

<ins> // Regression test for #79902 // Check that evaluation (which is used to determine whether to copy a type in // MIR building) evaluates bounds from normalizing an impl after evaluating // any bounds on the impl. // check-pass trait A { type B; } trait M {} struct G<T, U>(*const T, *const U); impl<T, U> Clone for G<T, U> { fn clone(&self) -> Self { G { ..*self } } } impl<T, U> Copy for G<T, U::B> where T: A<B = U>, U: A, { } impl A for () { type B = (); } fn is_m<T: M>(_: T) {} fn main() { let x = G(&(), &()); drop(x); drop(x); } </ins>
Change:
Currently, the following fails to compile, with errors about expecting int instead of uint: Is there any reason why this should be disallowed?
Linking to issue
Fixed by

Discussion:
<del> // Copyright 2012 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. enum test { thing = 3u } //~ ERROR mismatched types //~^ ERROR expected signed integer constant fn main() { error!(thing as int); assert_eq!(thing as int, 3); } </del>

<del> // Copyright 2012 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: mismatched types enum color { red = 1u, blue = 2, } fn main() {} </del>

<ins> // Copyright 2012 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. enum color { red = 1u, blue = 2, } fn main() {} </ins>
Change:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --In current Rust nightly, the std docs search function does a very annoying thing for me: every time I open a new tab onto the rust std docs, I get once again the popup with the keybindings which I then have to dismiss. I conjecture that this is because I am looking at locally built docs via a URL. Presumably the same thing would occur for a user who has sensibly disabled cookies in their web browser, resulting in the same horrible "stupid popup" user experience. Given that without web local storage it is not possible to make a thing that is shown to each user once, it would be better not to show this popup at all when local storage is not available. I'm not sure if it is possible to determine easily whether local storage is available. I think there may be browsers which silently discard local storage writes rather than explicitly saying it's not available. Until we know the answer to this question, I suggest that the new popup should be disabled :-(.
modify labels +T-rustdoc +A-rustdoc-ui
modify labels +regression-from-stable-to-nightly
I've been having a different version of this happen on (and ) too. Whenever I press <kbdEnter</kbdafter typing in the search field, the Help popup momentarily appears. I don't think mine is a cookies issue; I think rustdoc is handling events wrong.
cc – this is a pretty severe usability bug, and we should fix it as soon as possible
Might be related to or ?
I'll try to bisect.
I'll send a fix shortly.
Will the affected documentations on be rebuilt?
Unfortunately no. It'll require to rebuild the impacted crates.

Discussion:
placeholder="Click or press ‘S’ to search, ‘?’ for more options…"  type="search"> </div> <del> <button class="help-button">?</button> </del> <ins> <button type="button" class="help-button">?</button> </ins> <a id="settings-menu" href="{root_path}settings.html"> <img src="{static_root_path}wheel{suffix}.svg"  width="18"
Change:
suggested an optimization for , and it was implemented in . However, for some reason, was not optimized the same way: It can be implemented in terms of : Is this deliberate or just something that no-one noticed?
By the way, you don't need to open an issue if you're about to open a PR. Just include what you would put in the issue in the PR!

Discussion:
impl PartialOrd for bool { #[inline] fn partial_cmp(&self, other: &bool) -> Option<Ordering> { <del> (*self as u8).partial_cmp(&(*other as u8)) </del> <ins> Some(self.cmp(other)) </ins> } }
Change:
I expected VecDeque constructed from Vec to either work correctly or construction to panic if it is not possible. Instead: Introduced by . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
Not sure how severe this is, but figured that it's worth prioritizing.
claim
Assigning and removing as in the prioritization working group.
should fix this -- written before I saw this issue and claim, so I'm sorry if you were still working on it.

Discussion:
/// This avoids reallocating where possible, but the conditions for that are /// strict, and subject to change, and so shouldn't be relied upon unless the /// `Vec<T>` came from `From<VecDeque<T>>` and hasn't been reallocated. <del> fn from(other: Vec<T>) -> Self { unsafe { let mut other = ManuallyDrop::new(other); let other_buf = other.as_mut_ptr(); let mut buf = RawVec::from_raw_parts(other_buf, other.capacity()); let len = other.len(); // We need to extend the buf if it's not a power of two, too small // or doesn't have at least one free space. // We check if `T` is a ZST in the first condition, // because `usize::MAX` (the capacity returned by `capacity()` for ZST) // is not a power of two and thus it'll always try // to reserve more memory which will panic for ZST (rust-lang/rust#78532) if (!buf.capacity().is_power_of_two() && mem::size_of::<T>() != 0) || (buf.capacity() < (MINIMUM_CAPACITY + 1)) || (buf.capacity() == len) { let cap = cmp::max(buf.capacity() + 1, MINIMUM_CAPACITY + 1).next_power_of_two(); buf.reserve_exact(len, cap - len); </del> <ins> fn from(mut other: Vec<T>) -> Self { let len = other.len(); if mem::size_of::<T>() == 0 { // There's no actual allocation for ZSTs to worry about capacity, // but `VecDeque` can't handle as much length as `Vec`. assert!(len < MAXIMUM_ZST_CAPACITY, "capacity overflow"); } else { // We need to resize if the capacity is not a power of two, too small or // doesn't have at least one free space. We do this while it's still in // the `Vec` so the items will drop on panic. let min_cap = cmp::max(MINIMUM_CAPACITY, len) + 1; let cap = cmp::max(min_cap, other.capacity()).next_power_of_two(); if other.capacity() != cap { other.reserve_exact(cap - len); </ins> } <ins> } unsafe { let (other_buf, len, capacity) = other.into_raw_parts(); let buf = RawVec::from_raw_parts(other_buf, capacity); </ins> VecDeque { tail: 0, head: len, buf } } }

assert!(vd.into_iter().eq(vec)); } } <ins> let vec = Vec::from([(); MAXIMUM_ZST_CAPACITY - 1]); let vd = VecDeque::from(vec.clone()); assert!(vd.cap().is_power_of_two()); assert_eq!(vd.len(), vec.len()); } #[test] #[should_panic = "capacity overflow"] fn test_from_vec_zst_overflow() { use crate::vec::Vec; let vec = Vec::from([(); MAXIMUM_ZST_CAPACITY]); let vd = VecDeque::from(vec.clone()); // no room for +1 assert!(vd.cap().is_power_of_two()); assert_eq!(vd.len(), vec.len()); </ins> } #[test]
Change:
<!-- 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. --This bug occurs with . works fine. <!-- 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
might be a duplicate of
I think there are important differences: this code doesn't use feature gates, and it successfully builds, so rustdoc should be expected to succeed instead of erroring or ICE, and the rationale for prioritizing that low (that the input is invalid) doesn't apply.
MCVE (although it panics in a slightly different place):
Oh interesting my MCVE is not correct - that panics because the impls are missing: If I add those impls, suddenly rustdoc works:
In fact there are some programs rustdoc accepts that rustc doesn't:
Slightly smaller repro:

Discussion:
let bound_predicate = predicate.bound_atom(); match bound_predicate.skip_binder() { ty::PredicateAtom::Trait(p, _) => { <del> if self.is_param_no_infer(p.trait_ref.substs) && !only_projections && is_new_pred { self.add_user_pred(computed_preds, predicate); } </del> <ins> // Add this to `predicates` so that we end up calling `select` // with it. If this predicate ends up being unimplemented, // then `evaluate_predicates` will handle adding it the `ParamEnv` // if possible. </ins> predicates.push_back(bound_predicate.rebind(p)); } ty::PredicateAtom::Projection(p) => {

<ins> // Regression test for issue #80233 // Tests that we don't ICE when processing auto traits #![crate_type = "lib"] pub trait Trait1 {} pub trait Trait2 { type Type2; } pub trait Trait3 { type Type3; } impl Trait2 for Struct1 { type Type2 = Struct1; } impl<I: Trait2> Trait2 for Vec<I> { type Type2 = Vec<I::Type2>; } impl<T: Trait1> Trait3 for T { type Type3 = Struct1; } impl<T: Trait3> Trait3 for Vec<T> { type Type3 = Vec<T::Type3>; } pub struct Struct1 {} // @has issue_80233_normalize_auto_trait/struct.Question.html // @has - '//code' 'impl<T> Send for Question<T>' pub struct Question<T: Trait1> { pub ins: <<Vec<T> as Trait3>::Type3 as Trait2>::Type2, } </ins>