jiebi/CodeConvo huggingface dataset:
Change:
<ins> # ignore-windows include ../tools.mk all: echo 'mod unknown;' | $(RUSTC) --crate-type rlib - >$(TMPDIR)/unknown-mod.stdout 2>$(TMPDIR)/unknown-mod.stderr || echo "failed successfully" # Bless like this: RUSTC_BLESS_TEST=1 ./x.py test tests/run-make/unknown-mod-stdin ifdef RUSTC_BLESS_TEST cp "$(TMPDIR)"/unknown-mod.stdout unknown-mod.stdout cp "$(TMPDIR)"/unknown-mod.stderr unknown-mod.stderr else $(DIFF) unknown-mod.stdout "$(TMPDIR)"/unknown-mod.stdout $(DIFF) unknown-mod.stderr "$(TMPDIR)"/unknown-mod.stderr endif </ins>

Discussion:
Missing external modules don't report a build error when a crate is built from stdin. Expected: When parsing an external submodule from stdin, a compiler error (or warning) is emitted noting that external submodules are not supported for stdio crates. Actual: No diagnostics are emitted and an empty submodule is implicitly inserted. Generally if a statement references a file which does not exist, an E0583 compile error will be emitted. However, when building a crate from stdin, no relative filesystem is present, yet no compile errors are emitted, even with explicit attributes. Instead they are implicitly substituted with empty inline modules. I'm not super familiar with rustc, so this might not be handy, but I'm guessing this is caused by the flag being unset when parsing from a string rather than a file ( - rather than trying to access the filesystem or emit an error during the parse.
This was fixed in nightly-2020-03-20, probably by I don't think this is worth adding a regression test for this TBH, so I think we should simply close this issue. It remains fixed in current stable (1.71).
On a second thought the right way to close this issue is probably by writing a regression test after all. Otherwise the bug can re-appear. I was being too lazy. Edit: Fix: label E-needs-test
Change:
pub fn target() -> Target { let mut base = super::dragonfly_base::opts(); <ins> base.cpu = "x86-64".to_string(); </ins> base.pre_link_args.push("-m64".to_string()); Target {

Discussion:
By default, we use the "generic" target CPU, unfortunately on x8664, this disables various features because "generic" is more like "generic x86". This disable things like some SSE usage and multibyte nops. On x8664 we should use as the minimum target cpu, not sure about other archs. To present some arbitrary numbers: cc
To add some slightly more interesting numbers, these are for : generic: x86-64
Did your PR not resolve this?
It probably did for x84_64, but I'm not sure about x86 (I guess "generic" is like i386, which seems a bit too old a target), ARM, etc. Am 21.01.2015 23:33 schrieb "Alexis Beingessner"
Change:
// If the first pattern is an or-pattern, expand it. if let Some(vs) = v.expand_or_pat() { <del> // We need to push the already-seen patterns into the matrix in order to detect redundant // branches like `Some(_) | Some(0)`. We also keep track of the unreachable subpatterns. let mut matrix = matrix.clone(); // `Vec` of all the unreachable branches of the current or-pattern. let mut unreachable_branches = Vec::new(); // Subpatterns that are unreachable from all branches. E.g. in the following case, the last // `true` is unreachable only from one branch, so it is overall reachable. </del> <ins> // We expand the or pattern, trying each of its branches in turn and keeping careful track // of possible unreachable sub-branches. // // If two branches have detected some unreachable sub-branches, we need to be careful. If // they were detected in columns that are not the current one, we want to keep only the // sub-branches that were unreachable in _all_ branches. Eg. in the following, the last // `true` is unreachable in the second branch of the first or-pattern, but not otherwise. // Therefore we don't want to lint that it is unreachable. </ins> // // ``` // match (true, true) {

Discussion:
The match remains exhaustive with highlighted pattern removed, but it does not produce any warnings: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I know where the problem comes from: this bit of code tries to handle unreachable sub-or-patterns diagnostics, but it's a bit of a hack. What remains is to come up with a better solution. claim
Change:
_ => None, } } <ins> // we check the validity of params elsewhere Target::Param => return false, </ins> _ => None, } { return err_fn(meta.span(), &format!("isn't allowed on {}", err));

