jiebi/CodeConvo huggingface dataset:
Change:
I recently broke the command , see , which demonstrates that CI doesn’t test rustdoc on the standard library with these flags. In effect, code with broken intra doc links in or other issues with items (and probably also for private items?) aren’t detected and can be merged into . Maybe we want to add a test for it? Possibly it’s even true that normal will always succeed if the one with does so we wouldn’t even need to test both with and without those flags? (Correct me if I’m wrong on that last point.) label T-infra, A-docs, A-testsuite, C-enhancement
it seems weird that we'd support this - why would you run document-hidden-items at all?
Because it’s super useful when you’re trying to understand implementation details. I’ve recently been contributing on specializations of iterators involving traits like which is public but . The broken link intra doc link actually hindered my progress reviewing a PR for a few hours until I realized that I could add . But in any case, it’s mostly just an argument of: Hidden items can and do have doc comments and it can be useful to render them (with ), so why shouldn’t we make sure to keep them working? Note that the PR mentioned in didn’t even modify the comment in question that got broken but instead just modified code in the module and with the effect of subsequently removing an import, in turn breaking the hidden doc comments. It’s hard to consistently keep those doc comments clean/working without an automated test, IMO.
Gotcha - this seems reasonable to me, but it couldn't replace building without those flags because they're not actually tested, x.py just builds them directly for upload to But it should be pretty cheap to run it twice since it's just the libraries.
Mentoring instructions: looks like already --document-private-items, so we just need to add to this command and we can close the issue :)

Discussion:
/// 1. The `pieces` slice must be at least as long as `fmt`. /// 2. Every [`rt::v1::Argument::position`] value within `fmt` must be a ///    valid index of `args`. <del> /// 3. Every [`Count::Param`] within `fmt` must contain a valid index of </del> <ins> /// 3. Every [`rt::v1::Count::Param`] within `fmt` must contain a valid index of </ins> ///    `args`. #[doc(hidden)] #[inline]

python3 ../x.py test --stage 2 src/tools/tidy &&  python3 ../x.py test --stage 0 core alloc std test proc_macro &&  # Build both public and internal documentation. <del> RUSTDOCFLAGS="--document-private-items" python3 ../x.py doc --stage 0 library/test &&  </del> <ins> RUSTDOCFLAGS="--document-private-items --document-hidden-items" python3 ../x.py doc --stage 0 library/test &&  </ins> /scripts/validate-toolstate.sh &&  /scripts/validate-error-codes.sh &&  reuse lint &&
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. --I encountered an ICE while incorrectly inserting a outer attribute above deriving or inside of a proc-macro. This did not happen with any other derive I tried. <!-- 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
can you please also provide the configuration to reproduce an for your issue? thanks
Sure, sorry for forgetting, here is the mcve: But incase you dont want to see the entire project the for the macro was just: And the of the project to use the macro (and trigger the ICE) was:
Cool, thank you! Here's the result of a bisection: seems to point to PR cc searched nightlies: from nightly-2021-01-01 to nightly-2021-08-11 regressed nightly: nightly-2021-04-12 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: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium

Discussion:
for attr in &data.attrs { match attr.style { crate::AttrStyle::Outer => { <del> assert!( inner_attrs.len() == 0, "Found outer attribute {:?} after inner attrs {:?}", attr, inner_attrs ); </del> outer_attrs.push(attr); } crate::AttrStyle::Inner => {

<ins> // force-host // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(ICE)] pub fn derive(_: TokenStream) -> TokenStream { r#"#[allow(missing_docs)] struct X { }"#.parse().unwrap() } </ins>

<ins> // aux-build:issue-89971-outer-attr-following-inner-attr-ice.rs #[macro_use] extern crate issue_89971_outer_attr_following_inner_attr_ice; fn main() { Mew(); X {}; } #![deny(missing_docs)] //~^ ERROR an inner attribute is not permitted in this context #[derive(ICE)] #[deny(missing_docs)] struct Mew(); </ins>

<ins> error: an inner attribute is not permitted in this context --> $DIR/issue-89971-outer-attr-following-inner-attr-ice.rs:11:1 | LL | #![deny(missing_docs)] | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | struct Mew(); | ------------- the inner attribute doesn't annotate this struct | = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files help: to annotate the struct, change the attribute from inner to outer style | LL - #![deny(missing_docs)] LL + #[deny(missing_docs)] | error: aborting due to previous error </ins>
Change:
I think long cfg expressions should be broken across multiple lines. I saw this cause issues : !
Do you have an idea on how to improve this maybe
What if we inserted zero width spaces after the keywords? So after each we insert a zero width space (see the ). Maybe we would have to wrap each name in a too but I would have to experiment a bit. Then each expression would try to stay as an inline-block and then break the line on the keywords (like , , , ...)
If we start having "groups", not sure if it'll work well. But definitely worth a try!
I started a test case with a long and complicated expression that results in this image: ! Currently combining a lot of short features is very unreadable and not's are hard to spot. With just it gets a lot more readable, but since the braces get lost in translation it is not clear which flags are binding with , or respectively. ! What if we display a little tree diagram? For most cases that would probably result in a short list with an or an in the beginning. Another idea could be to not draw the tree but to have visible boxes encasing the respective flags. What do you think?
I need to see things to be able to make my own opinion on which approach is better. :smile: But maybe has an idea?
Maybe it could show "any of"/"all of" on longer chains (say 3+)? I don't think there's a ton that can realistically be done here — a long cfg is going to result in a long doc cfg.
There are a lot of things that can be done. For example, for more than 3 items, we could show only the 3 first and show the rest on click. It's mostly about how to display things.
The original case has gotten a lot better, the actual doc string now gets ~60% of the horizontal space rather than ~30%: !
Rendering has degraded again (even though the documented cfg expressions themselves have become shorter): !

Discussion:
display: flex; padding: 3px; margin-bottom: 5px; <ins> align-items: center; vertical-align: text-bottom; </ins> } .item-name .stab { margin-left: 0.3125em;

color: var(--main-color); background-color: var(--stab-background-color); width: fit-content; <del> align-items: center; </del> white-space: pre-wrap; border-radius: 3px; <del> display: inline-flex; vertical-align: text-bottom; </del> <ins> display: inline; </ins> } .stab.portability > code {

("y"), ) // Mobile view set-window-size: (600, 600) // staggered layout with 2em spacing

"//*[@class='desc docblock-short'][text()='a thing with a label']", ("y"), ) <ins> // Ensure it doesn't expand. set-window-size: (800, 800) go-to: "file://" + |DOC_PATH| + "/test_docs/cfgs/index.html" // This part of the tags should not be on the same line as the beginning since the width // is too small for that. compare-elements-position-false: ( "//*[@class='stab portability']/code[text()='appservice-api-c']", "//*[@class='stab portability']/code[text()='server']", ("y"), ) </ins>

}, } } <ins> pub mod cfgs { #[doc(cfg(all( any(not(feature = "appservice-api-c"), not(feature = "appservice-api-s")), any(not(feature = "client"), not(feature = "server")), )))] /// Some docs. pub mod cfgs {} } </ins>
Change:
From 1.55 crater run , : a generic method to the trait, making it no longer object safe. This only caused one crate in crater to fail, and the source for that crate seems to have been removed from github. Still, I don't think this is technically allowed breakage. modify labels: +regression-from-stable-to-beta -regression-untriaged +T-libs +I-nominated cc
I think this just needs a on that method, no? Probably was just overlooked during review.

Discussion:
/// ); /// ``` #[unstable(feature = "build_hasher_simple_hash_one", issue = "86161")] <del> fn hash_one<T: Hash>(&self, x: T) -> u64 { </del> <ins> fn hash_one<T: Hash>(&self, x: T) -> u64 where Self: Sized, { </ins> let mut hasher = self.build_hasher(); x.hash(&mut hasher); hasher.finish()

mod sip; use std::default::Default; <del> use std::hash::{Hash, Hasher}; </del> <ins> use std::hash::{BuildHasher, Hash, Hasher}; </ins> use std::rc::Rc; struct MyHasher {

} assert_eq!(hasher.hash, 5); } <ins> #[test] fn test_build_hasher_object_safe() { use std::collections::hash_map::{DefaultHasher, RandomState}; let _: &dyn BuildHasher<Hasher = DefaultHasher> = &RandomState::new(); } </ins>
Change:
At present, doctests aren't run on macros that are not annotated with . After , it will become possible to fix this problem. However, doing so will cause tests to run that were skipped previously to run, which will likely cause test failures and may mess up people's CI. It might be helpful to provide some form of warning period first. The relevant code is here: Fixing this issue technically just requires removing that special case. However, things are complicated by the fact that this will cause people's tests to suddenly fail. I'm not really sure how we should handle that. do you have any ideas? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also https://rust-
I think we should just change this; it's no different than in that the code was already broken before and we just didn't happen to run it. If you're really worried we can do a crater run but I would honestly be ok with just landing this.
label +E-easy +E-mentor
Looks like accidentally prevented these doctests from being run even if is passed :(
claim
FYI, rayon has an internal macro with an example that wasn't ready to be treated as a test: ... discovered by failing in a .
Hmm, I'm not even sure how to turn that into a working doctest, because the macro isn't exported. The in is also telling -- then what's the point?

Discussion:
/// /// # Example /// <del> /// ``` </del> <ins> /// ```ignore(cannot-test-this-because-non-exported-macro) </ins> /// cfg_if! { ///     if #[cfg(unix)] { ///         fn foo() { /* unix specific functionality */ }

fn visit_item(&mut self, item: &'hir hir::Item<'_>) { let name = match &item.kind { <del> hir::ItemKind::Macro(ref macro_def, _) => { // FIXME(#88038): Non exported macros have historically not been tested, // but we really ought to start testing them. let def_id = item.def_id.to_def_id(); if macro_def.macro_rules && !self.tcx.has_attr(def_id, sym::macro_export) { intravisit::walk_item(self, item); return; } item.ident.to_string() } </del> hir::ItemKind::Impl(impl_) => { rustc_hir_pretty::id_to_string(&self.map, impl_.self_ty.hir_id) }

/// /// Example: /// <del> /// ``` </del> <ins> /// ```ignore(cannot-test-this-because-non-exported-macro) </ins> /// let letters = map!{"a" => "b", "c" => "d"}; /// ``` ///
Change:
Given : The current output is: Ideally the code would compile successfully, but if that is infeasible, it would be nice if the diagnostic contained a hint to remove the . (It's rather head-scratching that the closure is being converted to a fn pointer even though the return type has also been resolved to be the closure type.) The is entirely unnecessary here, but I imagine a beginner might include it unthinkingly (as I did) and not be able to even guess that the has anything to do with the type error. The results are the same on stable 1.54.0, beta, and nightly. If I modify the closure to not be coercible to a function pointer by capturing a variable, then the code compiles without error or relevant warning: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +A-closures +A-inference
Interestingly, this compiles (note the semicolon): claim

Discussion:
exprs.len() ); <ins> // The following check fixes #88097, where the compiler erroneously // attempted to coerce a closure type to itself via a function pointer. if prev_ty == new_ty { return Ok(prev_ty); } </ins> // Special-case that coercion alone cannot handle: // Function items or non-capturing closures of differing IDs or InternalSubsts. let (a_sig, b_sig) = {

<ins> // In #88097, the compiler attempted to coerce a closure type to itself via // a function pointer, which caused an unnecessary error. Check that this // behavior has been fixed. // check-pass fn peculiar() -> impl Fn(u8) -> u8 { return |x| x + 1 } fn peculiar2() -> impl Fn(u8) -> u8 { return |x| x + 1; } fn peculiar3() -> impl Fn(u8) -> u8 { let f = |x| x + 1; return f } fn peculiar4() -> impl Fn(u8) -> u8 { let f = |x| x + 1; f } fn peculiar5() -> impl Fn(u8) -> u8 { let f = |x| x + 1; let g = |x| x + 2; return if true { f } else { g } } fn main() {} </ins>
Change:
While trying to migrate  0.11.1 to the 2021 edition, the compiler fails with this error: It is hard to create a small reproduction, but here is the command to run in that package to reproduce the error: I'm not sure if it is feasible to avoid this. I'm guessing that the lint is doing some kind of trait evaluation that happens to add some additional recursion that is not normally there. Adding fixes the problem. Opening this issue to track whether or not there is anything to do here. Note that the lint doesn't actually fire, so this is just during the analysis (presumably somewhere in ). Full error: <!-- 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. --: cc
don't think I have much context on this one either
I think the problem here is that we are using : But that uses : which is the variant that aborts on overflow we could write into and or something like that. I have to look at the places that call -- in this case, if we see overflow, we could just treat it as false. Scanning where is used: diagnostics, would be better to squelch overflow here too as above as above seems to be for lints, as above (side note that the is-drop-implemented-for-ty is not needed, right?) prelude2021: another 2021 lint, would prefer not to abort clippy: also a lint, probably also true there So, my proposed fix is that we change to return false on overflow. i.e., if it overflows, we don't know that the type implements the trait (we don't, in fact, know anything at all). The function is already approximating in the case of generics -- i.e., a false result doesn't mean that the type does NOT implement the trait, just that we don't know that it does.

Discussion:
/// - the self type /// - the *other* type parameters of the trait, excluding the self-type /// - the parameter environment <ins> /// /// Invokes `evaluate_obligation`, so in the event that evaluating /// `Ty: Trait` causes overflow, EvaluatedToRecur (or EvaluatedToUnknown) /// will be returned. </ins> fn type_implements_trait( &self, trait_def_id: DefId,

recursion_depth: 0, predicate: trait_ref.without_const().to_predicate(self.tcx), }; <del> self.evaluate_obligation_no_overflow(&obligation) </del> <ins> self.evaluate_obligation(&obligation).unwrap_or(traits::EvaluationResult::EvaluatedToErr) </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. --Playing around with some more complex possibilities of const traits + checked evaluation, and ran into an ICE. I minimized it as much as I could, but I imagine this may not be the most minimal example. Uncomment the lines marked as 'Does ICE' to see the error. Playground Link: <!-- 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. --Playground Version <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Update: Further minimized example, the actual value of the constants is irrelevant, it seems the dependent where bounds are the primary issue.
It appears somewhere along the way, the playground link started working. Does this need a test, something in glacier, or any other work?

Discussion:
<ins> // check-pass #![allow(incomplete_features)] #![feature(const_trait_impl, generic_const_exprs)] trait ConstName { const NAME_BYTES: &'static [u8]; } impl const ConstName for u8 { const NAME_BYTES: &'static [u8] = b"u8"; } const fn name_len<T: ?Sized + ConstName>() -> usize { T::NAME_BYTES.len() } impl<T: ?Sized + ConstName> const ConstName for &T where [(); name_len::<T>()]:, { const NAME_BYTES: &'static [u8] = b"&T"; } impl<T: ?Sized + ConstName> const ConstName for &mut T where [(); name_len::<T>()]:, { const NAME_BYTES: &'static [u8] = b"&mut T"; } pub const ICE_1: &'static [u8] = <&&mut u8 as ConstName>::NAME_BYTES; pub const ICE_2: &'static [u8] = <&mut &u8 as ConstName>::NAME_BYTES; fn main() {} </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. --code from glacier <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label +AsyncAwait-Triaged This looks like a probable const generics bug.
updated code: `

Discussion:
saved_locals: &GeneratorSavedLocals, ) { let did = body.source.def_id(); <del> let allowed_upvars = tcx.erase_regions(upvars); </del> <ins> let param_env = tcx.param_env(did); let allowed_upvars = tcx.normalize_erasing_regions(param_env, upvars); </ins> let allowed = match witness.kind() { <del> &ty::GeneratorWitness(s) => tcx.erase_late_bound_regions(s), </del> <ins> &ty::GeneratorWitness(interior_tys) => { tcx.normalize_erasing_late_bound_regions(param_env, interior_tys) } </ins> _ => { tcx.sess.delay_span_bug( body.span,

} }; <del> let param_env = tcx.param_env(did); </del> for (local, decl) in body.local_decls.iter_enumerated() { // Ignore locals which are internal or not saved between yields. if !saved_locals.contains(local) || decl.internal {

<ins> // edition:2018 // run-pass #![allow(incomplete_features)] #![feature(generic_const_exprs)] #![allow(unused)] fn main() { let x = test(); } fn concat<const A: usize, const B: usize>(a: [f32; A], b: [f32; B]) -> [f32; A + B] { todo!() } async fn reverse<const A: usize>(x: [f32; A]) -> [f32; A] { todo!() } async fn test() { let a = [0.0]; let b = [1.0, 2.0]; let ab = concat(a,b); let ba = reverse(ab).await; println!("{:?}", ba); } </ins>
Change:
The type signature of : Note how is the function that gets applied to the variant. Then, the docstring (emphasis mine): I think this is a very unfortunate choice of words and should be changed.
are you interested in making a PR to fix it? :) there are instructions in https://rustc-dev-
I could, but I think I'd prefer to bikeshed a bit first as to how it should be described.
To me these functions are so confusing that I practically never use them, the arguments are in the wrong order ... as repeatedly noted in both the and that it. It can't be changed, of course :/ I rather like the way it's documented in the corresponding method on :
How about It explains in the same order as the function name () and doesn't overload the meaning of "default" in the context of the unfortunate function argument.
Made a pull request using 's suggestion, only replacing "applying " with "applying function " to be consistent with the earlier part of the sentence.

Discussion:
} } <del> /// Maps a `Result<T, E>` to `U` by applying a provided default fallback /// function to a contained [`Err`] value, or a provided function to a /// contained [`Ok`] value. </del> <ins> /// Maps a `Result<T, E>` to `U` by applying fallback function `default` to /// a contained [`Err`] value, or function `f` to a contained [`Ok`] value. </ins> /// /// This function can be used to unpack a successful result /// while handling an error.
Change:
I tried this code: I expected to see this happen: It compiles or gives me a detailed error. Instead, this happened: Compiler suggests to add an already existing trait bound. Adding it one more time leads to compiler suggesting adding it once more and so on. While the code example uses GAT and TAIT, I'm not entirely sure both of those features are required to reproduce the issue. label +T-compiler +F-typealiasimpltrait +F-genericassociated_types +A-traits +requires-nightly
This compiles fine on the latest nightly, perhaps related to .

Discussion:
<ins> // check-pass // edition:2018 #![feature(generic_associated_types)] #![feature(type_alias_impl_trait)] use std::future::Future; trait SearchableResource<Criteria> { type SearchResult; } trait SearchableResourceExt<Criteria>: SearchableResource<Criteria> { type Future<'f, A: 'f + ?Sized, B: 'f>: Future<Output = Result<Vec<A::SearchResult>, ()>> + 'f where A: SearchableResource<B>; fn search<'c>(&'c self, client: &'c ()) -> Self::Future<'c, Self, Criteria>; } type SearchFutureTy<'f, A, B: 'f> where A: SearchableResource<B> + ?Sized + 'f, = impl Future<Output = Result<Vec<A::SearchResult>, ()>> + 'f; impl<T, Criteria> SearchableResourceExt<Criteria> for T where T: SearchableResource<Criteria>, { type Future<'f, A, B: 'f> where A: SearchableResource<B> + ?Sized + 'f, = SearchFutureTy<'f, A, B>; fn search<'c>(&'c self, _client: &'c ()) -> Self::Future<'c, Self, Criteria> { async move { todo!() } } } fn main() {} </ins>

<ins> // check-pass #![feature(generic_associated_types)] trait SomeTrait {} trait OtherTrait { type Item; } trait ErrorSimpleExample { type AssociatedType: SomeTrait; type GatBounded<T: SomeTrait>; type ErrorMinimal: OtherTrait<Item = Self::GatBounded<Self::AssociatedType>>; } fn main() {} </ins>