Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

// Local js definitions: /* global addClass, getCurrentValue, onEachLazy, removeClass, browserSupportsHistoryApi */ <del> /* global updateLocalStorage */ </del> <ins> /* global updateLocalStorage, getVar */ </ins> "use strict"; (function() { <del> const rootPath = document.getElementById("rustdoc-vars").attributes["data-root-path"].value; </del> <ins> const rootPath = getVar("root-path"); </ins> const NAME_OFFSET = 0; const DIRS_OFFSET = 1;


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

// Get a value from the rustdoc-vars div, which is used to convey data from // Rust to the JS. If there is no such element, return null. const getVar = (function getVar(name) { <del> const el = document.getElementById("rustdoc-vars"); </del> <ins> const el = document.querySelector("head > meta[name='rustdoc-vars']"); </ins> return el ? el.attributes["data-" + name].value : null; });


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

{% endfor %} ></script> {# #} {% endif %} <del> <div id="rustdoc-vars" {#+ #} </del> <ins> <meta name="rustdoc-vars" {#+ #} </ins> data-root-path="{{page.root_path|safe}}" {#+ #} data-static-root-path="{{static_root_path|safe}}" {#+ #} data-current-crate="{{layout.krate}}" {#+ #}


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

data-theme-dark-css="{{files.theme_dark_css}}" {#+ #} data-theme-ayu-css="{{files.theme_ayu_css}}" {#+ #} > {# #} <del> </div> {# #} </del> <script src="{{static_root_path|safe}}{{files.storage_js}}"></script> {# #} {% if page.css_class.contains("crate") %} <script defer src="{{page.root_path|safe}}crates{{page.resource_suffix}}.js"></script> {# #}


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.

// @has test.css // @has foo/struct.Foo.html <del> // @has - '//*[@id="rustdoc-vars"]/@data-themes' 'test' </del> <ins> // @has - '//*[@name="rustdoc-vars"]/@data-themes' 'test' </ins> pub struct Foo;


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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<del> // check-pass trait A { type Assoc; } impl A for () { // FIXME: it would be nice for this to at least cause a warning. type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() {} </del>


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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<del> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` trait A { type Assoc: ?Sized; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { let x: Foo<()>; } </del>


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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<del> error[E0391]: cycle detected when computing layout of `Foo<()>` | = note: ...which requires computing layout of `<() as A>::Assoc`... = note: ...which again requires computing layout of `Foo<()>`, completing the cycle note: cycle used when elaborating drops for `main` --> $DIR/recursive-type-2.rs:11:1 | LL | fn main() { | ^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0391`. </del>


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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<ins> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` trait A { type Assoc: ?Sized; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { let x: Foo<()>; } </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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<ins> error[E0391]: cycle detected when computing layout of `Foo<()>` | = note: ...which requires computing layout of `<() as A>::Assoc`... = note: ...which again requires computing layout of `Foo<()>`, completing the cycle note: cycle used when elaborating drops for `main` --> $DIR/recursive-type-binding.rs:11:1 | LL | fn main() { | ^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0391`. </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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<ins> // build-fail //~^ ERROR cycle detected when computing layout of `Foo<()>` // Regression test for a stack overflow: https://github.com/rust-lang/rust/issues/113197 trait A { type Assoc; } impl A for () { type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); fn main() { Foo::<()>(todo!()); } </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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<ins> error[E0391]: cycle detected when computing layout of `Foo<()>` | = note: ...which requires computing layout of `<() as A>::Assoc`... = note: ...which again requires computing layout of `Foo<()>`, completing the cycle note: cycle used when elaborating drops for `main` --> $DIR/recursive-type-coercion-from-never.rs:14:1 | LL | fn main() { | ^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0391`. </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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium

<ins> // check-pass trait A { type Assoc; } impl A for () { // FIXME: it would be nice for this to at least cause a warning. type Assoc = Foo<()>; } struct Foo<T: A>(T::Assoc); 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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

use rustc_hir as hir; use rustc_hir::def::Res; use rustc_hir::def_id::DefId; <del> use rustc_infer::traits::ObligationCauseCode; </del> <ins> use rustc_infer::{infer::type_variable::TypeVariableOriginKind, traits::ObligationCauseCode}; </ins> use rustc_middle::ty::{self, Ty, TyCtxt, TypeSuperVisitable, TypeVisitable, TypeVisitor}; use rustc_span::{self, symbol::kw, Span}; use rustc_trait_selection::traits;


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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

type BreakTy = ty::GenericArg<'tcx>; fn visit_ty(&mut self, ty: Ty<'tcx>) -> std::ops::ControlFlow<Self::BreakTy> { if let Some(origin) = self.0.type_var_origin(ty) <del> && let rustc_infer::infer::type_variable::TypeVariableOriginKind::TypeParameterDefinition(_, def_id) = origin.kind </del> <ins> && let TypeVariableOriginKind::TypeParameterDefinition(_, def_id) = origin.kind </ins> && let generics = self.0.tcx.generics_of(self.1) && let Some(index) = generics.param_def_id_to_index(self.0.tcx, def_id) && let Some(subst) = ty::GenericArgs::identity_for_item(self.0.tcx, self.1)


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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

let ty_vars = infcx_inner.type_variables(); let var_origin = ty_vars.var_origin(ty_vid); if let TypeVariableOriginKind::TypeParameterDefinition(name, def_id) = var_origin.kind <del> && !var_origin.span.from_expansion() </del> <ins> && name != kw::SelfUpper && !var_origin.span.from_expansion() </ins> { let generics = infcx.tcx.generics_of(infcx.tcx.parent(def_id)); let idx = generics.param_def_id_to_index(infcx.tcx, def_id).unwrap();


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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

// If there is only one implementation of the trait, suggest using it. // Otherwise, use a placeholder comment for the implementation. let (message, impl_suggestion) = if non_blanket_impl_count == 1 {( <del> "use the fully-qualified path to the only available implementation".to_string(), </del> <ins> "use the fully-qualified path to the only available implementation", </ins> format!("<{} as ", self.tcx.type_of(impl_def_id).instantiate_identity()) <del> )} else {( format!( "use a fully-qualified path to a specific available implementation ({} found)", non_blanket_impl_count ), "</* self type */ as ".to_string() </del> <ins> )} else { ("use a fully-qualified path to a specific available implementation", "</* self type */ as ".to_string() </ins> )}; let mut suggestions = vec![( path.span.shrink_to_lo(),


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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

LL |     let cont: u32 = Generator::create(); |                     ^^^^^^^^^^^^^^^^^ cannot call associated function of trait | <del> help: use a fully-qualified path to a specific available implementation (2 found) </del> <ins> help: use a fully-qualified path to a specific available implementation </ins> | LL |     let cont: u32 = </* self type */ as Generator>::create(); |                     +++++++++++++++++++          +


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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

LL |     MyTrait2::my_fn(); |     ^^^^^^^^^^^^^^^ cannot call associated function of trait | <del> help: use a fully-qualified path to a specific available implementation (2 found) </del> <ins> help: use a fully-qualified path to a specific available implementation </ins> | LL |     </* self type */ as MyTrait2>::my_fn(); |     +++++++++++++++++++         +


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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

<ins> // Regression test for #113610 where we ICEd when trying to print // inference variables created by instantiating the self type parameter. fn main() { let _ = (Default::default(),); //~^ ERROR cannot call associated function on trait } </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
cc
Thanks for the ping. It seems to be that here it's not always the parent which has , sometimes its on the as-is. I'm not entirely sure when we need the (IIRC it doesn't work for my test case if I don't add ).
Now if I stick to only using and not its parent, the line ICEs on my PR's test case because it can't find the param index for the . cc sorry for the ping, but do you know if here is special somehow? The debug path for my PR's test case seems to have another layer compared to this issue's ICE example, namely . I think this is why getting for my PR test case's parent worked but not for this ICE?
going to look into this, I think using is correct and the bug is somewhere else :sweat_smile:

<ins> error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type --> $DIR/infer-var-for-self-param.rs:5:14 | LL |     let _ = (Default::default(),); |              ^^^^^^^^^^^^^^^^ cannot call associated function of trait | help: use a fully-qualified path to a specific available implementation | LL |     let _ = (</* self type */ as Default>::default(),); |              +++++++++++++++++++        + error: aborting due to previous error For more information about this error, try `rustc --explain E0790`. </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. use std::io; use std::vec; pub struct Container<'a> { reader: &'a mut Reader //~ ERROR explicit lifetime bound required } impl<'a> Container<'a> { pub fn wrap<'s>(reader: &'s mut Reader) -> Container<'s> { Container { reader: reader } } pub fn read_to(&mut self, vec: &mut [u8]) { self.reader.read(vec); } } pub fn for_stdin<'a>() -> Container<'a> { let mut r = io::stdin(); Container::wrap(&mut r as &mut Reader) } fn main() { let mut c = for_stdin(); let mut v = vec::Vec::from_elem(10, 0u8); c.read_to(v.as_mut_slice()); } </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn blah() -> int { //~ ERROR not all control paths return a value 1i ; //~ NOTE consider removing this semicolon: } fn main() { } </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. #![feature(struct_variant)] mod a { pub enum Enum { EnumStructVariant { x: u8, y: u8, z: u8 } } pub fn get_enum_struct_variant() -> () { EnumStructVariant { x: 1, y: 2, z: 3 } //~^ ERROR mismatched types: expected `()`, found `a::Enum` (expected (), found enum a::Enum) } } mod b { mod test { use a; fn test_enum_struct_variant() { let enum_struct_variant = ::a::get_enum_struct_variant(); match enum_struct_variant { a::EnumStructVariant { x, y, z } => { //~^ ERROR error: mismatched types: expected `()`, found a structure pattern } } } } } fn main() {} </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let mut array = [1, 2, 3]; //~^ ERROR cannot determine a type for this local variable: cannot determine the type of this integ let pie_slice = array.slice(1, 2); } </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { let v = &[]; //~ ERROR cannot determine a type for this local variable: unconstrained type let it = v.iter(); } </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:explicit failure pub fn main() { fail!(); println!("{}", 1i); } </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // error-pattern:bad input fn main() { Some("foo").unwrap_or(fail!("bad input")).to_string(); } </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>


Question:
Here is a very simple program which employs trait objects: : : : When this program is compiled and run, it fails with segmentation fault: This program is not correct. You can see that function produces a for arbitrary lifetime , but the local variable is valid only for body. A pointer to , however, is saved to the , and when it is accessed inside , a segmentation fault occurs. However, Rust still compiles it. I thought that borrowing checker should prevent this kind of errors. BTW, I can write or and it will compile either way, but I thought that when going from plain pointers to trait objects I should always specify exact kind of trait object. Not sure that I'm right here thought.
cc
Sounds similar to ; potential duplicate?
This appears to be fixed: Original example code updated to current rust: : : :
Awesome! flagging as needstest (not sure if one already exists)

<ins> // Copyright 2014 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { if true { proc(_) {} } else { proc(_: &mut ()) {} }; } </ins>


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

} _ => {} } <del> // If someone calls a const fn, they can extract that call out into a separate constant (or a const // block in the future), so we check that to tell them that in the diagnostic. Does not affect typeck. let is_const_fn = match element.kind { </del> <ins> // If someone calls a const fn or constructs a const value, they can extract that // out into a separate constant (or a const block in the future), so we check that // to tell them that in the diagnostic. Does not affect typeck. let is_constable = match element.kind { </ins> hir::ExprKind::Call(func, _args) => match *self.node_ty(func.hir_id).kind() { <del> ty::FnDef(def_id, _) => tcx.is_const_fn(def_id), _ => false, </del> <ins> ty::FnDef(def_id, _) if tcx.is_const_fn(def_id) => traits::IsConstable::Fn, _ => traits::IsConstable::No, </ins> }, <del> _ => false, </del> <ins> hir::ExprKind::Path(qpath) => { match self.typeck_results.borrow().qpath_res(&qpath, element.hir_id) { Res::Def(DefKind::Ctor(_, CtorKind::Const), _) => traits::IsConstable::Ctor, _ => traits::IsConstable::No, } } _ => traits::IsConstable::No, </ins> }; // If the length is 0, we don't create any elements, so we don't copy any. If the length is 1, we // don't copy that one element, we move it. Only check for Copy if the length is larger. if count.try_eval_target_usize(tcx, self.param_env).map_or(true, |len| len > 1) { let lang_item = self.tcx.require_lang_item(LangItem::Copy, None); <del> let code = traits::ObligationCauseCode::RepeatElementCopy { is_const_fn }; </del> <ins> let code = traits::ObligationCauseCode::RepeatElementCopy { is_constable, elt_type: element_ty, elt_span: element.span, elt_stmt_span: self .tcx .hir() .parent_iter(element.hir_id) .find_map(|(_, node)| match node { hir::Node::Item(it) => Some(it.span), hir::Node::Stmt(stmt) => Some(stmt.span), _ => None, }) .expect("array repeat expressions must be inside an item or statement"), }; </ins> self.require_type_meets(element_ty, element.span, code, lang_item); } }


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

InlineAsmSized, /// `[expr; N]` requires `type_of(expr): Copy`. RepeatElementCopy { <del> /// If element is a `const fn` we display a help message suggesting to move the /// function call to a new `const` item while saying that `T` doesn't implement `Copy`. is_const_fn: bool, </del> <ins> /// If element is a `const fn` or const ctor we display a help message suggesting /// to move it to a new `const` item while saying that `T` doesn't implement `Copy`. is_constable: IsConstable, elt_type: Ty<'tcx>, elt_span: Span, /// Span of the statement/item in which the repeat expression occurs. We can use this to /// place a `const` declaration before it elt_stmt_span: Span, </ins> }, /// Types of fields (other than the last, except for packed structs) in a struct must be sized.


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

TypeAlias(InternedObligationCauseCode<'tcx>, Span, DefId), } <ins> /// Whether a value can be extracted into a const. /// Used for diagnostics around array repeat expressions. #[derive(Copy, Clone, Debug, PartialEq, Eq, HashStable, TyEncodable, TyDecodable)] pub enum IsConstable { No, /// Call to a const fn Fn, /// Use of a const ctor Ctor, } crate::TrivialTypeTraversalAndLiftImpls! { IsConstable, } </ins> /// The 'location' at which we try to perform HIR-based wf checking. /// This information is used to obtain an `hir::Ty`, which /// we can walk in order to obtain precise spans for any


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::infer::{DefineOpaqueTypes, InferOk, LateBoundRegionConversionTime}; use rustc_middle::hir::map; <ins> use rustc_middle::traits::IsConstable; </ins> use rustc_middle::ty::error::TypeError::{self, Sorts}; use rustc_middle::ty::{ self, suggest_arbitrary_trait_bound, suggest_constraining_type_param, AdtKind,


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

)); } } <del> ObligationCauseCode::RepeatElementCopy { is_const_fn } => { </del> <ins> ObligationCauseCode::RepeatElementCopy { is_constable, elt_type, elt_span, elt_stmt_span } => { </ins> err.note( "the `Copy` trait is required because this value will be copied for each element of the array", ); <del> if is_const_fn { err.help( "consider creating a new `const` item and initializing it with the result  of the function call to be used in the repeat position, like  `const VAL: Type = const_fn();` and `let x = [VAL; 42];`", ); </del> <ins> let value_kind = match is_constable { IsConstable::Fn => Some("the result of the function call"), IsConstable::Ctor => Some("the result of the constructor"), _ => None }; let sm = tcx.sess.source_map(); if let Some(value_kind) = value_kind && let Ok(snip) = sm.span_to_snippet(elt_span) { let help_msg = format!( "consider creating a new `const` item and initializing it with {value_kind}  to be used in the repeat position"); let indentation = sm.indentation_before(elt_stmt_span).unwrap_or_default(); err.multipart_suggestion(help_msg, vec![ (elt_stmt_span.shrink_to_lo(), format!("const ARRAY_REPEAT_VALUE: {elt_type} = {snip};n{indentation}")), (elt_span, "ARRAY_REPEAT_VALUE".to_string()) ], Applicability::MachineApplicable); </ins> } <del> if self.tcx.sess.is_nightly_build() && is_const_fn { </del> <ins> if self.tcx.sess.is_nightly_build() && matches!(is_constable, IsConstable::Fn|IsConstable::Ctor) { </ins> err.help( "create an inline `const` block, see RFC #2920  <https://github.com/rust-lang/rfcs/pull/2920> for more information",


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

| = note: required for `Option<Bar>` to implement `Copy` = note: the `Copy` trait is required because this value will be copied for each element of the array <del> = help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` </del> = help: create an inline `const` block, see RFC #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information help: consider annotating `Bar` with `#[derive(Copy)]` | LL + #[derive(Copy)] LL | struct Bar; | <ins> help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position | LL ~     const ARRAY_REPEAT_VALUE: Option<Bar> = no_copy(); LL ~     let _: [Option<Bar>; 2] = [ARRAY_REPEAT_VALUE; 2]; | </ins> error: aborting due to previous error


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

LL | #[derive(Copy, Clone)] |          ^^^^ unsatisfied trait bound introduced in this `derive` macro = note: the `Copy` trait is required because this value will be copied for each element of the array <del> = help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` </del> = help: create an inline `const` block, see RFC #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information = note: this error originates in the derive macro `Copy` (in Nightly builds, run with -Z macro-backtrace for more info) <ins> help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position | LL ~     const ARRAY_REPEAT_VALUE: Foo<String> = Foo(String::new()); LL ~     [ARRAY_REPEAT_VALUE; 4]; | </ins> error: aborting due to previous error


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

<ins> static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5]; //~^ ERROR the trait bound `String: Copy` is not satisfied </ins> fn main() { // should hint to create an inline `const` block // or to create a new `const` item <del> let strings: [String; 5] = [String::new(); 5]; </del> <ins> let _strings: [String; 5] = [String::new(); 5]; //~^ ERROR the trait bound `String: Copy` is not satisfied let _maybe_strings: [Option<String>; 5] = [None; 5]; </ins> //~^ ERROR the trait bound `String: Copy` is not satisfied <del> println!("{:?}", strings); </del> }


Question:
I'm basing this suggestion on two things. One, that if you follow it, the code compiles: and two, that the diagnostic help you get when you try to use a in the repeat position suggests something very similar, see "other cases." It would require the compiler to know that a value that is attempted to be repeated is able though, which I don't know whether it can, but I figured I'd suggest this, and you can reject it if it isn't possible to do. Alternatively, the help text could say something like "if the value can be made , consider creating [...]" I was inspired to make this issue based on the output you get when you try to use a as an array initializer. For instance, the code produces the output No response
hey why im getting this error message all over my github repository ! whenever i commit some changes, The first changes i able to create pull request but after some other changes im not able to do that why im getting these error ! Please help
I don't think your comment is related to this issue? If this is a problem you've encountered while trying to fix this issue, please reach out on instead.

error[E0277]: the trait bound `String: Copy` is not satisfied <del> --> $DIR/const-fn-in-vec.rs:4:33 </del> <ins> --> $DIR/const-fn-in-vec.rs:1:47 </ins> | <del> LL |     let strings: [String; 5] = [String::new(); 5]; |                                 ^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` </del> <ins> LL | static _MAYBE_STRINGS: [Option<String>; 5] = [None; 5]; |                                               ^^^^ the trait `Copy` is not implemented for `String` </ins> | <ins> = note: required for `Option<String>` to implement `Copy` </ins> = note: the `Copy` trait is required because this value will be copied for each element of the array <del> = help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position, like `const VAL: Type = const_fn();` and `let x = [VAL; 42];` </del> = help: create an inline `const` block, see RFC #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information <ins> help: consider creating a new `const` item and initializing it with the result of the constructor to be used in the repeat position | LL + const ARRAY_REPEAT_VALUE: Option<String> = None; LL ~ static _MAYBE_STRINGS: [Option<String>; 5] = [ARRAY_REPEAT_VALUE; 5]; | error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:7:34 | LL |     let _strings: [String; 5] = [String::new(); 5]; |                                  ^^^^^^^^^^^^^ the trait `Copy` is not implemented for `String` | = note: the `Copy` trait is required because this value will be copied for each element of the array = help: create an inline `const` block, see RFC #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information help: consider creating a new `const` item and initializing it with the result of the function call to be used in the repeat position | LL ~     const ARRAY_REPEAT_VALUE: String = String::new(); LL ~     let _strings: [String; 5] = [ARRAY_REPEAT_VALUE; 5]; | error[E0277]: the trait bound `String: Copy` is not satisfied --> $DIR/const-fn-in-vec.rs:9:48 | LL |     let _maybe_strings: [Option<String>; 5] = [None; 5]; |                                                ^^^^ the trait `Copy` is not implemented for `String` | = note: required for `Option<String>` to implement `Copy` = note: the `Copy` trait is required because this value will be copied for each element of the array = help: create an inline `const` block, see RFC #2920 <https://github.com/rust-lang/rfcs/pull/2920> for more information help: consider creating a new `const` item and initializing it with the result of the constructor to be used in the repeat position | LL ~     const ARRAY_REPEAT_VALUE: Option<String> = None; LL ~     let _maybe_strings: [Option<String>; 5] = [ARRAY_REPEAT_VALUE; 5]; | </ins> <del> error: aborting due to previous error </del> <ins> error: aborting due to 3 previous errors </ins> For more information about this error, try `rustc --explain E0277`.


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
This one works okay:
This one also (Just proxying a type, that means that something strange with struct's generics):
Bisected to but it probably just bubbles up a pre-existing issue that the OP could be massaged to emit without this PR, cc author just in case.
This worked fine before 1.70.0 so it's a regression.
minimized
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Once this will be fixed.

Self::new(List::empty(), self.reveal()) } <del> /// Creates a suitable environment in which to perform trait /// queries on the given value. When type-checking, this is simply /// the pair of the environment plus value. But when reveal is set to /// All, then if `value` does not reference any type parameters, we will /// pair it with the empty environment. This improves caching and is generally /// invisible. /// /// N.B., we preserve the environment when type-checking because it /// is possible for the user to have wacky where-clauses like /// `where Box<u32>: Copy`, which are clearly never /// satisfiable. We generally want to behave as if they were true, /// although the surrounding function is never reachable. </del> <ins> /// Creates a pair of param-env and value for use in queries. </ins> pub fn and<T: TypeVisitable<TyCtxt<'tcx>>>(self, value: T) -> ParamEnvAnd<'tcx, T> { <del> match self.reveal() { Reveal::UserFacing => ParamEnvAnd { param_env: self, value }, Reveal::All => { if value.is_global() { ParamEnvAnd { param_env: self.without_caller_bounds(), value } } else { ParamEnvAnd { param_env: self, value } } } } </del> <ins> ParamEnvAnd { param_env: self, value } </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
This one works okay:
This one also (Just proxying a type, that means that something strange with struct's generics):
Bisected to but it probably just bubbles up a pre-existing issue that the OP could be massaged to emit without this PR, cc author just in case.
This worked fine before 1.70.0 so it's a regression.
minimized
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Once this will be fixed.

<ins> // check-pass trait Bar<'a> { type Assoc: 'static; } impl<'a> Bar<'a> for () { type Assoc = (); } struct ImplsStatic<CG: Bar<'static>> { d: &'static <CG as Bar<'static>>::Assoc, } fn caller(b: ImplsStatic<()>) where for<'a> (): Bar<'a> { let _: &<() as Bar<'static>>::Assoc = b.d; } fn main() {} </ins>


Question:
's documentation says: However, is also specified to call the hook set with (unstable) which per its example is permitted to panic and thereby potentially unwind, and , a “likely” future version of might choose to panic on allocation failure instead. Therefore, the documentation should be changed to not imply that this function will always abort, which could be taken as a promise that it will never unwind. It also might be useful to expand the documentation of so that the text and not only the example code specifies that it's okay to unwind from the hook (and what happens if you don't). (See also which is broader but doesn't mention this aspect.) cc from label +A-allocators +T-libs-api <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

fn __rust_alloc_error_handler(size: usize, align: usize) -> !; } <del> /// Abort on memory allocation error or failure. </del> <ins> /// Signal a memory allocation error. </ins> /// <del> /// Callers of memory allocation APIs wishing to abort computation </del> <ins> /// Callers of memory allocation APIs wishing to cease execution </ins> /// in response to an allocation error are encouraged to call this function, <del> /// rather than directly invoking `panic!` or similar. </del> <ins> /// rather than directly invoking [`panic!`] or similar. </ins> /// <del> /// The default behavior of this function is to print a message to standard error /// and abort the process. /// It can be replaced with [`set_alloc_error_hook`] and [`take_alloc_error_hook`]. </del> <ins> /// This function is guaranteed to diverge (not return normally with a value), but depending on /// global configuration, it may either panic (resulting in unwinding or aborting as per /// configuration for all panics), or abort the process (with no unwinding). /// /// The default behavior is: /// ///  * If the binary links against `std` (typically the case), then ///   print a message to standard error and abort the process. ///   This behavior can be replaced with [`set_alloc_error_hook`] and [`take_alloc_error_hook`]. ///   Future versions of Rust may panic by default instead. /// /// * If the binary does not link against `std` (all of its crates are marked ///   [`#![no_std]`][no_std]), then call [`panic!`] with a message. ///   [The panic handler] applies as to any panic. </ins> /// /// [`set_alloc_error_hook`]: ../../std/alloc/fn.set_alloc_error_hook.html /// [`take_alloc_error_hook`]: ../../std/alloc/fn.take_alloc_error_hook.html <ins> /// [The panic handler]: https://doc.rust-lang.org/reference/runtime.html#the-panic_handler-attribute /// [no_std]: https://doc.rust-lang.org/reference/names/preludes.html#the-no_std-attribute </ins> #[stable(feature = "global_alloc", since = "1.28.0")] #[rustc_const_unstable(feature = "const_alloc_error", issue = "92523")] #[cfg(all(not(no_global_oom_handling), not(test)))]


Question:
's documentation says: However, is also specified to call the hook set with (unstable) which per its example is permitted to panic and thereby potentially unwind, and , a “likely” future version of might choose to panic on allocation failure instead. Therefore, the documentation should be changed to not imply that this function will always abort, which could be taken as a promise that it will never unwind. It also might be useful to expand the documentation of so that the text and not only the example code specifies that it's okay to unwind from the hook (and what happens if you don't). (See also which is broader but doesn't mention this aspect.) cc from label +A-allocators +T-libs-api <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim

/// Registers a custom allocation error hook, replacing any that was previously registered. /// <del> /// The allocation error hook is invoked when an infallible memory allocation fails, before /// the runtime aborts. The default hook prints a message to standard error, /// but this behavior can be customized with the [`set_alloc_error_hook`] and /// [`take_alloc_error_hook`] functions. </del> <ins> /// The allocation error hook is invoked when an infallible memory allocation fails — that is, /// as a consequence of calling [`handle_alloc_error`] — before the runtime aborts. </ins> /// <del> /// The hook is provided with a `Layout` struct which contains information </del> <ins> /// The allocation error hook is a global resource. [`take_alloc_error_hook`] may be used to /// retrieve a previously registered hook and wrap or discard it. /// /// # What the provided `hook` function should expect /// /// The hook function is provided with a [`Layout`] struct which contains information </ins> /// about the allocation that failed. /// <del> /// The allocation error hook is a global resource. </del> <ins> /// The hook function may choose to panic or abort; in the event that it returns normally, this /// will cause an immediate abort. /// /// Since [`take_alloc_error_hook`] is a safe function that allows retrieving the hook, the hook /// function must be _sound_ to call even if no memory allocations were attempted. /// /// # The default hook /// /// The default hook, used if [`set_alloc_error_hook`] is never called, prints a message to /// standard error (and then returns, causing the runtime to abort the process). /// Compiler options may cause it to panic instead, and the default behavior may be changed /// to panicking in future versions of Rust. </ins> /// /// # Examples ///


Question:
Hashbrown crate starts fail when running: , , with: <details<summaryBacktrace</summary<pFor : </p</details
Could this be related to cc
I'm also seeing this on x86_64 with the recent nightlies: Update 1: It seems like in both cases it's related to cross. The original PR mentions problems with old versions. Could it be that cross needs to update their docker images? (Though they seem to be based on Ubuntu 20, which doesn't seem THAT old) Update 2: cross runs
Centos 7 used by i686-dist builder seems to use Binutils 2.27, dist-armv7 uses Binutils 2.32 and dist-various1 (so thumbv6m-none-eabi) uses Binutils 2.38. They all are indeed newer than:
hashbrown ci uses cross 0.2.5, which is the latest stable release for cross. To fix this issue with cross specifically, one can set the image used by cross to be a newer version, cross 0.2.5 images use ubuntu 16.04, we can change that with the env vars or config (see ) (make sure to set the correct env-var and image for the specific target)
The diagnostic looks similar to a binutils 2.41 change I made to fix ld: Allow RX8664GOTPCREL for call *_tlsgetaddr Threadlocal int a; int main() { return a; } % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no /tmp/ccSSBgrg.o: TLS transition from RX8664TLSGD to RX8664_GOTTPOFF against .text' failed failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status There is incompatibility between  and with GNU ld<2.41. You may need to figure out where similar semantics are used.
Ran into this in github CI today as well (e.g. ). Works fine locally on Arch though when I try to recreate it. EDIT: Managed to reproduce it locally. I was mixing up -gnu and -musl targets, my bad.
Posted a revert at
This is really not a great solution for projects that build binaries for releases though (like I do). To target an old enough glibc to work on all systems (e.g. CentOS/RHEL, stable Debian, etc) you need to build on a fairly old distro. And then you also get older ld etc as well. It would be great if you could tell rust & gcc (for native dependencies) to target an older glibc than the system one, that would solve a lot of issues.
In GCC/Clang, can happen with . is to use modern GCC/Clang style . I am not sure why is related to the problem. I think I should keep arguing for for all targets, not just non-x86. is prone to cause such problems for GNU ld and possibly mold.
cc
I apologize to everyone, forgot about this issue. I can state that this issue is closed and no longer relevant. suggestion (as a workaround) and pull request fixed the issue.

tracked!(profile_emit, Some(PathBuf::from("abc"))); tracked!(profile_sample_use, Some(PathBuf::from("abc"))); tracked!(profiler_runtime, "abc".to_string()); <del> tracked!(relax_elf_relocations, Some(false)); </del> <ins> tracked!(relax_elf_relocations, Some(true)); </ins> tracked!(relro_level, Some(RelroLevel::Full)); tracked!(remap_cwd_prefix, Some(PathBuf::from("abc"))); tracked!(report_delayed_bugs, true);


Question:
Hashbrown crate starts fail when running: , , with: <details<summaryBacktrace</summary<pFor : </p</details
Could this be related to cc
I'm also seeing this on x86_64 with the recent nightlies: Update 1: It seems like in both cases it's related to cross. The original PR mentions problems with old versions. Could it be that cross needs to update their docker images? (Though they seem to be based on Ubuntu 20, which doesn't seem THAT old) Update 2: cross runs
Centos 7 used by i686-dist builder seems to use Binutils 2.27, dist-armv7 uses Binutils 2.32 and dist-various1 (so thumbv6m-none-eabi) uses Binutils 2.38. They all are indeed newer than:
hashbrown ci uses cross 0.2.5, which is the latest stable release for cross. To fix this issue with cross specifically, one can set the image used by cross to be a newer version, cross 0.2.5 images use ubuntu 16.04, we can change that with the env vars or config (see ) (make sure to set the correct env-var and image for the specific target)
The diagnostic looks similar to a binutils 2.41 change I made to fix ld: Allow RX8664GOTPCREL for call *_tlsgetaddr Threadlocal int a; int main() { return a; } % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no /tmp/ccSSBgrg.o: TLS transition from RX8664TLSGD to RX8664_GOTTPOFF against .text' failed failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status There is incompatibility between  and with GNU ld<2.41. You may need to figure out where similar semantics are used.
Ran into this in github CI today as well (e.g. ). Works fine locally on Arch though when I try to recreate it. EDIT: Managed to reproduce it locally. I was mixing up -gnu and -musl targets, my bad.
Posted a revert at
This is really not a great solution for projects that build binaries for releases though (like I do). To target an old enough glibc to work on all systems (e.g. CentOS/RHEL, stable Debian, etc) you need to build on a fairly old distro. And then you also get older ld etc as well. It would be great if you could tell rust & gcc (for native dependencies) to target an older glibc than the system one, that would solve a lot of issues.
In GCC/Clang, can happen with . is to use modern GCC/Clang style . I am not sure why is related to the problem. I think I should keep arguing for for all targets, not just non-x86. is prone to cause such problems for GNU ld and possibly mold.
cc
I apologize to everyone, forgot about this issue. I can state that this issue is closed and no longer relevant. suggestion (as a workaround) and pull request fixed the issue.

mcount: "mcount".into(), llvm_mcount_intrinsic: None, llvm_abiname: "".into(), <del> relax_elf_relocations: true, </del> <ins> relax_elf_relocations: false, </ins> llvm_args: cvs![], use_ctors_section: false, eh_frame_header: true,


Question:
Hashbrown crate starts fail when running: , , with: <details<summaryBacktrace</summary<pFor : </p</details
Could this be related to cc
I'm also seeing this on x86_64 with the recent nightlies: Update 1: It seems like in both cases it's related to cross. The original PR mentions problems with old versions. Could it be that cross needs to update their docker images? (Though they seem to be based on Ubuntu 20, which doesn't seem THAT old) Update 2: cross runs
Centos 7 used by i686-dist builder seems to use Binutils 2.27, dist-armv7 uses Binutils 2.32 and dist-various1 (so thumbv6m-none-eabi) uses Binutils 2.38. They all are indeed newer than:
hashbrown ci uses cross 0.2.5, which is the latest stable release for cross. To fix this issue with cross specifically, one can set the image used by cross to be a newer version, cross 0.2.5 images use ubuntu 16.04, we can change that with the env vars or config (see ) (make sure to set the correct env-var and image for the specific target)
The diagnostic looks similar to a binutils 2.41 change I made to fix ld: Allow RX8664GOTPCREL for call *_tlsgetaddr Threadlocal int a; int main() { return a; } % gcc -fno-plt -fpic a.c -fuse-ld=bfd -Wa,-mrelax-relocations=no /tmp/ccSSBgrg.o: TLS transition from RX8664TLSGD to RX8664_GOTTPOFF against .text' failed failed to set dynamic section sizes: bad value collect2: error: ld returned 1 exit status There is incompatibility between  and with GNU ld<2.41. You may need to figure out where similar semantics are used.
Ran into this in github CI today as well (e.g. ). Works fine locally on Arch though when I try to recreate it. EDIT: Managed to reproduce it locally. I was mixing up -gnu and -musl targets, my bad.
Posted a revert at
This is really not a great solution for projects that build binaries for releases though (like I do). To target an old enough glibc to work on all systems (e.g. CentOS/RHEL, stable Debian, etc) you need to build on a fairly old distro. And then you also get older ld etc as well. It would be great if you could tell rust & gcc (for native dependencies) to target an older glibc than the system one, that would solve a lot of issues.
In GCC/Clang, can happen with . is to use modern GCC/Clang style . I am not sure why is related to the problem. I think I should keep arguing for for all targets, not just non-x86. is prone to cause such problems for GNU ld and possibly mold.
cc
I apologize to everyone, forgot about this issue. I can state that this issue is closed and no longer relevant. suggestion (as a workaround) and pull request fixed the issue.

position_independent_executables: true, pre_link_args, override_export_symbols: Some(EXPORT_SYMBOLS.iter().cloned().map(Cow::from).collect()), <ins> relax_elf_relocations: true, </ins> ..Default::default() }; Target {


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --When using the syntax in the Display format in formatting macros, the is ignored and treated as a . I tried this code: I expected to see this happen: Getting an error that is out of the bounds for type . Instead, this happened: This function compiles and prints . <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I went and looked through the implementation and found where the issue comes from. The check at ignores the integer type, and it blindly calls on the value of the literal.
claim
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Did run a bisection on the reproducible provided (and duplicated ) Regression in nightly-2023-04-22, specifically I think commit or (as pointed out in PR ) found 11 bors merge commits in the specified range commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk commit[2] 2023-04-21: Auto merge of - c410-f3r:dqewdas, r=petrochenkov commit[3] 2023-04-21: Auto merge of - jsoref:spelling-src-etc, r=Mark-Simulacrum commit[4] 2023-04-21: Auto merge of - matthiaskrgr:rollup-, r=matthiaskrgr commit[5] 2023-04-21: Auto merge of - cjgillot:query-feed, r=oli-obk commit[6] 2023-04-21: Auto merge of - michaelvanstraten:master, r=petrochenkov commit[7] 2023-04-21: Auto merge of - petrochenkov:qcstore4, r=cjgillot commit[8] 2023-04-21: Auto merge of - saethlin:mir-pass-cooperation, r=cjgillot commit[9] 2023-04-21: Auto merge of - cjgillot:const-prop-lint-junk, r=oli-obk commit[10] 2023-04-21: Auto merge of - Dylan-DPC:rollup-em3ovcq, r=Dylan-DPC cc
Looks like it's not easy invoke the same integer-literal-range-checking code from the place where formatargs!() is expanded. So the easiest solution is probably to expand to something like when literals are removed, such that the literals are still be checked later.
Actually, looks like there is a much easier fix that mostly just involves removing code. ^^' Will send a PR soon, probably tomorrow.
Fix:

let mut fmt = Cow::Borrowed(fmt); if self.tcx.sess.opts.unstable_opts.flatten_format_args { fmt = flatten_format_args(fmt); <del> fmt = inline_literals(fmt); </del> <ins> fmt = self.inline_literals(fmt); </ins> } expand_format_args(self, sp, &fmt, allow_const) } <ins> /// Try to convert a literal into an interned string fn try_inline_lit(&self, lit: token::Lit) -> Option<Symbol> { match LitKind::from_token_lit(lit) { Ok(LitKind::Str(s, _)) => Some(s), Ok(LitKind::Int(n, ty)) => { match ty { // unsuffixed integer literals are assumed to be i32's LitIntType::Unsuffixed => { (n <= i32::MAX as u128).then_some(Symbol::intern(&n.to_string())) } LitIntType::Signed(int_ty) => { let max_literal = self.int_ty_max(int_ty); (n <= max_literal).then_some(Symbol::intern(&n.to_string())) } LitIntType::Unsigned(uint_ty) => { let max_literal = self.uint_ty_max(uint_ty); (n <= max_literal).then_some(Symbol::intern(&n.to_string())) } } } _ => None, } } /// Get the maximum value of int_ty. It is platform-dependent due to the byte size of isize fn int_ty_max(&self, int_ty: IntTy) -> u128 { match int_ty { IntTy::Isize => self.tcx.data_layout.pointer_size.signed_int_max() as u128, IntTy::I8 => i8::MAX as u128, IntTy::I16 => i16::MAX as u128, IntTy::I32 => i32::MAX as u128, IntTy::I64 => i64::MAX as u128, IntTy::I128 => i128::MAX as u128, } } /// Get the maximum value of uint_ty. It is platform-dependent due to the byte size of usize fn uint_ty_max(&self, uint_ty: UintTy) -> u128 { match uint_ty { UintTy::Usize => self.tcx.data_layout.pointer_size.unsigned_int_max(), UintTy::U8 => u8::MAX as u128, UintTy::U16 => u16::MAX as u128, UintTy::U32 => u32::MAX as u128, UintTy::U64 => u64::MAX as u128, UintTy::U128 => u128::MAX as u128, } } /// Inline literals into the format string. /// /// Turns /// /// `format_args!("Hello, {}! {} {}", "World", 123, x)` /// /// into /// /// `format_args!("Hello, World! 123 {}", x)`. fn inline_literals<'fmt>(&self, mut fmt: Cow<'fmt, FormatArgs>) -> Cow<'fmt, FormatArgs> { let mut was_inlined = vec![false; fmt.arguments.all_args().len()]; let mut inlined_anything = false; for i in 0..fmt.template.len() { let FormatArgsPiece::Placeholder(placeholder) = &fmt.template[i] else { continue }; let Ok(arg_index) = placeholder.argument.index else { continue }; let mut literal = None; if let FormatTrait::Display = placeholder.format_trait && placeholder.format_options == Default::default() && let arg = fmt.arguments.all_args()[arg_index].expr.peel_parens_and_refs() && let ExprKind::Lit(lit) = arg.kind { literal = self.try_inline_lit(lit); } if let Some(literal) = literal { // Now we need to mutate the outer FormatArgs. // If this is the first time, this clones the outer FormatArgs. let fmt = fmt.to_mut(); // Replace the placeholder with the literal. fmt.template[i] = FormatArgsPiece::Literal(literal); was_inlined[arg_index] = true; inlined_anything = true; } } // Remove the arguments that were inlined. if inlined_anything { let fmt = fmt.to_mut(); let mut remove = was_inlined; // Don't remove anything that's still used. for_all_argument_indexes(&mut fmt.template, |index| remove[*index] = false); // Drop all the arguments that are marked for removal. let mut remove_it = remove.iter(); fmt.arguments.all_args_mut().retain(|_| remove_it.next() != Some(&true)); // Calculate the mapping of old to new indexes for the remaining arguments. let index_map: Vec<usize> = remove .into_iter() .scan(0, |i, remove| { let mapped = *i; *i += !remove as usize; Some(mapped) }) .collect(); // Correct the indexes that refer to arguments that have shifted position. for_all_argument_indexes(&mut fmt.template, |index| *index = index_map[*index]); } fmt } </ins> } /// Flattens nested `format_args!()` into one.


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --When using the syntax in the Display format in formatting macros, the is ignored and treated as a . I tried this code: I expected to see this happen: Getting an error that is out of the bounds for type . Instead, this happened: This function compiles and prints . <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I went and looked through the implementation and found where the issue comes from. The check at ignores the integer type, and it blindly calls on the value of the literal.
claim
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Did run a bisection on the reproducible provided (and duplicated ) Regression in nightly-2023-04-22, specifically I think commit or (as pointed out in PR ) found 11 bors merge commits in the specified range commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk commit[2] 2023-04-21: Auto merge of - c410-f3r:dqewdas, r=petrochenkov commit[3] 2023-04-21: Auto merge of - jsoref:spelling-src-etc, r=Mark-Simulacrum commit[4] 2023-04-21: Auto merge of - matthiaskrgr:rollup-, r=matthiaskrgr commit[5] 2023-04-21: Auto merge of - cjgillot:query-feed, r=oli-obk commit[6] 2023-04-21: Auto merge of - michaelvanstraten:master, r=petrochenkov commit[7] 2023-04-21: Auto merge of - petrochenkov:qcstore4, r=cjgillot commit[8] 2023-04-21: Auto merge of - saethlin:mir-pass-cooperation, r=cjgillot commit[9] 2023-04-21: Auto merge of - cjgillot:const-prop-lint-junk, r=oli-obk commit[10] 2023-04-21: Auto merge of - Dylan-DPC:rollup-em3ovcq, r=Dylan-DPC cc
Looks like it's not easy invoke the same integer-literal-range-checking code from the place where formatargs!() is expanded. So the easiest solution is probably to expand to something like when literals are removed, such that the literals are still be checked later.
Actually, looks like there is a much easier fix that mostly just involves removing code. ^^' Will send a PR soon, probably tomorrow.
Fix:

fmt } <del> /// Inline literals into the format string. /// /// Turns /// /// `format_args!("Hello, {}! {} {}", "World", 123, x)` /// /// into /// /// `format_args!("Hello, World! 123 {}", x)`. fn inline_literals(mut fmt: Cow<'_, FormatArgs>) -> Cow<'_, FormatArgs> { let mut was_inlined = vec![false; fmt.arguments.all_args().len()]; let mut inlined_anything = false; for i in 0..fmt.template.len() { let FormatArgsPiece::Placeholder(placeholder) = &fmt.template[i] else { continue }; let Ok(arg_index) = placeholder.argument.index else { continue }; let mut literal = None; if let FormatTrait::Display = placeholder.format_trait && placeholder.format_options == Default::default() && let arg = fmt.arguments.all_args()[arg_index].expr.peel_parens_and_refs() && let ExprKind::Lit(lit) = arg.kind { if let token::LitKind::Str | token::LitKind::StrRaw(_) = lit.kind && let Ok(LitKind::Str(s, _)) = LitKind::from_token_lit(lit) { literal = Some(s); } else if let token::LitKind::Integer = lit.kind && let Ok(LitKind::Int(n, _)) = LitKind::from_token_lit(lit) { literal = Some(Symbol::intern(&n.to_string())); } } if let Some(literal) = literal { // Now we need to mutate the outer FormatArgs. // If this is the first time, this clones the outer FormatArgs. let fmt = fmt.to_mut(); // Replace the placeholder with the literal. fmt.template[i] = FormatArgsPiece::Literal(literal); was_inlined[arg_index] = true; inlined_anything = true; } } // Remove the arguments that were inlined. if inlined_anything { let fmt = fmt.to_mut(); let mut remove = was_inlined; // Don't remove anything that's still used. for_all_argument_indexes(&mut fmt.template, |index| remove[*index] = false); // Drop all the arguments that are marked for removal. let mut remove_it = remove.iter(); fmt.arguments.all_args_mut().retain(|_| remove_it.next() != Some(&true)); // Calculate the mapping of old to new indexes for the remaining arguments. let index_map: Vec<usize> = remove .into_iter() .scan(0, |i, remove| { let mapped = *i; *i += !remove as usize; Some(mapped) }) .collect(); // Correct the indexes that refer to arguments that have shifted position. for_all_argument_indexes(&mut fmt.template, |index| *index = index_map[*index]); } fmt } </del> #[derive(Copy, Clone, Debug, Hash, PartialEq, Eq)] enum ArgumentType { Format(FormatTrait),


Question:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --When using the syntax in the Display format in formatting macros, the is ignored and treated as a . I tried this code: I expected to see this happen: Getting an error that is out of the bounds for type . Instead, this happened: This function compiles and prints . <!-- 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. --: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I went and looked through the implementation and found where the issue comes from. The check at ignores the integer type, and it blindly calls on the value of the literal.
claim
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Did run a bisection on the reproducible provided (and duplicated ) Regression in nightly-2023-04-22, specifically I think commit or (as pointed out in PR ) found 11 bors merge commits in the specified range commit[0] 2023-04-20: Auto merge of - m-ou-se:fmt-lang-items, r=jyn514 commit[1] 2023-04-20: Auto merge of - m-ou-se:flatten-format-args, r=oli-obk commit[2] 2023-04-21: Auto merge of - c410-f3r:dqewdas, r=petrochenkov commit[3] 2023-04-21: Auto merge of - jsoref:spelling-src-etc, r=Mark-Simulacrum commit[4] 2023-04-21: Auto merge of - matthiaskrgr:rollup-, r=matthiaskrgr commit[5] 2023-04-21: Auto merge of - cjgillot:query-feed, r=oli-obk commit[6] 2023-04-21: Auto merge of - michaelvanstraten:master, r=petrochenkov commit[7] 2023-04-21: Auto merge of - petrochenkov:qcstore4, r=cjgillot commit[8] 2023-04-21: Auto merge of - saethlin:mir-pass-cooperation, r=cjgillot commit[9] 2023-04-21: Auto merge of - cjgillot:const-prop-lint-junk, r=oli-obk commit[10] 2023-04-21: Auto merge of - Dylan-DPC:rollup-em3ovcq, r=Dylan-DPC cc
Looks like it's not easy invoke the same integer-literal-range-checking code from the place where formatargs!() is expanded. So the easiest solution is probably to expand to something like when literals are removed, such that the literals are still be checked later.
Actually, looks like there is a much easier fix that mostly just involves removing code. ^^' Will send a PR soon, probably tomorrow.
Fix:

<ins> //@ only-64bit fn main() { format_args!("{}", 0x8f_i8); // issue #115423 //~^ ERROR literal out of range for `i8` format_args!("{}", 0xffff_ffff_u8); // issue #116633 //~^ ERROR literal out of range for `u8` format_args!("{}", 0xffff_ffff_ffff_ffff_ffff_usize); //~^ ERROR literal out of range for `usize` format_args!("{}", 0x8000_0000_0000_0000_isize); //~^ ERROR literal out of range for `isize` format_args!("{}", 0xffff_ffff); // treat unsuffixed literals as i32 //~^ ERROR literal out of range for `i32` } </ins>