jiebi/CodeConvo huggingface dataset:
Change:
Compare , this was intentional Items which are private, like , have disappeared
The warnings is removed in .
The haven't never been public. Not sure if I made it disappeared. cc
Also this page is 404 now. Before it listed all the internal crates.
I don't see how your PR could've done that -- cc I think you recently had a PR touching document-private-items?
The PR just changed some warnings around intra-doc-links, nothing to do with . My suspicion since the index page is gone is that something changed in bootstrap.
I take it back, I did modify href in That was a few weeks ago now and should have documented strictly more items, though.
This is the issue I pointed out in the second part of I clearly didn't explain the issue well enough.

Discussion:
} impl Cargo { <ins> pub fn rustdocflag(&mut self, arg: &str) -> &mut Cargo { self.rustdocflags.arg(arg); self } </ins> pub fn rustflag(&mut self, arg: &str) -> &mut Cargo { self.rustflags.arg(arg); self

} pub fn env(&mut self, key: impl AsRef<OsStr>, value: impl AsRef<OsStr>) -> &mut Cargo { <ins> // These are managed through rustflag/rustdocflag interfaces. assert_ne!(key.as_ref(), "RUSTFLAGS"); assert_ne!(key.as_ref(), "RUSTDOCFLAGS"); </ins> self.command.env(key.as_ref(), value.as_ref()); self }

// Build cargo command. let mut cargo = builder.cargo(compiler, Mode::Rustc, SourceType::InTree, target, "doc"); <del> cargo.env( "RUSTDOCFLAGS", "--document-private-items  --enable-index-page -Zunstable-options", ); </del> <ins> cargo.rustdocflag("--document-private-items"); cargo.rustdocflag("--enable-index-page"); cargo.rustdocflag("-Zunstable-options"); </ins> compile::rustc_cargo(builder, &mut cargo, target); // Only include compiler crates, no dependencies of those, such as `libc`.

cargo.arg("--no-deps"); cargo.arg("-p").arg("rustdoc"); <del> cargo.env("RUSTDOCFLAGS", "--document-private-items"); </del> <ins> cargo.rustdocflag("--document-private-items"); </ins> builder.run(&mut cargo.into()); } }
Change:
e.g., is missing the file/line/column method docs which are present in beta cc
Removing as this is issue.
Why?
A quick test indicates that copying the source of std::panic::Location out into a no_std crate doesn't fix the problem
Oh wait I don't have the latest nightly
As mentioned in , I'm not sure this should be prioritized under t-compiler's wg-prioritization. If this label is useful for the rustdoc team as well, we could tweak triagebot not to notify on Zulip.
Yeah it seems like it would be useful for us
Hmm so I am unable to reproduce this bug on a self contained no-core file that contains the exact code of aside for changes in the body
Regression range .. Auto merge of - Manishearth:rollup-9gxn4od, r=Manishearth Auto merge of - marmeladema:duration-consts-2, r=oli-obk Auto merge of - oli-obk:mir_const, r=RalfJung Auto merge of - Manishearth:rollup-i7iueu8, r=Manishearth Auto merge of - Manishearth:rollup-10vbpdh, r=Manishearth
Works in Regressing PR is
Rustdoc PRs in that rollup Rollup merge of - Manishearth:re-spotlight, r=GuillaumeGomez Rollup merge of - lzutao:rustdoc-tostring, r=GuillaumeGomez Rollup merge of - GuillaumeGomez:focus-source-file-sidebar, r=kinnison Rollup merge of - GuillaumeGomez:doc-alias-check, r=Manishearth Rollup merge of - euclio:rustdoc-highlighting, r=ollie27,GuillaumeGomez Rollup merge of - alexcrichton:ignore-unstable, r=estebank,GuillaumeGomez Rollup merge of - jyn514:name-resolve-first, r=eddyb
Confirmed, (try build from ) is the culprit
What's happening is that that code erroneously checks the stability of the impl, which apparently is "unstable if it contains unstable items". The "foreign item" check applies to libstd reexporting libcore. It shouldn't. The minimal reproduction is two crates, one using stability attrs such that an impl has at least one unstable item, and the second crate reexporting the type.
I'm going to take a stab at fixing this.

