Question:
This is one of those ICEs that are terribly hard to minimize because they happen cache-dependently, [update: see below for repro instructions]. If nothing else, notice that there is a panic while trying to print the query stack; it might be desirable to look into making that not happen so as to be able to get more information. <!-- 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. --Occurred while running or . : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +A-incr-comp
On looking more closely at the backtrace, it seems that this error results from attempting to load corrupted (truncated) query cache files, and therefore it would be valuable to obtain a trace from the file having been written (assuming that they are truncated due to a panic during write; if they're silently corrupted that's even harder to notice). I will update this issue if I manage to catch such a case.
Looking at the first panic observed since a and it is still the above in , so it's not that I missed the writing event but that it didn't panic.
I have made some progress on reproducing the problem with a minimal incremental change (but not yet a minimal standalone code sample), and expressed some interest in looking at the problem, so I've published branches with the work I have so far. Repro steps: The second build will ICE. The differences between the two branches are shuffling code between modules, adding a module, and deleting a module; the code in them is as identical as it can be.
Note: I cannot reproduce this ICE on x86_64-unknown-linux-gnu with the latest nightly by default, but makes it ICE. <details<summarybacktrace</summary</details
I've created a new branch which slighly simplifies the diff application: ( at the time of writing).
I've tried to find out a bit more about this, but didn't get very far. From what I can tell: In the second session refers to the derived impl for . And refers to the const generic of that impl. It has the span of the CHUNKSIZE const generic of the type definition. In the first session, as far as I can tell, the def-path refers to the , which also has a generic const. The query should not evaluate to green, but for some reason all of its dependencies are marked as green.
Maybe is too broken (it needed some fixing to show more than just DepKinds), but is it possible that has no dependencies at all during the first session?
It does indeed have no dependencies. I imagine that this is the culprit: I'm not really up-to-date with query feeding but this looks fishy. When a dep-node has no dependencies, it will trivially evaluate to green. Don't we need at least a dependency on the query that does the feeding? cc &
Given what we've learned about this bug, it's likely that this is purely about incremental compilation cache keying, i.e. neither state of the code is more likely to be miscompiled than the other, right? In other words, I as the author of the original code probably don't need to worry that I'm making my compiled code less reliable if I make the change that caused the ICE, as long as I after that point?
Yes, as far as I can tell, this is a bug in incremental compilation's dependency tracking and does not affect non-incremental builds.
Hey, I'm back with a repro! Thanks go out to , without which I would have never been able to minimize this. A one-command minimization is available at with . Basically: must be enabled. Running . Then applying Then running again panics. <details</detailsFor some strange reason I am unable to reproduce the changes when applying the diff in vscode via WSL. and work though.
I will unassign myself as I mostly assigned myself for the MCVE.
It looks like some things, like lowering to HIR, are run within a context, which leads to this call being ignored too -- and thus never making it into the we are trying to duplicate during . As a consequence, the feed queries in question go from explicitly "re-compute unconditionally" to effectively "re-use unconditionally" The reason seems to be that we . That's fine for those queries themselves because we make sure to re-compute those explicitly. But we fail to "inherit" the eval-always-ness to nested feed-queries. I'll look into fixing this some time this week.

