Question: <ins> // check-pass trait Identity<Q> { type T; } impl<Q, T> Identity<Q> for T { type T = T; } trait Holds { type Q; } struct S; struct X(S); struct XHelper; impl Holds for X { type Q = XHelper; } impl<Q> Clone for X where <S as Identity<Q>>::T: Clone, X: Holds<Q = Q>, { fn clone(&self) -> Self { Self(self.0.clone()) } } fn main() {} </ins>

Trying to emulate trivial bounds via generics & associated types panics on stable, beta and nightly. <!-- 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. --: Reproducible on 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Bug is not present in 1.51 and appears in 1.52. More precisely, it appeared somewhere between and .
Seems like introduces the regression Probably is the culprit
It seems to affect only traits that are checked by . Changing to fixes the panic.
I wonder if this could be fixed by normalizing the caller-bounds when checking for trivial bounds in WF. Hmm.... might think about this issue later tonight.
I'm putting up a PR soon to fix a whole bunch of impossible-bounds related things. So I'll claim this for the time being. claim


Question: .any(|build_llvm_ourselves| build_llvm_ourselves); let need_cmake = building_llvm || build.config.any_sanitizers_enabled(); if need_cmake { <del> cmd_finder.must_have("cmake"); </del> <ins> if cmd_finder.maybe_have("cmake").is_none() { eprintln!( " Couldn't find required command: cmake You should install cmake, or set `download-ci-llvm = true` in the `[llvm]` section section of `config.toml` to download LLVM rather than building it. " ); std::process::exit(1); } </ins> } build.config.python = build

I tried to build on a new machine. Got this message: Which I'm used to. I googled a bit, installed , figured out how to get PATH set up, et cetera. Then I built again. And got this: I'm not sure, but: Isn't solely necessary in our build for building LLVM? if that's the case, then shouldn't both the failure and the failure be providing the same level of feedback (namely, suggesting that one side-step building LLVM altogether as an alternative option to downloading and installing )? (Or is the assumption here that will be used by so many crates, people should just bite bullet and install it? Even so, we could give better guidance up front about where to look for it.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I don't think cmake intentionally has a worse error, it's just that a bunch of people building from source for the first time have been confused what ninja is and where to get it. If you made a PR improving the error for cmake I'd approve it :)
label: +E-easy
claim
Hello I'd like to claim this issue if you're interested in releasing it.
Sorry about that Gave it a try but got sidetracked and wasn't really interested in doing it anymore
claim


Question: <ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags:--no-defaults --passes strip-priv-imports // aux-build:empty.rs // ignore-cross-compile // @has issue_27104/index.html // @!has - 'extern crate std' // @!has - 'use std::prelude::' // @has - 'pub extern crate empty' pub extern crate empty; </ins>

Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?