Discussion:
<!-- 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
ICE only appears since 1.52. label regression-from-stable-to-stable
Better-looking code example Bisection points to
Reading the descriptions, I’d guess most likely , cc
This is indeed caused by since we're now checking parameters unlike before. The issue is in when . The call to panics because there is no name for a param. The question I have is whether we should support params for doc aliases. I didn't find anything in the tracking issue to indicate that it was supposed to be supported, and I personally don't think it makes sense. If we decide to not support doc aliases for params, then it should be an easy change to to error when is a . cc
Doc aliases are only supported for items showing up in doc search, function parameters don't, so in this case, it should error on the doc alias attribute.
Do you want to send a fix or should I?
I'll submit a fix.
Thanks! Please ping me on it (and don't forget to add a test for it too ;) ).
Change:
<del> //@ known-bug: #120600 #![feature(never_type)] #![feature(never_type_fallback)] #[derive(Ord, Eq, PartialOrd, PartialEq)] enum E { Foo, Bar(!, i32, i32), } fn main() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution', 'error: internal compiler error: broken MIR in DefId(0:20 ~ o[fbbd]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move 23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !): NoSolution' File: --snippet: Version information Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: error: internal compiler error: broken MIR in DefId(0:20 ~ mvce[954a]::{impl}::eq) (Terminator { sourceinfo: SourceInfo { span: 7:10 (), scope: scope[3] }, kind: 21 = <! as PartialEq::eq(move 22, move _23) -[return: bb9, unwind: bb18] }): bad arg (&'?38 ! <- !

): NoSolution --
Regression in nightly-2023-05-23 commit[0] 2023-05-21: Auto merge of - MU001999:fix/issue-, r=cjgillot commit[1] 2023-05-21: Auto merge of - Zoxc:query-structs-trim, r=cjgillot commit[2] 2023-05-22: Auto merge of - lukas-code:strike, r=notriddle commit[3] 2023-05-22: Auto merge of - the8472:filter-map-chunk, r=thomcc commit[4] 2023-05-22: Auto merge of - matthiaskrgr:rollup-qd4b2vu, r=matthiaskrgr commit[5] 2023-05-22: Auto merge of - Jules-Bertholet:document-pin-layout, r=thomcc commit[6] 2023-05-22: Auto merge of - compiler-errors:triple-check, r=Nilstrieb commit[7] 2023-05-22: Auto merge of - marc0246:arc-new-uninit-bloat, r=thomcc commit[8] 2023-05-22: Auto merge of - lcnr:recursion-depth, r=matthewjasper commit[9] 2023-05-22: Auto merge of - Dylan-DPC:rollup-7jqydzg, r=Dylan-DPC ERROR: no CI builds available between and within last 167 days cc
Minimized:
Minimized even more: (I independently found the same bug while running crater with the fallback being )
Change:
<ins> // compile-flags: --document-private-items #![feature(decl_macro)] // @has decl_macro_priv/macro.crate_macro.html //pre 'pub(crate) macro crate_macro() {' // @has - //pre '...' // @has - //pre '}' pub(crate) macro crate_macro() {} // @has decl_macro_priv/macro.priv_macro.html //pre 'macro priv_macro() {' // @!has - //pre 'pub macro priv_macro() {' // @has - //pre '...' // @has - //pre '}' macro priv_macro() {} </ins>