let mut edges = SmallVec::new(); K::read_deps(|task_deps| match task_deps { TaskDepsRef::Allow(deps) => edges.extend(deps.lock().reads.iter().copied()), <del> TaskDepsRef::Ignore => {} // During HIR lowering, we have no dependencies. </del> <ins> TaskDepsRef::EvalAlways => { edges.push(DepNodeIndex::FOREVER_RED_NODE); } TaskDepsRef::Ignore => {} </ins> TaskDepsRef::Forbid => { panic!("Cannot summarize when dependencies are not recorded.") }


Question:
This is one of those ICEs that are terribly hard to minimize because they happen cache-dependently, [update: see below for repro instructions]. If nothing else, notice that there is a panic while trying to print the query stack; it might be desirable to look into making that not happen so as to be able to get more information. <!-- 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. --Occurred while running or . : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +A-incr-comp
On looking more closely at the backtrace, it seems that this error results from attempting to load corrupted (truncated) query cache files, and therefore it would be valuable to obtain a trace from the file having been written (assuming that they are truncated due to a panic during write; if they're silently corrupted that's even harder to notice). I will update this issue if I manage to catch such a case.
Looking at the first panic observed since a and it is still the above in , so it's not that I missed the writing event but that it didn't panic.
I have made some progress on reproducing the problem with a minimal incremental change (but not yet a minimal standalone code sample), and expressed some interest in looking at the problem, so I've published branches with the work I have so far. Repro steps: The second build will ICE. The differences between the two branches are shuffling code between modules, adding a module, and deleting a module; the code in them is as identical as it can be.
Note: I cannot reproduce this ICE on x86_64-unknown-linux-gnu with the latest nightly by default, but makes it ICE. <details<summarybacktrace</summary</details
I've created a new branch which slighly simplifies the diff application: ( at the time of writing).
I've tried to find out a bit more about this, but didn't get very far. From what I can tell: In the second session refers to the derived impl for . And refers to the const generic of that impl. It has the span of the CHUNKSIZE const generic of the type definition. In the first session, as far as I can tell, the def-path refers to the , which also has a generic const. The query should not evaluate to green, but for some reason all of its dependencies are marked as green.
Maybe is too broken (it needed some fixing to show more than just DepKinds), but is it possible that has no dependencies at all during the first session?
It does indeed have no dependencies. I imagine that this is the culprit: I'm not really up-to-date with query feeding but this looks fishy. When a dep-node has no dependencies, it will trivially evaluate to green. Don't we need at least a dependency on the query that does the feeding? cc &
Given what we've learned about this bug, it's likely that this is purely about incremental compilation cache keying, i.e. neither state of the code is more likely to be miscompiled than the other, right? In other words, I as the author of the original code probably don't need to worry that I'm making my compiled code less reliable if I make the change that caused the ICE, as long as I after that point?
Yes, as far as I can tell, this is a bug in incremental compilation's dependency tracking and does not affect non-incremental builds.
Hey, I'm back with a repro! Thanks go out to , without which I would have never been able to minimize this. A one-command minimization is available at with . Basically: must be enabled. Running . Then applying Then running again panics. <details</detailsFor some strange reason I am unable to reproduce the changes when applying the diff in vscode via WSL. and work though.
I will unassign myself as I mostly assigned myself for the MCVE.
It looks like some things, like lowering to HIR, are run within a context, which leads to this call being ignored too -- and thus never making it into the we are trying to duplicate during . As a consequence, the feed queries in question go from explicitly "re-compute unconditionally" to effectively "re-use unconditionally" The reason seems to be that we . That's fine for those queries themselves because we make sure to re-compute those explicitly. But we fail to "inherit" the eval-always-ness to nested feed-queries. I'll look into fixing this some time this week.

/// `TaskDeps`. This is used when executing a 'normal' query /// (no `eval_always` modifier) Allow(&'a Lock<TaskDeps<K>>), <del> /// New dependencies are ignored. This is used when /// executing an `eval_always` query, since there's no </del> <ins> /// This is used when executing an `eval_always` query. We don't </ins> /// need to track dependencies for a query that's always <del> /// re-executed. This is also used for `dep_graph.with_ignore` </del> <ins> /// re-executed -- but we need to know that this is an `eval_always` /// query in order to emit dependencies to `DepNodeIndex::FOREVER_RED_NODE` /// when directly feeding other queries. EvalAlways, /// New dependencies are ignored. This is also used for `dep_graph.with_ignore`. </ins> Ignore, /// Any attempt to add new dependencies will cause a panic. /// This is used when decoding a query result from disk,


Question:
This is one of those ICEs that are terribly hard to minimize because they happen cache-dependently, [update: see below for repro instructions]. If nothing else, notice that there is a panic while trying to print the query stack; it might be desirable to look into making that not happen so as to be able to get more information. <!-- 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. --Occurred while running or . : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +A-incr-comp
On looking more closely at the backtrace, it seems that this error results from attempting to load corrupted (truncated) query cache files, and therefore it would be valuable to obtain a trace from the file having been written (assuming that they are truncated due to a panic during write; if they're silently corrupted that's even harder to notice). I will update this issue if I manage to catch such a case.
Looking at the first panic observed since a and it is still the above in , so it's not that I missed the writing event but that it didn't panic.
I have made some progress on reproducing the problem with a minimal incremental change (but not yet a minimal standalone code sample), and expressed some interest in looking at the problem, so I've published branches with the work I have so far. Repro steps: The second build will ICE. The differences between the two branches are shuffling code between modules, adding a module, and deleting a module; the code in them is as identical as it can be.
Note: I cannot reproduce this ICE on x86_64-unknown-linux-gnu with the latest nightly by default, but makes it ICE. <details<summarybacktrace</summary</details
I've created a new branch which slighly simplifies the diff application: ( at the time of writing).
I've tried to find out a bit more about this, but didn't get very far. From what I can tell: In the second session refers to the derived impl for . And refers to the const generic of that impl. It has the span of the CHUNKSIZE const generic of the type definition. In the first session, as far as I can tell, the def-path refers to the , which also has a generic const. The query should not evaluate to green, but for some reason all of its dependencies are marked as green.
Maybe is too broken (it needed some fixing to show more than just DepKinds), but is it possible that has no dependencies at all during the first session?
It does indeed have no dependencies. I imagine that this is the culprit: I'm not really up-to-date with query feeding but this looks fishy. When a dep-node has no dependencies, it will trivially evaluate to green. Don't we need at least a dependency on the query that does the feeding? cc &
Given what we've learned about this bug, it's likely that this is purely about incremental compilation cache keying, i.e. neither state of the code is more likely to be miscompiled than the other, right? In other words, I as the author of the original code probably don't need to worry that I'm making my compiled code less reliable if I make the change that caused the ICE, as long as I after that point?
Yes, as far as I can tell, this is a bug in incremental compilation's dependency tracking and does not affect non-incremental builds.
Hey, I'm back with a repro! Thanks go out to , without which I would have never been able to minimize this. A one-command minimization is available at with . Basically: must be enabled. Running . Then applying Then running again panics. <details</detailsFor some strange reason I am unable to reproduce the changes when applying the diff in vscode via WSL. and work though.
I will unassign myself as I mostly assigned myself for the MCVE.
It looks like some things, like lowering to HIR, are run within a context, which leads to this call being ignored too -- and thus never making it into the we are trying to duplicate during . As a consequence, the feed queries in question go from explicitly "re-compute unconditionally" to effectively "re-use unconditionally" The reason seems to be that we . That's fine for those queries themselves because we make sure to re-compute those explicitly. But we fail to "inherit" the eval-always-ness to nested feed-queries. I'll look into fixing this some time this week.

<ins> // revisions: cpass1 cpass2 #![crate_type = "rlib"] use std::fmt::Debug; // MCVE kindly provided by Nilstrieb at // https://github.com/rust-lang/rust/issues/108481#issuecomment-1493080185 #[derive(Debug)] pub struct ConstGeneric<const CHUNK_SIZE: usize> { _p: [(); CHUNK_SIZE], } #[cfg(cpass1)] impl<const CHUNK_SIZE: usize> ConstGeneric<CHUNK_SIZE> {} </ins>


Question: The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"

self.draw_code_line( &mut buffer, &mut row_num, <del> &Vec::new(), </del> <ins> &[], </ins> p + line_start, l, show_code_change,


Question: The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"

self.draw_code_line( &mut buffer, &mut row_num, <del> highlight_parts, </del> <ins> &highlight_parts, </ins> line_pos + line_start, line, show_code_change,


Question: The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"

&self, buffer: &mut StyledBuffer, row_num: &mut usize, <del> highlight_parts: &Vec<SubstitutionHighlight>, </del> <ins> highlight_parts: &[SubstitutionHighlight], </ins> line_num: usize, line_to_add: &str, show_code_change: DisplaySuggestion,


Question: The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"

}); buf.push_str(&part.snippet); let cur_hi = sm.lookup_char_pos(part.span.hi()); <del> if prev_hi.line == cur_lo.line && cur_hi.line == cur_lo.line { </del> <ins> if cur_hi.line == cur_lo.line { </ins> // Account for the difference between the width of the current code and the // snippet being suggested, so that the *later* suggestions are correctly // aligned on the screen.


Question: The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"

<ins> // compile-flags: --error-format=human --color=always // ignore-windows fn short(foo_bar: &Vec<&i32>) -> &i32 { //~ ERROR missing lifetime specifier &12 } fn long( //~ ERROR missing lifetime specifier foo_bar: &Vec<&i32>, something_very_long_so_that_the_line_will_wrap_around__________: i32, ) -> &i32 { &12 } fn long2( //~ ERROR missing lifetime specifier foo_bar: &Vec<&i32>) -> &i32 { &12 } fn main() {} </ins>


Question: The bug is in the help section of the "missing lifetime specifier" error (E0106). When the method head is formatted over multiple lines, then green highlighting will be misaligned. I tried this code: I expected to see this happen: For the function it looks like this, which is fine <img width="417" alt="image" src="https://user-"Instead, this happened: But for the function the highlight is misaligned <img width="564" alt="image" src="https://user-"

<ins> error[E0106]: missing lifetime specifier   --> $DIR/multiline-multipart-suggestion.rs:4:34    | LL | fn short(foo_bar: &Vec<&i32>) -> &i32 {    |                   ----------     ^ expected named lifetime parameter    |    = help: this function's return type contains a borrowed value, but the signature does not say which one of `foo_bar`'s 2 lifetimes it is borrowed from help: consider introducing a named lifetime parameter    | LL | fn short<'a>(foo_bar: &'a Vec<&'a i32>) -> &'a i32 {    |         ++++           ++      ++           ++ error[E0106]: missing lifetime specifier   --> $DIR/multiline-multipart-suggestion.rs:11:6    | LL |     foo_bar: &Vec<&i32>,    |              ---------- LL |     something_very_long_so_that_the_line_will_wrap_around__________: i32, LL | ) -> &i32 {    |      ^ expected named lifetime parameter    |    = help: this function's return type contains a borrowed value, but the signature does not say which one of `foo_bar`'s 2 lifetimes it is borrowed from help: consider introducing a named lifetime parameter    | LL ~ fn long<'a>( LL ~     foo_bar: &'a Vec<&'a i32>, LL |     something_very_long_so_that_the_line_will_wrap_around__________: i32, LL ~ ) -> &'a i32 {    | error[E0106]: missing lifetime specifier   --> $DIR/multiline-multipart-suggestion.rs:16:29    | LL |     foo_bar: &Vec<&i32>) -> &i32 {    |              ----------     ^ expected named lifetime parameter    |    = help: this function's return type contains a borrowed value, but the signature does not say which one of `foo_bar`'s 2 lifetimes it is borrowed from help: consider introducing a named lifetime parameter    | LL ~ fn long2<'a>( LL ~     foo_bar: &'a Vec<&'a i32>) -> &'a i32 {    | error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0106`. </ins>


Question:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

BareFunctionDecl { unsafety: bare_fn.unsafety, abi: bare_fn.abi, decl, generic_params } } <del> /// This visitor is used to go through only the "top level" of a item and not enter any sub /// item while looking for a given `Ident` which is stored into `item` if found. struct OneLevelVisitor<'hir> { </del> <ins> /// Get DefId of of an item's user-visible parent. /// /// "User-visible" should account for re-exporting and inlining, which is why this function isn't /// just `tcx.parent(def_id)`. If the provided `path` has more than one path element, the `DefId` /// of the second-to-last will be given. /// /// ```text /// use crate::foo::Bar; ///            ^^^ DefId of this item will be returned /// ``` /// /// If the provided path has only one item, `tcx.parent(def_id)` will be returned instead. fn get_path_parent_def_id( tcx: TyCtxt<'_>, def_id: DefId, path: &hir::UsePath<'_>, ) -> Option<DefId> { if let [.., parent_segment, _] = &path.segments { match parent_segment.res { hir::def::Res::Def(_, parent_def_id) => Some(parent_def_id), _ if parent_segment.ident.name == kw::Crate => { // In case the "parent" is the crate, it'll give `Res::Err` so we need to // circumvent it this way. Some(tcx.parent(def_id)) } _ => None, } } else { // If the path doesn't have a parent, then the parent is the current module. Some(tcx.parent(def_id)) } } /// This visitor is used to find an HIR Item based on its `use` path. This doesn't use the ordinary /// name resolver because it does not walk all the way through a chain of re-exports. pub(crate) struct OneLevelVisitor<'hir> { </ins> map: rustc_middle::hir::map::Map<'hir>, <del> item: Option<&'hir hir::Item<'hir>>, </del> <ins> pub(crate) item: Option<&'hir hir::Item<'hir>>, </ins> looking_for: Ident, target_def_id: LocalDefId, } impl<'hir> OneLevelVisitor<'hir> { <del> fn new(map: rustc_middle::hir::map::Map<'hir>, target_def_id: LocalDefId) -> Self { </del> <ins> pub(crate) fn new(map: rustc_middle::hir::map::Map<'hir>, target_def_id: LocalDefId) -> Self { </ins> Self { map, item: None, looking_for: Ident::empty(), target_def_id } } <del> fn reset(&mut self, looking_for: Ident) { self.looking_for = looking_for; </del> <ins> pub(crate) fn find_target( &mut self, tcx: TyCtxt<'_>, def_id: DefId, path: &hir::UsePath<'_>, ) -> Option<&'hir hir::Item<'hir>> { let parent_def_id = get_path_parent_def_id(tcx, def_id, path)?; let parent = self.map.get_if_local(parent_def_id)?; // We get the `Ident` we will be looking for into `item`. self.looking_for = path.segments[path.segments.len() - 1].ident; // We reset the `item`. </ins> self.item = None; <ins> match parent { hir::Node::Item(parent_item) => { hir::intravisit::walk_item(self, parent_item); } hir::Node::Crate(m) => { hir::intravisit::walk_mod( self, m, tcx.local_def_id_to_hir_id(parent_def_id.as_local().unwrap()), ); } _ => return None, } self.item </ins> } }


Question:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

add_without_unwanted_attributes(attributes, hir_map.attrs(item.hir_id()), is_inline); } <del> let def_id = if let [.., parent_segment, _] = &path.segments { match parent_segment.res { hir::def::Res::Def(_, def_id) => def_id, _ if parent_segment.ident.name == kw::Crate => { // In case the "parent" is the crate, it'll give `Res::Err` so we need to // circumvent it this way. tcx.parent(item.owner_id.def_id.to_def_id()) } _ => break, } } else { // If the path doesn't have a parent, then the parent is the current module. tcx.parent(item.owner_id.def_id.to_def_id()) }; let Some(parent) = hir_map.get_if_local(def_id) else { break }; // We get the `Ident` we will be looking for into `item`. let looking_for = path.segments[path.segments.len() - 1].ident; visitor.reset(looking_for); match parent { hir::Node::Item(parent_item) => { hir::intravisit::walk_item(&mut visitor, parent_item); } hir::Node::Crate(m) => { hir::intravisit::walk_mod( &mut visitor, m, tcx.local_def_id_to_hir_id(def_id.as_local().unwrap()), ); } _ => break, } if let Some(i) = visitor.item { </del> <ins> if let Some(i) = visitor.find_target(tcx, item.owner_id.def_id.to_def_id(), path) { </ins> item = i; } else { break;


Question:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

use std::mem; <del> use crate::clean::{cfg::Cfg, AttributesExt, NestedAttributesExt}; </del> <ins> use crate::clean::{cfg::Cfg, AttributesExt, NestedAttributesExt, OneLevelVisitor}; </ins> use crate::core; /// This module is used to store stuff from Rust's AST in a more convenient


Question:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

renamed: Option<Symbol>, glob: bool, please_inline: bool, <ins> path: &hir::UsePath<'_>, </ins> ) -> bool { debug!("maybe_inline_local res: {:?}", res);


Question:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

return false; } <ins> if !please_inline && let mut visitor = OneLevelVisitor::new(self.cx.tcx.hir(), res_did) && let Some(item) = visitor.find_target(self.cx.tcx, def_id.to_def_id(), path) && let item_def_id = item.owner_id.def_id && item_def_id != def_id && self .cx .cache .effective_visibilities .is_directly_public(self.cx.tcx, item_def_id.to_def_id()) && !inherits_doc_hidden(self.cx.tcx, item_def_id) { // The imported item is public and not `doc(hidden)` so no need to inline it. return false; } </ins> let ret = match tcx.hir().get_by_def_id(res_did) { Node::Item(&hir::Item { kind: hir::ItemKind::Mod(ref m), .. }) if glob => { let prev = mem::replace(&mut self.inlining, true);


Question:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

ident, is_glob, please_inline, <ins> path, </ins> ) { continue; }


Question:
When running with the above code, the docs list the following items: <details<summaryDocs</summary </detailsI would expect to be listed as a reexport, not a struct. The way it is now, it looks like and are different types, which is not the case. If is made , everything looks as it's supposed to. label +T-rustdoc
It's the intended behaviour. Since the module is private, is inlining the item into .
Yes, but is public, so should it really be inlined a second time?
Ok sorry I misunderstood what you meant. No, it shouldn't be inlined a second time.

<ins> // This test ensures that the `struct.B.html` only exists in `a`: // since `a::B` is public (and inlined too), `self::a::B` doesn't // need to be inlined as well. #![crate_name = "foo"] pub mod a { // @has 'foo/a/index.html' // Should only contain "Structs". // @count - '//*[@id="main-content"]//*[@class="item-table"]' 1 // @has - '//*[@id="structs"]' 'Structs' // @has - '//*[@id="main-content"]//a[@href="struct.A.html"]' 'A' // @has - '//*[@id="main-content"]//a[@href="struct.B.html"]' 'B' mod b { pub struct B; } pub use self::b::B; pub struct A; } // @has 'foo/index.html' // @!has - '//*[@id="structs"]' 'Structs' // @has - '//*[@id="reexports"]' 'Re-exports' // @has - '//*[@id="modules"]' 'Modules' // @has - '//*[@id="main-content"]//*[@id="reexport.A"]' 'pub use self::a::A;' // @has - '//*[@id="main-content"]//*[@id="reexport.B"]' 'pub use self::a::B;' // Should only contain "Modules" and "Re-exports". // @count - '//*[@id="main-content"]//*[@class="item-table"]' 2 pub use self::a::{A, B}; </ins>


Question:
No response No response It could also recommend using <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a good first issue am I missing something? I am happy to claim it. The write! docs say that write! should accept a writer, a format string, and a list of arguments, so the error output should probably remind that
claim
That's great, let us know if you're having any trouble
Ok! So this is where I am with it: the macro for write! is the following: The issue being that if a writer is forgotten, the macro gets expanded with .writefmt() being called on the formatting string, and the rest of the arguments get passed into formatargs!, which then returns an error that the formatting string maybe was forgotten. In most other erroneous cases, .writefmt() will get called on something that is not a writer and will return a more helpful error that whatever first argument was passed to write! does not have a method writefmt. I had two ideas, the first being to modify the error from , which is where the missing string literal to format with error originates. My idea is that if a string literal is missing AND the formatargs was called from a write! then there probably is a missing writer. My second idea is to add another pattern match to the write! macro itself like: I am not sure which approach is more appropriate, or how exactly to determine the macro that called formatargs! to clarify the error. Do either of these approaches seem worthwhile? I think the write! macro should be the parent of format_args in AST and that is how I would access it? Thanks :) James
You will have to determine whether you are in an expansion of the macro. See for an example of how you could do that and check that it's write/writeln/etc. Most likely you can use and/or to do that. I think this is not a good idea that arm will show up in the documentation, and probably confuse people it also isn't helpful when it's used on something other than a literal. I think I would have the following approach: If the method is named and if we're in a write macro expansion don't emit the "no method named x found for ..." error at , but instead emit an error like... being more specific if it's a string literal...
Got it, thank you so much for pointing me in the right direction As far as the writefmt, this is where I am so far: Which gives the following output: Where I am checking to see if the function is writefmt and the macro is write! and then creating the relevant error message. I still need to create the recommended substitution from your example, I think that would be from rustcerrors::CodeSuggestions, is that correct? Then for the error about the missing format string, using ecx.expansioncause() gives me the whole line of the write! macro , I can think of some hacky ways to pull write! out of the outer span, is there a better way to extract the outer macro or should I just focus on improving the portion of the diagnostic? Thanks again! James
I suggest posting on https://rust- so more people see your message and can help you.
first of all, I would suggest using the fact that the macro has so you can match on the def id like this for example: This will be more reliable than matching on the name, as it won't fire on user provided macros with the same name, for example. Secondly I wouldn't suggest using , currently it is seen more as an anti-pattern. Instead you could probably use to highlight the argument and say (there are other alternatives like printing the type instead, but using is a good idea anyway, I think). Thirdly about your question about suggestions: the easiest way is to use to get the span just before the literal, to add there. However, I'm not sure if such suggestion is a good idea, after all may not be present, or may be named differently, etc; a suggestion that is almost always wrong seems awkward (this reminds me that suggestions should be more powerful than they are currently in rustc…).
Thanks for the tip , I've been lurking on Zulip for a little bit but wasn't sure if it was the right place for questions once there was already an issue on github Amazing thank you so much! I get what you're saying about the suggestion being unclear since the writer name will almost always be different... I also was thinking it might be a little awkward. Anyway I implemented the changes as you suggested and now I think the error message makes it pretty clear that a writer is missing: Otherwise is there anything that could be improved with the message? I am not sure if E0599 is still the correct error code but I think that it is because the error is still technically no method found?
looks good :) I think at this point you can open a PR, if any tweaks are needed we'll tell you in the review process. Feel free to , if you want me to review it.
Ok awesome thanks, just submitted PR

None } <ins> fn suggest_missing_writer( &self, rcvr_ty: Ty<'tcx>, args: (&'tcx hir::Expr<'tcx>, &'tcx [hir::Expr<'tcx>]), ) -> DiagnosticBuilder<'_, ErrorGuaranteed> { let (ty_str, _ty_file) = self.tcx.short_ty_string(rcvr_ty); let mut err = struct_span_err!(self.tcx.sess, args.0.span, E0599, "cannot write into `{}`", ty_str); err.span_note( args.0.span, "must implement `io::Write`, `fmt::Write`, or have a `write_fmt` method", ); if let ExprKind::Lit(_) = args.0.kind { err.span_help( args.0.span.shrink_to_lo(), "a writer is needed before this format string", ); }; err } </ins> pub fn report_no_match_method_error( &self, mut span: Span,


Question:
No response No response It could also recommend using <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a good first issue am I missing something? I am happy to claim it. The write! docs say that write! should accept a writer, a format string, and a list of arguments, so the error output should probably remind that
claim
That's great, let us know if you're having any trouble
Ok! So this is where I am with it: the macro for write! is the following: The issue being that if a writer is forgotten, the macro gets expanded with .writefmt() being called on the formatting string, and the rest of the arguments get passed into formatargs!, which then returns an error that the formatting string maybe was forgotten. In most other erroneous cases, .writefmt() will get called on something that is not a writer and will return a more helpful error that whatever first argument was passed to write! does not have a method writefmt. I had two ideas, the first being to modify the error from , which is where the missing string literal to format with error originates. My idea is that if a string literal is missing AND the formatargs was called from a write! then there probably is a missing writer. My second idea is to add another pattern match to the write! macro itself like: I am not sure which approach is more appropriate, or how exactly to determine the macro that called formatargs! to clarify the error. Do either of these approaches seem worthwhile? I think the write! macro should be the parent of format_args in AST and that is how I would access it? Thanks :) James
You will have to determine whether you are in an expansion of the macro. See for an example of how you could do that and check that it's write/writeln/etc. Most likely you can use and/or to do that. I think this is not a good idea that arm will show up in the documentation, and probably confuse people it also isn't helpful when it's used on something other than a literal. I think I would have the following approach: If the method is named and if we're in a write macro expansion don't emit the "no method named x found for ..." error at , but instead emit an error like... being more specific if it's a string literal...
Got it, thank you so much for pointing me in the right direction As far as the writefmt, this is where I am so far: Which gives the following output: Where I am checking to see if the function is writefmt and the macro is write! and then creating the relevant error message. I still need to create the recommended substitution from your example, I think that would be from rustcerrors::CodeSuggestions, is that correct? Then for the error about the missing format string, using ecx.expansioncause() gives me the whole line of the write! macro , I can think of some hacky ways to pull write! out of the outer span, is there a better way to extract the outer macro or should I just focus on improving the portion of the diagnostic? Thanks again! James
I suggest posting on https://rust- so more people see your message and can help you.
first of all, I would suggest using the fact that the macro has so you can match on the def id like this for example: This will be more reliable than matching on the name, as it won't fire on user provided macros with the same name, for example. Secondly I wouldn't suggest using , currently it is seen more as an anti-pattern. Instead you could probably use to highlight the argument and say (there are other alternatives like printing the type instead, but using is a good idea anyway, I think). Thirdly about your question about suggestions: the easiest way is to use to get the span just before the literal, to add there. However, I'm not sure if such suggestion is a good idea, after all may not be present, or may be named differently, etc; a suggestion that is almost always wrong seems awkward (this reminds me that suggestions should be more powerful than they are currently in rustc…).
Thanks for the tip , I've been lurking on Zulip for a little bit but wasn't sure if it was the right place for questions once there was already an issue on github Amazing thank you so much! I get what you're saying about the suggestion being unclear since the writer name will almost always be different... I also was thinking it might be a little awkward. Anyway I implemented the changes as you suggested and now I think the error message makes it pretty clear that a writer is missing: Otherwise is there anything that could be improved with the message? I am not sure if E0599 is still the correct error code but I think that it is because the error is still technically no method found?
looks good :) I think at this point you can open a PR, if any tweaks are needed we'll tell you in the review process. Feel free to , if you want me to review it.
Ok awesome thanks, just submitted PR

} } <del> let mut err = struct_span_err!( tcx.sess, span, E0599, "no {} named `{}` found for {} `{}` in the current scope", item_kind, item_name, rcvr_ty.prefix_string(self.tcx), ty_str_reported, ); </del> <ins> let is_write = sugg_span.ctxt().outer_expn_data().macro_def_id.map_or(false, |def_id| { tcx.is_diagnostic_item(sym::write_macro, def_id) || tcx.is_diagnostic_item(sym::writeln_macro, def_id) }) && item_name.name == Symbol::intern("write_fmt"); let mut err = if is_write && let Some(args) = args { self.suggest_missing_writer(rcvr_ty, args) } else { struct_span_err!( tcx.sess, span, E0599, "no {} named `{}` found for {} `{}` in the current scope", item_kind, item_name, rcvr_ty.prefix_string(self.tcx), ty_str_reported, ) }; </ins> if tcx.sess.source_map().is_multiline(sugg_span) { err.span_label(sugg_span.with_hi(span.lo()), ""); }


Question:
No response No response It could also recommend using <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a good first issue am I missing something? I am happy to claim it. The write! docs say that write! should accept a writer, a format string, and a list of arguments, so the error output should probably remind that
claim
That's great, let us know if you're having any trouble
Ok! So this is where I am with it: the macro for write! is the following: The issue being that if a writer is forgotten, the macro gets expanded with .writefmt() being called on the formatting string, and the rest of the arguments get passed into formatargs!, which then returns an error that the formatting string maybe was forgotten. In most other erroneous cases, .writefmt() will get called on something that is not a writer and will return a more helpful error that whatever first argument was passed to write! does not have a method writefmt. I had two ideas, the first being to modify the error from , which is where the missing string literal to format with error originates. My idea is that if a string literal is missing AND the formatargs was called from a write! then there probably is a missing writer. My second idea is to add another pattern match to the write! macro itself like: I am not sure which approach is more appropriate, or how exactly to determine the macro that called formatargs! to clarify the error. Do either of these approaches seem worthwhile? I think the write! macro should be the parent of format_args in AST and that is how I would access it? Thanks :) James
You will have to determine whether you are in an expansion of the macro. See for an example of how you could do that and check that it's write/writeln/etc. Most likely you can use and/or to do that. I think this is not a good idea that arm will show up in the documentation, and probably confuse people it also isn't helpful when it's used on something other than a literal. I think I would have the following approach: If the method is named and if we're in a write macro expansion don't emit the "no method named x found for ..." error at , but instead emit an error like... being more specific if it's a string literal...
Got it, thank you so much for pointing me in the right direction As far as the writefmt, this is where I am so far: Which gives the following output: Where I am checking to see if the function is writefmt and the macro is write! and then creating the relevant error message. I still need to create the recommended substitution from your example, I think that would be from rustcerrors::CodeSuggestions, is that correct? Then for the error about the missing format string, using ecx.expansioncause() gives me the whole line of the write! macro , I can think of some hacky ways to pull write! out of the outer span, is there a better way to extract the outer macro or should I just focus on improving the portion of the diagnostic? Thanks again! James
I suggest posting on https://rust- so more people see your message and can help you.
first of all, I would suggest using the fact that the macro has so you can match on the def id like this for example: This will be more reliable than matching on the name, as it won't fire on user provided macros with the same name, for example. Secondly I wouldn't suggest using , currently it is seen more as an anti-pattern. Instead you could probably use to highlight the argument and say (there are other alternatives like printing the type instead, but using is a good idea anyway, I think). Thirdly about your question about suggestions: the easiest way is to use to get the span just before the literal, to add there. However, I'm not sure if such suggestion is a good idea, after all may not be present, or may be named differently, etc; a suggestion that is almost always wrong seems awkward (this reminds me that suggestions should be more powerful than they are currently in rustc…).
Thanks for the tip , I've been lurking on Zulip for a little bit but wasn't sure if it was the right place for questions once there was already an issue on github Amazing thank you so much! I get what you're saying about the suggestion being unclear since the writer name will almost always be different... I also was thinking it might be a little awkward. Anyway I implemented the changes as you suggested and now I think the error message makes it pretty clear that a writer is missing: Otherwise is there anything that could be improved with the message? I am not sure if E0599 is still the correct error code but I think that it is because the error is still technically no method found?
looks good :) I think at this point you can open a PR, if any tweaks are needed we'll tell you in the review process. Feel free to , if you want me to review it.
Ok awesome thanks, just submitted PR

<ins> // Check error for missing writer in writeln! and write! macro fn main() { let x = 1; let y = 2; write!("{}_{}", x, y); //~^ ERROR format argument must be a string literal //~| HELP you might be missing a string literal to format with //~| ERROR cannot write into `&'static str` //~| NOTE must implement `io::Write`, `fmt::Write`, or have a `write_fmt` method //~| HELP a writer is needed before this format string writeln!("{}_{}", x, y); //~^ ERROR format argument must be a string literal //~| HELP you might be missing a string literal to format with //~| ERROR cannot write into `&'static str` //~| NOTE must implement `io::Write`, `fmt::Write`, or have a `write_fmt` method //~| HELP a writer is needed before this format string } </ins>


Question:
No response No response It could also recommend using <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a good first issue am I missing something? I am happy to claim it. The write! docs say that write! should accept a writer, a format string, and a list of arguments, so the error output should probably remind that
claim
That's great, let us know if you're having any trouble
Ok! So this is where I am with it: the macro for write! is the following: The issue being that if a writer is forgotten, the macro gets expanded with .writefmt() being called on the formatting string, and the rest of the arguments get passed into formatargs!, which then returns an error that the formatting string maybe was forgotten. In most other erroneous cases, .writefmt() will get called on something that is not a writer and will return a more helpful error that whatever first argument was passed to write! does not have a method writefmt. I had two ideas, the first being to modify the error from , which is where the missing string literal to format with error originates. My idea is that if a string literal is missing AND the formatargs was called from a write! then there probably is a missing writer. My second idea is to add another pattern match to the write! macro itself like: I am not sure which approach is more appropriate, or how exactly to determine the macro that called formatargs! to clarify the error. Do either of these approaches seem worthwhile? I think the write! macro should be the parent of format_args in AST and that is how I would access it? Thanks :) James
You will have to determine whether you are in an expansion of the macro. See for an example of how you could do that and check that it's write/writeln/etc. Most likely you can use and/or to do that. I think this is not a good idea that arm will show up in the documentation, and probably confuse people it also isn't helpful when it's used on something other than a literal. I think I would have the following approach: If the method is named and if we're in a write macro expansion don't emit the "no method named x found for ..." error at , but instead emit an error like... being more specific if it's a string literal...
Got it, thank you so much for pointing me in the right direction As far as the writefmt, this is where I am so far: Which gives the following output: Where I am checking to see if the function is writefmt and the macro is write! and then creating the relevant error message. I still need to create the recommended substitution from your example, I think that would be from rustcerrors::CodeSuggestions, is that correct? Then for the error about the missing format string, using ecx.expansioncause() gives me the whole line of the write! macro , I can think of some hacky ways to pull write! out of the outer span, is there a better way to extract the outer macro or should I just focus on improving the portion of the diagnostic? Thanks again! James
I suggest posting on https://rust- so more people see your message and can help you.
first of all, I would suggest using the fact that the macro has so you can match on the def id like this for example: This will be more reliable than matching on the name, as it won't fire on user provided macros with the same name, for example. Secondly I wouldn't suggest using , currently it is seen more as an anti-pattern. Instead you could probably use to highlight the argument and say (there are other alternatives like printing the type instead, but using is a good idea anyway, I think). Thirdly about your question about suggestions: the easiest way is to use to get the span just before the literal, to add there. However, I'm not sure if such suggestion is a good idea, after all may not be present, or may be named differently, etc; a suggestion that is almost always wrong seems awkward (this reminds me that suggestions should be more powerful than they are currently in rustc…).
Thanks for the tip , I've been lurking on Zulip for a little bit but wasn't sure if it was the right place for questions once there was already an issue on github Amazing thank you so much! I get what you're saying about the suggestion being unclear since the writer name will almost always be different... I also was thinking it might be a little awkward. Anyway I implemented the changes as you suggested and now I think the error message makes it pretty clear that a writer is missing: Otherwise is there anything that could be improved with the message? I am not sure if E0599 is still the correct error code but I think that it is because the error is still technically no method found?
looks good :) I think at this point you can open a PR, if any tweaks are needed we'll tell you in the review process. Feel free to , if you want me to review it.
Ok awesome thanks, just submitted PR

<ins> error: format argument must be a string literal --> $DIR/missing-writer.rs:5:21 | LL |     write!("{}_{}", x, y); |                     ^ | help: you might be missing a string literal to format with | LL |     write!("{}_{}", "{} {}", x, y); |                     ++++++++ error: format argument must be a string literal --> $DIR/missing-writer.rs:11:23 | LL |     writeln!("{}_{}", x, y); |                       ^ | help: you might be missing a string literal to format with | LL |     writeln!("{}_{}", "{} {}", x, y); |                       ++++++++ error[E0599]: cannot write into `&'static str` --> $DIR/missing-writer.rs:5:12 | LL |     write!("{}_{}", x, y); |     -------^^^^^^^------- method not found in `&str` | note: must implement `io::Write`, `fmt::Write`, or have a `write_fmt` method --> $DIR/missing-writer.rs:5:12 | LL |     write!("{}_{}", x, y); |            ^^^^^^^ help: a writer is needed before this format string --> $DIR/missing-writer.rs:5:12 | LL |     write!("{}_{}", x, y); |            ^ error[E0599]: cannot write into `&'static str` --> $DIR/missing-writer.rs:11:14 | LL |     writeln!("{}_{}", x, y); |     ---------^^^^^^^------- method not found in `&str` | note: must implement `io::Write`, `fmt::Write`, or have a `write_fmt` method --> $DIR/missing-writer.rs:11:14 | LL |     writeln!("{}_{}", x, y); |              ^^^^^^^ help: a writer is needed before this format string --> $DIR/missing-writer.rs:11:14 | LL |     writeln!("{}_{}", x, y); |              ^ error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0599`. </ins>


Question:
No response No response It could also recommend using <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This seems like a good first issue am I missing something? I am happy to claim it. The write! docs say that write! should accept a writer, a format string, and a list of arguments, so the error output should probably remind that
claim
That's great, let us know if you're having any trouble
Ok! So this is where I am with it: the macro for write! is the following: The issue being that if a writer is forgotten, the macro gets expanded with .writefmt() being called on the formatting string, and the rest of the arguments get passed into formatargs!, which then returns an error that the formatting string maybe was forgotten. In most other erroneous cases, .writefmt() will get called on something that is not a writer and will return a more helpful error that whatever first argument was passed to write! does not have a method writefmt. I had two ideas, the first being to modify the error from , which is where the missing string literal to format with error originates. My idea is that if a string literal is missing AND the formatargs was called from a write! then there probably is a missing writer. My second idea is to add another pattern match to the write! macro itself like: I am not sure which approach is more appropriate, or how exactly to determine the macro that called formatargs! to clarify the error. Do either of these approaches seem worthwhile? I think the write! macro should be the parent of format_args in AST and that is how I would access it? Thanks :) James
You will have to determine whether you are in an expansion of the macro. See for an example of how you could do that and check that it's write/writeln/etc. Most likely you can use and/or to do that. I think this is not a good idea that arm will show up in the documentation, and probably confuse people it also isn't helpful when it's used on something other than a literal. I think I would have the following approach: If the method is named and if we're in a write macro expansion don't emit the "no method named x found for ..." error at , but instead emit an error like... being more specific if it's a string literal...
Got it, thank you so much for pointing me in the right direction As far as the writefmt, this is where I am so far: Which gives the following output: Where I am checking to see if the function is writefmt and the macro is write! and then creating the relevant error message. I still need to create the recommended substitution from your example, I think that would be from rustcerrors::CodeSuggestions, is that correct? Then for the error about the missing format string, using ecx.expansioncause() gives me the whole line of the write! macro , I can think of some hacky ways to pull write! out of the outer span, is there a better way to extract the outer macro or should I just focus on improving the portion of the diagnostic? Thanks again! James
I suggest posting on https://rust- so more people see your message and can help you.
first of all, I would suggest using the fact that the macro has so you can match on the def id like this for example: This will be more reliable than matching on the name, as it won't fire on user provided macros with the same name, for example. Secondly I wouldn't suggest using , currently it is seen more as an anti-pattern. Instead you could probably use to highlight the argument and say (there are other alternatives like printing the type instead, but using is a good idea anyway, I think). Thirdly about your question about suggestions: the easiest way is to use to get the span just before the literal, to add there. However, I'm not sure if such suggestion is a good idea, after all may not be present, or may be named differently, etc; a suggestion that is almost always wrong seems awkward (this reminds me that suggestions should be more powerful than they are currently in rustc…).
Thanks for the tip , I've been lurking on Zulip for a little bit but wasn't sure if it was the right place for questions once there was already an issue on github Amazing thank you so much! I get what you're saying about the suggestion being unclear since the writer name will almost always be different... I also was thinking it might be a little awkward. Anyway I implemented the changes as you suggested and now I think the error message makes it pretty clear that a writer is missing: Otherwise is there anything that could be improved with the message? I am not sure if E0599 is still the correct error code but I think that it is because the error is still technically no method found?
looks good :) I think at this point you can open a PR, if any tweaks are needed we'll tell you in the review process. Feel free to , if you want me to review it.
Ok awesome thanks, just submitted PR

--> $SRC_DIR/std/src/io/buffered/bufwriter.rs:LL:COL error[E0599]: the method `write_fmt` exists for struct `BufWriter<&dyn Write>`, but its trait bounds were not satisfied <del> --> $DIR/mut-borrow-needed-by-trait.rs:21:5 </del> <ins> --> $DIR/mut-borrow-needed-by-trait.rs:21:14 </ins> | LL |     writeln!(fp, "hello world").unwrap(); <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^ method cannot be called on `BufWriter<&dyn Write>` due to unsatisfied trait bounds </del> <ins> |     ---------^^---------------- method cannot be called on `BufWriter<&dyn Write>` due to unsatisfied trait bounds </ins> --> $SRC_DIR/std/src/io/buffered/bufwriter.rs:LL:COL | = note: doesn't satisfy `BufWriter<&dyn std::io::Write>: std::io::Write` | <ins> note: must implement `io::Write`, `fmt::Write`, or have a `write_fmt` method --> $DIR/mut-borrow-needed-by-trait.rs:21:14 | LL |     writeln!(fp, "hello world").unwrap(); |              ^^ </ins> = note: the following trait bounds were not satisfied: `&dyn std::io::Write: std::io::Write` which is required by `BufWriter<&dyn std::io::Write>: std::io::Write` <del> = note: this error originates in the macro `writeln` (in Nightly builds, run with -Z macro-backtrace for more info) </del> error: aborting due to 3 previous errors


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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.

r: ty::Region<'tcx>, ) -> ty::Region<'tcx> { match *r { <del> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReErased | ty::ReStatic => r, </del> <ins> ty::ReEarlyBound(_) | ty::ReFree(_) | ty::ReErased | ty::ReStatic | ty::ReError(_) => r, </ins> ty::ReVar(_) => canonicalizer.canonical_var_for_region_in_root_universe(r), <del> _ => { </del> <ins> ty::RePlaceholder(..) | ty::ReLateBound(..) => { </ins> // We only expect region names that the user can type. bug!("unexpected region in query response: `{:?}`", r) }


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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.

<ins> // Regression test for #109072. // Check that we don't ICE when canonicalizing user annotation. trait Lt<'a> { type T; } impl Lt<'missing> for () { //~ ERROR undeclared lifetime type T = &'missing (); //~ ERROR undeclared lifetime } fn main() { let _: <() as Lt<'_>>::T = &(); } </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-01-01 to nightly-2023-03-11 regressed nightly: nightly-2023-03-09 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
This is "due" to , but probably needs to be passed through silently in the canonicalization code.
reduced via treereduce `
I'd argue that repro is worse than the one provided at the top of the issue, even if it's a few bytes shorter. It introduces a bit of superfluous syntax/unnecessary syntax errors. Here's a denser minimization that avoids the syntax errors (except for the one that actually is the root-cause of the issue):
haha, the original snipped looked like this but I though it looked a little too weird :)
claim
Sorry for the off-topic comment: In response to this feedback I made a wrapper for treereduce that avoids introducing unrelated issues. It also runs for you (when it doesn't remove the ICE), and can output a nice Markdown comment with the reduced program.

<ins> error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/region-error-ice-109072.rs:8:9 | LL | impl Lt<'missing> for () { |     -   ^^^^^^^^ undeclared lifetime |     | |     help: consider introducing lifetime `'missing` here: `<'missing>` error[E0261]: use of undeclared lifetime name `'missing` --> $DIR/region-error-ice-109072.rs:9:15 | LL |     type T = &'missing (); |               ^^^^^^^^ undeclared lifetime | help: consider introducing lifetime `'missing` here | LL |     type T<'missing> = &'missing (); |           ++++++++++ help: consider introducing lifetime `'missing` here | LL | impl<'missing> Lt<'missing> for () { |     ++++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0261`. </ins>


Question:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

e.note( "the macro call doesn't expand to an expression, but it can expand to a statement", ); <del> e.span_suggestion_verbose( site_span.shrink_to_hi(), "add `;` to interpret the expansion as a statement", ";", Applicability::MaybeIncorrect, ); </del> <ins> if parser.token == token::Semi { if let Ok(snippet) = parser.sess.source_map().span_to_snippet(site_span) { e.span_suggestion_verbose( site_span, "surround the macro invocation with `{}` to interpret the expansion as a statement", format!("{{ {}; }}", snippet), Applicability::MaybeIncorrect, ); } } else { e.span_suggestion_verbose( site_span.shrink_to_hi(), "add `;` to interpret the expansion as a statement", ";", Applicability::MaybeIncorrect, ); } </ins> } }, _ => annotate_err_with_kind(&mut e, kind, site_span),


