Question:
Given Rustdoc does not escape the ASCII angle brackets for the generic argument list of the generic associated type projection leading to the following butchered HTML output: I've noticed this while working on rustdoc integration for in . It's possible that the refactoring PR will fix this (need to check) or at least make it more pleasant to fix. Assigning myself for now since I'm gonna fix this otherwise. claim label T-rustdoc A-rustdoc-ui F-genericassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Copying my comment from : is requesting alternate formatting (i.e. plaintext), but in this branch of things, alternate formatting hasn't been requested by the caller. So this is likely emitting into an HTML context. If you change it to in your branch I'm guessing that will fix things.
Here's a live example: As it turns out, this bug does appear to be what's crashing rustdoc in . So I will wind up fixing it. But feel free to investigate and fix if you prefer not to wait.
This wound up being the fix:
On at least I cannot reproduce your fix that involves adding in branch (maybe that only works on your branch). In any case, the lines in are definitely the culprit. I've already fixed it that way in but I've now also opened a separate PR. Thanks for the live example!

//        the ugliness comes from inlining across crates where //        everything comes in as a fully resolved QPath (hard to //        look at).  match href(trait_.def_id(), cx) { Ok((ref url, _, ref path)) if !f.alternate() => { write!( f, "{name}{args}", url = url, shortty = ItemType::AssocType, name = assoc.name, path = join_with_double_colon(path), args = assoc.args.print(cx), )?; } _ => write!(f, "{}{:#}", assoc.name, assoc.args.print(cx))?, } Ok(())   if !f.alternate() && let Ok((url, _, path)) = href(trait_.def_id(), cx) { write!( f, "{name}", shortty = ItemType::AssocType, name = assoc.name, path = join_with_double_colon(&path), ) } else { write!(f, "{}", assoc.name) }?; // Carry `f.alternate()` into this display w/o branching manually. fmt::Display::fmt(&assoc.args.print(cx), f)  } } }


Question:
Given Rustdoc does not escape the ASCII angle brackets for the generic argument list of the generic associated type projection leading to the following butchered HTML output: I've noticed this while working on rustdoc integration for in . It's possible that the refactoring PR will fix this (need to check) or at least make it more pleasant to fix. Assigning myself for now since I'm gonna fix this otherwise. claim label T-rustdoc A-rustdoc-ui F-genericassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Copying my comment from : is requesting alternate formatting (i.e. plaintext), but in this branch of things, alternate formatting hasn't been requested by the caller. So this is likely emitting into an HTML context. If you change it to in your branch I'm guessing that will fix things.
Here's a live example: As it turns out, this bug does appear to be what's crashing rustdoc in . So I will wind up fixing it. But feel free to investigate and fix if you prefer not to wait.
This wound up being the fix:
On at least I cannot reproduce your fix that involves adding in branch (maybe that only works on your branch). In any case, the lines in are definitely the culprit. I've already fixed it that way in but I've now also opened a separate PR. Thanks for the live example!

<ins> // Make sure that we escape the arguments of the GAT projection even if we fail to compute // the href of the corresponding trait (in this case it is private). // Further, test that we also linkify the GAT arguments. // @has 'issue_109488/type.A.html' // @has - '//pre[@class="rust item-decl"]' '<S as Tr>::P<Option<i32>>' // @has - '//pre[@class="rust item-decl"]//a[@class="enum"]/@href' '{{channel}}/core/option/enum.Option.html' pub type A = <S as Tr>::P<Option<i32>>; /*private*/ trait Tr { type P<T>; } pub struct S; impl Tr for S { type P<T> = (); } </ins>


Question:
I tried this code: I expected this to happen: Bootstrap builds cranelift, since I named it explicitly. Instead, this happened: Nothing, since I didn't have cranelift configured in : At a minimum, I would expect this to give an error or warning that I need to configure codegen-backends. It would be even nicer if we could treat as only controlling the defaults, instead of as a hard-off switch, like how works. That should be possible to do by looking at the we're passed. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The first element in codegen-backends is used as default backend. In addition even if the CodegenBackend step were to directly use the passed in paths, assembling the toolchain did still only add the backends in codegen-backends to the sysroot. Having path specifiers for one step affect another step doesn't feel right. For check builds I do agree this is an improvement. Although I personally actually use this behavior to have build all backends, not just cranelift (by enabling all in codegen-backends) It did be nice to have a replacement for this. In addition for at the very least a warning makes sense.
Does it make sense to separate cgclif and cggcc into different steps in that case? cc
That doesn't have any effect on if specifying a backend as path will add it to the sysroot.

use crate::builder::crate_description; use crate::builder::Cargo; <del> use crate::builder::{Builder, Kind, RunConfig, ShouldRun, Step}; </del> <ins> use crate::builder::{Builder, Kind, PathSet, RunConfig, ShouldRun, Step, TaskPath}; </ins> use crate::cache::{Interned, INTERNER}; use crate::config::{LlvmLibunwind, RustcLto, TargetSelection}; use crate::dist;


Question:
I tried this code: I expected this to happen: Bootstrap builds cranelift, since I named it explicitly. Instead, this happened: Nothing, since I didn't have cranelift configured in : At a minimum, I would expect this to give an error or warning that I need to configure codegen-backends. It would be even nicer if we could treat as only controlling the defaults, instead of as a hard-off switch, like how works. That should be possible to do by looking at the we're passed. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The first element in codegen-backends is used as default backend. In addition even if the CodegenBackend step were to directly use the passed in paths, assembling the toolchain did still only add the backends in codegen-backends to the sysroot. Having path specifiers for one step affect another step doesn't feel right. For check builds I do agree this is an improvement. Although I personally actually use this behavior to have build all backends, not just cranelift (by enabling all in codegen-backends) It did be nice to have a replacement for this. In addition for at the very least a warning makes sense.
Does it make sense to separate cgclif and cggcc into different steps in that case? cc
That doesn't have any effect on if specifying a backend as path will add it to the sysroot.

pub backend: Interned<String>, } <ins> fn needs_codegen_config(run: &RunConfig<'_>) -> bool { let mut needs_codegen_cfg = false; for path_set in &run.paths { needs_codegen_cfg = match path_set { PathSet::Set(set) => set.iter().any(|p| is_codegen_cfg_needed(p, run)), PathSet::Suite(suite) => is_codegen_cfg_needed(&suite, run), } } needs_codegen_cfg } const CODEGEN_BACKEND_PREFIX: &str = "rustc_codegen_"; fn is_codegen_cfg_needed(path: &TaskPath, run: &RunConfig<'_>) -> bool { if path.path.to_str().unwrap().contains(&CODEGEN_BACKEND_PREFIX) { let mut needs_codegen_backend_config = true; for &backend in &run.builder.config.rust_codegen_backends { if path .path .to_str() .unwrap() .ends_with(&(CODEGEN_BACKEND_PREFIX.to_owned() + &backend)) { needs_codegen_backend_config = false; } } if needs_codegen_backend_config { run.builder.info( "Warning: no codegen-backends config matched the requested path to build a codegen backend.  Help: add backend to codegen-backends in config.toml.", ); return true; } } return false; } </ins> impl Step for CodegenBackend { type Output = (); const ONLY_HOSTS: bool = true;


Question:
I tried this code: I expected this to happen: Bootstrap builds cranelift, since I named it explicitly. Instead, this happened: Nothing, since I didn't have cranelift configured in : At a minimum, I would expect this to give an error or warning that I need to configure codegen-backends. It would be even nicer if we could treat as only controlling the defaults, instead of as a hard-off switch, like how works. That should be possible to do by looking at the we're passed. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
The first element in codegen-backends is used as default backend. In addition even if the CodegenBackend step were to directly use the passed in paths, assembling the toolchain did still only add the backends in codegen-backends to the sysroot. Having path specifiers for one step affect another step doesn't feel right. For check builds I do agree this is an improvement. Although I personally actually use this behavior to have build all backends, not just cranelift (by enabling all in codegen-backends) It did be nice to have a replacement for this. In addition for at the very least a warning makes sense.
Does it make sense to separate cgclif and cggcc into different steps in that case? cc
That doesn't have any effect on if specifying a backend as path will add it to the sysroot.

} fn make_run(run: RunConfig<'_>) { <ins> if needs_codegen_config(&run) { return; } </ins> for &backend in &run.builder.config.rust_codegen_backends { if backend == "llvm" { continue; // Already built as part of rustc


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

let tcx = self.tcx; let def_id = instance.def_id(); <del> let containing_scope = get_containing_scope(self, instance); </del> <ins> let (containing_scope, is_method) = get_containing_scope(self, instance); </ins> let span = tcx.def_span(def_id); let loc = self.lookup_debug_loc(span.lo()); let file_metadata = file_metadata(self, &loc.file);


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

} } <del> unsafe { return llvm::LLVMRustDIBuilderCreateFunction( </del> <ins> // When we're adding a method to a type DIE, we only want a DW_AT_declaration there, because // LLVM LTO can't unify type definitions when a child DIE is a full subprogram definition. // When we use this `decl` below, the subprogram definition gets created at the CU level // with a DW_AT_specification pointing back to the type's declaration. let decl = is_method.then(|| unsafe { llvm::LLVMRustDIBuilderCreateMethod( DIB(self), containing_scope, name.as_ptr().cast(), name.len(), linkage_name.as_ptr().cast(), linkage_name.len(), file_metadata, loc.line, function_type_metadata, flags, spflags & !DISPFlags::SPFlagDefinition, template_parameters, ) }); return unsafe { llvm::LLVMRustDIBuilderCreateFunction( </ins> DIB(self), containing_scope, name.as_ptr().cast(),


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

spflags, maybe_definition_llfn, template_parameters, <del> None, ); } </del> <ins> decl, ) }; </ins> fn get_function_signature<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>,


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

names } <ins> /// Returns a scope, plus `true` if that's a type scope for "class" methods, /// otherwise `false` for plain namespace scopes. </ins> fn get_containing_scope<'ll, 'tcx>( cx: &CodegenCx<'ll, 'tcx>, instance: Instance<'tcx>, <del> ) -> &'ll DIScope { </del> <ins> ) -> (&'ll DIScope, bool) { </ins> // First, let's see if this is a method within an inherent impl. Because // if yes, we want to make the result subroutine DIE a child of the // subroutine's self-type. <del> let self_type = cx.tcx.impl_of_method(instance.def_id()).and_then(|impl_def_id| { </del> <ins> if let Some(impl_def_id) = cx.tcx.impl_of_method(instance.def_id()) { </ins> // If the method does *not* belong to a trait, proceed if cx.tcx.trait_id_of_impl(impl_def_id).is_none() { let impl_self_ty = cx.tcx.subst_and_normalize_erasing_regions(


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

// Only "class" methods are generally understood by LLVM, // so avoid methods on other types (e.g., `<*mut T>::null`). <del> match impl_self_ty.kind() { ty::Adt(def, ..) if !def.is_box() => { // Again, only create type information if full debuginfo is enabled if cx.sess().opts.debuginfo == DebugInfo::Full && !impl_self_ty.has_param() { Some(type_di_node(cx, impl_self_ty)) } else { Some(namespace::item_namespace(cx, def.did())) } </del> <ins> if let ty::Adt(def, ..) = impl_self_ty.kind() && !def.is_box() { // Again, only create type information if full debuginfo is enabled if cx.sess().opts.debuginfo == DebugInfo::Full && !impl_self_ty.has_param() { return (type_di_node(cx, impl_self_ty), true); } else { return (namespace::item_namespace(cx, def.did()), false); </ins> } <del> _ => None, </del> } } else { // For trait method impls we still use the "parallel namespace" // strategy <del> None </del> } <del> }); </del> <ins> } </ins> <del> self_type.unwrap_or_else(|| { namespace::item_namespace( cx, DefId { krate: instance.def_id().krate, index: cx .tcx .def_key(instance.def_id()) .parent .expect("get_containing_scope: missing parent?"), }, ) }) </del> <ins> let scope = namespace::item_namespace( cx, DefId { krate: instance.def_id().krate, index: cx .tcx .def_key(instance.def_id()) .parent .expect("get_containing_scope: missing parent?"), }, ); (scope, false) </ins> } }


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

Decl: Option<&'a DIDescriptor>, ) -> &'a DISubprogram; <ins> pub fn LLVMRustDIBuilderCreateMethod<'a>( Builder: &DIBuilder<'a>, Scope: &'a DIDescriptor, Name: *const c_char, NameLen: size_t, LinkageName: *const c_char, LinkageNameLen: size_t, File: &'a DIFile, LineNo: c_uint, Ty: &'a DIType, Flags: DIFlags, SPFlags: DISPFlags, TParam: &'a DIArray, ) -> &'a DISubprogram; </ins> pub fn LLVMRustDIBuilderCreateBasicType<'a>( Builder: &DIBuilder<'a>, Name: *const c_char,


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

return wrap(Sub); } <ins> extern "C" LLVMMetadataRef LLVMRustDIBuilderCreateMethod( LLVMRustDIBuilderRef Builder, LLVMMetadataRef Scope, const char *Name, size_t NameLen, const char *LinkageName, size_t LinkageNameLen, LLVMMetadataRef File, unsigned LineNo, LLVMMetadataRef Ty, LLVMRustDIFlags Flags, LLVMRustDISPFlags SPFlags, LLVMMetadataRef TParam) { DITemplateParameterArray TParams = DITemplateParameterArray(unwrap<MDTuple>(TParam)); DISubprogram::DISPFlags llvmSPFlags = fromRust(SPFlags); DINode::DIFlags llvmFlags = fromRust(Flags); DISubprogram *Sub = Builder->createMethod( unwrapDI<DIScope>(Scope), StringRef(Name, NameLen), StringRef(LinkageName, LinkageNameLen), unwrapDI<DIFile>(File), LineNo, unwrapDI<DISubroutineType>(Ty), 0, 0, nullptr, // VTable params aren't used llvmFlags, llvmSPFlags, TParams); return wrap(Sub); } </ins> extern "C" LLVMMetadataRef LLVMRustDIBuilderCreateBasicType( LLVMRustDIBuilderRef Builder, const char *Name, size_t NameLen, uint64_t SizeInBits, unsigned Encoding) {


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

<ins> # ignore-cross-compile include ../tools.mk # With the upgrade to LLVM 16, this was getting: # #   error: Cannot represent a difference across sections # # The error stemmed from DI function definitions under type scopes, fixed by # only declaring in type scope and defining the subprogram elsewhere. all: $(RUSTC) lib.rs --test -C lto=fat -C debuginfo=2 -C incremental=$(TMPDIR)/inc-fat </ins>


Question:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --Since nightly release , we've had build failures for () with message when lto is enabled. If I disable LTO, the build succeeds and the test passes. There are many similar tests which do currently build and run successfully with this version, it is only one specific test we have which is causing the issue. You can reproduce the issue if you build the test in release mode: I haven't been able to work out what actually causes this, and it seems to require a reasonable amount of code before the issue gets triggered. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust nightly 2023-03-23 <!-- Provide the version you are using that has the regression. --: The error message isn't particularly helpful here, but here is the full output from our github action: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
here probably more info on how to reproduce could help. If I read the , the test alone compiles but it fails when enabling the flag, thus the label. label E-needs-mcve
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Probably related to the LLVM upgrade, but I was unable to reduce this to a pure LLVM reproducer.
We just got this error building Firefox on Fedora 38, with Rust 1.69.0 and LLVM 16.0.1:
See /
I'll try a build with that patch. One thing to note though, regarding: The Firefox build got this message on aarch64, ppc64le, and x86_64. (Only s390x succeeded.)
D147620 worked locally for me, building LLVM 16 with that patch and then Firefox built fine. But it looks like that review is not settled yet. Whether the ultimate fix is in LLVM or rustc, I hope we can get that into beta for the 1.70.0 release.
I have a patch for rustc that passes the test case in -- I'll try with Firefox later today. claim

<ins> extern crate alloc; #[cfg(test)] mod tests { #[test] fn something_alloc() { assert_eq!(Vec::<u32>::new(), Vec::<u32>::new()); } } </ins>


Question:
There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim

sugar for dynamic allocations via `malloc` and `free`: ```rust,ignore (libc-is-finicky) <del> #![feature(lang_items, box_syntax, start, libc, core_intrinsics, rustc_private)] </del> <ins> #![feature(lang_items, start, libc, core_intrinsics, rustc_private, rustc_attrs)] </ins> #![no_std] use core::intrinsics; use core::panic::PanicInfo; <ins> use core::ptr::NonNull; </ins> extern crate libc; <del> struct Unique<T>(*mut T); </del> <ins> struct Unique<T>(NonNull<T>); </ins> #[lang = "owned_box"] pub struct Box<T>(Unique<T>); <ins> impl<T> Box<T> { pub fn new(x: T) -> Self { #[rustc_box] Box::new(x) } } </ins> #[lang = "exchange_malloc"] unsafe fn allocate(size: usize, _align: usize) -> *mut u8 { let p = libc::malloc(size as libc::size_t) as *mut u8;


Question:
There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim

#[start] fn main(_argc: isize, _argv: *const *const u8) -> isize { <del> let _x = box 1; </del> <ins> let _x = Box::new(1); </ins> 0 } #[lang = "eh_personality"] extern fn rust_eh_personality() {} <del> #[lang = "panic_impl"] extern fn rust_begin_panic(info: &PanicInfo) -> ! { unsafe { intrinsics::abort() } } </del> <ins> #[lang = "panic_impl"] extern fn rust_begin_panic(_info: &PanicInfo) -> ! { intrinsics::abort() } </ins> #[no_mangle] pub extern fn rust_eh_register_frames () {} #[no_mangle] pub extern fn rust_eh_unregister_frames () {} ```


Question:
There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim

that warns about any item named `lintme`. ```rust,ignore (requires-stage-2) <del> #![feature(box_syntax, rustc_private)] </del> <ins> #![feature(rustc_private)] </ins> extern crate rustc_ast;


Question:
There is no such thing as boxsyntax anymore :D <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
does the same.
It probably makes sense to search across the repository (including submodules) any references to this removed feature and remove them
claim

#[no_mangle] fn __rustc_plugin_registrar(reg: &mut Registry) { reg.lint_store.register_lints(&[&TEST_LINT]); <del> reg.lint_store.register_early_pass(|| box Pass); </del> <ins> reg.lint_store.register_early_pass(|| Box::new(Pass)); </ins> } ```


Question:
The unbounded channel implementation from can segfault due to what looks like a race condition when dropping channel senders and receivers. You can find a repro at Unfortunately it is not minimal at all, since it depends on the timely-dataflow crate, which is the actual channel user. I hope it is still self-contained enough that people familiar with the channel implementation can run it and use it as a starting point for debugging. Run the example like this: On some machines it will segfault after some time, e.g.: The segfault happens inside , as visible in the gdb backtrace below. The same segfault also happens with . You can reproduce this by reverting the second-to-last commit on the repro branch. I understand that is a port of , so that's not surprising. : I can reproduce the segfault on nightly as well. The segfault is not reproducible on all machines! We were able to reproduce it on: a c5.2xlarge EC2 instance running Ubuntu an AMD Threadripper Thinkpad running Debian an Intel i5-8250U Dell XPS 13 running Arch Linux It doesn't seem to reproduce on: an M1 MacBook Pro Also note that the repro is using more and more memory over time. That is because the different worker threads create and drop dataflows at different speeds and timely-dataflow keeps per-dataflow communication state (including channels) around until the last worker has dropped the dataflow. It is possible to avoid that by adding a that lets late workers catch up, but in my experience that also stops the segfault from happening. <details<summaryBacktrace</summary<p</p</details
Here are the results of some initial investigation I have been doing. I used , but I assume the results will apply to the std port as well: The segfault happens in . In the linked line, is a null pointer, and so is . It seems like there is an inconsistency between the channel's and . is pointing to nothing while points to a block. I observed the following variable assignments at the time of the segfault: If I change all the atomic orderings in to , the segfault still occurs. This suggests that the issue is not caused by the usage of too-weak orderings. If I add an after , it is triggered under the repro. This is where the sender is advancing and it seems plausible that this is the place where the inconsistency between and described above is introduced. I couldn't figure out why becomes a null pointer. The same method makes sure that the head is allocated previously, so some other thread must set it to null after the check.
cc
This suggests that the issue is not caused by the usage of too-weak orderings. I wouldn't be so quick to write off an ordering issue, the race condition could require stronger synchronization to fix (e.g. fences).
The segfault did occur (after about 5 minutes of runtime) on my Macbook Pro with an Intel Core i7 processor running macOS 13.3 and rustc 1.68.2. So whatever is causing this, it's not exclusive to Linux.
I have a feeling the issue is to do with a CAS failure when updating the tail not synchronizing with the update to head. If the thread that actually makes the update is preempted, the second thread might continue with the assumption that head has been updated, which might matter if it quickly writes to the entire block and the channel is disconnected before the head is ever touched. I haven't verified if this is possible, but it would be extremely rare if it is, which explains why this issue hasn't been hit before.

let mut head = self.head.index.load(Ordering::Acquire); let mut block = self.head.block.load(Ordering::Acquire); <ins> // If we're going to be dropping messages we need to synchronize with initialization if head >> SHIFT != tail >> SHIFT { // The block can be null here only if a sender is in the process of initializing the // channel while another sender managed to send a message by inserting it into the // semi-initialized channel and advanced the tail. // In that case, just wait until it gets initialized. while block.is_null() { backoff.spin_heavy(); block = self.head.block.load(Ordering::Acquire); } } </ins> unsafe { // Drop all messages between head and tail and deallocate the heap-allocated blocks. while head >> SHIFT != tail >> SHIFT {


Question:
As the title says - Miri UI tests aren't run when invoked through x.py, or on CI: The actual issue appears to be that in the miri directory expects no non-filter args to be passed to it when being run, but the args are getting passed. I was trying to test miri locally, and I ran the command . I expected the miri UI tests to get run, but instead, they were all always getting filtered out, despite not passing a filter. After looking into it a bit, I discovered the filter vector was always , and decided to check whether bors was running them.
This seems ... pretty unfortunate :sweat: cc I know miri is nightly only but it makes me pretty uncomfortable to be shipping tools that aren't running tests, even if rust-lang/miri is still running the tests.
If my shell history is anything to go by, this is recent breakage, and used to run all of Miri's tests.
Yea, this is not breakage on the miri side afaict, but must be a change on the cargo or bootstrap side. I'm fine fixing this on our side tho. I can replicate the behaviour of the default test runner and adjust the wrappers in the miri repo to insert that
For making it follow normal behavior, I'm just replacing the in compiletest with for now. I'd be willing to PR this change as a standalone if desired.
Thanks! That would be great
Yeah I am pretty sure I tested this when we changed Miri to a subtree, and it worked back then. How does looking for help? Looks to me like we'd have to know exactly which flags the regular test runner understands and parse them all the same way. E.g. should apply the filer but should not. Which is of course ridiculous. Can we stop bootstrap from passing wrong flags to test runners?
I suggest that we change the test runner argument parsing to error out if there is any filter starting with -- except after a . So, something like:
The source of the regression is Meanwhile should fix bootstrap invoking the Miri test suite.

// Forward test filters. cargo.arg("--").args(builder.config.cmd.test_args()); <del> add_flags_and_try_run_tests(builder, &mut cargo.into()); </del> <ins> // This can NOT be `add_flags_and_try_run_tests` since the Miri test runner // does not understand those flags! let mut cargo = Command::from(cargo); builder.run(&mut cargo); </ins> // # Run `cargo miri test`. // This is just a smoke test (Miri's own CI invokes this in a bunch of different ways and ensures


Question:
<!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in

}; use crate::traits::{Obligation, PredicateObligations}; <del> use rustc_middle::ty::relate::{Relate, RelateResult, TypeRelation}; </del> <ins> use rustc_middle::ty::relate::{ relate_args_invariantly, relate_args_with_variances, Relate, RelateResult, TypeRelation, }; </ins> use rustc_middle::ty::TyVar; use rustc_middle::ty::{self, Ty, TyCtxt}; use rustc_span::Span;


Question:
<!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in

self.fields.infcx.tcx } <ins> fn relate_item_args( &mut self, item_def_id: rustc_hir::def_id::DefId, a_arg: ty::GenericArgsRef<'tcx>, b_arg: ty::GenericArgsRef<'tcx>, ) -> RelateResult<'tcx, ty::GenericArgsRef<'tcx>> { if self.ambient_variance == ty::Variance::Invariant { // Avoid fetching the variance if we are in an invariant // context; no need, and it can induce dependency cycles // (e.g., #41849). relate_args_invariantly(self, a_arg, b_arg) } else { let tcx = self.tcx(); let opt_variances = tcx.variances_of(item_def_id); relate_args_with_variances(self, item_def_id, opt_variances, a_arg, b_arg, false) } } </ins> fn relate_with_variance<T: Relate<'tcx>>( &mut self, variance: ty::Variance,


Question:
<!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in

<ins> //@ check-pass #![feature(inherent_associated_types)] //~^ WARN the feature `inherent_associated_types` is incomplete struct D<T> { a: T } impl<T: Default> D<T> { type Item = T; fn next() -> Self::Item { Self::Item::default() } } fn main() { } </ins>


Question:
<!-- 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
related. label F-inherentassociatedtypes
It caused by a cycle query:
There's a related bug to this (I believe by involving some traits with associated types) that I would like to report, though I was able to raise mine on Stable (1.70.0) without using the feature flag. Should I make a separate bug report or attach it here?
Regression in nightly-2023-02-21 found 9 bors merge commits in the specified range commit[0] 2023-02-19: Auto merge of - cjgillot:codegen-overflow-check, r=tmiasko commit[1] 2023-02-19: Auto merge of - clubby789:builtin-derived-attr, r=jackh726 commit[2] 2023-02-20: Auto merge of - fmease:iat-type-directed-probing, r=jackh726 commit[3] 2023-02-20: Auto merge of - tmiasko:read-buf, r=the8472 commit[4] 2023-02-20: Auto merge of - camelid:rustdoc-all-only-stable, r=GuillaumeGomez commit[5] 2023-02-20: Auto merge of - b-naber:proj-relate-variance, r=lcnr commit[6] 2023-02-20: Auto merge of - megakorre:issue_105700, r=petrochenkov commit[7] 2023-02-20: Auto merge of - matthiaskrgr:rollup-4tdvnx6, r=matthiaskrgr commit[8] 2023-02-20: Auto merge of - lnicola:rust-analyzer-2023-02-20, r=lnicola ERROR: no CI builds available between and within last 167 days I guess ?
Seems this has been fixed on the latest nightly, marked as E-needs-test. labels: +E-needs-test
this regressed again in

<ins> warning: the feature `inherent_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/variance-computation-requires-equality.rs:3:12 | LL | #![feature(inherent_associated_types)] |            ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #8995 <https://github.com/rust-lang/rust/issues/8995> for more information = note: `#[warn(incomplete_features)]` on by default warning: 1 warning emitted </ins>


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::DefineOpaqueTypes; use rustc_infer::infer::InferOk; <ins> use rustc_infer::traits::query::NoSolution; </ins> use rustc_infer::traits::ObligationCause; use rustc_middle::middle::stability; use rustc_middle::ty::adjustment::{Adjust, Adjustment, AllowTwoPhase};


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

use rustc_target::abi::FieldIdx; use rustc_target::spec::abi::Abi::RustIntrinsic; use rustc_trait_selection::infer::InferCtxtExt; <ins> use rustc_trait_selection::traits::error_reporting::TypeErrCtxtExt; use rustc_trait_selection::traits::ObligationCtxt; </ins> use rustc_trait_selection::traits::{self, ObligationCauseCode}; impl<'a, 'tcx> FnCtxt<'a, 'tcx> {


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

element_ty } None => { <ins> // Attempt to *shallowly* search for an impl which matches, // but has nested obligations which are unsatisfied. for (base_t, _) in self.autoderef(base.span, base_t).silence_errors() { if let Some((_, index_ty, element_ty)) = self.find_and_report_unsatisfied_index_impl(expr.hir_id, base, base_t) { self.demand_coerce(idx, idx_t, index_ty, None, AllowTwoPhase::No); return element_ty; } } </ins> let mut err = type_error_struct!( self.tcx.sess, expr.span,


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

} } <ins> /// Try to match an implementation of `Index` against a self type, and report /// the unsatisfied predicates that result from confirming this impl. /// /// Given an index expression, sometimes the `Self` type shallowly but does not /// deeply satisfy an impl predicate. Instead of simply saying that the type /// does not support being indexed, we want to point out exactly what nested /// predicates cause this to be, so that the user can add them to fix their code. fn find_and_report_unsatisfied_index_impl( &self, index_expr_hir_id: HirId, base_expr: &hir::Expr<'_>, base_ty: Ty<'tcx>, ) -> Option<(ErrorGuaranteed, Ty<'tcx>, Ty<'tcx>)> { let index_trait_def_id = self.tcx.lang_items().index_trait()?; let index_trait_output_def_id = self.tcx.get_diagnostic_item(sym::IndexOutput)?; let mut relevant_impls = vec![]; self.tcx.for_each_relevant_impl(index_trait_def_id, base_ty, |impl_def_id| { relevant_impls.push(impl_def_id); }); let [impl_def_id] = relevant_impls[..] else { // Only report unsatisfied impl predicates if there's one impl return None; }; self.commit_if_ok(|_| { let ocx = ObligationCtxt::new_in_snapshot(self); let impl_substs = self.fresh_substs_for_item(base_expr.span, impl_def_id); let impl_trait_ref = self.tcx.impl_trait_ref(impl_def_id).unwrap().subst(self.tcx, impl_substs); let cause = self.misc(base_expr.span); // Match the impl self type against the base ty. If this fails, // we just skip this impl, since it's not particularly useful. let impl_trait_ref = ocx.normalize(&cause, self.param_env, impl_trait_ref); ocx.eq(&cause, self.param_env, impl_trait_ref.self_ty(), base_ty)?; // Register the impl's predicates. One of these predicates // must be unsatisfied, or else we wouldn't have gotten here // in the first place. ocx.register_obligations(traits::predicates_for_generics( |idx, span| { traits::ObligationCause::new( base_expr.span, self.body_id, if span.is_dummy() { traits::ExprItemObligation(impl_def_id, index_expr_hir_id, idx) } else { traits::ExprBindingObligation(impl_def_id, span, index_expr_hir_id, idx) }, ) }, self.param_env, self.tcx.predicates_of(impl_def_id).instantiate(self.tcx, impl_substs), )); // Normalize the output type, which we can use later on as the // return type of the index expression... let element_ty = ocx.normalize( &cause, self.param_env, self.tcx.mk_projection(index_trait_output_def_id, impl_trait_ref.substs), ); let errors = ocx.select_where_possible(); // There should be at least one error reported. If not, we // will still delay a span bug in `report_fulfillment_errors`. Ok::<_, NoSolution>(( self.err_ctxt().report_fulfillment_errors(&errors), impl_trait_ref.substs.type_at(1), element_ty, )) }) .ok() } </ins> fn point_at_index_if_possible( &self, errors: &mut Vec<traits::FulfillmentError<'tcx>>,


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

HashSet, Hasher, Implied, <ins> IndexOutput, </ins> Input, Into, IntoDiagnostic,


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

pub trait Index<Idx: ?Sized> { /// The returned type after indexing. #[stable(feature = "rust1", since = "1.0.0")] <ins> #[rustc_diagnostic_item = "IndexOutput"] </ins> type Output: ?Sized; /// Performs the indexing (`container[index]`) operation.


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

<ins> use std::hash::Hash; use std::marker::PhantomData; use std::ops::Index; struct HashMap<K, V>(PhantomData<(K, V)>); impl<K, V> Index<&K> for HashMap<K, V> where K: Hash, V: Copy, { type Output = V; fn index(&self, k: &K) -> &V { todo!() } } fn index<'a, K, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { map[k] //~^ ERROR the trait bound `K: Hash` is not satisfied //~| ERROR the trait bound `V: Copy` is not satisfied //~| ERROR mismatched types //~| ERROR mismatched types } fn main() {} </ins>


Question:
I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim

<ins> error[E0277]: the trait bound `K: Hash` is not satisfied --> $DIR/bad-index-due-to-nested.rs:20:5 | LL |     map[k] |     ^^^ the trait `Hash` is not implemented for `K` | note: required by a bound in `<HashMap<K, V> as Index<&K>>` --> $DIR/bad-index-due-to-nested.rs:9:8 | LL |     K: Hash, |        ^^^^ required by this bound in `<HashMap<K, V> as Index<&K>>` help: consider restricting type parameter `K` | LL | fn index<'a, K: std::hash::Hash, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { |               +++++++++++++++++ error[E0277]: the trait bound `V: Copy` is not satisfied --> $DIR/bad-index-due-to-nested.rs:20:5 | LL |     map[k] |     ^^^ the trait `Copy` is not implemented for `V` | note: required by a bound in `<HashMap<K, V> as Index<&K>>` --> $DIR/bad-index-due-to-nested.rs:10:8 | LL |     V: Copy, |        ^^^^ required by this bound in `<HashMap<K, V> as Index<&K>>` help: consider restricting type parameter `V` | LL | fn index<'a, K, V: std::marker::Copy>(map: &'a HashMap<K, V>, k: K) -> &'a V { |                  +++++++++++++++++++ error[E0308]: mismatched types --> $DIR/bad-index-due-to-nested.rs:20:9 | LL | fn index<'a, K, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { |              - this type parameter LL |     map[k] |         ^ |         | |         expected `&K`, found type parameter `K` |         help: consider borrowing here: `&k` | = note:   expected reference `&K` found type parameter `K` error[E0308]: mismatched types --> $DIR/bad-index-due-to-nested.rs:20:5 | LL | fn index<'a, K, V>(map: &'a HashMap<K, V>, k: K) -> &'a V { |                 - this type parameter               ----- expected `&'a V` because of return type LL |     map[k] |     ^^^^^^ |     | |     expected `&V`, found type parameter `V` |     help: consider borrowing here: `&map[k]` | = note:   expected reference `&'a V` found type parameter `V` error: aborting due to 4 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>


Question:
<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

Some(blk_id), ); if !fcx.tcx.features().unsized_locals { <del> unsized_return = self.is_return_ty_unsized(fcx, blk_id); </del> <ins> unsized_return = self.is_return_ty_definitely_unsized(fcx); </ins> } if let Some(expression) = expression && let hir::ExprKind::Loop(loop_blk, ..) = expression.kind {


Question:
<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

None, ); if !fcx.tcx.features().unsized_locals { <del> let id = fcx.tcx.hir().parent_id(id); unsized_return = self.is_return_ty_unsized(fcx, id); </del> <ins> unsized_return = self.is_return_ty_definitely_unsized(fcx); </ins> } } _ => {


Question:
<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

err.help("you could instead create a new `enum` with a variant for each returned type"); } <del> fn is_return_ty_unsized<'a>(&self, fcx: &FnCtxt<'a, 'tcx>, blk_id: hir::HirId) -> bool { if let Some((_, fn_decl, _)) = fcx.get_fn_decl(blk_id) && let hir::FnRetTy::Return(ty) = fn_decl.output && let ty = fcx.astconv().ast_ty_to_ty( ty) && let ty::Dynamic(..) = ty.kind() { return true; </del> <ins> /// Checks whether the return type is unsized via an obligation, which makes /// sure we consider `dyn Trait: Sized` where clauses, which are trivially /// false but technically valid for typeck. fn is_return_ty_definitely_unsized(&self, fcx: &FnCtxt<'_, 'tcx>) -> bool { if let Some(sig) = fcx.body_fn_sig() { !fcx.predicate_may_hold(&Obligation::new( fcx.tcx, ObligationCause::dummy(), fcx.param_env, ty::TraitRef::new( fcx.tcx, fcx.tcx.require_lang_item(hir::LangItem::Sized, None), [sig.output()], ), )) } else { false </ins> } <del> false </del> } pub fn complete<'a>(self, fcx: &FnCtxt<'a, 'tcx>) -> Ty<'tcx> {


Question:
<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

<ins> trait Trait<T> {} fn foo<T>() -> dyn Trait<T> where dyn Trait<T>: Sized, // pesky sized predicate { 42 //~^ ERROR mismatched types } fn main() {} </ins>


Question:
<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

<ins> error[E0308]: mismatched types --> $DIR/return-dyn-type-mismatch-2.rs:7:5 | LL | fn foo<T>() -> dyn Trait<T> |                ------------ expected `(dyn Trait<T> + 'static)` because of return type ... LL |     42 |     ^^ expected `dyn Trait`, found integer | = note: expected trait object `(dyn Trait<T> + 'static)` found type `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

<ins> pub trait TestTrait { type MyType; fn func() -> Option<Self> where Self: Sized; } impl<T> dyn TestTrait<MyType = T> where Self: Sized, // pesky sized predicate { fn other_func() -> dyn TestTrait<MyType = T> { match Self::func() { None => None, //~^ ERROR mismatched types } } } fn main() {} </ins>


Question:
<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `

<ins> error[E0308]: mismatched types --> $DIR/return-dyn-type-mismatch.rs:15:21 | LL |     fn other_func() -> dyn TestTrait<MyType = T> { |                        ------------------------- expected `(dyn TestTrait<MyType = T> + 'static)` because of return type LL |         match Self::func() { LL |             None => None, |                     ^^^^ expected `dyn TestTrait`, found `Option<_>` | = note: expected trait object `(dyn TestTrait<MyType = T> + 'static)` found enum `Option<_>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
All existing standard library documentation implicitly assumes that the APIs are being used between the start of a Rust and end of . For example  does not document any indication that the function would panic. It does not need to document that, because the function cannot panic, as long as the call occurs within the duration of . However it's possible to observe a panic like this: (Related PR and discussion: ) In general using the standard library from an callback, or before through a static constructor, is UB: according to "we can't really guarantee anything specific happens [...]; at least not in a cross-platform way." Is this worth calling out centrally as a caveat to all other documentation of the standard library? At the top level of the whole crate (it would perhaps be more prominent than it deserves), at the module level, or in the Reference? Certainly for , , , the expectation users need to have is that nothing in there will work outside of . Are there APIs it makes sense to carve out as being permissible outside of ? Stuff like , , , , etc. We'd maybe need to do research into how constructors and atexit are being used in the wild. For example the crate relies on , , and to be usable before : It seems obvious that those things should work but there isn't documentation which guarantees it. I assume that makes the crate technically unsound as written.
IMHO, core types should work in whatever context but libstd is more dicey. It more explicitly has a runtime or three (e.g. Rust's, libc's and the OS's). So at a minimum anything in the modules , , , , , , , etc should be regarded with suspicion unless documented otherwise. In summary, my thoughts are: is fine depends on the allocator used assumes code is running in main (except for the and possibly stuff)
Core types can still panic and panics do IO.
Hm... how much of an issue is that? Panics don't have to do I/O (e.g. if stderr is closed) so if platforms don't support that before or after main then it can be silently skipped, no?
But do we do that properly today? And it's not just IO but also panic hooks which in turn can rely on various other parts of std.
I think it would be fine to document that e.g. after main they may want to set an empty (or aborting) panic hook if panicking is possible. I really don't want to be in a situation where the user is in a worse place than if they'd just used .
Could we turn panics into immediate aborts after main? That would also avoid the backtrace printing and symbolication.
I looked through the standard library, and is the only function that has limitation on usage before/after main (in this case, this is only a problem during TLS destruction). This function is also called from , and , which can therefore panic when called during TLS destruction. and might be able to be reworked to avoid this, but this is fundamentally a limitation of since it requires a reference to the current to work. The stack guard used by the stack overflow handler also accesses the same TLS slot as , but since the stack bounds don't have a this could be moved to a separate to properly support stack overflow handling during TLS destruction.
If we're going to make a statement at all then imo we should start out with something more cautious than making solid guarantees since this would be a pretty wide-ranging promise. before/after main behavior is not tested. It is best-effort and if someone relies on it they should have their own tests core and alloc are expected to work because they don't touch OS APIs or global state caveat: user code in any hookable API like panic handlers, global allocators, OOM handler or any future hooks. Especially panics affect a lot of code. we might replace hooks after main? most existing parts of std, backtrace and other things interacting with the OS are expected to work but there may be platform-specific edge-cases and the behavior may change in the future due to changing implementation details or new features that depend more runtime state (e.g. a std threadpool or async runtime) then finally a list of known limitations
Proposed documentation based on my previous comment:

//! contains further primitive shared memory types, including [`atomic`] and //! [`mpsc`], which contains the channel types for message passing. //! <ins> //! # Use before and after `main()` //! //! Many parts of the standard library are expected to work before and after `main()`; //! but this is not guaranteed or ensured by tests. It is recommended that you write your own tests //! and run them on each platform you wish to support. //! This means that use of `std` before/after main, especially of features that interact with the //! OS or global state, is exempted from stability and portability guarantees and instead only //! provided on a best-effort basis. Nevertheless bug reports are appreciated. //! //! On the other hand `core` and `alloc` are most likely to work in such environments with //! the caveat that any hookable behavior such as panics, oom handling or allocators will also //! depend on the compatibility of the hooks. //! //! Some features may also behave differently outside main, e.g. stdio could become unbuffered, //! some panics might turn into aborts, backtraces might not get symbolicated or similar. //! //! Non-exhaustive list of known limitations: //! //! - after-main use of thread-locals, which also affects additional features: //!   - [`thread::current()`] //!   - [`thread::scope()`] //!   - [`sync::mpsc`] //! - before-main stdio file descriptors are not guaranteed to be open on unix platforms //! //! </ins> //! [I/O]: io //! [`MIN`]: i32::MIN //! [`MAX`]: i32::MAX


Question:
All existing standard library documentation implicitly assumes that the APIs are being used between the start of a Rust and end of . For example  does not document any indication that the function would panic. It does not need to document that, because the function cannot panic, as long as the call occurs within the duration of . However it's possible to observe a panic like this: (Related PR and discussion: ) In general using the standard library from an callback, or before through a static constructor, is UB: according to "we can't really guarantee anything specific happens [...]; at least not in a cross-platform way." Is this worth calling out centrally as a caveat to all other documentation of the standard library? At the top level of the whole crate (it would perhaps be more prominent than it deserves), at the module level, or in the Reference? Certainly for , , , the expectation users need to have is that nothing in there will work outside of . Are there APIs it makes sense to carve out as being permissible outside of ? Stuff like , , , , etc. We'd maybe need to do research into how constructors and atexit are being used in the wild. For example the crate relies on , , and to be usable before : It seems obvious that those things should work but there isn't documentation which guarantees it. I assume that makes the crate technically unsound as written.
IMHO, core types should work in whatever context but libstd is more dicey. It more explicitly has a runtime or three (e.g. Rust's, libc's and the OS's). So at a minimum anything in the modules , , , , , , , etc should be regarded with suspicion unless documented otherwise. In summary, my thoughts are: is fine depends on the allocator used assumes code is running in main (except for the and possibly stuff)
Core types can still panic and panics do IO.
Hm... how much of an issue is that? Panics don't have to do I/O (e.g. if stderr is closed) so if platforms don't support that before or after main then it can be silently skipped, no?
But do we do that properly today? And it's not just IO but also panic hooks which in turn can rely on various other parts of std.
I think it would be fine to document that e.g. after main they may want to set an empty (or aborting) panic hook if panicking is possible. I really don't want to be in a situation where the user is in a worse place than if they'd just used .
Could we turn panics into immediate aborts after main? That would also avoid the backtrace printing and symbolication.
I looked through the standard library, and is the only function that has limitation on usage before/after main (in this case, this is only a problem during TLS destruction). This function is also called from , and , which can therefore panic when called during TLS destruction. and might be able to be reworked to avoid this, but this is fundamentally a limitation of since it requires a reference to the current to work. The stack guard used by the stack overflow handler also accesses the same TLS slot as , but since the stack bounds don't have a this could be moved to a separate to properly support stack overflow handling during TLS destruction.
If we're going to make a statement at all then imo we should start out with something more cautious than making solid guarantees since this would be a pretty wide-ranging promise. before/after main behavior is not tested. It is best-effort and if someone relies on it they should have their own tests core and alloc are expected to work because they don't touch OS APIs or global state caveat: user code in any hookable API like panic handlers, global allocators, OOM handler or any future hooks. Especially panics affect a lot of code. we might replace hooks after main? most existing parts of std, backtrace and other things interacting with the OS are expected to work but there may be platform-specific edge-cases and the behavior may change in the future due to changing implementation details or new features that depend more runtime state (e.g. a std threadpool or async runtime) then finally a list of known limitations
Proposed documentation based on my previous comment:

//! [rust-discord]: https://discord.gg/rust-lang //! [array]: prim@array //! [slice]: prim@slice // To run std tests without x.py without ending up with two copies of std, Miri needs to be // able to "empty" this crate. See <https://github.com/rust-lang/miri-test-libstd/issues/4>. // rustc itself never sets the feature, so this line has no effect there.


Question:
Tello-edu The says use my build failed with error <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc could you provide some input here? Thanks!
The rustdoc book documents rustdoc flags. You are passing this flag to cargo. I don't remember how to configure cargo for this argument off the top of my head, but you should look in the cargo book for how.
Oh wait, apparently the rustdoc book directly documents using this with it's probably just outdated then - I'll transfer this to rust-lang/rust.
Btw it works fine after taking out the "=examples"
claim

This feature is unstable, so you can enable it by calling Rustdoc with the unstable `rustdoc-scrape-examples` flag: ```bash <del> cargo doc -Zunstable-options -Zrustdoc-scrape-examples=examples </del> <ins> cargo doc -Zunstable-options -Zrustdoc-scrape-examples </ins> ``` To enable this feature on [docs.rs](https://docs.rs), add this to your Cargo.toml: ```toml [package.metadata.docs.rs] <del> cargo-args = ["-Zunstable-options", "-Zrustdoc-scrape-examples=examples"] </del> <ins> cargo-args = ["-Zunstable-options", "-Zrustdoc-scrape-examples"] </ins> ```


Question: Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexMap}; use rustc_errors::{Applicability, DiagnosticArgValue, DiagnosticId, IntoDiagnosticArg}; use rustc_hir::def::Namespace::{self, *}; <del> use rustc_hir::def::{self, CtorKind, DefKind, LifetimeRes, PartialRes, PerNS}; </del> <ins> use rustc_hir::def::{self, CtorKind, DefKind, LifetimeRes, NonMacroAttrKind, PartialRes, PerNS}; </ins> use rustc_hir::def_id::{DefId, LocalDefId, CRATE_DEF_ID, LOCAL_CRATE}; use rustc_hir::{BindingAnnotation, PrimTy, TraitCandidate}; use rustc_middle::middle::resolve_bound_vars::Set1;


Question: Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

} } <del> fn resolve_and_cache_rustdoc_path(&mut self, path_str: &str, ns: Namespace) -> bool { </del> <ins> fn resolve_and_cache_rustdoc_path(&mut self, path_str: &str, ns: Namespace) -> Option<Res> { </ins> // FIXME: This caching may be incorrect in case of multiple `macro_rules` // items with the same name in the same module. // Also hygiene is not considered. let mut doc_link_resolutions = std::mem::take(&mut self.r.doc_link_resolutions); <del> let res = doc_link_resolutions </del> <ins> let res = *doc_link_resolutions </ins> .entry(self.parent_scope.module.nearest_parent_mod().expect_local()) .or_default() .entry((Symbol::intern(path_str), ns))


Question: Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

return None; } res <del> }) .is_some(); </del> <ins> }); </ins> self.r.doc_link_resolutions = doc_link_resolutions; res }


Question: Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

let mut any_resolved = false; let mut need_assoc = false; for ns in [TypeNS, ValueNS, MacroNS] { <del> if self.resolve_and_cache_rustdoc_path(&path_str, ns) { any_resolved = true; </del> <ins> if let Some(res) = self.resolve_and_cache_rustdoc_path(&path_str, ns) { // Rustdoc ignores tool attribute resolutions and attempts // to resolve their prefixes for diagnostics. any_resolved = !matches!(res, Res::NonMacroAttr(NonMacroAttrKind::Tool)); </ins> } else if ns != MacroNS { need_assoc = true; }


Question: Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

Def(kind, id) => Ok(Res::Def(kind, id)), PrimTy(prim) => Ok(Res::Primitive(PrimitiveType::from_hir(prim))), // e.g. `#[derive]` <del> NonMacroAttr(..) | Err => Result::Err(()), </del> <ins> ToolMod | NonMacroAttr(..) | Err => Result::Err(()), </ins> other => bug!("unrecognized res {:?}", other), } }


Question: Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

<ins> // Regression test for <https://github.com/rust-lang/rust/issues/111189>. // This test ensures that it doesn't crash. #![deny(warnings)] /// #[rustfmt::skip] //~^ ERROR unresolved link to `rustfmt::skip` /// #[clippy::whatever] //~^ ERROR unresolved link to `clippy::whatever` pub fn foo() {} </ins>


Question: Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details

<ins> error: unresolved link to `rustfmt::skip` --> $DIR/issue-111189-resolution-ice.rs:6:7 | LL | /// #[rustfmt::skip] |       ^^^^^^^^^^^^^ no item named `rustfmt` in scope | note: the lint level is defined here --> $DIR/issue-111189-resolution-ice.rs:4:9 | LL | #![deny(warnings)] |         ^^^^^^^^ = note: `#[deny(rustdoc::broken_intra_doc_links)]` implied by `#[deny(warnings)]` error: unresolved link to `clippy::whatever` --> $DIR/issue-111189-resolution-ice.rs:8:7 | LL | /// #[clippy::whatever] |       ^^^^^^^^^^^^^^^^ no item named `clippy` in scope error: aborting due to 2 previous errors </ins>


Question:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

) -> Result<std::ops::Range<BasicBlock>, &'static str> { let callee_attrs = self.tcx.codegen_fn_attrs(callsite.callee.def_id()); self.check_codegen_attributes(callsite, callee_attrs)?; <ins> let terminator = caller_body[callsite.block].terminator.as_ref().unwrap(); let TerminatorKind::Call { args, destination, .. } = &terminator.kind else { bug!() }; let destination_ty = destination.ty(&caller_body.local_decls, self.tcx).ty; for arg in args { if !arg.ty(&caller_body.local_decls, self.tcx).is_sized(self.tcx, self.param_env) { // We do not allow inlining functions with unsized params. Inlining these functions // could create unsized locals, which are unsound and being phased out. return Err("Call has unsized argument"); } } </ins> self.check_mir_is_available(caller_body, &callsite.callee)?; let callee_body = try_instance_mir(self.tcx, callsite.callee.def)?; self.check_mir_body(callsite, callee_body, callee_attrs)?;


Question:
Inlining introduces unsized temporaries. This is problematic since unsized temporaries fail to uphold alignment requirements as described in . For example:
The unsized locals alignment issue itself was fixed in .

// Check call signature compatibility. // Normally, this shouldn't be required, but trait normalization failure can create a // validation ICE. <del> let terminator = caller_body[callsite.block].terminator.as_ref().unwrap(); let TerminatorKind::Call { args, destination, .. } = &terminator.kind else { bug!() }; let destination_ty = destination.ty(&caller_body.local_decls, self.tcx).ty; </del> let output_type = callee_body.return_ty(); if !util::is_subtype(self.tcx, self.param_env, output_type, destination_ty) { trace!(?output_type, ?destination_ty);