Question: let attrs = self.tcx.hir().attrs(hir_id); for attr in attrs { match attr.path().as_slice() { <del> [sym::diagnostic, sym::do_not_recommend] => { </del> <ins> [sym::diagnostic, sym::do_not_recommend, ..] => { </ins> self.check_do_not_recommend(attr.span, hir_id, target) } <del> [sym::diagnostic, sym::on_unimplemented] => { </del> <ins> [sym::diagnostic, sym::on_unimplemented, ..] => { </ins> self.check_diagnostic_on_unimplemented(attr.span, hir_id, target) } <del> [sym::inline] => self.check_inline(hir_id, attr, span, target), [sym::coverage] => self.check_coverage(attr, span, target), [sym::optimize] => self.check_optimize(hir_id, attr, target), [sym::non_exhaustive] => self.check_non_exhaustive(hir_id, attr, span, target), [sym::marker] => self.check_marker(hir_id, attr, span, target), [sym::target_feature] => { </del> <ins> [sym::inline, ..] => self.check_inline(hir_id, attr, span, target), [sym::coverage, ..] => self.check_coverage(attr, span, target), [sym::optimize, ..] => self.check_optimize(hir_id, attr, target), [sym::non_exhaustive, ..] => self.check_non_exhaustive(hir_id, attr, span, target), [sym::marker, ..] => self.check_marker(hir_id, attr, span, target), [sym::target_feature, ..] => { </ins> self.check_target_feature(hir_id, attr, span, target, attrs) } <del> [sym::thread_local] => self.check_thread_local(attr, span, target), [sym::track_caller] => { </del> <ins> [sym::thread_local, ..] => self.check_thread_local(attr, span, target), [sym::track_caller, ..] => { </ins> self.check_track_caller(hir_id, attr.span, attrs, span, target) } <del> [sym::doc] => self.check_doc_attrs( </del> <ins> [sym::doc, ..] => self.check_doc_attrs( </ins> attr, hir_id, target, &mut specified_inline, &mut doc_aliases, ), <del> [sym::no_link] => self.check_no_link(hir_id, attr, span, target), [sym::export_name] => self.check_export_name(hir_id, attr, span, target), [sym::rustc_layout_scalar_valid_range_start] | [sym::rustc_layout_scalar_valid_range_end] => { </del> <ins> [sym::no_link, ..] => self.check_no_link(hir_id, attr, span, target), [sym::export_name, ..] => self.check_export_name(hir_id, attr, span, target), [sym::rustc_layout_scalar_valid_range_start, ..] | [sym::rustc_layout_scalar_valid_range_end, ..] => { </ins> self.check_rustc_layout_scalar_valid_range(attr, span, target) } <del> [sym::allow_internal_unstable] => { </del> <ins> [sym::allow_internal_unstable, ..] => { </ins> self.check_allow_internal_unstable(hir_id, attr, span, target, attrs) } <del> [sym::debugger_visualizer] => self.check_debugger_visualizer(attr, target), [sym::rustc_allow_const_fn_unstable] => { </del> <ins> [sym::debugger_visualizer, ..] => self.check_debugger_visualizer(attr, target), [sym::rustc_allow_const_fn_unstable, ..] => { </ins> self.check_rustc_allow_const_fn_unstable(hir_id, attr, span, target) } <del> [sym::rustc_std_internal_symbol] => { </del> <ins> [sym::rustc_std_internal_symbol, ..] => { </ins> self.check_rustc_std_internal_symbol(attr, span, target) } <del> [sym::naked] => self.check_naked(hir_id, attr, span, target, attrs), [sym::rustc_never_returns_null_ptr] => { </del> <ins> [sym::naked, ..] => self.check_naked(hir_id, attr, span, target, attrs), [sym::rustc_never_returns_null_ptr, ..] => { </ins> self.check_applied_to_fn_or_method(hir_id, attr, span, target) } <del> [sym::rustc_legacy_const_generics] => { </del> <ins> [sym::rustc_legacy_const_generics, ..] => { </ins> self.check_rustc_legacy_const_generics(hir_id, attr, span, target, item) } <del> [sym::rustc_lint_query_instability] => { </del> <ins> [sym::rustc_lint_query_instability, ..] => { </ins> self.check_rustc_lint_query_instability(hir_id, attr, span, target) } <del> [sym::rustc_lint_diagnostics] => { </del> <ins> [sym::rustc_lint_diagnostics, ..] => { </ins> self.check_rustc_lint_diagnostics(hir_id, attr, span, target) } <del> [sym::rustc_lint_opt_ty] => self.check_rustc_lint_opt_ty(attr, span, target), [sym::rustc_lint_opt_deny_field_access] => { </del> <ins> [sym::rustc_lint_opt_ty, ..] => self.check_rustc_lint_opt_ty(attr, span, target), [sym::rustc_lint_opt_deny_field_access, ..] => { </ins> self.check_rustc_lint_opt_deny_field_access(attr, span, target) } <del> [sym::rustc_clean] | [sym::rustc_dirty] | [sym::rustc_if_this_changed] | [sym::rustc_then_this_would_need] => self.check_rustc_dirty_clean(attr), [sym::rustc_coinductive] | [sym::rustc_must_implement_one_of] | [sym::rustc_deny_explicit_impl] | [sym::const_trait] => self.check_must_be_applied_to_trait(attr, span, target), [sym::cmse_nonsecure_entry] => { </del> <ins> [sym::rustc_clean, ..] | [sym::rustc_dirty, ..] | [sym::rustc_if_this_changed, ..] | [sym::rustc_then_this_would_need, ..] => self.check_rustc_dirty_clean(attr), [sym::rustc_coinductive, ..] | [sym::rustc_must_implement_one_of, ..] | [sym::rustc_deny_explicit_impl, ..] | [sym::const_trait, ..] => self.check_must_be_applied_to_trait(attr, span, target), [sym::cmse_nonsecure_entry, ..] => { </ins> self.check_cmse_nonsecure_entry(hir_id, attr, span, target) } <del> [sym::collapse_debuginfo] => self.check_collapse_debuginfo(attr, span, target), [sym::must_not_suspend] => self.check_must_not_suspend(attr, span, target), [sym::must_use] => self.check_must_use(hir_id, attr, target), [sym::rustc_pass_by_value] => self.check_pass_by_value(attr, span, target), [sym::rustc_allow_incoherent_impl] => { </del> <ins> [sym::collapse_debuginfo, ..] => self.check_collapse_debuginfo(attr, span, target), [sym::must_not_suspend, ..] => self.check_must_not_suspend(attr, span, target), [sym::must_use, ..] => self.check_must_use(hir_id, attr, target), [sym::rustc_pass_by_value, ..] => self.check_pass_by_value(attr, span, target), [sym::rustc_allow_incoherent_impl, ..] => { </ins> self.check_allow_incoherent_impl(attr, span, target) } <del> [sym::rustc_has_incoherent_inherent_impls] => { </del> <ins> [sym::rustc_has_incoherent_inherent_impls, ..] => { </ins> self.check_has_incoherent_inherent_impls(attr, span, target) } <del> [sym::ffi_pure] => self.check_ffi_pure(attr.span, attrs, target), [sym::ffi_const] => self.check_ffi_const(attr.span, target), [sym::rustc_const_unstable] | [sym::rustc_const_stable] | [sym::unstable] | [sym::stable] | [sym::rustc_allowed_through_unstable_modules] | [sym::rustc_promotable] => self.check_stability_promotable(attr, target), [sym::link_ordinal] => self.check_link_ordinal(attr, span, target), [sym::rustc_confusables] => self.check_confusables(attr, target), [sym::rustc_safe_intrinsic] => { </del> <ins> [sym::ffi_pure, ..] => self.check_ffi_pure(attr.span, attrs, target), [sym::ffi_const, ..] => self.check_ffi_const(attr.span, target), [sym::rustc_const_unstable, ..] | [sym::rustc_const_stable, ..] | [sym::unstable, ..] | [sym::stable, ..] | [sym::rustc_allowed_through_unstable_modules, ..] | [sym::rustc_promotable, ..] => self.check_stability_promotable(attr, target), [sym::link_ordinal, ..] => self.check_link_ordinal(attr, span, target), [sym::rustc_confusables, ..] => self.check_confusables(attr, target), [sym::rustc_safe_intrinsic, ..] => { </ins> self.check_rustc_safe_intrinsic(hir_id, attr, span, target) } <del> [sym::cold] => self.check_cold(hir_id, attr, span, target), [sym::link] => self.check_link(hir_id, attr, span, target), [sym::link_name] => self.check_link_name(hir_id, attr, span, target), [sym::link_section] => self.check_link_section(hir_id, attr, span, target), [sym::no_mangle] => self.check_no_mangle(hir_id, attr, span, target), [sym::deprecated] => self.check_deprecated(hir_id, attr, span, target), [sym::macro_use] | [sym::macro_escape] => { </del> <ins> [sym::cold, ..] => self.check_cold(hir_id, attr, span, target), [sym::link, ..] => self.check_link(hir_id, attr, span, target), [sym::link_name, ..] => self.check_link_name(hir_id, attr, span, target), [sym::link_section, ..] => self.check_link_section(hir_id, attr, span, target), [sym::no_mangle, ..] => self.check_no_mangle(hir_id, attr, span, target), [sym::deprecated, ..] => self.check_deprecated(hir_id, attr, span, target), [sym::macro_use, ..] | [sym::macro_escape, ..] => { </ins> self.check_macro_use(hir_id, attr, target) } <del> [sym::path] => self.check_generic_attr(hir_id, attr, target, Target::Mod), [sym::macro_export] => self.check_macro_export(hir_id, attr, target), [sym::ignore] | [sym::should_panic] => { </del> <ins> [sym::path, ..] => self.check_generic_attr(hir_id, attr, target, Target::Mod), [sym::macro_export, ..] => self.check_macro_export(hir_id, attr, target), [sym::ignore, ..] | [sym::should_panic, ..] => { </ins> self.check_generic_attr(hir_id, attr, target, Target::Fn) } <del> [sym::automatically_derived] => { </del> <ins> [sym::automatically_derived, ..] => { </ins> self.check_generic_attr(hir_id, attr, target, Target::Impl) } <del> [sym::no_implicit_prelude] => { </del> <ins> [sym::no_implicit_prelude, ..] => { </ins> self.check_generic_attr(hir_id, attr, target, Target::Mod) } <del> [sym::rustc_object_lifetime_default] => self.check_object_lifetime_default(hir_id), [sym::proc_macro] => { </del> <ins> [sym::rustc_object_lifetime_default, ..] => self.check_object_lifetime_default(hir_id), [sym::proc_macro, ..] => { </ins> self.check_proc_macro(hir_id, target, ProcMacroKind::FunctionLike) } <del> [sym::proc_macro_attribute] => { </del> <ins> [sym::proc_macro_attribute, ..] => { </ins> self.check_proc_macro(hir_id, target, ProcMacroKind::Attribute); } <del> [sym::proc_macro_derive] => { </del> <ins> [sym::proc_macro_derive, ..] => { </ins> self.check_generic_attr(hir_id, attr, target, Target::Fn); self.check_proc_macro(hir_id, target, ProcMacroKind::Derive) } <del> [sym::coroutine] => { </del> <ins> [sym::coroutine, ..] => { </ins> self.check_coroutine(attr, target); } [

<!-- ICE: Rustc '' 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ', 'error: internal compiler error: builtin attribute "shouldpanic" not handled by ' 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: [checkmodattrs] checking attributes in top-level module [analysis] running analysis passes on this crate --
there are a bunch more which probably all follow the pattern... 2 "errorreason": "error: internal compiler error: builtin attribute "allow" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cfgattr" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "cfg" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "cmsenonsecureentry" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "collapsedebuginfo" not handled by ", 6 "errorreason": "error: internal compiler error: builtin attribute "deny" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "doc" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "inline" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "macroexport" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "optimize" not handled by ", 4 "errorreason": "error: internal compiler error: builtin attribute "procmacroderive" not handled by ", 14 "errorreason": "error: internal compiler error: builtin attribute "procmacro" not handled by ", 2 "errorreason": "error: internal compiler error: builtin attribute "shouldpanic" not handled by ",
cc
Taking a look
Problem is the previous match falls through to the fallback case for etc. because it has 1 segments ... and then since et al. is a attribute, it triggers the ICE.
I have a candidate fix locally, doing some more testing
Opened as a candidate fix.


Question: [[package]] name = "libgit2-sys" <del> version = "0.10.0" </del> <ins> version = "0.11.0+0.99.0" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "d9ec6bca50549d34a392611dde775123086acbd994e3fff64954777ce2dc2e51" </del> <ins> checksum = "4d5d1459353d397a029fb18862166338de938e6be976606bd056cf8f1a912ecf" </ins> dependencies = [ "cc", "libc",

Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.


Question: /// /// # Safety /// <del> /// The resulting pointer does not need to be in bounds, but it is /// potentially hazardous to dereference (which requires `unsafe`). </del> <ins> /// This operation itself is always safe, but using the resulting pointer is not. </ins> /// <del> /// In particular, the resulting pointer remains attached to the same allocated /// object that `self` points to. It may *not* be used to access a /// different allocated object. Note that in Rust, /// every (stack-allocated) variable is considered a separate allocated object. </del> <ins> /// The resulting pointer remains attached to the same allocated object that `self` points to. /// It may *not* be used to access a different allocated object. Note that in Rust, every /// (stack-allocated) variable is considered a separate allocated object. </ins> /// <del> /// In other words, `x.wrapping_offset((y as usize).wrapping_sub(x as usize) / size_of::<T>())` /// is *not* the same as `y`, and dereferencing it is undefined behavior /// unless `x` and `y` point into the same allocated object. </del> <ins> /// In other words, `let z = x.wrapping_offset((y as isize) - (x as isize))` does *not* make `z` /// the same as `y` even if we assume `T` has size `1` and there is no overflow: `z` is still /// attached to the object `x` is attached to, and dereferencing it is Undefined Behavior unless /// `x` and `y` point into the same allocated object. </ins> /// <del> /// Compared to [`offset`], this method basically delays the requirement of staying /// within the same allocated object: [`offset`] is immediate Undefined Behavior when /// crossing object boundaries; `wrapping_offset` produces a pointer but still leads /// to Undefined Behavior if that pointer is dereferenced. [`offset`] can be optimized /// better and is thus preferable in performance-sensitive code. </del> <ins> /// Compared to [`offset`], this method basically delays the requirement of staying within the /// same allocated object: [`offset`] is immediate Undefined Behavior when crossing object /// boundaries; `wrapping_offset` produces a pointer but still leads to Undefined Behavior if a /// pointer is dereferenced when it is out-of-bounds of the object it is attached to. [`offset`] /// can be optimized better and is thus preferable in performance-sensitive code. /// /// The delayed check only considers the value of the pointer that was dereferenced, not the /// intermediate values used during the computation of the final result. For example, /// `x.wrapping_offset(o).wrapping_offset(o.wrapping_neg())` is always the same as `x`. In other /// words, leaving the allocated object and then re-entering it later is permitted. </ins> /// /// If you need to cross object boundaries, cast the pointer to an integer and /// do the arithmetic there.

whether pointer arithmetic is allowed to - temporarily - leave the bounds of an object, then go back into bounds and afterwards dereference the pointer. The question is if code like this: is sound or unsound. The current documentation says: So it specifies that the resulting pointer “remains attached to the same allocated object that points to”, which suggests that after going back into bounds, dereferencing should be safe again. It also says “this method basically delays the requirement of staying within the same allocated object; ” which sounds like, staying within the same allocated object is still a requirement, which could be interpreted as that whenever any intermediate value did not stay within bounds, that intermediate value has some delayed violation of requirements attached to it that triggers UB once the final (back in bounds) pointer is dereferenced. The following comparison, “ / / is immediate Undefined Behavior when crossing object boundaries; / / produces a pointer but still leads to Undefined Behavior if that pointer is dereferenced” can easily be interpreted as confirming this interpretation, since object boundaries are crossed (twice, first going out of the object, then going back in) and the pointer is dereference afterwards (right after the second crossing of object boundaries). After I was addressing this , gave the answer modify labels: T-doc, T-libs, T-lang, C-enhancement Feel free to remove a label if this doesn’t seem relevant for that team.
Ah I see... yeah that is a misunderstanding. The delayed check means that when the (derived) ptr is dereferenced, that ptr needs to be in-bounds, but the intermediate ptrs do not have to be.


Question: let _: &dyn BuildHasher<Hasher = DefaultHasher> = &RandomState::new(); } <ins> // just tests by whether or not this compiles fn _build_hasher_default_impl_all_auto_traits<T>() { use std::panic::{RefUnwindSafe, UnwindSafe}; fn all_auto_traits<T: Send + Sync + Unpin + UnwindSafe + RefUnwindSafe>() {} all_auto_traits::<std::hash::BuildHasherDefault<T>>(); } </ins>

Right.. is my own PR; I'm noting this as an issue, mainly so I won't forget this, because I won't do this myself right now / today. Or someone else can do this if they want. I'm not 100% certain where the best place for such a test to go is, and/or whether it makes sense to have them in one place or separated and more close to the respective type's definition. A test to prevent any future regression removing the new auto trait implementations introduced by can look about as follows <s` </sEdit: This code is needlessly complicated, see my comment below. label C-enhancement, A-testsuite, E-easy, E-needs-test, T-libs <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI, somehow I missed the more straightforward way of writing these.


Question: } // handled in the `strip-priv-imports` pass <del> clean::ExternCrateItem { .. } | clean::ImportItem(..) => {} </del> <ins> clean::ExternCrateItem { .. } => {} clean::ImportItem(ref imp) => { // Because json doesn't inline imports from private modules, we need to mark // the imported item as retained so it's impls won't be stripped.i // // FIXME: Is it necessary to check for json output here: See // https://github.com/rust-lang/rust/pull/100325#discussion_r941495215 if let Some(did) = imp.source.did && self.is_json_output { self.retained.insert(did.into()); } } </ins> clean::ImplItem(..) => {}

<!-- 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. --Given a public type, I expected all traits implemented by that type to be part of rustdoc JSON output. However, rustdoc JSON output sometimes does not include information about all the traits implemented by a type unless is specified. For example, in this : The following invocation on v3.1.18 generates JSON stating that is implemented for : However, the following invocation has no mention of for at all: Related to: :
cc
modify labels: +E-needs-mcve
Interestingly, rustdoc-json is providing no impls at all: norunn# use clap::{Command, Arg};nlet matches = Command::new("MyApp")n .arg(Arg::new("out")n .long("output")n .required(true)n .takesvalue(true))n .arg(Arg::new("debug")n .short('d')n .multipleoccurrences(true))n .arg(Arg::new("cfg")n .short('c')n .takesvalue(true))n .getmatches(); // builds the instance of ArgMatchesnn// to get information about the "cfg" argument we created, such as the value supplied we usen// various ArgMatches methods, such as ArgMatches::valueofnif let Some(c) = matches.valueof("cfg") {n println!("Value for -c: {}", c);n}nn// The ArgMatches::valueof method returns an Option because the user may not have suppliedn// that argument at runtime. But if we specified that the argument was "required" as we didn// with the "out" argument, we can safely unwrap because verifies that was actuallyn// used at runtime.nprintln!("Value for --output: {}", matches.valueof("out").unwrap());nn// You can check the presence of an argumentnif matches.ispresent("out") {n // Another way to check if an argument was present, or if it occurred multiple times is ton // use occurrencesof() which returns 0 if an argument isn't found at runtime, or then // number of times that it occurred, if it was.


Question: } // handled in the `strip-priv-imports` pass <del> clean::ExternCrateItem { .. } | clean::ImportItem(..) => {} </del> <ins> clean::ExternCrateItem { .. } => {} clean::ImportItem(ref imp) => { // Because json doesn't inline imports from private modules, we need to mark // the imported item as retained so it's impls won't be stripped.i // // FIXME: Is it necessary to check for json output here: See // https://github.com/rust-lang/rust/pull/100325#discussion_r941495215 if let Some(did) = imp.source.did && self.is_json_output { self.retained.insert(did.into()); } } </ins> clean::ImplItem(..) => {}

To allow an argument to appear more thann // once, you must use the .multipleoccurrences(true) method, otherwise it will only return 1 or 0.n if matches.occurrences_of("debug") 2 {n println!("Debug mode is REALLY on, don't be crazy");n } else {n println!("Debug mode kind of on");n }n}n
Missing impls is probably a recent regression, see
MCVE produces () and with () modify labels: -E-needs-mcve
This is almost certanly due to searched nightlies: from nightly-2022-07-01 to nightly-2022-08-08 regressed nightly: nightly-2022-07-17 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: </details
More minimal (no_core) Is correct in html ! and wrong in json


Question: } // handled in the `strip-priv-imports` pass <del> clean::ExternCrateItem { .. } | clean::ImportItem(..) => {} </del> <ins> clean::ExternCrateItem { .. } => {} clean::ImportItem(ref imp) => { // Because json doesn't inline imports from private modules, we need to mark // the imported item as retained so it's impls won't be stripped.i // // FIXME: Is it necessary to check for json output here: See // https://github.com/rust-lang/rust/pull/100325#discussion_r941495215 if let Some(did) = imp.source.did && self.is_json_output { self.retained.insert(did.into()); } } </ins> clean::ImplItem(..) => {}

running produces this record for the type : I would expect "impls" to not be blank, since the matrix implements many traits and has a non-trait implementation as well. The paths entry also does not contain as well as many other types exported by the crate, is this expected ? I know that these paths included all exported types before : :
Now running with produces: So i think there's been a regression since then
Thank you for reporting labels +A-rustdoc-json +T-rustdoc
Seems like this could be another symptom of the regression reported as
This is the same issue as Items in a non-public module (ie accessed only via imports) have no impls


Question: --> $DIR/issue-17800.rs:18:28 | LL |         MyOption::MySome { x: 42 } => (), <del> |                            ^^^^^ variant `MyOption::MySome` does not have this field </del> <ins> |                            ^^^^^ |                            | |                            variant `MyOption::MySome` does not have this field |                            help: did you mean: `0` </ins> <del> error[E0027]: pattern does not mention field `0` --> $DIR/issue-17800.rs:18:9 | LL |         MyOption::MySome { x: 42 } => (), |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ missing field `0` | = note: trying to match a tuple variant with a struct variant pattern error: aborting due to 2 previous errors </del> <ins> error: aborting due to previous error </ins> <del> Some errors occurred: E0026, E0027. For more information about an error, try `rustc --explain E0026`. </del> <ins> For more information about this error, try `rustc --explain E0026`. </ins>

With a single typo in a match arm, we generate three separate errors: We should collect all these errors into a single diagnostic:
could you share sample code to exactly reproduce above diagnostic?
I will raise another PR to address the case where we are unnecessarily throwing .


Question: ``` "##, <del> //NB: not currently reachable E0247: r##" This error indicates an attempt to use a module name where a type is expected. For example: ``` mod MyMod { mod MySubMod { } } fn do_something(x: MyMod::MySubMod) { } ``` In this example, we're attempting to take a parameter of type `MyMod::MySubMod` in the do_something function. This is not legal: `MyMod::MySubMod` is a module name, not a type. "##, </del> E0248: r##" This error indicates an attempt to use a value where a type is expected. For example:

rustc crashes when compiling the following source code. I expect this to compile or report error. Instead the compiler crashed.
Reduced testcase:
This also causes an ICE with the latest nightly:
Any update on the issue. Please let me know if you need more information. Thanks


Question: return; } <ins> let self_contained_linker = sess.opts.cg.link_self_contained.linker(); // FIXME: some targets default to using `lld`, but users can only override the linker on the CLI // and cannot yet select the precise linker flavor to opt out of that. See for example issue // #113597 for the `thumbv6m-none-eabi` target: a driver is used, and its default linker // conflicts with the target's flavor, causing unexpected arguments being passed. // // Until the new `LinkerFlavor`-like CLI options are stabilized, we only adopt MCP510's behavior // if its dedicated unstable CLI flags are used, to keep the current sub-optimal stable // behavior. let using_mcp510 = self_contained_linker || sess.opts.cg.linker_flavor.is_some_and(|f| f.is_unstable()); if !using_mcp510 && !unstable_use_lld { return; } </ins> // 1. Implement the "self-contained" part of this feature by adding rustc distribution //    directories to the tool's search path. <del> let self_contained_linker = sess.opts.cg.link_self_contained.linker() || unstable_use_lld; if self_contained_linker { </del> <ins> if self_contained_linker || unstable_use_lld { </ins> for path in sess.get_tools_search_paths(false) { cmd.arg({ let mut arg = OsString::from("-B");

The CI tests building with all our supported linkers: Rust's provided , ARM GCC's , and ARM GCC's . It recently encountered an error when using in nightly builds since . The most likely culprit is that the failing version has started to the linker arguments, which was not present in previous working versions. I wonder if we're meant to be adding some other argument to disable adding ? The error occurs with the cortex-m-rt CI and can be reproduced like so: Or viewed in CI . The error is: nightly-2023-07-02 nightly-2023-07-03 bisected to from PR modify labels: +regression-from-stable-to-nightly -regression-untriaged
shows that the default for the target is rust-lld. i wonder if the new code uses the default instead of the linker in -C linker for some reason?
You were not meant to do anything, sorry about that. I'll fix it.
I can't build a toolchain locally, via , which would be complete enough for this test to build. There are issues about missing core/std. I tried on a example, and can also reproduce the issue and investigate more there, and that and work. The code I in is asked to add CLI arguments for a flavor: this asks to link using via a c/c++ compiler, and why is . I assume that flavor is incorrect when using ? (I don't know who the target maintainers are, so I'll also ping the other 2 people involved in : and still work because they result in a non- request, and we don't do anything there as expected. For my own understanding: does use by default maybe ? And if so, I'd expect that explicitly specifying the linker would also fix the issue, à la which seems to work for me ? I'll look into why this surprising flavor is used in this situation, as it seems to be the pre-existing issue here uncovered by the PR, and report back. It could be an issue in the flavor inference, or some information missing in the targets' definitions, and so on.
Technically, the target builds. As a tier 2 target, we would strongly prefer it to not require additional antics to build. There was but I have taken lqd's remarks that this may be just exposed preexisting problems as a reason to set it slightly lower.


Question: return; } <ins> let self_contained_linker = sess.opts.cg.link_self_contained.linker(); // FIXME: some targets default to using `lld`, but users can only override the linker on the CLI // and cannot yet select the precise linker flavor to opt out of that. See for example issue // #113597 for the `thumbv6m-none-eabi` target: a driver is used, and its default linker // conflicts with the target's flavor, causing unexpected arguments being passed. // // Until the new `LinkerFlavor`-like CLI options are stabilized, we only adopt MCP510's behavior // if its dedicated unstable CLI flags are used, to keep the current sub-optimal stable // behavior. let using_mcp510 = self_contained_linker || sess.opts.cg.linker_flavor.is_some_and(|f| f.is_unstable()); if !using_mcp510 && !unstable_use_lld { return; } </ins> // 1. Implement the "self-contained" part of this feature by adding rustc distribution //    directories to the tool's search path. <del> let self_contained_linker = sess.opts.cg.link_self_contained.linker() || unstable_use_lld; if self_contained_linker { </del> <ins> if self_contained_linker || unstable_use_lld { </ins> for path in sess.get_tools_search_paths(false) { cmd.arg({ let mut arg = OsString::from("-B");

The linker flavor used is a mix between what can be inferred from the CLI () and the target's default linker flavor: there is no linker flavor on the CLI (and that also offers another workaround on nightly: ), so it will have to be inferred to . in  infers a cc hint, and no hint about lld. the target's is combined in with these hints. We have our , but there is no hint about lld, . It's . so we now have our flavor is the linker people are expected to use on supposed to be some ? Is the default linker and flavor in correct ? In the meantime, I'll see to change this so that the lld flags are only when the unstable MCP510 options are used, to keep this stable and unfortunate behavior unchanged when the CLI and target conflict instead of compose.
Thanks for looking into this quickly! Most people building for will use the default linker today. It works fine for (I believe) all Rust-only projects. However, it's not uncommon to use , maybe to use specific GCC linker script directives, or just when hunting down linker-related bugs. For both of those use cases there's no problem with nightly, and I think the default in thumb_base is therefore fine. Some people do need to use when linking with pre-compiled C libraries - I understand that using gcc pulls in a target specific libc, and a lot of pre-compiled C libraries will be trying to link against symbols it exports which Rust doesn't. I believe does delegate to . Passing either or does work to get a build without errors, though I don't have a test case handy to check it's actually getting what people need out of . I'll try and dig around a bit more for the specific use cases where it's required over .
My main recollection is that gcc requires you to put in front of your linker arguments and using ld directly you don't But I think and friends are gcc options not ld options so maybe ld won't bring in libc and the C startup automatically. I'll test it out shortly.
main.c: Compile object code: Link with GCC: Link with ld: This does imply that for trivial invocations will include both the default start code (which provides ) and newlib (the C library), whilst will not.


Question: return; } <ins> let self_contained_linker = sess.opts.cg.link_self_contained.linker(); // FIXME: some targets default to using `lld`, but users can only override the linker on the CLI // and cannot yet select the precise linker flavor to opt out of that. See for example issue // #113597 for the `thumbv6m-none-eabi` target: a driver is used, and its default linker // conflicts with the target's flavor, causing unexpected arguments being passed. // // Until the new `LinkerFlavor`-like CLI options are stabilized, we only adopt MCP510's behavior // if its dedicated unstable CLI flags are used, to keep the current sub-optimal stable // behavior. let using_mcp510 = self_contained_linker || sess.opts.cg.linker_flavor.is_some_and(|f| f.is_unstable()); if !using_mcp510 && !unstable_use_lld { return; } </ins> // 1. Implement the "self-contained" part of this feature by adding rustc distribution //    directories to the tool's search path. <del> let self_contained_linker = sess.opts.cg.link_self_contained.linker() || unstable_use_lld; if self_contained_linker { </del> <ins> if self_contained_linker || unstable_use_lld { </ins> for path in sess.get_tools_search_paths(false) { cmd.arg({ let mut arg = OsString::from("-B");

See also , where I set the default target for bare-metal SPARC to be gcc, precisely because the default libraries it links in are so useful - they include not only the start-up code (no idea how that works, didn't need to find out) but also a C library for talking to the stdout of a popular SPARC CPU emulator. So, yeah, GCC is a really useful linker driver in some scenarios and we don't want to stop that from working.
Thanks for the information, it's very helpful. The good news is that using GCC as a linker is still working . In the future where we switch to lld, maybe rustc will also need an explicit linker flavor here, to make sure the flavor it guesses actually matches your expectations. But that's a topic for another day/stabilization: in the more immediate future, things will return to normal for the target and 's tests in a day or two.
Thank you! Just to come back to this point: I was under the impression that Arm Ltd were maintaining the targets. However, they don't appear to have the platform-support documentation that is required for more recently targets. Maybe that could be addressed.
This is now on beta, reopening to track backport.
Pursuant to your concern I have opened to summarize the issue that affects indeed all our tier 2 targets.
The backport of has landed on beta in We can close this issue as fixed.


Question: .next() .map_or(false, |c| c.is_ascii_uppercase()) { <del> (format!("use of undeclared type `{}`", ident), None) </del> <ins> // Check whether the name refers to an item in the value namespace. let suggestion = if ribs.is_some() { let match_span = match self.resolve_ident_in_lexical_scope( ident, ValueNS, parent_scope, None, path_span, &ribs.unwrap()[ValueNS], ) { // Name matches a local variable. For example: // ``` // fn f() { //     let Foo: &str = ""; //     println!("{}", Foo::Bar); // Name refers to local //                               // variable `Foo`. // } // ``` Some(LexicalScopeBinding::Res(Res::Local(id))) => { Some(*self.pat_span_map.get(&id).unwrap()) } // Name matches item from a local name binding // created by `use` declaration. For example: // ``` // pub Foo: &str = ""; // // mod submod { //     use super::Foo; //     println!("{}", Foo::Bar); // Name refers to local //                               // binding `Foo`. // } // ``` Some(LexicalScopeBinding::Item(name_binding)) => { Some(name_binding.span) } _ => None, }; if let Some(span) = match_span { Some(( vec![(span, String::from(""))], format!("`{}` is defined here, but is not a type", ident), Applicability::MaybeIncorrect, )) } else { None } } else { None }; (format!("use of undeclared type `{}`", ident), suggestion) </ins> } else { (format!("use of undeclared crate or module `{}`", ident), None) }

The following code... the following error and warning: The warning says that is not used but it clearly is, just not properly. This error is normally easier to spot when using the proper casing for constants, but that might not always be the case. Perhaps in this instance, we should look for other items with the exact same name and point out that the user is trying to use a constant as a type. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Every single one of these errors should point at similarly named things of the wrong namespace.
Do you know where in the code this is coming from?
running the following will tell you where the error is being emitted: From there the place you might want to start looking at is , which is a bit hard to follow at the moment (I'm doing a slight clean up of that method at the moment), but should be reasonably straight forward to add another check for this case to that pile :)
claim
Can I take this issue?
Yes feel free to take it, I removed my assignment.
I’m going to be tied up until May, feel free to take this issue:pray:
Hey I'm looking to get to know the Rust codebase better and contribute to the project - would love to take a crack at this issue!
claim


Question: <ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] // Check that we don't crash when printing inherent projections in diagnostics. pub struct Carrier<'a>(&'a ()); pub type User = for<'b> fn(Carrier<'b>::Focus<i32>); impl<'a> Carrier<'a> { pub type Focus<T> = &'a mut User; //~ ERROR overflow evaluating associated type } fn main() {} </ins>

<!-- 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 --
cc is this fixed by one of your PRs? This looked like it might be , but while was bisected to this one was bisected to , not sure what to make of it :thinking:
Yes, this issue is fixed in (ice → errors): <details<summarystderr</summary</detailsI'm not sure why the bisection points differ, they all share the same root cause. It doesn't really matter though. Btw, I saw about another new reproducer but I dismissed it as irrelevant since I assumed it required , too (I did run it but didn't notice I could omit that flag). Sorry about that. Thanks for opening a separate issue because now we actually have 2 beautiful regression tests for the bug fixed in ! So let's not close this issue then but wait for to get merged and then I will open a separate PR with the regression tests & assign you. claim


Question: <ins> warning: the feature `lazy_type_alias` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/alias-bounds-when-not-wf.rs:3:12 | LL | #![feature(lazy_type_alias)] |            ^^^^^^^^^^^^^^^ | = note: see issue #112792 <https://github.com/rust-lang/rust/issues/112792> for more information = note: `#[warn(incomplete_features)]` on by default error: the type `W<A<usize>>` is not well-formed --> $DIR/alias-bounds-when-not-wf.rs:16:13 | LL | fn hello(_: W<A<usize>>) {} |             ^^^^^^^^^^^ error: aborting due to 1 previous error; 1 warning emitted </ins>

<!-- ICE: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'', 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc


Question: use std::path::{Path, PathBuf}; use std::process::Command; <del> use build_helper::ci::CiEnv; </del> use tracing::*; use crate::common::{Config, Debugger, FailMode, Mode, PassMode};

I tried this code: and I expected to see this happen: All tests passing. No doc tests running when using 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The tests pass for me and they're passing in CI. So I suspect there is something about your system that differs from mine and CI. Can you post the contents of your ?
Also, could you share how these tests are failing? Failing tests usually explain why their stderr differs from expected, or otherwise explain why the test happened to fail.
Hi there, I just did a fresh clone and got the same failures (target x86_64-unknown-linux-gnu). The file has not been changed. The test pass when I used my Mac device. The test each have "The actual stderr differed from the expected stderr." The actual stderr seems to have extra lines " full type name has been written to.." which are not in the expected stderr. Could that be the cause of the failure? If so, what can a fix look like? Full output on terminal:
is your copy of rust cloned into some really deep directory path? like... ? the problem is that your tests are failing because your build is producing type names that hit the length limit and are spilled to disk, and that file limit is dependent (unfortunately) on the path that the rust clone is located at...
we should probably fix this so that UI tests don't spill any long type names to disk by default. We could do this by adding a compiler flag that disables this behavior, and enable that flag by default in the ui testing suite.
this is a great idea — if we do this, we should also remove the code that enables remap-path-prefix in CI.
I can reproduce this locally by cloning under a long path. I would like to work on this. I'll take a look to see if I can identify where we have the logic for spilling the type names to disk, and guard it with a flag. I'll ask questions if I have trouble with that.


Question: use std::path::{Path, PathBuf}; use std::process::Command; <del> use build_helper::ci::CiEnv; </del> use tracing::*; use crate::common::{Config, Debugger, FailMode, Mode, PassMode};

claim
alternatively, we could gate it under the existing flag
I have code that works for this, but there are some tests under that seem to actually test specifically this behaviour of spilling to disk. So I'm thinking, under we skip spilling to disk, unless there is another flag, enabled, in which case we spill long type names to disk so that logic can be tested as well. Thoughts?
Two examples I found where we are testing the long type name spilling behaviour: with
:+1: this seems good. i would bikeshed the name as and uncouple it from (i.e. compiletest would start passing instead of you changing the behavior of ), but i like the idea :)
I have a pull-request for this, but I'm getting an error in the CI pipeline that I haven't dug too deep into, was wondering if there is a simple explanation for this? Thanks
The pull-request is going through well, but I'm now wondering about this part: Do you mean to basically revert this pull-request:
Pull-request to remove remap-path-prefix code for CI builds:


Question: <ins> pub struct Option; impl Option { pub fn unwrap(self) {} } mod macros { use crate::Option; /// [`Option::unwrap`] #[macro_export] macro_rules! print { () => () } } mod structs { use crate::Option; /// [`Option::unwrap`] pub struct Print; } pub use structs::Print; </ins>

I tried to create a minimum example from an issue we've seen in our project (). I tried running: On the following crate: : I expected to see this happen: The command should succeed. Instead, this happened: It crashed with an ICE <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<p</p</details
This issue may be related to , however I can only reproduce it on the nightly build. On the stable channel, rustdoc succeeds.
cc
does this reproduce on beta?
I know I'm not celinval, but I've been able to reduce this to a test case, and yeah, it reproduces on beta.
That was quick. Thank you!
Reopening to track beta breakage.
I was silly and nominated even though the PR has already been nominated, and that's really the thing that's supposed to be. Please ignore, and sorry for the noise.


Question: <ins> // check-pass // edition:2021 use std::rc::Rc; // Test that we restrict precision when moving not-`Copy` types, if any of the parent paths // implement `Drop`. This is to ensure that we don't move out of a type that implements Drop. pub fn test1() { struct Foo(Rc<i32>); impl Drop for Foo { fn drop(self: &mut Foo) {} } let f = Foo(Rc::new(1)); let x = move || { println!("{:?}", f.0); }; x(); } // Test that we don't restrict precision when moving `Copy` types(i.e. when copying), // even if any of the parent paths implement `Drop`. pub fn test2() { struct Character { hp: u32, name: String, } impl Drop for Character { fn drop(&mut self) {} } let character = Character { hp: 100, name: format!("A") }; let c = move || { println!("{}", character.hp) }; c(); println!("{}", character.name); } fn main() {} </ins>

I tried this code: This does not issue a warning for , however it fails to compile with enabled: I would expect to give a suggestion to add . Found in the 2021 crater run for: I'm uncertain if this is a duplicate of or , they seem very similar, but this case is specific to implementing Drop. : cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim


Question: <ins> error[E0428]: the name `f` is defined multiple times --> $DIR/test-compile-fail1.rs:8:1 | 6 | pub fn f() {} | ---------- previous definition of the value `f` here 7 | 8 | pub fn f() {} | ^^^^^^^^^^ `f` redefined here | = note: `f` must be defined only once in the value namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>

I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.


Question: <ins> error[E0428]: the name `f` is defined multiple times --> $DIR/test-compile-fail1.rs:8:1 | 6 | pub fn f() {} | ---------- previous definition of the value `f` here 7 | 8 | pub fn f() {} | ^^^^^^^^^^ `f` redefined here | = note: `f` must be defined only once in the value namespace of this module error: aborting due to previous error For more information about this error, try `rustc --explain E0428`. </ins>

I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.


Question: target_val!(data_layout); target_option_val!(is_builtin); <del> target_option_val!(endian, "target_endian"); target_option_val!(c_int_width, "target_c_int_width"); </del> <ins> target_option_val!(endian, "target-endian"); target_option_val!(c_int_width, "target-c-int-width"); </ins> target_option_val!(os); target_option_val!(env); target_option_val!(vendor);

Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)


Question: infer::IfExpression(_) => { format!("if and else have compatible types") } <ins> infer::IfExpressionWithNoElse(_) => { format!("if may be missing an else clause") } </ins> }; match self.values_str(&trace.values) {

I apologize in advance if this is a separate issue. With the map() generic function from the tutorial: That code gives a nice error message: However, remove the assignment and what should be the same error message becomes:
Yes, that is unrelated to this issue. You're seeing an expected type mismatch error since the return type of main() is () and your samples result in two different non-() results.
Thanks I was one hour into learning Rust when I came across this. I understand what is going on now. I still think the error message could be improved to mention that "expected " is referring to the return type of main(). That simple clue could help people not as familiar with Rust to remember the semicolon rule to turn a statement into an expression.
Not critical for 0.7, but improving error messages is always good. Nominating for milestone 5.
declined. this is bad but it's not a blocker.
Confirmed that the situation is unchanged.
This is still an issue.
Bug triage. Still an issue.
Very, very small change:


Question: -include ../tools.mk <del> # This test makes sure that indirect call promotion is performed. The test # programs calls the same function a thousand times through a function pointer. # Only PGO data provides the information that it actually always is the same # function. We verify that the indirect call promotion pass inserts a check # whether it can make a direct call instead of the indirect call. # LLVM doesn't support instrumenting binaries that use SEH: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMMON_FLAGS=-Cpanic=abort endif </del> all: # We don't compile `opaque` with either optimizations or instrumentation. # We don't compile `opaque` with either optimizations or instrumentation.

LLVM's "IR-level" instrumentation, which is used by to generate PGO instrumented binaries, does not yet work with exception handling on Windows MSVC. The problem has been reported to LLVM for C++ here: This also affects Rust programs built with for Windows MSVC. As long as LLVM does not support exception handling there, it is a known limitation that PGO can only be used with on this platform.
PGO does not yet work on for other reasons (see ). Once it does, we should check if this problem is specific to MSVC.
I have working x86_64 windows-gnu (64 bit builds use SEH) build with PGO I'll open PR once is merged. I can do testing in meantime. FWIW simple hello world example works fine after going through PGO.
if you test, be sure to compile your LLVM with assertions: Thanks for looking into it!
I'll recompile it with assertions today later. Should the test case be using any specific code like ?
The following test case runs into the problem with MSVC: See for how the file is compiled.
It does not reproduce with gnu toolchain with Rust and LLVM assertions enabled, I'll try to remember about fixing along with gnu profiler.
Cool!
I just confirmed that (for me locally) PGO seems to work on Windows GNU. That is, I built with instrumentation, ran it, and rebuilt it with the profiling data collected. It worked just fine, no crashes. So I updated the original issue text to just mention MSVC instead of Windows in general.
It looks like is a bit too aggressive with its error reporting. For example when invoking rustc, but not compiling in our Firefox build we can the following : I'm not sure the best solution while mw is away; perhaps we should revert for now.
Maybe we can just convert the error to a warning?
Not the best long-term solution but seems ok
It looks like the was marked fixed a year ago. What's the status of this issue in rustc?


Question: _marker: PhantomData<&'f mut &'f c_void>, } <ins> /// s390x ABI implementation of a `va_list`. #[cfg(target_arch = "s390x")] #[repr(C)] #[derive(Debug)] #[unstable( feature = "c_variadic", reason = "the `c_variadic` feature has not been properly tested on  all supported platforms", issue = "44930" )] #[lang = "va_list"] pub struct VaListImpl<'f> { gpr: i64, fpr: i64, overflow_arg_area: *mut c_void, reg_save_area: *mut c_void, _marker: PhantomData<&'f mut &'f c_void>, } </ins> /// x86_64 ABI implementation of a `va_list`. #[cfg(all(target_arch = "x86_64", not(target_os = "uefi"), not(windows)))] #[repr(C)]

fails this test on native : (This is not a new failure, but I am cleaning up issues from downstream Red Hat bugzilla.)
We started discussing this in , and looking at the clang implementation here: I tried that minimal step with , but it still gives the same "Cannot select" error. I don't see any lowering of in like other targets, only stuff implementing the calling convention. So I guess we do need custom support, or perhaps the clang bits could be moved down into the LLVM lowering?
Hi , I ran into the same problem and noticed you had already opened an issue. I've now submitted a PR to implement valist and vaarg for s390x to fix this.


Question: // memmove back untouched tail, update to new length let start = source_vec.len(); let tail = self.tail_start; <del> let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); </del> <ins> if tail != start { let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); } </ins> source_vec.set_len(start + self.tail_len); } }

The build time of html5ever has gone up by more than 70% for debug builds recently: There are quite a few candidates for introducing this regression in the changeset: Would anybody from or care to bisect further?
The "tuple stress" benchmark is affected even more while most of the other things have improved. Maybe that gives a hint?
My first guess would be quadratic or exponential blowup. Maybe someone can do a ?
Yes, good idea!
Bisection for tuple-stress points to (cc Before that PR took ~4s and afterwards I killed it after 2m as I didn't want to wait for it to finish
That may also be the source of the html5ever regression. takes 10s before that commit (the entire time) and 21s afterwards.
Thanks, cc also &
Could you post instructions for replicating the slow down? Neither or I could reproduce it -- despite running perf on the appropriate commit range locally.
So should we revert that PR's commits?
sure yeah, using I did the equivalent of:
We should probably only run the disaggregation pass if the opt level is 1. That's what's done for the copy prop pass already
assuming and can reproduce I think yeah we'll probably want to start off by reverting and possibly doing what suggests in a follow-up
I cannot reproduce, which is odd, since I can't tell what the difference could be that would make this much of a difference...
No repro on macOS, although the c116 version is consistently slower than a272. <details</details
Ok I swear I'm not going crazy! I think though given this data it may only be reproducible on Ubuntu 16.04? I can reproduce with this : Can y'all reproduce the slowdown for html5ever?
Sure enough starting the docker image from 18.04 means I cannot reproduce the regression. Maybe some glibc bug was fixed which I was accidentally running into? The html5ever regression though is still worrisome and seems like it may not be connected to a glibc bug
I can repro the tuple-stress slow down on 16.04.4 LTS. indicates it is stuck at the step.


Question: // memmove back untouched tail, update to new length let start = source_vec.len(); let tail = self.tail_start; <del> let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); </del> <ins> if tail != start { let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); } </ins> source_vec.set_len(start + self.tail_len); } }

<details<summaryGDB backtrace sample</summary</details<details<summaryCode surrounding the call of that memmove</summary</details
Presuming the same two commits would be responsible for the html5ever regression, I also cannot reproduce it on 18.04 Ubuntu.
Using this dockerfile: I can reproduce the regression from 10s to 20s on html5ever. Starting from 18.04 it does indeed not show a regression. The perf server is indeed 16.04. Ok so it looks like this is a regression specific to something that changed between glibc 2.23 and 2.27. With the profiles it looks like it's something related to the efficiency of memcpy/memmove. It also seems like this isn't reproducible on OSX (thanks ). I can, however, reproduce it locally on Windows 64-bit MSVC. Since could reproduce a slightly slowdown on OSX, I wonder if these code paths do something like exercise a ton of moves? It may be the case that glibc optimized one of its routines in the 2.23 -2.27 transition (and OSX already had it). In that case it may appear like there's no regression on Linux/OSX but on glibc 2.23 and Windows they may have unoptimized versions of the routines causing slowdowns. All in all I think that this is a regression that is still worth fixing, despite it not immediately being applicable on glibc 2.27 or OSX. The fact that it affects somewhat-recent versions of Ubuntu and Windows is enough for me.
Isn't glibc 2.27 the version released after the spectre/meltdown/whatever fixes that slow (primarily Intel but to a lesser extent AMD as well) systems down?
No sorry glibc 2.27 is just what I tested. I've now narrowed it down (conveniently) to glibc 2.23 and 2.24. Ubuntu 16.04 ships with 2.23 and 16.10 ships with 2.24. On 2.24 I'm seeing a faster compilation Perusing the it looks like may be why we're not seeing the regression in newer Linux
Ok I've found the source of the regression, will post a PR soon.
It's a pleasure watching you folks work!


Question: // memmove back untouched tail, update to new length let start = source_vec.len(); let tail = self.tail_start; <del> let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); </del> <ins> if tail != start { let src = source_vec.as_ptr().offset(tail as isize); let dst = source_vec.as_mut_ptr().offset(start as isize); ptr::copy(src, dst, self.tail_len); } </ins> source_vec.set_len(start + self.tail_len); } }

I've posted what I believe is a fix to
triage: P-high Has pending fix.


Question: // if a test does not crash, consider it an error if proc_res.status.success() || matches!(proc_res.status.code(), Some(1 | 0)) { self.fatal(&format!( <del> "crashtest no longer crashes/triggers ICE, horray! Please give it a meaningful name,  add a doc-comment to the start of the test explaining why it exists and  move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR description  ensures that the corresponding ticket is auto-closed upon merge." </del> <ins> "crashtest no longer crashes/triggers ICE, horray! Please give it a meaningful  name, add a doc-comment to the start of the test explaining why it exists and  move it to tests/ui or wherever you see fit. Adding 'Fixes #<issueNr>' to your PR  description ensures that the corresponding ticket is auto-closed upon merge.  If you want to see verbose output, set `COMPILETEST_VERBOSE_CRASHES=1`." </ins> )); } }

E.g. if a test doesn't have a fn it can prevent the test from ICEing because ICEing codepath might not yet be reached before compilation is aborted. In this case, the stderr should be printed to help the person figure out that "I forgor to annotate crate type" is the cause.
you can set env var which should print stdout, stderr and exit code
Oh right, good point, I forgor this existed. We should (I'll do this later unless you want to work on it): Mention this env var in the panic message for when the crashes test no longer crash. () Mention this env var in rustc-dev-guide. () EDIT: ended up duplicating some description of ` in because I would not have thought to look there for docs specifically.


Question: // not covered via the Shared impl above b/c the inner contents use // Cell/AtomicUsize, but the usage here is recover safe so we can lift the // impl up one level to Arc/Rc itself <del> impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Rc<T> {} impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Arc<T> {} </del> <ins> impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Rc<T> {} impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Arc<T> {} </ins> <del> // Pretty simple implementations for the `NoUnsafeCell` marker trait, basically // just saying that this is a marker trait and `UnsafeCell` is the only thing // which doesn't implement it (which then transitively applies to everything // else. impl NoUnsafeCell for .. {} impl<T: ?Sized> !NoUnsafeCell for UnsafeCell<T> {} </del> <ins> // Pretty simple implementations for the `RefRecoverSafe` marker trait, // basically just saying that this is a marker trait and `UnsafeCell` is the // only thing which doesn't implement it (which then transitively applies to // everything else. impl RefRecoverSafe for .. {} impl<T: ?Sized> !RefRecoverSafe for UnsafeCell<T> {} impl<T> RefRecoverSafe for AssertRecoverSafe<T> {} </ins> impl<T> AssertRecoverSafe<T> { /// Creates a new `AssertRecoverSafe` wrapper around the provided type.

Test Case 1: Test Case 2: Both produce errors like this: CC
Hm, so the first case here should work (e.g. should subvert basically everything), although the second case is correct in yielding an error (albeit not a very good one)
Is the second case not allowed then? 's documentation suggests that manually implementing it is okay to do: I figured only existed to wrap types which you couldn't yourself, but for which you can ensure their invariants are upheld across the boundary. And what about moving values into the closure? can't be unwrapped, at least not currently.
Oh wait sorry I misread your second example, I failed to notice the manual ! This is basically a case where closure captures are coming into play. The closures aren't annotated with , so outer variables are captured by-reference which means that the actual types being tested against the trait here are and . In the first case that should be handled by , but the second is legitimately indicating that it's not a recover-safe type (b/c the reference is different than the by-value). You should be able to get around this via either plus or via . Certainly an interesting interaction going on here though. One would likely expect that if isn't recover safe that would fix the problem but it's likely what you really need to do is due to the way closures largely work.
There's , why not ? Coherence?
Nah unfortunately that'd defeat the purpose of the distinction. The type is itself recover safe, it's just that's not (so the distinction need to be there)
It's unfortunate that fails due to coherence or something like that:
Hm interesting, I guess yeah you'll be forced to move the reference inside the wrapper rather than having a reference to the wrapper
Is it possible to implement then? My use case can contain and friends but I'm guaranteeing that they're unobservable in user code after recovery because I immediately re-panic after escaping the FFI stack.
I guess I can just use once it's fixed :stuckouttongue:. I see your PR has been accepted so I'll look forward to trying it on tonight's nightly. When do the buildbots fire?
Yeah currently you can implement (being renamed to ) I believe (although I can't say I've tried). For now though yeah I'd recommend just using plus closures.


Question: // not covered via the Shared impl above b/c the inner contents use // Cell/AtomicUsize, but the usage here is recover safe so we can lift the // impl up one level to Arc/Rc itself <del> impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Rc<T> {} impl<T: NoUnsafeCell + ?Sized> RecoverSafe for Arc<T> {} </del> <ins> impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Rc<T> {} impl<T: RefRecoverSafe + ?Sized> RecoverSafe for Arc<T> {} </ins> <del> // Pretty simple implementations for the `NoUnsafeCell` marker trait, basically // just saying that this is a marker trait and `UnsafeCell` is the only thing // which doesn't implement it (which then transitively applies to everything // else. impl NoUnsafeCell for .. {} impl<T: ?Sized> !NoUnsafeCell for UnsafeCell<T> {} </del> <ins> // Pretty simple implementations for the `RefRecoverSafe` marker trait, // basically just saying that this is a marker trait and `UnsafeCell` is the // only thing which doesn't implement it (which then transitively applies to // everything else. impl RefRecoverSafe for .. {} impl<T: ?Sized> !RefRecoverSafe for UnsafeCell<T> {} impl<T> RefRecoverSafe for AssertRecoverSafe<T> {} </ins> impl<T> AssertRecoverSafe<T> { /// Creates a new `AssertRecoverSafe` wrapper around the provided type.

The PR is in but'll take a few hours at least to land.
the problem with moving at this point in time is that I call in different branches of a but I pass the same closed-over value to it; I can't do the branch in the closure because I need to do some FFI cleanup afterwards regardless of whether a panic happened or not (which also requires the closed-over value). It would help if derived and/or so I could reuse it without constructing a new value for each arm, but that would probably require some discussion because I don't know if it's safe or not. I'll probably just implement and fix the name after your PR drops. A quick check confirms that it works just fine. Thanks anyways!
Oh yeah we could totally add more traits like and to , there shouldn't be any safety concerns there.
Updating code to modern functions and traits in makes this compile, so I'm going to close.


Question: builder.install(&exe, &dst_bindir, 0o755); } <ins> // Copy libLLVM.so to the target lib dir as well, so the RPATH like // `$ORIGIN/../lib` can find it. It may also be used as a dependency // of `rustc-dev` to support the inherited `-lLLVM` when using the // compiler libraries. maybe_install_llvm_target(builder, target, &image); </ins> // Prepare the overlay let overlay = tmp.join("llvm-tools-overlay"); drop(fs::remove_dir_all(&overlay));

Since , has been distributed in the component in two locations: (presumably as a runtime dependency of ) (not sure, maybe for linking custom drivers?) likely belongs in the component, if the duplication can't be avoided <hr/The difference can be seen in these consecutive nightlies' components: has just the second maybe it's used via relative by ? separate codegen backends are gone, maybe we should just try removing it? first nightly to include has both copies All 3 of those files are identical (even across nightlies, yay for deterministic builds): One fascinating aspect is that the size only increases from to , despite alone being uncompressed, so compression is really helping. Even the only goes from to . (I'm using archive sizes from the and directory listings in , FWIW) <hr/This part of the build system seems relevant, but I'm not sure which of the two this creates: cc
cc -- you've touched code related to this a bunch recently I think, so maybe would have some time to investigate fixing this. I suspect we want to only ship one LLVM per tarball, at least, though ideally we would only have just the one LLVM library total as well.
Half-way through writing up this issue I realized the connection. I'd suggest we try to get rid of the copy and see what breaks, it's possible it's been dead weight for a while now. And only if we have to keep both for some odd reason, we'd move it to .
The purposely orders the tarred files so that similar filenames are adjacent in the compression stream, especially in hope of helping with such duplicate files. I think we may still want the copy for the odd cross-compiled tool using , but that definitely belongs in .
Is that... even possible? Is a per-target component in the same way is?
Yes it is -- try -- but I don't know if anyone really needs that...
Actually, can you try something like cross-compiling a copy of to , after deleting the per-target ? I suspect that it would actually run just fine on a host, because 's s should only really contain the information and maybe some object code that is missing (which we could get rid of if we kept MIR for everything but idk how feasible that is). That is, the result of linking against should still use at runtime, so in is unnecessary. But maybe I'm missing something.


Question: builder.install(&exe, &dst_bindir, 0o755); } <ins> // Copy libLLVM.so to the target lib dir as well, so the RPATH like // `$ORIGIN/../lib` can find it. It may also be used as a dependency // of `rustc-dev` to support the inherited `-lLLVM` when using the // compiler libraries. maybe_install_llvm_target(builder, target, &image); </ins> // Prepare the overlay let overlay = tmp.join("llvm-tools-overlay"); drop(fs::remove_dir_all(&overlay));

Like running the cross-compiled on a host without anything more than the component?
Hmm, I can't actually get cross-builds to work with . I this to : ... so it would pick that up from the sysroot. Trying to cross-compile i686, I get: I do have both i686 and x8664 builds of in the sysroot. I suspect the error is because the i686 build has different metadata than my host build, so it can't find the one it wants for the host. That may mean that is really tied to being used on the same host. It works if I just compile native x86_64 though. Then I tried removing the , and it gets essentially the same error as : AFAICS, building normal crates still works fine with that extra removed though. In short: Cross-compiling with seems broken -- maybe it should be shipped native-only. The only difference would be in the manifest created for rustup. Linking to crates will inherit , so that needs to be in the library path.
Ah, fascinating. What happens if you build such an executable and then remove the component entirely? Can it pick up the dylibs outside or does it hardcode the paths inside?
The final executable still isn't actually linked to LLVM, since it didn't need any of those symbols: I can run this with , which set , or even if I set that path myself. But doesn't work if we've removed that library, since needs itself.
Okay, it being dependent on makes sense. Overall, probably the safe thing to do would be to move the duplicate to , oh well.
Oh, also needs LLVM, and those binaries are installed in with RUNPATH . I guess they might be able to find the LLVM in anyway?


Question: COMPILE_FLAGS=-O -Ccodegen-units=1 -Cprofile-generate="$(TMPDIR)" <del> # LLVM doesn't yet support instrumenting binaries that use unwinding on MSVC: # https://github.com/rust-lang/rust/issues/61002 # # Things work fine with -Cpanic=abort though. ifdef IS_MSVC COMPILE_FLAGS+= -Cpanic=abort endif </del> all: $(RUSTC) $(COMPILE_FLAGS) --emit=llvm-ir test.rs # We expect symbols starting with "__llvm_profile_".


Question: } }; <del> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); </del> while let Some(def) = bfs_queue.pop_front() { for child in tcx.item_children(def).iter() { add_child(bfs_queue, child, def);

On nightly rustc (cargo) I get misleading expected type errors. If a crate has the same(?) type it is displayed instead of the std type. I tried this code: I expected to see this happen: (stable rust) Instead, this happened: (nightly) :
Confirming - broken on nightly (1.23), good on beta.
bisected across nightlys: bug was injected between and
Skimming output from , there are a number of different potential culprits. Rather than guess and "point fingers" right now, I'll just continue bisecting within that commit range.
This is recent enough that we should be able to run bisect-rust on it (cc
it is cc .
I'm a little surprised that this would be caused by that PR. I can push a revert but would like to first test locally to make sure that revert that PR will fix this.
I have misread 's statement. Your PR is not at fault, sorry. I'm doing another search further back to find the causing PR.
I tried it locally in the meantime and I can confirm it is not :)
Okay so the bug dates as far back as from September 2nd which is as close to the limit as I dare to go. So to the people in control, please, prolong the limit :).
suggests that the bug was introduced much more recently (11-08 to 11-09). Maybe the bisection script was wrong?
I should probably have read the original issue more closely :). sorry for pinging you! It seems to be cc
In particular, I have bisected it down to the commit: I have been trying to further dissect that commit to figure out why it causes the change we observe here. My current hypothesis (that I have not yet managed to confirm) is that it has to do with how we seed the hashmap's hashers with randomized state. (This commit changes our behavior in certain scenarios.) If this hypothesis is actually true, though, then I would think that this represents either a bug in hashmap itself, or a bug in how the compiler is using the hashmap...
Hmm. Its something more subtle than a hashmap-related bug.


Question: } }; <del> bfs_queue.push_back(DefId { krate: cnum, index: CRATE_DEF_INDEX }); </del> while let Some(def) = bfs_queue.pop_front() { for child in tcx.item_children(def).iter() { add_child(bfs_queue, child, def);

In particular, I can reproduce the old behavior on master by just linking in the old crate into (in addtion to linking in the one from ; doing this requires changing the name of the old ), without making any actual calls into the old crate. That, to me, seems very strange. I'm now trying to reduce down the size of the crate that I am linking in (while still causing this delta in behavior).
triage: P-high
I still get a non std types in erros when the path has the same length. That would be okay if it is somehow deterministic, but I get different type errors within the same file for the same types.
is that a regression from the stable channel? While I absolutely agree that a deterministic result would be better (and better stilll, a deterministic result that favored minimal-length paths rooted at ), I want to triage this appropriately.
Hmm I guess since is the person who filed the original ticket then it is reasonable to infer that they are indeed seeing the described regression compared to the stable channel.
gives me: seems to work now: Maybe this was some sort of partial compile cache issue? I haven't found a way to reproduce these mixed errors yet.
This looks like a duplicate of . That issue has some repro cases that affect the 1.22.1 stable compiler but not 1.21.0.
When I bisected the nightlies by hand on I ended up with a range (...) that does not include the commit identified here. Is it possible that the nondeterministic nature of the bug is also messing with our attempts to bisect? I wonder whether merely linking affects in the same way as it affected this issue.
Any evidence of this problem existing with the newest nightly?
All the cases I tried seem to have been fixed by and . Nicely done! I reported one follow-up in .


Question: <ins> // This is a non-regression test for issue #127052 where unreferenced `#[used]` statics couldn't be // removed by the MSVC linker, causing linking errors. //@ build-pass: needs linking //@ only-msvc #[used] static FOO: u32 = 0; fn main() {} </ins>

I tried this code: I expected to see this happen: Compiles successfully. Instead, this happened: Fails with this error: nightly-2024-06-26 and earlier. nightly-2024-06-27 and later, starting with . See for a discussion of the issue. : cc
To elaborate, the difference is in symbols.o. Here's a dump of symbols.o before the change: And here's after: Spot the difference. Spoiler: is now present.
So is that right or wrong? The static is "used" so marking it exported to ensure it does not get optimized away seems to make sense? I don't understand why this is a problem only on Windows.
Well that's not a problem per se but if we want to do that then we have to do it properly. is defined as a in (on my machine). This is linked directly and not in a lib file. So it's already being included. There's no reason for to include it. The only issue is that is being emitted as a comdat, meaning the linker is still allowed to remove it. We could just not do that (or add a linker directive). But that's a pre-existing issue.
I don't understand any part of that.^^ Should my PR get reverted or is there a better way to fix this regression? If there is a better way, I am afraid I lack the knowledge to implement and test it. I don't understand symbol handling on Linux, let alone on Windows.
I don't know enough about the Rust compiler to say. My complete guess would be that was silently broken before but now it's nosily broken.
Hm, who would understand our Windows linking story? ?
After CGU partitioning, we try to internalize symbols when possible. What is surprising to me is that this process only looks at export level, ignoring used attribute (in the contrast to say the internalization during fat LTO). Consequently we have a situation where synthetic object file references a symbol that is no longer exported (on Linux that does not result in a linking error, even though reference is unresolved). Anyway, if the consequence of would be to export those symbols for no reason, that seems rather counter productive to me.


Question: <ins> // This is a non-regression test for issue #127052 where unreferenced `#[used]` statics couldn't be // removed by the MSVC linker, causing linking errors. //@ build-pass: needs linking //@ only-msvc #[used] static FOO: u32 = 0; fn main() {} </ins>

Ah, the behaviour was working to spec before: So I think I'd agree that is the wrong approach and should be reverted because this currently ends up conflating different things. Maybe changes elsewhere would fix this but I don't want to speculate.
the separate issue you pointed out earlier in is presumably still relevant for ?
Could this explain recent CI flakiness? The failure at and a couple other failed merges (linked on that thread, also the retries) have been msvc linker errors.
That's unfortunate. :/ Our reachable symbol code is such a spaghetti mess... I guess I'll just have to copy-paste more things into Miri then. :shrug: I am traveling right now, I'd appreciate if someone else could do the revert.
The following patch should fix the incorrect internalization I mentioned earlier: As for the question whether those symbols should be exported in the first place, it might be necessary for COFF and . The following code suggests that would not have the desired effect otherwise I don't have access to windows environment at the moment to verify that, so I don't plan to work on this myself.
Ooh this is also the stuff that also broke several ci-runs already ...
Looks like this did not fully fix the ci failures :melting_face:
Makes sense: some CI failures look non-deterministic, while we'd expect this error not to be.
Alternative approach for Miri:


Question: <ins> warning: function cannot return without recursing --> $DIR/issue-87450.rs:5:1 | LL | fn foo() -> impl Fn() { | ^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing ... LL |     wrap(wrap(wrap(wrap(wrap(wrap(wrap(foo()))))))) |                                        ----- recursive call site | = note: `#[warn(unconditional_recursion)]` on by default = help: a `loop` may express intention better if this is on purpose error[E0720]: cannot resolve opaque type --> $DIR/issue-87450.rs:5:13 | LL | fn foo() -> impl Fn() { |             ^^^^^^^^^ recursive opaque type ... LL |     wrap(wrap(wrap(wrap(wrap(wrap(wrap(foo()))))))) |     ----------------------------------------------- returning here with type `impl Fn<()>` ... LL | fn wrap(f: impl Fn()) -> impl Fn() { |                          --------- returning this opaque type `impl Fn<()>` error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0720`. </ins>

I tried this code: I expected running to produce an error like: It does, but takes time exponential in the number of calls, although doesn't appear to use any extra memory. In the time take looks like: I believe it's also exponential in the number of calls in . The reason I had code like this was because I was using nom's parser combinators which results in lots of nested closures. I spotted it because this caused rust-analyzer to hang because cargo clippy hung (it looks like check was the issue), I had to kill clippy to fix it. I bisected this (with cargo-bisect-rustc) to find the regression in , which contained the following bors commits: merge of - Centril:rollup-rzvry15, r=Centril merge of - tmandry:rollup-0k6jiik, r=tmandry merge of - Manishearth:clippyup, r=Manishearth merge of - tanriol:explain_borrow-use-context-dominators, r=nagisa merge of - ehuss:update-cargo-books, r=alexcrichton modify labels: +regression-from-stable-to-stable -regression-untriaged
what version of rust are you using? Is this also present on nightly?
Good question! This repros on the latest nightly () and on stable (1.53.0 2021-06-17).
Regression means that it was linear, or exponential, but smaller?
I didn't looks to still be exponential just much quicker, and with a smaller base (~2 vs ~14):
looks related
Bisected to innocent-looking commit . Removing the caching from in master does indeed fix the issue. I haven't looked at the how or why or where that causes (other) problems though. cc
Hmm, the only thing that looks expensive there is the hashing - I wonder if it's hashing over and over again without ever getting a cache hit? Hashing has a fixed cost, but can be an arbitrary length:
cuts down on time for this testcase and others with invalid recursive opaque types by bailing out early if a recursion is found.


Question: <ins> warning: function cannot return without recursing --> $DIR/issue-87450.rs:5:1 | LL | fn foo() -> impl Fn() { | ^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing ... LL |     wrap(wrap(wrap(wrap(wrap(wrap(wrap(foo()))))))) |                                        ----- recursive call site | = note: `#[warn(unconditional_recursion)]` on by default = help: a `loop` may express intention better if this is on purpose error[E0720]: cannot resolve opaque type --> $DIR/issue-87450.rs:5:13 | LL | fn foo() -> impl Fn() { |             ^^^^^^^^^ recursive opaque type ... LL |     wrap(wrap(wrap(wrap(wrap(wrap(wrap(foo()))))))) |     ----------------------------------------------- returning here with type `impl Fn<()>` ... LL | fn wrap(f: impl Fn()) -> impl Fn() { |                          --------- returning this opaque type `impl Fn<()>` error: aborting due to previous error; 1 warning emitted For more information about this error, try `rustc --explain E0720`. </ins>

This fixes the regression but the check time is still exponential in the recursion: #wraps|time (s) ---|--- 23|9.2 24|18.3 25|36.6 Not sure if that matters in practice though.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
That's the same as before the regression, right? I definitely think that's a change worth making :) I expect the doubling will have a completely different cause.
Yes, same ballpark.


Question: <ins> use std::{ptr::NonNull, task::Poll}; struct TaskRef; struct Header { vtable: &'static Vtable, } struct Vtable { poll: unsafe fn(TaskRef) -> Poll<()>, deallocate: unsafe fn(NonNull<Header>), } // in the "Header" type, which is a private type in maitake impl Header { pub(crate) const fn new_stub() -> Self { unsafe fn nop(_ptr: TaskRef) -> Poll<()> { Poll::Pending } unsafe fn nop_deallocate(ptr: NonNull<Header>) { unreachable!("stub task ({ptr:p}) should never be deallocated!"); } Self { vtable: &Vtable { poll: nop, deallocate: nop_deallocate } } } } // This is a public type in `maitake` #[repr(transparent)] #[cfg_attr(loom, allow(dead_code))] pub struct TaskStub { hdr: Header, } impl TaskStub { /// Create a new unique stub [`Task`]. pub const fn new() -> Self { Self { hdr: Header::new_stub() } } } </ins>

<!-- 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. --Github: Repro: Reproduces in: Stable Linux - rustc 1.61.0 ( 2022-05-18) Nightly Linux - rustc 1.63.0-nightly ( 2022-06-02) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I'll see if I can make a smaller repro case
So, the minimal repro case is MUCH smaller: in : In : Which points to these code chunks: This seems to work in the tests for , so it seems like the ICE only triggers when used from an external trait. Additionally, this ICE does NOT trigger in .
CC
Yeah, this seems to occur specifically when trying to compile an external crate that calls this function. Lib tests inside the crate that call the function don't ICE, but adding an integration test (outside of the crate's compilation unit) does trigger the ICE:
If the function is made , the ICE no longer occurs. For example, this commit does not ICE:
prioritize
, if the functions are made but placed in a private module, they get culled again, triggering the ICE:
It also appears that if you move the functions out of the , AND mark them as , the ICE is also abated. See this PR for addressing:
For folks joining now/as a TL;DR, the offending code is basically this: The function produces a value, that gets created in a static: Which gets loaded into a static in user code: It LOOKS like somehow the two original functions (declared inside a private, const fn; inside a private type), are getting culled, which means that when the static (in another compilation unit) goes to be created, the MIR for those functions are missing.
This is likely a disagreement between . Though I don't know much about codegen.
Anyways I think I have a fix, though I am not certain it's the right one. In any case, I at least have a minimized UI test for rustc devs who know codegen better than me. PR incoming.


Question: <ins> // revisions: rpass cfail enum A { //[cfail]~^ ERROR 3:1: 3:7: recursive type `A` has infinite size [E0072] B(C), } #[cfg(rpass)] struct C(Box<A>); #[cfg(cfail)] struct C(A); //[cfail]~^ ERROR 12:1: 12:13: recursive type `C` has infinite size [E0072] fn main() {} </ins>

Creating a recursive type with infinite size by removing a leads to an internal compiler error. Might be the same issue as . To reproduce this bug, run on this code: Replace by and run again: I expected to see this happen: Instead, this happened: :
triage: P-high. Removing nomination.
assigning to with expectation that they will delegate.
nominating to try to find someone to investigate this.
well spotted ;) Because this issue has the tag and the other doesn't I will post the incremental test here:
triage: Reassigning to self and in hopes that one of us will find time to investigate, since it seems to be an issue with the dep-graph/incr-comp infrastructure.
triage: Downgrading to P-medium. I still want to resolve this, but it simply does not warrant revisiting every week during T-compiler triage.
I encountered the same bug. I starting to create a new issue, but it's exactly the same than this one. In case it's needed, I uploaded the code on on the branch (there is two commits, the first is fine, the second generate the ICE) in case you want to validate your patch when you will eventually have time to fix it.
I am running into this issue as well. Since the corresponding pr has been merged 24 days ago and the latest version was tagged 14 days ago, I am not sure, if this error should have been fixed with . (I did not find the commit on the master but I am also unsure if it was squashed with other commits.) Therefore, I thought I would at least post my error as well, just in case this is supposed to work. In my case I have an enum which holds a struct which in turn references that enum. I know that this can't work and I know how the correct way of handling this scenario is, I just wanted to let you know that this crashes the compiler. If you need a more detailed code sample, let me know and I will try to reproduce the error outside of my project.


Question: pub fn check_for_errors_in<T, F>(f: F) -> Result<T, String> where F: FnOnce() -> T, { <del> use std::sync::{Mutex, Once, ONCE_INIT}; static INIT: Once = ONCE_INIT; </del> <ins> use std::sync::{Mutex, Once}; static INIT: Once = Once::new(); </ins> static mut LOCK: *mut Mutex<()> = 0 as *mut _; unsafe { INIT.call_once(|| {

, anyone using the former . I guess we can't outright deprecate given our backwards compatibility policy, but I would like to lint on its usage and at the very least call it out in the documentation ("use instead"). This also opens the conversation around the larger problem of what to do with the parts of the API that would get superseded by new features, like const generics, or in this case const fns.
Can we just deprecate it?
Why is a problem?
Similarly, the initializers for the family of structs were deprecated in 1.34 and have a rustfix-able suggestion to use the function. For example, see .
"There should be only one way of doing it" I saw someone today get quite confused today as to why both existed in the first place, which required an explanation of 's backwards compatibility policy, behavior, and release schedules. I feel that we should have an aggressive funnel towards "the right way of doing things" across the board, that includes linting against usages that are only kept because of historical reasons. At the very least I'd like to see the documentation updated so that it preempts the questions I got asked today
/me Prepares plans to deprecate :) In all seriousness, imo someone's confusion as to why both existed and "only one way to do it" is a rather weak justification for churn when the old way isn't harmful in any way. Seems fine.
We deprecate things like ONCE_INIT 3 releases after their replacements (in this case Once::new specifically being a const fn) were . I can't find in the release notes when that happened, but if someone tracks it down, it should be an easy PR!
was stabilized . Didn't find any reference to it .
Was it callable as a const fn in 1.2.0?
The const-ness was made stable in the same PR as for AtomicUsize::new: