jiebi/CodeConvo huggingface dataset:
Change:
<table<tr<thcode</th<thrustdoc</th</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr<tr<td</td<td<img src="https://user-" width="400"</td</tr</tableWould it be reasonable for Rustdoc to produce exactly the same output for and ? I think so. These two types have an identical public API. Separately, would it be reasonable for Rustdoc to produce exactly the same output for and ? Whether that means printing a synthetic attribute on instead of the comment, or some other approach that unifies all three of these outputs. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
IMHO, for both is more clear. It better conveys meaning. I'm happy to work on this but I've never touched rustdoc before so I might need some help. claim EDIT: is it acceptable to literally a new attribute onto ?
I think it's important that the docs not disagree with behavior users can observe from the compiler. So we shouldn't document a attribute when none exists because a user could write an exhaustive match and not get a compile error (even though they might have had to look at the source to do so). I think it would be reasonable for Enum2 and Enum3 to render as Enum2 is today: <img width=300 src="https://user-"For Enum1, I think there should be a doc lint warning if there is a variant without the enum being marked .
I agree, a doc lint sounds like the best idea because semantically is even if not technically so. I see that you are the reviewer on the linked PR, I've marked it as a draft for now and will re-implement with your suggestion. I assume that broadly agrees from the OP?

Discussion:
w.write_str(",n"); } <del> if variants_stripped { </del> <ins> if variants_stripped && !it.is_non_exhaustive() { </ins> w.write_str("    // some variants omittedn"); } if toggle {

<ins> // @has issue_108925/enum.MyThing.html // @has - '//code' 'Shown' // @!has - '//code' 'NotShown' // @!has - '//code' '// some variants omitted' #[non_exhaustive] pub enum MyThing { Shown, #[doc(hidden)] NotShown, } </ins>
Change:
Today error :
I've heard the error from IRC: misses , but invoking again seems to work well.
Yes I just successfully build it today, thanks
I think the first error is significant and should be fixed (no need to re-). Could you reopen it?
wait... but it's building without errors for me now... Do you mean it's working only because I run build second time?
llvm build is triggered only if you haven't built it before or llvm has been upgraded. So I guess llvm fails to complete, but it anyway succeeded to make some binary we use.
I will try to reproduce with clean build
Right, it's still being failing if I build it first time ( or even if I remove i686-... (build) folder ) with the same error.
What version of mingw/gcc did you use? would show and/or . (If both values exist, trust the second one.)
I also reproduced the error on mingw 4.0 / gcc 4.8.1.
I'm having the same issue:
I'm also having this issue. Same version information as
I am also getting the error. Same versions as ameyp. Any more info on this?
According to , this error happens because this particular binary (llvm-c-test) is compiled with -std=c99 flag. Apparently 'offt' is not in ANSI standard, so mingw's specifically omits it when is defined.

Discussion:
LLVM_COMPONENTS=x86 arm mips ipo bitreader bitwriter linker asmparser jit mcjit  interpreter instrumentation <ins> # Only build these LLVM tools LLVM_TOOLS=bugpoint llc llvm-ar llvm-as llvm-dis llvm-mc opt </ins> define DEF_LLVM_VARS # The configure script defines these variables with the target triples # separated by Z. This defines new ones with the expected format.

$$(LLVM_CONFIG_$(1)): $$(LLVM_DEPS) $$(LLVM_STAMP_$(1)) @$$(call E, make: llvm) <del> $$(Q)$$(MAKE) -C $$(CFG_LLVM_BUILD_DIR_$(1)) $$(CFG_LLVM_BUILD_ENV_$(1)) </del> <ins> $$(Q)$$(MAKE) -C $$(CFG_LLVM_BUILD_DIR_$(1)) $$(CFG_LLVM_BUILD_ENV_$(1)) ONLY_TOOLS="$$(LLVM_TOOLS)" </ins> $$(Q)touch $$(LLVM_CONFIG_$(1)) endif
Change:
doesn't seem to know that custom targets can extend the set of values. The following creates a custom spec with a . No warning Got the warning: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

Discussion:
add_configuration(&mut cfg, &mut sess, &*codegen_backend); let mut check_cfg = config::to_crate_check_config(check_cfg); <del> check_cfg.fill_well_known(); </del> <ins> check_cfg.fill_well_known(&sess.target); </ins> sess.parse_sess.config = cfg; sess.parse_sess.check_config = check_cfg;

} /// Fills a `CrateCheckConfig` with well-known configuration values. <del> fn fill_well_known_values(&mut self) { </del> <ins> fn fill_well_known_values(&mut self, current_target: &Target) { </ins> if !self.well_known_values { return; }

for target in TARGETS .iter() .map(|target| Target::expect_builtin(&TargetTriple::from_triple(target))) <ins> .chain(iter::once(current_target.clone())) </ins> { values_target_os.insert(Symbol::intern(&target.options.os)); values_target_family

} } <del> pub fn fill_well_known(&mut self) { </del> <ins> pub fn fill_well_known(&mut self, current_target: &Target) { </ins> self.fill_well_known_names(); <del> self.fill_well_known_values(); </del> <ins> self.fill_well_known_values(current_target); </ins> } }

<ins> { "llvm-target": "x86_64-unknown-none-gnu", "data-layout": "e-m:e-i64:64-f80:128-n8:16:32:64-S128", "arch": "x86_64", "target-endian": "little", "target-pointer-width": "64", "target-c-int-width": "32", "os": "ericos", "linker-flavor": "ld.lld", "linker": "rust-lld", "executables": true } </ins>

<ins> // This test checks that we don't lint values defined by a custom target (target json) // // check-pass // needs-llvm-components: x86 // compile-flags: --crate-type=lib --check-cfg=values() --target={{src-base}}/check-cfg/my-awesome-platform.json -Z unstable-options #![feature(lang_items, no_core, auto_traits)] #![no_core] #[lang = "sized"] trait Sized {} #[cfg(target_os = "linuz")] //~^ WARNING unexpected `cfg` condition value fn target_os_linux_misspell() {} #[cfg(target_os = "linux")] fn target_os_linux() {} #[cfg(target_os = "ericos")] fn target_os_ericos() {} </ins>

<ins> warning: unexpected `cfg` condition value --> $DIR/values-target-json.rs:13:7 | LL | #[cfg(target_os = "linuz")] |       ^^^^^^^^^^^^------- |                   | |                   help: did you mean: `"linux"` | = note: expected values for `target_os` are: aix, android, cuda, dragonfly, emscripten, ericos, espidf, freebsd, fuchsia, haiku, hermit, horizon, illumos, ios, l4re, linux, macos, netbsd, none, nto, openbsd, psp, redox, solaris, solid_asp3, tvos, uefi, unknown, vita, vxworks, wasi, watchos, windows, xous = note: `#[warn(unexpected_cfgs)]` on by default warning: 1 warning emitted </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. --Explicitly giving lifetimes to with and doing the same on does not fix the ICE either. Version
label +S-bug-has-mcve
Triage: Fixed on the latest nightly, labels: +E-needs-test

Discussion:
<ins> // edition:2021 #![feature(type_alias_impl_trait)] struct CallMe; type ReturnType<'a> = impl std::future::Future<Output = u32> + 'a; type FnType = impl Fn(&u32) -> ReturnType; impl std::ops::Deref for CallMe { type Target = FnType; fn deref(&self) -> &Self::Target { fn inner(val: &u32) -> ReturnType { async move { *val * 2 } } &inner //~ ERROR: expected generic lifetime parameter, found `'_` } } fn main() {} </ins>