Discussion:
// such. This helps prevent dependencies of the standard library, for // example, from getting documented as "traits `u32` implements" which // isn't really too helpful. <del> if let Some(stab) = cx.tcx.lookup_stability(did) { if stab.level.is_unstable() { return; </del> <ins> if let Some(trait_did) = associated_trait { if let Some(stab) = cx.tcx.lookup_stability(trait_did.def_id) { if stab.level.is_unstable() { return; } </ins> } } }

<ins> #![feature(staged_api)] #![stable(feature = "private_general", since = "1.0.0")] #[unstable(feature = "private_trait", issue = "none")] pub trait Bar {} #[stable(feature = "private_general", since = "1.0.0")] pub struct Foo { // nothing } impl Foo { #[stable(feature = "private_general", since = "1.0.0")] pub fn stable_impl() {} } impl Foo { #[unstable(feature = "private_trait", issue = "none")] pub fn bar() {} #[stable(feature = "private_general", since = "1.0.0")] pub fn bar2() {} } #[stable(feature = "private_general", since = "1.0.0")] impl Bar for Foo {} </ins>

<ins> // aux-build:unstable-trait.rs #![crate_name = "foo"] #![feature(private_trait)] extern crate unstable_trait; // @has foo/struct.Foo.html 'bar' // @has foo/struct.Foo.html 'bar2' #[doc(inline)] pub use unstable_trait::Foo; </ins>
Change:
Not sure if this is due to the packaging, or if it is a rustup bug, but I cannot install the rust-src component for the latest nightly-2020-07-21. Fails on macOS and Linux with the same error. I'll try to dig in some tonight, but figured I'd file this to see if anyone has any ideas. If I had to take a wild guess, I would say it may be related to .
Rustup doesn't support symlink entry in tar file: There are two symlinks in backtrace:
cc
Once this is fixed we should look into checking that we're not creating these tarballs on the dist builders (rather than failing "late" when rustup fails to install)
Getting the same with (this might break ci of clippy/rustfmt/rls etc):
Posted a fix at .

Discussion:
// (essentially libstd and all of its path dependencies) let std_src_dirs = [ "src/build_helper", <del> "src/backtrace", </del> <ins> "src/backtrace/src", </ins> "src/liballoc", "src/libcore", "src/libpanic_abort",
Change:
Configured with
I found that does not properly emit some information for android assembler. keep digging do you have any idea to fix this ?
some symbol starts with which arm as cannot recognize it [error] [orig]
Ok, I know what the issue is now. I changed the naming of the vtables, since they are internal, in order to make it easier to debug. So they now have the type attached. Apparently the 's don't get changed the same way the '<' and ''s do. I'll get on it.
works with below patch

Discussion:
use middle::ty; use middle::typeck; use util::common::indenter; <del> use util::ppaux::{Repr, ty_to_str}; </del> <ins> use util::ppaux::Repr; </ins> use middle::trans::type_::Type;

use syntax::ast_map::{path, path_mod, path_name}; use syntax::ast_util; use syntax::{ast, ast_map}; <del> use syntax::parse::token; </del> /** The main "translation" pass for methods.  Generates code

components.push(ptr) } <del> let name = fmt!("%s_vtable_%u", ty_to_str(ccx.tcx, tydesc.ty), token::gensym("vtable")); </del> let tbl = C_struct(components); <del> let vt_gvar = do name.as_c_str |buf| { </del> <ins> let vtable = ccx.sess.str_of(gensym_name("vtable")); let vt_gvar = do vtable.as_c_str |buf| { </ins> llvm::LLVMAddGlobal(ccx.llmod, val_ty(tbl).to_ref(), buf) }; llvm::LLVMSetInitializer(vt_gvar, tbl);
Change:
I would expect to error with "overflow evaluating the requirement", or compile without issue. Instead it segfaults. () Errors:
This segfault occurs since 1.45.0, 1.44.1 emits the expected error. It'd be great if we could bisect if possible.
18 out of backtrace frames: <details<summaryDetails</summary</detailsProbably not very useful.
I believe that we still have the bors artifacts, so it should be possible to use . ping cleanup
Error: Only Rust team members can ping teams. Please let know if you're having trouble with this bot.
ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
searched nightlies: from nightly-2020-05-07 to nightly-2020-05-08 regressed nightly: nightly-2020-05-08 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
It's likely related -- cc
Does fix this issue?
Hm, I don't think so, let me confirm it. -- Confirmed with the master toolchain, it doesn't fix this.
I believe we need to wrap and the similar invocations further down with

Discussion:
use crate::infer::InferCtxt; use crate::traits::normalize_projection_type; <ins> use rustc_data_structures::stack::ensure_sufficient_stack; </ins> use rustc_errors::{error_code, struct_span_err, Applicability, DiagnosticBuilder, Style}; use rustc_hir as hir; use rustc_hir::def::DefKind;

let parent_predicate = parent_trait_ref.without_const().to_predicate(tcx); if !self.is_recursive_obligation(obligated_types, &data.parent_code) { <del> self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ); </del> <ins> // #74711: avoid a stack overflow ensure_sufficient_stack(|| { self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ) }); </ins> } } ObligationCauseCode::ImplDerivedObligation(ref data) => {

parent_trait_ref.skip_binder().self_ty() )); let parent_predicate = parent_trait_ref.without_const().to_predicate(tcx); <del> self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ); </del> <ins> // #74711: avoid a stack overflow ensure_sufficient_stack(|| { self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ) }); </ins> } ObligationCauseCode::DerivedObligation(ref data) => { let parent_trait_ref = self.resolve_vars_if_possible(&data.parent_trait_ref); let parent_predicate = parent_trait_ref.without_const().to_predicate(tcx); <del> self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ); </del> <ins> // #74711: avoid a stack overflow ensure_sufficient_stack(|| { self.note_obligation_cause_code( err, &parent_predicate, &data.parent_code, obligated_types, ) }); </ins> } ObligationCauseCode::CompareImplMethodObligation { .. } => { err.note(&format!(
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. --<!-- 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. --: New backtrace: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsThis probably is the same as found in , except this hits on stable :)
17 - now ICE's 9 - 1.16 just error normally 6 - 1.8 also produce an ICE (unreachable code in ) 0 - 1.5 just error normally
This is has a similar cause to .
Assigning as and removing .
Since minconstgenerics stabilisation this now requires
Seems it has been fixed (finally) in the latest nightly, marking as
Triage: This still triggers ICE with a debug assertion, see for details.
Is there a known workaround to this ? I'm getting this error with the following:
I think I have found a duplicate. <!-- 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
from what I can tell this now works even with debug assertions? marking as needs-test.

Discussion:
<ins> fn bug<'a>() where [(); { //~ ERROR mismatched types let _: &'a (); //~ ERROR a non-static lifetime is not allowed in a `const` }]: {} fn main() {} </ins>

<ins> error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/issue-74713.rs:4:17 | LL |         let _: &'a (); |                 ^^ | = note: see issue #76560 <https://github.com/rust-lang/rust/issues/76560> for more information = help: add `#![feature(generic_const_exprs)]` to the crate attributes to enable error[E0308]: mismatched types --> $DIR/issue-74713.rs:3:10 | LL |       [(); { |  __________^ LL | |         let _: &'a (); LL | |     }]: | |_____^ expected `usize`, found `()` error: aborting due to 2 previous errors Some errors have detailed explanations: E0308, E0658. For more information about an error, try `rustc --explain E0308`. </ins>
Change:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.

Discussion:
fn print_comment(&mut self, cmnt: &comments::Comment) { match cmnt.style { comments::Mixed => { <del> self.zerobreak(); </del> <ins> if !self.is_beginning_of_line() { self.zerobreak(); } </ins> if let Some((last, lines)) = cmnt.lines.split_last() { self.ibox(0);

Space 6+2:                     compare A Ogham Space Mark 6+2: compare B */ /* */ /*

<ins> // ignore-tidy-trailing-newlines // pretty-compare-only /* */ </ins>  No newline at end of file