Discussion:
See for []: ! But when you click on : Or for []: ! With source: Or for [], which is not a built-in: ! []: []: []: modify labels: T-rustdoc C-bug
Related:
I have a hunch that and are both represented as and/or .
Cc
I would experiment to see if that is what's causing it, but I'm waiting on a build for something else
https://rustc-dev-
Wow, I never noticed that! That's so cool :)
Indeed, changing changed the output. See if you can notice my experimental change ;) ! And for a built-in: !
Change:
hir::ExprKind::Closure(&hir::Closure { ref fn_decl, body, fn_decl_span, kind, .. }) => { <del> // FIXME(coroutines): This doesn't handle coroutines correctly </del> let cx = match kind { <del> hir::ClosureKind::Coroutine(hir::CoroutineKind::Desugared( hir::CoroutineDesugaring::Async, hir::CoroutineSource::Block, )) => AsyncClosure(fn_decl_span), </del> <ins> hir::ClosureKind::Coroutine(hir::CoroutineKind::Desugared(kind, source)) => { Coroutine { coroutine_span: fn_decl_span, kind, source } } </ins> _ => Closure(fn_decl_span), }; self.visit_fn_decl(fn_decl);

Discussion:
Same issue as which was for blocks. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
docs = MarkdownSummaryLine(&doc_value, &myitem.links(cx)).into_string(), class = myitem.type_(), add = add, <del> stab = stab.unwrap_or_else(String::new), </del> <ins> stab = stab.unwrap_or_default(), </ins> unsafety_flag = unsafety_flag, href = item_path(myitem.type_(), &myitem.name.unwrap().as_str()), title = [full_path(cx, myitem), myitem.type_().to_string()]

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim
Change:
use super::linker::{self, Linker}; use super::rpath::{self, RPathConfig}; use crate::{ <del> looks_like_rust_object_file, CodegenResults, CompiledModule, CrateInfo, METADATA_FILENAME, </del> <ins> looks_like_rust_object_file, CodegenResults, CompiledModule, CrateInfo, NativeLib, METADATA_FILENAME, </ins> }; use cc::windows_registry;

Discussion:
<!-- 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 command: I expected to see this happen: An file is generated. Instead, this happened: <!-- 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. --: Originally posted by in cc (original implementer of
PR changed the encode/decode method of . When was implemented, the encode/decode of was purposely crafted to avoid calling the encode/decode method of . The most straightforward fix is to implement / for to allow it be serialized outside of metadata. After that, may be now it is the time to re-think the way we store data in the file. What do you think ?
I think should completely be avoided in the input of the linker function. One of the uses if in it's field. This field doesn't seem to be used by the linking code.
Good suggestion, let me look into it.
are you still working on this?
Thank you for reminding and apologize for the delay. I did create a prototype but haven't got a chance polish it yet. I'll create the PR this week.
Sorry again about the delay. I've created PR , which fixes this issue.
Change:
<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>

Discussion:
<!-- 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:
Change:
.span_label(span, "cannot break inside of a closure") .emit(); } <ins> AsyncClosure => { struct_span_err!(self.sess, span, E0267, "`{}` inside of an async block", name) .span_label(span, "cannot break inside of an async block") .emit(); } </ins> Normal | AnonConst => { struct_span_err!(self.sess, span, E0268, "`{}` outside of loop", name) .span_label(span, "cannot break outside of a loop")

Discussion:
With: you get: Note how it references "a closure" which seems confusing for a user who doesn't presume the implementation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I'm assuming its ok to leave this as the same error code of E0267 - in essence it's the same error, just more specific text.
Yeah I think it's fine.
Change:
} let guar = diag.emit(); <del> if should_recover { ty::Binder::dummy(fn_sig) } else { ty::Binder::dummy(tcx.mk_fn_sig( fn_sig.inputs().iter().copied(), Ty::new_error(tcx, guar), fn_sig.c_variadic, fn_sig.unsafety, fn_sig.abi, )) } </del> <ins> ty::Binder::dummy(tcx.mk_fn_sig( fn_sig.inputs().iter().copied(), recovered_ret_ty.unwrap_or_else(|| Ty::new_error(tcx, guar)), fn_sig.c_variadic, fn_sig.unsafety, fn_sig.abi, )) </ins> } None => icx.lowerer().lower_fn_ty( hir_id,

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: Unexpected coroutine/closure type in variance computation', 'error: internal compiler error: Unexpected coroutine/closure type in variance computation' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [cratevariances] computing the variances for items in this crate [variancesof] computing the variances of [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
smaller
ice since it seems
i can look into this claim
Change:
} crate fn build_external_trait(cx: &mut DocContext<'_>, did: DefId) -> clean::Trait { <del> let trait_items = cx.tcx.associated_items(did).in_definition_order().map(|item| item.clean(cx)).collect(); </del> <ins> let trait_items = cx .tcx .associated_items(did) .in_definition_order() .map(|item| { // When building an external trait, the cleaned trait will have all items public, // which causes methods to have a `pub` prefix, which is invalid since items in traits // can not have a visibility prefix. Thus we override the visibility here manually. // See https://github.com/rust-lang/rust/issues/81274 clean::Item { visibility: Visibility::Inherited, ..item.clean(cx) } }) .collect(); </ins> let predicates = cx.tcx.predicates_of(did); let generics = (cx.tcx.generics_of(did), predicates).clean(cx);

Discussion:
The trait on 1.49.0 (current stable) doesn't contain modifier in function declaration of that trait. ! However, on and nightly, there is modifier. ! This is wrong because you cannot use modifier for each method/function in Trait definition. Why is this important? People copy the method/function declaration in the documentation to their code and see the compiler error: . : cc I think this might relate to some changes in visibility around macros ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Yes, this needs the same fix as (in particular should work).
Self-assigning because this is a beta regression.
Note that this also occurs for the impl's docs.
Removed since this was fixed.
, trait methods still rendered as : ! Is there something wrong to Rust release or the bug still exists ?
Hmm, maybe it was only fixed for items in the local crate. do you have time to come up with an MCVE? I expect it's related to cross-crate re-exports.
Your guess sounds right. With core link (), things are normal.
I don't think I'll have time to fix this second part soon, so unassigning myself.
Assigning and removing as in the prioritization working group.
Removing E-mentor + E-easy labels since we don't have guides for cross-crate linking: label -E-easy -E-mentor
I think is the cross-crate case.
Fix backported to 1.50.0 and landed in 1.51.0, closing this.
Please reopen. The issue is not entirely fixed for cross-crate trait reexport case.
The cross-crate issue is now on stable. label: +regression-from-stable-to-stable -regression-from-stable-to-beta
claim
Change:
ty::FnDef(_, _) => { // Zero-sized type, nothing to do. } <del> ty::Bool | ty::Int(_) | ty::Uint(_) | ty::Float(_) | ty::Char => { </del> <ins> ty::Bool | ty::Int(_) | ty::Uint(_) | ty::Float(_) | ty::Char | ty::RawPtr(..) => { </ins> let scalar_int = valtree.unwrap_leaf(); debug!("writing trivial valtree {:?} to place {:?}", scalar_int, place); ecx.write_immediate(Immediate::Scalar(scalar_int.into()), place).unwrap();

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: shouldn't have created a ValTree for const NoDerive', 'error: internal compiler error: shouldn't have created a ValTree for const NoDerive' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [valtreetoconstval] converting type-level constant value to mir constant value [mirdropselaboratedandconstchecked] elaborating drops for [analysis] running analysis passes on this crate --
Regression in cc
Should be fixed by
label -needs-triage
Change:
item }); <del> return vec![Annotatable::Item(item)]; </del> <ins> let ret = if is_stmt { Annotatable::Stmt(P(ecx.stmt_item(item.span, item))) } else { Annotatable::Item(item) }; vec![ret] </ins> } pub fn expand_test(

Discussion:
This happens when a test function is declared inside another function, the one where the tests start running to be precise, using a custom testing framework in a nostd environment. link: at lines: 31 [function declared outside] , 40 [comment of function declared inside] I checked with the latest version of the nightly channel, and could not find any related issues <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Running on your current master branch () doesn't reproduce the issue for me, all tests pass.
That is because the section causing the issue is commented out, if you remove function27 (dont mind the name) from and replace the comment from the function init() in with function27, it should reproduce the issue (just checked again) ! I shouldve pushed and linked a version that reproduces the issue, my bad
I'm able to reproduce this with nightly <details<summary<stronglong file</strong</summary<p</p</details
Got it down to this: using (see ).
claim
Change:
<ins> // compile-flags: -Wrust-2021-incompatible-closure-captures pub struct A {} impl A { async fn create(path: impl AsRef<std::path::Path>)  { //~ ERROR  `async fn` is not permitted in Rust 2015 //~^ WARN changes to closure capture in Rust 2021 will affect drop order [rust_2021_incompatible_closure_captures] ; crate(move || {} ).await //~ ERROR expected function, found module `crate` } } trait C{async fn new(val: T) {} //~ ERROR  `async fn` is not permitted in Rust 2015 //~^ ERROR functions in traits cannot be declared `async` //~^^ ERROR cannot find type `T` in this scope //~^^^ WARN changes to closure capture in Rust 2021 will affect drop order [rust_2021_incompatible_closure_captures] //~ ERROR  this file contains an unclosed delimiter </ins>

Discussion:
Works even with calling just - no need for a project, and does not need as a dependency in . Bug exists on 1.59, 1.60, beta and nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Do you have a codebase that can be shared instead? Unfortunately, it's kinda difficult to investigate this without seeing what triggered the ICE.
might be a duplicate of
I tried my hands at minimizing this, and it turned out way easier than I thought. Updated the original comment with reproduction code.
I subscribed to this thread for curiosity about ICEs on . Here's a smaller crashing program using
Managed to minimize it more:
you might be right, especially after I narrowed down the reproduction code.

<!-- 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 reduced 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
another example: `