<ins> error[E0792]: expected generic lifetime parameter, found `'_` --> $DIR/issue-109054.rs:18:9 | LL | type ReturnType<'a> = impl std::future::Future<Output = u32> + 'a; |                 -- this generic parameter must be used with a generic lifetime parameter ... LL |         &inner |         ^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0792`. </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. --This is a fuzzed test case, found with and minimized with , and did not find any related issues. I was able to reproduce with a compiler I compiled from . <!-- 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 --<!-- TRIAGEBOT_END --
claim
label +S-bug-has-mcve

Discussion:
passes_doc_keyword_only_impl = `#[doc(keyword = "...")]` should be used on impl blocks <ins> passes_doc_test_literal = `#![doc(test(...)]` does not take a literal </ins> passes_doc_test_takes_list = `#[doc(test(...)]` takes a list of attributes

let mut is_valid = true; if let Some(metas) = meta.meta_item_list() { for i_meta in metas { <del> match i_meta.name_or_empty() { sym::attr | sym::no_crate_inject => {} _ => { </del> <ins> match (i_meta.name_or_empty(), i_meta.meta_item()) { (sym::attr | sym::no_crate_inject, _) => {} (_, Some(m)) => { </ins> self.tcx.emit_spanned_lint( INVALID_DOC_ATTRIBUTES, hir_id, i_meta.span(), errors::DocTestUnknown { <del> path: rustc_ast_pretty::pprust::path_to_string( &i_meta.meta_item().unwrap().path, ), </del> <ins> path: rustc_ast_pretty::pprust::path_to_string(&m.path), </ins> }, ); is_valid = false; } <ins> (_, None) => { self.tcx.emit_spanned_lint( INVALID_DOC_ATTRIBUTES, hir_id, i_meta.span(), errors::DocTestLiteral, ); is_valid = false; } </ins> } } } else {

} #[derive(LintDiagnostic)] <ins> #[diag(passes_doc_test_literal)] pub struct DocTestLiteral; #[derive(LintDiagnostic)] </ins> #[diag(passes_doc_test_takes_list)] pub struct DocTestTakesList;

<ins> #![deny(warnings)] #![doc(test(""))] //~^ ERROR `#![doc(test(...)]` does not take a literal //~^^ WARN this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! fn main() {} </ins>

<ins> error: `#![doc(test(...)]` does not take a literal --> $DIR/doc-test-literal.rs:3:13 | LL | #![doc(test(""))] |             ^^ | = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #82730 <https://github.com/rust-lang/rust/issues/82730> note: the lint level is defined here --> $DIR/doc-test-literal.rs:1:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(invalid_doc_attributes)]` implied by `#[deny(warnings)]` error: aborting due to previous error </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. --This is a fuzzed test case, found with and minimized with , but found no similar issues. <!-- 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 --
searched nightlies: from nightly-2021-01-01 to nightly-2023-03-12 regressed nightly: nightly-2023-01-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsNote that this requires edition 2015/2018, as edition 2021 hard errors on the bare trait object before ever getting to layout code. cc
claim

Discussion:
*/ }; <del> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() { </del> <ins> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() // Projection eagerly bails out when the pointee references errors, // fall back to structurally deducing metadata. && !pointee.references_error() { </ins> let metadata = tcx.normalize_erasing_regions( cx.param_env(), tcx.mk_projection(metadata_def_id, [pointee]),

let unsized_part = tcx.struct_tail_erasing_lifetimes(pointee, param_env); <del> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() { </del> <ins> let metadata = if let Some(metadata_def_id) = tcx.lang_items().metadata_type() // Projection eagerly bails out when the pointee references errors, // fall back to structurally deducing metadata. && !pointee.references_error() { </ins> let metadata_ty = tcx.normalize_erasing_regions( param_env, tcx.mk_projection(metadata_def_id, [pointee]),

<ins> trait Trait<T> {} struct Bar(Box<dyn Trait<T>>); //~^ ERROR cannot find type `T` in this scope fn main() { let x: Bar = unsafe { std::mem::transmute(()) }; } </ins>

<ins> error[E0412]: cannot find type `T` in this scope --> $DIR/transmute-to-tail-with-err.rs:3:26 | LL | struct Bar(Box<dyn Trait<T>>); |                          ^ not found in this scope | help: you might be missing a type parameter | LL | struct Bar<T>(Box<dyn Trait<T>>); |           +++ error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </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. --Building rust with the option fails with a symbolic link creation error. Reverting fixes the issue. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.67.1 Rust 1.68.0 <!-- Provide the version you are using that has the regression. --<!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details<!-- 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 --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +t-bootstrap Edit: how very convenient, wasn't even aware there was limitations on label, either way, does this issue occur with x86_64-windows-msvc.
Error: Label t-bootstrap can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I am one of the maintainers of the Rust build at The upgrade from 1.67.1 to 1.68.0 broke the aarch64 build (which uses the --enable-local-rust option). We can also reproduce it on other architectures and tool chains.
I ... don't see how this could be related to --enable-local-rust? we're not modifying anything in the stage 0 directory, only in the build directory. do you still see this issue if you remove that option?
oh I see, when that option is enabled doesn't download the toolchain and so there's no folder yet. the correct fix is to add just after
Using --enable-local-rust will skip downloading and extracting the previous Rust version. The new code tries to create a symlink from to a directory that was supposedly extracted (but was not). There is the same issue with --local-rust-root btw.
claim

Discussion:
// Make a symbolic link so we can use a consistent directory in the documentation. let build_triple = build.out.join(&build.build.triple); <ins> t!(fs::create_dir_all(&build_triple)); </ins> let host = build.out.join("host"); if let Err(e) = symlink_dir(&build.config, &build_triple, &host) { if e.kind() != ErrorKind::AlreadyExists {
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
searched toolchains through Regression in
Triage: Fixed on the latest nightly, labels: +E-needs-test

Discussion:
<ins> #![feature(generic_const_exprs)] #![allow(incomplete_features)] impl EntriesBuffer { fn a(&self) -> impl Iterator { self.0.iter_mut() //~ ERROR: cannot borrow `*self.0` as mutable, as it is behind a `&` reference } } struct EntriesBuffer(Box<[[u8; HashesEntryLEN]; 5]>); //~^ ERROR: cannot find value `HashesEntryLEN` in this scope fn main() {} </ins>

<ins> error[E0425]: cannot find value `HashesEntryLEN` in this scope --> $DIR/issue-109141.rs:10:32 | LL | struct EntriesBuffer(Box<[[u8; HashesEntryLEN]; 5]>); |                                ^^^^^^^^^^^^^^ not found in this scope | help: you might be missing a const parameter | LL | struct EntriesBuffer<const HashesEntryLEN: /* Type */>(Box<[[u8; HashesEntryLEN]; 5]>); |                     ++++++++++++++++++++++++++++++++++ error[E0596]: cannot borrow `*self.0` as mutable, as it is behind a `&` reference --> $DIR/issue-109141.rs:6:9 | LL |         self.0.iter_mut() |         ^^^^^^^^^^^^^^^^^ `self` is a `&` reference, so the data it refers to cannot be borrowed as mutable | help: consider changing this to be a mutable reference | LL |     fn a(&mut self) -> impl Iterator { |          ~~~~~~~~~ error: aborting due to 2 previous errors Some errors have detailed explanations: E0425, E0596. For more information about an error, try `rustc --explain E0425`. </ins>
Change:
This is a fuzzed test case, found with and minimized with . I wasn't able to find any similar issues: : <details<summary<strongBacktrace</strong</summary<p</p</details
This is related to , do we need to keep this ICE or we cover it at here:
The assert was in If you have a reproducer, then it can be to and the assert can be removed.
label +S-bug-has-mcve

Discussion:
} else { LifetimeUseSet::Many }), <del> LifetimeRibKind::Generics { .. } => None, LifetimeRibKind::ConstGeneric | LifetimeRibKind::AnonConst => { </del> <ins> LifetimeRibKind::Generics { .. } | LifetimeRibKind::ConstGeneric => None, LifetimeRibKind::AnonConst => { </ins> span_bug!(ident.span, "unexpected rib kind: {:?}", rib.kind) } })

//~^ ERROR missing lifetime specifier //~| ERROR `S<'_>` is forbidden as the type of a const generic parameter <ins> trait Foo<'a> {} struct Bar<const N: &'a (dyn for<'a> Foo<'a>)>; //~^ ERROR use of non-static lifetime `'a` in const generic //~| ERROR `&dyn for<'a> Foo<'a>` is forbidden as the type of a const generic parameter </ins> fn main() {}

LL | fn d<'a, const C: S<'a>>() {} |      +++           ++++ <ins> error[E0771]: use of non-static lifetime `'a` in const generic --> $DIR/unusual-rib-combinations.rs:29:22 | LL | struct Bar<const N: &'a (dyn for<'a> Foo<'a>)>; |                      ^^ | = note: for more information, see issue #74052 <https://github.com/rust-lang/rust/issues/74052> </ins> error[E0214]: parenthesized type parameters may only be used with a `Fn` trait --> $DIR/unusual-rib-combinations.rs:7:16 |

= note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` <del> error: aborting due to 7 previous errors </del> <ins> error: `&dyn for<'a> Foo<'a>` is forbidden as the type of a const generic parameter --> $DIR/unusual-rib-combinations.rs:29:21 | LL | struct Bar<const N: &'a (dyn for<'a> Foo<'a>)>; |                     ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: the only supported types are integers, `bool` and `char` = help: more complex types are supported with `#![feature(adt_const_params)]` error: aborting due to 9 previous errors </ins> <del> Some errors have detailed explanations: E0106, E0214, E0308. </del> <ins> Some errors have detailed explanations: E0106, E0214, E0308, E0771. </ins> For more information about an error, try `rustc --explain E0106`.
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
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve

Discussion:
Erroneous code example: ```compile_fail,E0577,edition2018 <del> pub struct Sea; </del> <ins> pub enum Sea {} </ins> pub (in crate::Sea) struct Shark; // error!

}; match self.r.resolve_path( &segments, <del> Some(TypeNS), </del> <ins> None, </ins> parent_scope, finalize.then(|| Finalize::new(id, path.span)), None,

<ins> // Check that we do not ICE due to unresolved segments in visibility path. #![crate_type = "lib"] extern crate alloc as b; mod foo { mod bar { pub(in b::string::String::newy) extern crate alloc as e; //~^ ERROR failed to resolve: `String` is a struct, not a module [E0433] } } </ins>

<ins> error[E0433]: failed to resolve: `String` is a struct, not a module --> $DIR/unresolved-segments-visibility.rs:8:27 | LL |         pub(in b::string::String::newy) extern crate alloc as e; |                           ^^^^^^ `String` is a struct, not a module error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>

struct S<T>(T); m!{ S<u8> } //~ ERROR unexpected generic arguments in path <del> //~| ERROR expected module, found struct `S` </del> <ins> //~| ERROR failed to resolve: `S` is a struct, not a module [E0433] </ins> mod m { m!{ m<> } //~ ERROR unexpected generic arguments in path

LL | m!{ S<u8> } |      ^^^^ <del> error[E0577]: expected module, found struct `S` </del> <ins> error[E0433]: failed to resolve: `S` is a struct, not a module </ins> --> $DIR/visibility-ty-params.rs:6:5 | LL | m!{ S<u8> } <del> |     ^^^^^ not a module </del> <ins> |     ^ `S` is a struct, not a module </ins> error: unexpected generic arguments in path --> $DIR/visibility-ty-params.rs:10:10

error: aborting due to 3 previous errors <del> For more information about this error, try `rustc --explain E0577`. </del> <ins> For more information about this error, try `rustc --explain E0433`. </ins>

<del> error[E0433]: failed to resolve: `Self` is only available in impls, traits, and type definitions </del> <ins> error[E0433]: failed to resolve: `Self` cannot be used in imports </ins> --> $DIR/use-self-type.rs:7:16 | LL |         pub(in Self::f) struct Z; <del> |                ^^^^ `Self` is only available in impls, traits, and type definitions </del> <ins> |                ^^^^ `Self` cannot be used in imports </ins> error[E0432]: unresolved import `Self` --> $DIR/use-self-type.rs:6:13