results } <del> fn print_diff(expected: &str, actual: &str, context_size: usize) { </del> <ins> fn write_diff(expected: &str, actual: &str, context_size: usize) -> String { use std::fmt::Write; let mut output = String::new(); </ins> let diff_results = make_diff(expected, actual, context_size); for result in diff_results { let mut line_number = result.line_number; for line in result.lines { match line { DiffLine::Expected(e) => { <del> println!("-t{}", e); </del> <ins> writeln!(output, "-t{}", e).unwrap(); </ins> line_number += 1; } DiffLine::Context(c) => { <del> println!("{}t{}", line_number, c); </del> <ins> writeln!(output, "{}t{}", line_number, c).unwrap(); </ins> line_number += 1; } DiffLine::Resulting(r) => { <del> println!("+t{}", r); </del> <ins> writeln!(output, "+t{}", r).unwrap(); </ins> } } } <del> println!(); </del> <ins> writeln!(output, "").unwrap(); </ins> } <ins> output </ins> } pub fn run(config: Config, testpaths: &TestPaths, revision: Option<&str>) {

------------------------------------------n {}n ------------------------------------------n <del> n", expected, actual </del> <ins> diff:n ------------------------------------------n {}n", expected, actual, write_diff(expected, actual, 3), </ins> )); } }

} let expected_string = fs::read_to_string(&expected_file).unwrap(); if dumped_string != expected_string { <del> print_diff(&expected_string, &dumped_string, 3); </del> <ins> print!("{}", write_diff(&expected_string, &dumped_string, 3)); </ins> panic!( "Actual MIR output differs from expected MIR output {}", expected_file.display()

println!("normalized {}:n{}n", kind, actual); } else { println!("diff of {}:n", kind); <del> print_diff(expected, actual, 3); </del> <ins> print!("{}", write_diff(expected, actual, 3)); </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. -- <!-- 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. --: I had first seen: Removing the second lifetime () gives the correct error, Additionally, disabling either or still panics (and prompts to enable those features), except in stable where it prompts to enable the features, but does not panic. Perhaps similar to <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The ICE is fixed in the latest nightly, marking as .

Discussion:
<ins> #![feature(member_constraints)] #![feature(type_alias_impl_trait)] pub trait A { type B; fn f(&self) -> Self::B; } impl<'a, 'b> A for () { //~^ ERROR the lifetime parameter `'a` is not constrained //~| ERROR the lifetime parameter `'b` is not constrained type B = impl core::fmt::Debug; fn f(&self) -> Self::B {} } fn main() {} </ins>

<ins> error[E0207]: the lifetime parameter `'a` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74761.rs:8:6 | LL | impl<'a, 'b> A for () { |      ^^ unconstrained lifetime parameter error[E0207]: the lifetime parameter `'b` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74761.rs:8:10 | LL | impl<'a, 'b> A for () { |          ^^ unconstrained lifetime parameter error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0207`. </ins>
Change:
After reducing a from I get a segfault from : This repros for me on my up-to-date checkout as well as for the current beta compiler. I'm not sure whether that makes this a regression from stable to beta, since it's an apparent bug in an API which is first stabilizing in this release. cc
this causes a segfault on stable: results in Luckily is very rarely used
Oof! I'm looking at the existing tests and I realize what we missed. We test direct calls to tracked trait methods and we test indirect calls to tracked trait functions (i.e. no receivers), but we don't test indirect calls of trait methods with receivers.
My immediate suspicion is that trait object vtables aren't going through the reification path we to .
Thanks to for confirming this .
Opened with a fix, thanks again to for help finding the missing call!
Assigning .

Discussion:
debug!(" => associated item with unsizeable self: Self"); Some(Instance { def: InstanceDef::VtableShim(def_id), substs }) } else { <del> Instance::resolve(tcx, param_env, def_id, substs).ok().flatten() </del> <ins> Instance::resolve_for_fn_ptr(tcx, param_env, def_id, substs) </ins> } }

<ins> // run-pass trait Tracked { #[track_caller] fn handle(&self) { let location = std::panic::Location::caller(); assert_eq!(location.file(), file!()); // we only call this via trait object, so the def site should *always* be returned assert_eq!(location.line(), line!() - 4); assert_eq!(location.column(), 5); } } impl Tracked for () {} impl Tracked for u8 {} fn main() { let tracked: &dyn Tracked = &5u8; tracked.handle(); const TRACKED: &dyn Tracked = &(); TRACKED.handle(); } </ins>
Change:
<!-- 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. --I tried this code: I expected to see this happen: Getting some errors that does not satisfy the bound. Instead, this happened: The program compiled and resulted in a double free, and both are of type and point to the same memory... <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</detailsThis seems like some variation of and <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess, this duplicates . (Especially with the comment that I pretty much at the exact same time you created this issue).
Yes, I noticed it haha. Perhaps splitting your original issue up in several issues is a good idea, though
Triage: this given an error, on nightly. modify labels +E-needs-test claim

Discussion:
<ins> #![feature(generic_associated_types)] #![feature(associated_type_defaults)] #![allow(incomplete_features)] use std::ops::Deref; trait UnsafeCopy { type Copy<T>: Copy = Box<T>; //~^ ERROR the trait bound `Box<T>: Copy` is not satisfied //~^^ ERROR the trait bound `T: Clone` is not satisfied fn copy<T>(x: &Self::Copy<T>) -> Self::Copy<T> { *x } } impl<T> UnsafeCopy for T {} fn main() { let b = Box::new(42usize); let copy = <()>::copy(&b); let raw_b = Box::deref(&b) as *const _; let raw_copy = Box::deref(&copy) as *const _; // assert the addresses. assert_eq!(raw_b, raw_copy); } </ins>

<ins> error[E0277]: the trait bound `Box<T>: Copy` is not satisfied --> $DIR/issue-74824.rs:8:5 | LL |     type Copy<T>: Copy = Box<T>; |     ^^^^^^^^^^^^^^----^^^^^^^^^^ |     |             | |     |             required by this bound in `UnsafeCopy::Copy` |     the trait `Copy` is not implemented for `Box<T>` error[E0277]: the trait bound `T: Clone` is not satisfied --> $DIR/issue-74824.rs:8:5 | LL |     type Copy<T>: Copy = Box<T>; |     ^^^^^^^^^^^^^^----^^^^^^^^^^ |     |             | |     |             required by this bound in `UnsafeCopy::Copy` |     the trait `Clone` is not implemented for `T` | = note: required because of the requirements on the impl of `Clone` for `Box<T>` help: consider restricting type parameter `T` | LL |     type Copy<T: Clone>: Copy = Box<T>; |                ^^^^^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>
Change:
version 1.44.1 I will be adding an feature as part of , just wanted to confirm these failures are OK to ignore: ~ ~ CC and who wrote the tests, but I guess you may not be responsible for the underlying behavior.
We have adjusted the const test to be endianess-independent in
For the suggestion in we can presort the restrictions so that the output is always consistent.

Discussion:
.collect::<Vec<(usize, String)>>(); for ((span, empty_where), obligations) in type_params.into_iter() { restrict_type_params = true; <ins> // #74886: Sort here so that the output is always the same. let mut obligations = obligations.into_iter().collect::<Vec<_>>(); obligations.sort(); </ins> err.span_suggestion_verbose( span, &format!(

format!( "{} {}", if empty_where { " where" } else { "," }, <del> obligations.into_iter().collect::<Vec<_>>().join(", ") </del> <ins> obligations.join(", ") </ins> ), Applicability::MaybeIncorrect, );
Change:
The use of async/await and const generics can cause ICE (in the type checker?). Here is a minimal example which induces ICE: The behaviour is not triggered without the use of async/await. The . I am running recent nightly compiler: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Guessing: It might be comparing an const to another const and expects them to compare equal. Slightly minified:
Related to . Not going to mark as a duplicate yet, since the MVCE is quite different.
Note that this ICEs with but not , where it compiles successfully. We should add a test.
Triage: It's now compiled successfully with and the latest nightly.
Great! Leaving open to track adding a regression test.
I'd like to add the test. claim

Discussion:
<ins> // edition:2018 // check-pass // revisions: full min #![cfg_attr(full, feature(const_generics))] #![cfg_attr(full, allow(incomplete_features))] #![cfg_attr(min, feature(min_const_generics))] const SIZE: usize = 16; struct Bar<const H: usize> {} struct Foo<const H: usize> {} impl<const H: usize> Foo<H> { async fn biz(_: &[[u8; SIZE]]) -> Vec<()> { vec![] } pub async fn baz(&self) -> Bar<H> { Self::biz(&vec![]).await; Bar {} } } fn main() { } </ins>