jiebi/CodeConvo huggingface dataset:
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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Is this related to ?
Nope
Ooh I misread the Typerror ice, my bad :upsidedownface:
No big deal, this has to do with a lock (well, refcell) being held in hir typeck, if you're curious

Discussion:
hir::Path { segments: [segment], .. }, )) | hir::ExprKind::Path(QPath::TypeRelative(ty, segment)) => { <del> let self_ty = self.astconv().ast_ty_to_ty(ty); if let Ok(pick) = self.probe_for_name( Mode::Path, Ident::new(capitalized_name, segment.ident.span), Some(expected_ty), IsSuggestion(true), self_ty, expr.hir_id, ProbeScope::TraitsInScope, ) { </del> <ins> if let Some(self_ty) = self.typeck_results.borrow().node_type_opt(ty.hir_id) && let Ok(pick) = self.probe_for_name( Mode::Path, Ident::new(capitalized_name, segment.ident.span), Some(expected_ty), IsSuggestion(true), self_ty, expr.hir_id, ProbeScope::TraitsInScope, ) { </ins> (pick.item, segment) } else { return false;

<ins> // edition: 2021 use std::collections::HashMap; use std::future::Future; use std::pin::Pin; pub trait Trait { fn do_something<'async_trait>(byte: u8) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>>; } pub struct Struct; impl Trait for Struct { fn do_something<'async_trait>(byte: u8) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>> { Box::pin( async move { let byte = byte; let _: () = {}; }) } } pub struct Map { map: HashMap<u16, fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>>>, } impl Map { pub fn new() -> Self { let mut map = HashMap::new(); map.insert(1, Struct::do_something); Self { map } //~^ ERROR mismatched types } } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-107775.rs:35:16 | LL |         map.insert(1, Struct::do_something); |                    -  -------------------- this is of type `fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}`, which causes `map` to be inferred as `HashMap<{integer}, fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}>` |                    | |                    this is of type `{integer}`, which causes `map` to be inferred as `HashMap<{integer}, fn(u8) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}>` LL |         Self { map } |                ^^^ expected `HashMap<u16, fn(u8) -> Pin<...>>`, found `HashMap<{integer}, ...>` | = note: expected struct `HashMap<u16, fn(_) -> Pin<Box<(dyn Future<Output = ()> + Send + 'static)>>>` found struct `HashMap<{integer}, fn(_) -> Pin<Box<dyn Future<Output = ()> + Send>> {<Struct as Trait>::do_something::<'_>}>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </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: Macro is expanded to Instead, this happened: On stable it works as expected. On beta and nightly it fails with the following error It is probably caused by fragment that now treats as a start of type. So makes sense. But breaks existing code :) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
searched nightlies: from nightly-2022-06-01 to nightly-2023-02-01 regressed nightly: nightly-2023-01-18 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsI think I see where the issue is, I'll fix it. claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
IIRC issues with a backport pending should stay open to track the backport process (not 100% sure tho)
beta backport in

Discussion:
// `where`, so stop if it's it. // We also continue if we find types (not traits), again for error recovery. while self.can_begin_bound() <del> || self.token.can_begin_type() || (self.token.is_reserved_ident() && !self.token.is_keyword(kw::Where)) </del> <ins> || (self.may_recover() && (self.token.can_begin_type() || (self.token.is_reserved_ident() && !self.token.is_keyword(kw::Where)))) </ins> { if self.token.is_keyword(kw::Dyn) { // Account for `&dyn Trait + dyn Other`.

<ins> // check-pass // edition:2021 // for the `impl` + keyword test macro_rules! impl_primitive { ($ty:ty) => { compile_error!("whoops"); }; (impl async) => {}; } impl_primitive!(impl async); fn main() {} </ins>

<ins> // check-pass macro_rules! impl_primitive { ($ty:ty) => { impl_primitive!(impl $ty); }; (impl $ty:ty) => { fn a(_: $ty) {} } } impl_primitive! { u8 } macro_rules! test { ($ty:ty) => { compile_error!("oh no"); }; (impl &) => {}; } test!(impl &); fn main() {} </ins>
Change:
do you have time to fix this regression? Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Yes, will do claim

Discussion:
) exit_code = 0 <ins> success_word = "successfully" </ins> try: bootstrap(args) except (SystemExit, KeyboardInterrupt) as error:

else: exit_code = 1 print(error) <ins> success_word = "unsuccessfully" </ins> if not help_triggered: <del> print("Build completed successfully in", format_build_time(time() - start_time)) </del> <ins> print("Build completed", success_word, "in", format_build_time(time() - start_time)) </ins> sys.exit(exit_code)
Change:
I think this is one of the reasons (maybe not the only one?) that introducing a build failure in src/bootstrap means that rust-analyzer doesn't show red squigglies in the IDE. Mentoring instructions: add a new flag to around and pass to cargo around if it's set. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc https://rust-
claim
Solving this may also solve

Discussion:
if self.get_toml("metrics", "build"): args.append("--features") args.append("build-metrics") <ins> if self.json_output: args.append("--message-format=json") </ins> if color == "always": args.append("--color=always") elif color == "never":

parser.add_argument('--build') parser.add_argument('--color', choices=['always', 'never', 'auto']) parser.add_argument('--clean', action='store_true') <ins> parser.add_argument('--json-output', action='store_true') </ins> parser.add_argument('-v', '--verbose', action='count', default=0) return parser.parse_known_args(sys.argv)[0]

build.rust_root = os.path.abspath(os.path.join(__file__, '../../..')) build.verbose = args.verbose != 0 build.clean = args.clean <ins> build.json_output = args.json_output </ins> # Read from `--config`, then `RUST_BOOTSTRAP_CONFIG`, then `./config.toml`, # then `config.toml` in the root directory.
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. --: Regression in <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Considering this errors with rustc, and rustdoc can only document rust code that actually compiles, I'd say this is in the same bucket as the other issues we have open about this, meaning "not a bug, just a papercut"?
this is not true
I can only document code that compiles, ignoring method bodies. This specific test has no method bodies, so does it fall under that rule?
That seems possible, but you should test to make sure. Rustdoc's logic around this is extremely janky and indirect.
What is the benefit of documenting code that does not compile?
I can't keep having this argument. Please read the documentation.
cc
Triage: No longer ICEs. Might need regression test, not sure. Current compiler output:

Discussion:
<ins> // Test to ensure that there is no ICE when normalizing a projection. // See also <https://github.com/rust-lang/rust/pull/106938>. // issue: rust-lang/rust#107872 pub trait Identity { type Identity; } pub type Foo = u8; pub union Bar { a:  <Foo as Identity>::Identity, //~ ERROR the trait bound `u8: Identity` is not satisfied b: u8, } </ins>

<ins> error[E0277]: the trait bound `u8: Identity` is not satisfied --> $DIR/projection-as-union-type-error.rs:12:9 | LL |     a:  <Foo as Identity>::Identity, |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Identity` is not implemented for `u8` | help: this trait has no implementations, consider adding one --> $DIR/projection-as-union-type-error.rs:5:1 | LL | pub trait Identity { | ^^^^^^^^^^^^^^^^^^ error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0277`. </ins>

<ins> // issue: rust-lang/rust#98250 //@ check-pass #![feature(type_alias_impl_trait)] mod foo { pub type Foo = impl PartialEq<(Foo, i32)>; fn foo() -> Foo { super::Bar } } use foo::Foo; struct Bar; impl PartialEq<(Foo, i32)> for Bar { fn eq(&self, _other: &(Foo, i32)) -> bool { true } } fn main() {} </ins>
Change:
It seems like fails is there is a dependency that has a and a binary that defines it as well, even if the dependency is never imported. I ran into this issue when I had 1 nostd bin per crate, where one binary had a custom panic_impl and another used that from a dependency. Minimal reproduction: The following works: But this fails (also when specifying target) : label +T-rustdoc
Possibly similar cause:
Seems like this happens even with so not really a good workaround, yuck...
I can't reproduce the bug locally. Do you still have the issue?
Interesting - it looks like it was broken on but working on my current . Probably not worth bisecting, but maybe a regression test would be good if there isn't one?
Agreed, wanna add one? Otherwise I plan to do it in the next hours.
I'm not too familiar with the test patterns for rustdoc, so I'll just leave it to you if you don't mind
No problem!

Discussion:
<ins> // compile-flags: -C panic=abort #![no_std] #![no_main] #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { loop {} } </ins>

<ins> // aux-build:panic-handler.rs // compile-flags: --document-private-items // build-pass // ignore-windows #![no_std] #![no_main] #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { loop {} } </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. --I ran with this code: I expected to see this happen: intra-doc-links work and no warning Instead, this happened: intra-doc-links is not working in the generated docs. <img width="215" alt="doc" src="https://user-"And I got brokenintradoc_links warnings: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: nightly-2023-02-11 <img width="215" alt="doc-old" src="https://user-"<!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
Fixed in
label A-intra-doc-links

Discussion:
if let Some(res) = res && let Some(def_id) = res.opt_def_id() && !def_id.is_local() <del> && self.r.session.crate_types().contains(&CrateType::ProcMacro) { </del> <ins> && self.r.session.crate_types().contains(&CrateType::ProcMacro) && matches!(self.r.session.opts.resolve_doc_links, ResolveDocLinks::ExportedMetadata) { </ins> // Encoding foreign def ids in proc macro crate metadata will ICE. return None; }

.filter_map(|tr| { if !tr.def_id.is_local() && self.r.session.crate_types().contains(&CrateType::ProcMacro) <ins> && matches!( self.r.session.opts.resolve_doc_links, ResolveDocLinks::ExportedMetadata ) </ins> { // Encoding foreign def ids in proc macro crate metadata will ICE. return None;

<ins> // check-pass // force-host // no-prefer-dynamic // compile-flags: --crate-type proc-macro #![deny(rustdoc::broken_intra_doc_links)] extern crate proc_macro; use proc_macro::*; /// [`Unpin`] #[proc_macro_derive(F)] pub fn derive_(t: proc_macro::TokenStream) -> proc_macro::TokenStream { t } /// [`Vec`] #[proc_macro_attribute] pub fn attr(t: proc_macro::TokenStream, _: proc_macro::TokenStream) -> proc_macro::TokenStream { t } /// [`std::fs::File`] #[proc_macro] pub fn func(t: proc_macro::TokenStream) -> proc_macro::TokenStream { t } </ins>
Change:
The documentation of states: but this is not accurate since programs can rely on it behaving like the identity function. It would be better to reword this as or similar, e.g., <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
are you interested in making a PR to fix this? :)
Can't, sorry.
claim
It seems that there are some other parts of the docs that are still incorrect. For example, in the How to use it section, the incorrect claim continues to be repeated: I think the whole document needs a pass to fix this.
claim

Discussion:
/// /// Note however, that `black_box` is only (and can only be) provided on a "best-effort" basis. The /// extent to which it can block optimisations may vary depending upon the platform and code-gen <del> /// backend used. Programs cannot rely on `black_box` for *correctness* in any way. </del> <ins> /// backend used. Programs cannot rely on `black_box` for *correctness*, beyond it behaving as the /// identity function. </ins> /// /// [`std::convert::identity`]: crate::convert::identity ///
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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
are you working on this?
yes

Discussion:
} (VarValue::Value(a), VarValue::Empty(_)) => { match *a { <del> ReLateBound(..) | ReErased | ReError(_) => { </del> <ins> // this is always on an error path, // so it doesn't really matter if it's shorter or longer than an empty region ReError(_) => false, ReLateBound(..) | ReErased => { </ins> bug!("cannot relate region: {:?}", a); }

} (VarValue::Empty(a_ui), VarValue::Value(b)) => { match *b { <del> ReLateBound(..) | ReErased | ReError(_) => { </del> <ins> // this is always on an error path, // so it doesn't really matter if it's shorter or longer than an empty region ReError(_) => false, ReLateBound(..) | ReErased => { </ins> bug!("cannot relate region: {:?}", b); }

<ins> pub trait TraitEngine<'tcx>: 'tcx {} pub trait TraitEngineExt<'tcx> { fn register_predicate_obligations(&mut self); } impl<T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { //~^ ERROR use of undeclared lifetime name `'tcx` //~| ERROR use of undeclared lifetime name `'tcx` fn register_predicate_obligations(&mut self) {} } fn main() {} </ins>

<ins> error[E0261]: use of undeclared lifetime name `'tcx` --> $DIR/issue-107988.rs:7:52 | LL | impl<T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |      -                                             ^^^^ undeclared lifetime |      | |      help: consider introducing lifetime `'tcx` here: `'tcx,` error[E0261]: use of undeclared lifetime name `'tcx` --> $DIR/issue-107988.rs:7:30 | LL | impl<T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |                              ^^^^ undeclared lifetime | = note: for more information on higher-ranked polymorphism, visit https://doc.rust-lang.org/nomicon/hrtb.html help: consider making the bound lifetime-generic with a new `'tcx` lifetime | LL | impl<T: ?Sized + for<'tcx> TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |                  +++++++++ help: consider introducing lifetime `'tcx` here | LL | impl<'tcx, T: ?Sized + TraitEngine<'tcx>> TraitEngineExt<'tcx> for T { |      +++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0261`. </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. --: <details<summarycargo bisect-rustc points </summarysearched nightlies: from nightly-2023-01-30 to nightly-2023-02-13 regressed nightly: nightly-2023-02-12 searched commit range: regressed commit: </details label +regression-from-stable-to-nightly +T-rustdoc
cc as author of
Duplicate of
I have a similar problem. Steps to reproduce:
Same issue also reproduces when is documented directly, not as a dependency.
The link in looks like this , not the single backtick and also whitespace. Looks like a mismatch in preprocessing the stuff inside between rustc and rustdoc.
link , extra whitespace.
Oh, yes, this reproduces:
There's still something else going on since AFAICT there are no links in case of
link , extra newlines (?) after the doc strings are merged.
Oh, I was looking at the wrong macro, sorry. :man_facepalming:
I'll try to fix all this stuff tomorrow.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Fixed in

Discussion:
fn preprocess_link(link: &str) -> String { let link = link.replace('`', ""); let link = link.split('#').next().unwrap(); <ins> let link = link.trim(); </ins> let link = link.rsplit('@').next().unwrap(); let link = link.strip_suffix("()").unwrap_or(link); let link = link.strip_suffix("{}").unwrap_or(link);

let mut parts = stripped.split('#'); let link = parts.next().unwrap(); <del> if link.trim().is_empty() { </del> <ins> let link = link.trim(); if link.is_empty() { </ins> // This is an anchor to an element of the current page, nothing to do in here! return None; }

// Parse and strip the disambiguator from the link, if present. let (disambiguator, path_str, link_text) = match Disambiguator::from_str(link) { Ok(Some((d, path, link_text))) => (Some(d), path.trim(), link_text.trim()), <del> Ok(None) => (None, link.trim(), link.trim()), </del> <ins> Ok(None) => (None, link, link), </ins> Err((err_msg, relative_range)) => { // Only report error if we would not have ignored this link. See issue #83859. if !should_ignore_link_with_disambiguators(link) {

<ins> // Regression test for <https://github.com/rust-lang/rust/issues/107995>. #![crate_name = "foo"] // @has 'foo/fn.foo.html' // @has - '//*[@class="docblock"]//a[@href="fn.bar.html"]' 'bar`' /// A foo, see also [ bar`] pub fn foo() {} // @has 'foo/fn.bar.html' // @has - '//*[@class="docblock"]' 'line Path line' // @has - '//*[@class="docblock"]//a[@href="struct.Path.html"]' 'Path' #[doc = "line ["] #[doc = "Path"] #[doc = "] line"] pub fn bar() {} // @has 'foo/fn.another.html' // @has - '//*[@class="docblock"]//a[@href="struct.Path.html"]' 'Path' /// [ `Path`] pub fn another() {} // @has 'foo/fn.last.html' // @has - '//*[@class="docblock"]//a[@href="struct.Path.html"]' 'Path' /// [ Path`] pub fn last() {} pub struct Path; </ins>
Change:
<!-- 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. --: Needs a rustc built with debug assertions, <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details

Discussion:
(use_span, "'_".to_owned()) }; debug!(?deletion_span, ?use_span); <ins> // issue 107998 for the case such as a wrong function pointer type // `deletion_span` is empty and there is no need to report lifetime uses here let suggestions = if deletion_span.is_empty() { vec![(use_span, replace_lt)] } else { vec![(deletion_span, String::new()), (use_span, replace_lt)] }; </ins> db.multipart_suggestion( msg, <del> vec![(deletion_span, String::new()), (use_span, replace_lt)], </del> <ins> suggestions, </ins> Applicability::MachineApplicable, ); }

<ins> #![deny(single_use_lifetimes)] fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { //~^ ERROR function pointer types may not have generic parameters //~| ERROR lifetime parameter `'a` only used once f(&3) } fn main() {} </ins>

<ins> error: function pointer types may not have generic parameters --> $DIR/issue-107998.rs:3:18 | LL | fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { |                  ^^^^ | help: consider moving the lifetime parameter to a `for` parameter list | LL - fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { LL + fn with<R>(f: &for<'a> fn(x: &'a i32) -> R) -> R { | error: lifetime parameter `'a` only used once --> $DIR/issue-107998.rs:3:19 | LL | fn with<R>(f: &fn<'a>(x: &'a i32) -> R) -> R { |                   ^^      --- |                   |       | |                   |       ...is used only here |                   |       help: elide the single-use lifetime |                   this lifetime... | note: the lint level is defined here --> $DIR/issue-107998.rs:1:9 | LL | #![deny(single_use_lifetimes)] |         ^^^^^^^^^^^^^^^^^^^^ error: aborting due to 2 previous errors </ins>