Question:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> macro_rules! statement { () => {;}; //~ ERROR expected expression } fn main() { let _ = statement!(); } </ins>


Question:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim

<ins> error: expected expression, found `;` --> $DIR/issue-109237.rs:2:12 | LL |     () => {;}; |            ^ expected expression ... LL |     let _ = statement!(); |             ------------ in this macro invocation | = note: the macro call doesn't expand to an expression, but it can expand to a statement = note: this error originates in the macro `statement` (in Nightly builds, run with -Z macro-backtrace for more info) help: surround the macro invocation with `{}` to interpret the expansion as a statement | LL |     let _ = { statement!(); }; |             ~~~~~~~~~~~~~~~~~ error: aborting due to previous error </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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

// the expected const's type. Specifically, we don't want const infer vars // to do any type shapeshifting before and after resolution. if let Err(guar) = compatible_types { <del> return Ok(self.tcx.const_error_with_guaranteed( if relation.a_is_expected() { a.ty() } else { b.ty() }, guar, )); </del> <ins> // HACK: equating both sides with `[const error]` eagerly prevents us // from leaving unconstrained inference vars during things like impl // matching in the solver. let a_error = self.tcx.const_error_with_guaranteed(a.ty(), guar); if let ty::ConstKind::Infer(InferConst::Var(vid)) = a.kind() { return self.unify_const_variable(vid, a_error); } let b_error = self.tcx.const_error_with_guaranteed(b.ty(), guar); if let ty::ConstKind::Infer(InferConst::Var(vid)) = b.kind() { return self.unify_const_variable(vid, b_error); } return Ok(if relation.a_is_expected() { a_error } else { b_error }); </ins> } match (a.kind(), b.kind()) {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

use rustc_data_structures::fx::FxIndexSet; use rustc_errors::{error_code, DelayDm, Diagnostic}; use rustc_hir::def_id::{DefId, LocalDefId}; <del> use rustc_middle::ty::{self, ImplSubject, Ty, TyCtxt}; </del> <ins> use rustc_middle::ty::{self, ImplSubject, Ty, TyCtxt, TypeVisitableExt}; </ins> use rustc_middle::ty::{InternalSubsts, SubstsRef}; use rustc_session::lint::builtin::COHERENCE_LEAK_CHECK; use rustc_session::lint::builtin::ORDER_DEPENDENT_TRAIT_OBJECTS;


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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

impl_span: Span, err: &mut Diagnostic, ) { <ins> if (overlap.trait_ref, overlap.self_ty).references_error() { err.downgrade_to_delayed_bug(); } </ins> match tcx.span_of_impl(overlap.with_impl) { Ok(span) => { err.span_label(span, "first implementation here");


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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> // incremental #![crate_type = "lib"] trait Q { const ASSOC: usize; } impl<const N: u64> Q for [u8; N] { //~^ ERROR mismatched types const ASSOC: usize = 1; } pub fn test() -> [u8; <[u8; 13] as Q>::ASSOC] { 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</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<ins> error[E0308]: mismatched types --> $DIR/bad-subst-const-kind.rs:8:31 | LL | impl<const N: u64> Q for [u8; N] { |                               ^ expected `usize`, found `u64` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

// An impl that has an erroneous const substitution should not specialize one // that is well-formed. <ins> #[derive(Clone)] </ins> struct S<const L: usize>; impl<const N: i32> Copy for S<N> {} <ins> //~^ ERROR the constant `N` is not of type `usize` </ins> impl<const M: usize> Copy for S<M> {} <del> //~^ ERROR conflicting implementations of trait `Copy` for type `S<_>` </del> fn main() {}


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
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium

<del> error[E0119]: conflicting implementations of trait `Copy` for type `S<_>` --> $DIR/bad-const-wf-doesnt-specialize.rs:9:1 </del> <ins> error: the constant `N` is not of type `usize` --> $DIR/bad-const-wf-doesnt-specialize.rs:8:29 </ins> | LL | impl<const N: i32> Copy for S<N> {} <del> | -------------------------------- first implementation here LL | impl<const M: usize> Copy for S<M> {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `S<_>` </del> <ins> |                             ^^^^ | note: required by a bound in `S` --> $DIR/bad-const-wf-doesnt-specialize.rs:6:10 | LL | struct S<const L: usize>; |          ^^^^^^^^^^^^^^ required by this bound in `S` </ins> error: aborting due to previous error <del> For more information about this error, try `rustc --explain E0119`. </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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

use rustc_infer::traits::ObligationCause; use rustc_middle::infer::unify_key::{ConstVariableOrigin, ConstVariableOriginKind}; use rustc_middle::middle::stability::AllowUnstable; <ins> use rustc_middle::ty::fold::FnMutDelegate; </ins> use rustc_middle::ty::subst::{self, GenericArgKind, InternalSubsts, SubstsRef}; use rustc_middle::ty::DynKind; use rustc_middle::ty::GenericParamDefKind;


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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

let param_env = tcx.param_env(block.owner.to_def_id()); let cause = ObligationCause::misc(span, block.owner.def_id); let mut fulfillment_errors = Vec::new(); <del> let mut applicable_candidates: Vec<_> = candidates .iter() .filter_map(|&(impl_, (assoc_item, def_scope))| { infcx.probe(|_| { let ocx = ObligationCtxt::new_in_snapshot(&infcx); </del> <ins> let mut applicable_candidates: Vec<_> = infcx.probe(|_| { let universe = infcx.create_next_universe(); // Regions are not considered during selection. let self_ty = tcx.replace_escaping_bound_vars_uncached( self_ty, FnMutDelegate { regions: &mut |_| tcx.lifetimes.re_erased, types: &mut |bv| { tcx.mk_placeholder(ty::PlaceholderType { universe, name: bv.kind }) }, consts: &mut |bv, ty| { tcx.mk_const(ty::PlaceholderConst { universe, name: bv }, ty) }, }, ); </ins> <del> let impl_ty = tcx.type_of(impl_); let impl_substs = infcx.fresh_item_substs(impl_); let impl_ty = impl_ty.subst(tcx, impl_substs); let impl_ty = ocx.normalize(&cause, param_env, impl_ty); </del> <ins> candidates .iter() .filter_map(|&(impl_, (assoc_item, def_scope))| { infcx.probe(|_| { let ocx = ObligationCtxt::new_in_snapshot(&infcx); </ins> <del> // Check that the Self-types can be related. // FIXME(fmease): Should we use `eq` here? ocx.sup(&ObligationCause::dummy(), param_env, impl_ty, self_ty).ok()?; </del> <ins> let impl_ty = tcx.type_of(impl_); let impl_substs = infcx.fresh_item_substs(impl_); let impl_ty = impl_ty.subst(tcx, impl_substs); let impl_ty = ocx.normalize(&cause, param_env, impl_ty); </ins> <del> // Check whether the impl imposes obligations we have to worry about. let impl_bounds = tcx.predicates_of(impl_); let impl_bounds = impl_bounds.instantiate(tcx, impl_substs); </del> <ins> // Check that the Self-types can be related. // FIXME(fmease): Should we use `eq` here? ocx.sup(&ObligationCause::dummy(), param_env, impl_ty, self_ty).ok()?; </ins> <del> let impl_bounds = ocx.normalize(&cause, param_env, impl_bounds); </del> <ins> // Check whether the impl imposes obligations we have to worry about. let impl_bounds = tcx.predicates_of(impl_); let impl_bounds = impl_bounds.instantiate(tcx, impl_substs); </ins> <del> let impl_obligations = traits::predicates_for_generics( |_, _| cause.clone(), param_env, impl_bounds, ); </del> <ins> let impl_bounds = ocx.normalize(&cause, param_env, impl_bounds); </ins> <del> ocx.register_obligations(impl_obligations); </del> <ins> let impl_obligations = traits::predicates_for_generics( |_, _| cause.clone(), param_env, impl_bounds, ); </ins> <del> let mut errors = ocx.select_where_possible(); if !errors.is_empty() { fulfillment_errors.append(&mut errors); return None; } </del> <ins> ocx.register_obligations(impl_obligations); let mut errors = ocx.select_where_possible(); if !errors.is_empty() { fulfillment_errors.append(&mut errors); return None; } </ins> <del> // FIXME(fmease): Unsolved vars can escape this InferCtxt snapshot. Some((assoc_item, def_scope, infcx.resolve_vars_if_possible(impl_substs))) </del> <ins> // FIXME(fmease): Unsolved vars can escape this InferCtxt snapshot. Some((assoc_item, def_scope, infcx.resolve_vars_if_possible(impl_substs))) }) </ins> }) <del> }) .collect(); </del> <ins> .collect() }); </ins> if applicable_candidates.len() > 1 { return Err(self.complain_about_ambiguous_inherent_assoc_type(


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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

<ins> #![feature(inherent_associated_types, non_lifetime_binders, type_alias_impl_trait)] #![allow(incomplete_features)] struct Lexer<T>(T); impl Lexer<i32> { type Cursor = (); } type X = impl for<T> Fn() -> Lexer<T>::Cursor; //~ ERROR associated type `Cursor` not found for `Lexer<T>` in the current scope 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

<ins> error[E0220]: associated type `Cursor` not found for `Lexer<T>` in the current scope --> $DIR/issue-109299-1.rs:10:40 | LL | struct Lexer<T>(T); | --------------- associated item `Cursor` not found for this struct ... LL | type X = impl for<T> Fn() -> Lexer<T>::Cursor; |                                        ^^^^^^ associated item not found in `Lexer<T>` | = note: the associated type was found for - `Lexer<i32>` error: aborting due to previous error For more information about this error, try `rustc --explain E0220`. </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] struct Lexer<'d>(&'d ()); impl Lexer<'d> { //~ ERROR use of undeclared lifetime name `'d` type Cursor = (); } fn test(_: Lexer::Cursor) {} 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2023-02-17 to nightly-2023-03-18 regressed nightly: nightly-2023-02-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
cc is this fixed by your branch?
No, it's not. The stacktrace does indeed contain but that's not the root cause of the problem. It just calls which ices (changing it to doesn't help either). The actual (?) bug is probably inside of the code I assume.
Ah, wait. If it's a bug to pass s to the type relating functions then it is the fault of and it should probably return early if a type . Edit: But it that case?
Hm, actually I think we should just fix the relate code instead.
Sure. I also feel like I've seen this ICE message pop up several times already on this issue tracker. I might be mistaken tho.
More minimal:
Reassigning to myself since the approach involving region erasure during selection we talked about fixes this issue (obviously) and since I'd like to integrate this into my PR to be able to write UI tests that exercise the bound region code used during IAT confirmation (otherwise we would never go past selection in those cases). claim label F-inherentassociatedtypes

<ins> error[E0261]: use of undeclared lifetime name `'d` --> $DIR/issue-109299.rs:6:12 | LL | impl Lexer<'d> { |     -      ^^ undeclared lifetime |     | |     help: consider introducing lifetime `'d` here: `<'d>` error: aborting due to previous error For more information about this error, try `rustc --explain E0261`. </ins>