Question:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma

const WHILE_PARSING_OR_MSG: &str = "while parsing this or-pattern starting here"; /// Whether or not an or-pattern should be gated when occurring in the current context. <del> #[derive(PartialEq)] </del> <ins> #[derive(PartialEq, Clone, Copy)] </ins> pub(super) enum GateOr { Yes, No,


Question:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma

) -> PResult<'a, P<Pat>> { // Parse the first pattern (`p_0`). let first_pat = self.parse_pat(expected)?; <del> self.maybe_recover_unexpected_comma(first_pat.span, rc)?; </del> <ins> self.maybe_recover_unexpected_comma(first_pat.span, rc, gate_or)?; </ins> // If the next token is not a `|`, // this is not an or-pattern and we should exit here.


Question:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma

err.span_label(lo, WHILE_PARSING_OR_MSG); err })?; <del> self.maybe_recover_unexpected_comma(pat.span, rc)?; </del> <ins> self.maybe_recover_unexpected_comma(pat.span, rc, gate_or)?; </ins> pats.push(pat); } let or_pattern_span = lo.to(self.prev_token.span);


Question:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma

/// Some special error handling for the "top-level" patterns in a match arm, /// `for` loop, `let`, &c. (in contrast to subpatterns within such). <del> fn maybe_recover_unexpected_comma(&mut self, lo: Span, rc: RecoverComma) -> PResult<'a, ()> { </del> <ins> fn maybe_recover_unexpected_comma( &mut self, lo: Span, rc: RecoverComma, gate_or: GateOr, ) -> PResult<'a, ()> { </ins> if rc == RecoverComma::No || self.token != token::Comma { return Ok(()); }


Question:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma

let seq_span = lo.to(self.prev_token.span); let mut err = self.struct_span_err(comma_span, "unexpected `,` in pattern"); if let Ok(seq_snippet) = self.span_to_snippet(seq_span) { <ins> const MSG: &str = "try adding parentheses to match on a tuple..."; let or_suggestion = gate_or == GateOr::No || !self.sess.gated_spans.is_ungated(sym::or_patterns); </ins> err.span_suggestion( seq_span, <del> "try adding parentheses to match on a tuple...", </del> <ins> if or_suggestion { MSG } else { MSG.trim_end_matches('.') }, </ins> format!("({})", seq_snippet), Applicability::MachineApplicable, <del> ) .span_suggestion( seq_span, "...or a vertical bar to match on multiple alternatives", seq_snippet.replace(",", " |"), Applicability::MachineApplicable, </del> ); <ins> if or_suggestion { err.span_suggestion( seq_span, "...or a vertical bar to match on multiple alternatives", seq_snippet.replace(",", " |"), Applicability::MachineApplicable, ); } </ins> } Err(err) }


Question:
When forgetting to include parenthesis around a tuple pattern in a for loop, the compiler gives a suggestion to use an or pattern. I would expect this, a. because it's not what most would expect if you use a comma to separate two values in a pattern, and b. because or patterns in for loops are still an unstable feature. I tried this code: As expected, the compiler gives an , error, because I forgot the parenthesis around . However, the compiler also suggests that I add a "vertical bar to match on multiple alternatives". While it does provide the correct answer (adding parenthesis), it also provides the vertical bar option, which is an unstable feature in this . While the RFC does not explicitly single out for loops as a situation where this is necessary, I believe it does apply here, because in (credit /u/ehuss for the example, which is a situation where the or pattern syntax is being used correctly, I get a error, as expected, and including resolves the error. I tested this on stable, beta, and nightly in the rust playground. The output is identical for all 3 of them. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I would like to work on this, if possible Would it just be only giving if like ?
that seems like the right approach :)
claim
Looking at this more closely I'm not sure the fix is that simple, since and seems to (Which matches the comment for )
Looking at usages of GateOr::{Yes, No}, it looks like the only top level things (Which are the only ones that give the suggestion AIUI) that are GateOr::Yes are local variable declaration patterns and for patterns EDIT: I'm gonna try just propagating the GateOr into mayberecoverunexpected_comma

--> $DIR/issue-48492-tuple-destructure-missing-parens.rs:67:10 | LL |     for x, _barr_body in women.iter().map(|woman| woman.allosomes.clone()) { <del> |          ^ | help: try adding parentheses to match on a tuple... | LL |     for (x, _barr_body) in women.iter().map(|woman| woman.allosomes.clone()) { |         ^^^^^^^^^^^^^^^ help: ...or a vertical bar to match on multiple alternatives | LL |     for x | _barr_body in women.iter().map(|woman| woman.allosomes.clone()) { |         ^^^^^^^^^^^^^^ </del> <ins> |         -^----------- help: try adding parentheses to match on a tuple: `(x, _barr_body)` </ins> error: unexpected `,` in pattern --> $DIR/issue-48492-tuple-destructure-missing-parens.rs:75:10 | LL |     for x, y @ Allosome::Y(_) in men.iter().map(|man| man.allosomes.clone()) { <del> |          ^ | help: try adding parentheses to match on a tuple... | LL |     for (x, y @ Allosome::Y(_)) in men.iter().map(|man| man.allosomes.clone()) { |         ^^^^^^^^^^^^^^^^^^^^^^^ help: ...or a vertical bar to match on multiple alternatives | LL |     for x | y @ Allosome::Y(_) in men.iter().map(|man| man.allosomes.clone()) { |         ^^^^^^^^^^^^^^^^^^^^^^ </del> <ins> |         -^------------------- help: try adding parentheses to match on a tuple: `(x, y @ Allosome::Y(_))` </ins> error: unexpected `,` in pattern --> $DIR/issue-48492-tuple-destructure-missing-parens.rs:84:14 | LL |     let women, men: (Vec<Genome>, Vec<Genome>) = genomes.iter().cloned() <del> |              ^ | help: try adding parentheses to match on a tuple... | LL |     let (women, men): (Vec<Genome>, Vec<Genome>) = genomes.iter().cloned() |         ^^^^^^^^^^^^ help: ...or a vertical bar to match on multiple alternatives | LL |     let women | men: (Vec<Genome>, Vec<Genome>) = genomes.iter().cloned() |         ^^^^^^^^^^^ </del> <ins> |         -----^---- help: try adding parentheses to match on a tuple: `(women, men)` </ins> error: aborting due to 6 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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

Ok(true) } ty::Float(_) | ty::Int(_) | ty::Uint(_) => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = try_validation!( self.ecx.read_scalar(value), self.path, err_unsup!(ReadPointerAsBytes) => { "read of part of a pointer" }, ); </ins> // NOTE: Keep this in sync with the array optimization for int/float // types below! if self.ctfe_mode.is_some() {


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

<ins> // ignore-32bit // This test gives a different error on 32-bit architectures. union Transmute<T: Copy, U: Copy> { t: T, u: U, } trait Bar { fn bar(&self) -> u32; } struct Foo { foo: u32, bar: bool, } impl Bar for Foo { fn bar(&self) -> u32 { self.foo } } #[derive(Copy, Clone)] struct Fat<'a>(&'a Foo, &'static VTable); struct VTable { size: Foo, } const FOO: &dyn Bar = &Foo { foo: 128, bar: false, }; const G: Fat = unsafe { Transmute { t: FOO }.u }; //~^ ERROR it is undefined behavior to use this value 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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

<ins> error[E0080]: it is undefined behavior to use this value --> $DIR/issue-79690.rs:29:1 | LL | const G: Fat = unsafe { Transmute { t: FOO }.u }; | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered read of part of a pointer at .1.<deref>.size.foo | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior. error: aborting due to previous error For more information about this error, try `rustc --explain E0080`. </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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

use super::{ CheckInAllocMsg, GlobalAlloc, InterpCx, InterpResult, MPlaceTy, Machine, MemPlaceMeta, OpTy, <del> ValueVisitor, </del> <ins> ScalarMaybeUninit, ValueVisitor, </ins> }; macro_rules! throw_validation_failure {


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

value: OpTy<'tcx, M::PointerTag>, kind: &str, ) -> InterpResult<'tcx> { <del> let value = self.ecx.read_immediate(value)?; </del> <ins> let value = try_validation!( self.ecx.read_immediate(value), self.path, err_unsup!(ReadPointerAsBytes) => { "part of a pointer" } expected { "a proper pointer or integer value" }, ); </ins> // Handle wide pointers. // Check metadata early, for better diagnostics let place = try_validation!(


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

Ok(()) } <ins> fn read_scalar( &self, op: OpTy<'tcx, M::PointerTag>, ) -> InterpResult<'tcx, ScalarMaybeUninit<M::PointerTag>> { Ok(try_validation!( self.ecx.read_scalar(op), self.path, err_unsup!(ReadPointerAsBytes) => { "(potentially part of) a pointer" } expected { "plain (non-pointer) bytes" }, )) } </ins> /// Check if this is a value of primitive type, and if yes check the validity of the value /// at that type.  Return `true` if the type is indeed primitive. fn try_visit_primitive(


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

let ty = value.layout.ty; match ty.kind() { ty::Bool => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = self.read_scalar(value)?; </ins> try_validation!( value.to_bool(), self.path,


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

Ok(true) } ty::Char => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = self.read_scalar(value)?; </ins> try_validation!( value.to_char(), self.path,


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

Ok(true) } ty::Float(_) | ty::Int(_) | ty::Uint(_) => { <del> let value = try_validation!( self.ecx.read_scalar(value), self.path, err_unsup!(ReadPointerAsBytes) => { "read of part of a pointer" }, ); </del> <ins> let value = self.read_scalar(value)?; </ins> // NOTE: Keep this in sync with the array optimization for int/float // types below! if self.ctfe_mode.is_some() {


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

// actually enforce the strict rules for raw pointers (mostly because // that lets us re-use `ref_to_mplace`). let place = try_validation!( <del> self.ecx.ref_to_mplace(self.ecx.read_immediate(value)?), </del> <ins> self.ecx.read_immediate(value).and_then(|i| self.ecx.ref_to_mplace(i)), </ins> self.path, err_ub!(InvalidUninitBytes(None)) => { "uninitialized raw pointer" }, <ins> err_unsup!(ReadPointerAsBytes) => { "part of a pointer" } expected { "a proper pointer or integer value" }, </ins> ); if place.layout.is_unsized() { self.check_wide_ptr_meta(place.meta, place.layout)?;


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

Ok(true) } ty::FnPtr(_sig) => { <del> let value = self.ecx.read_scalar(value)?; </del> <ins> let value = try_validation!( self.ecx.read_immediate(value), self.path, err_unsup!(ReadPointerAsBytes) => { "part of a pointer" } expected { "a proper pointer or integer value" }, ); </ins> let _fn = try_validation!( <del> value.check_init().and_then(|ptr| self.ecx.memory.get_fn(ptr)), </del> <ins> value.to_scalar().and_then(|ptr| self.ecx.memory.get_fn(ptr)), </ins> self.path, err_ub!(DanglingIntPointer(..)) | err_ub!(InvalidFunctionPointer(..)) |


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

op: OpTy<'tcx, M::PointerTag>, scalar_layout: &Scalar, ) -> InterpResult<'tcx> { <del> let value = self.ecx.read_scalar(op)?; </del> <ins> let value = self.read_scalar(op)?; </ins> let valid_range = &scalar_layout.valid_range; let (lo, hi) = valid_range.clone().into_inner(); // Determine the allowed range


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
glacier ""
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
Compiler error on but ICE on label +regression-from-stable-to-stable
cc
A previous (now-fixed) ICE with the same error message is
Thanks for the report! Would be good to get a better backtrace; this one seems to be missing many frames and there are no line numbers.
, I updated the backtrace in my first post. I used rustup to get the latest trunk version, and the one I have been using does not have line numbers. If there is a flag or configuration for rustup to get rustc binaries with line numbers, I would be happy to change the settings on my testing machine.
I think getting line numbers requires a debug build of the compiler, so it's not quite as easy as installing something via rustup.
Labeling .
Here's a backtrace with debug info: <details</details
Unfortunately, this bottoms out ; more digging will be needed to determine the true underlying cause of the error.
Here is the actual backtrace of the underlying CTFE/Miri error: <details</detailsIt points to this line: can handle pointer values just fine, so I think what is happening is that we are reading parts of a pointer value here, which indeed is not supported in CTFE.
So... I guess the fix is to make this kind of error also be permitted during validation and turn it into a proper validation error?
Permitting it at the top-level is no good, since then we don't know "where in the value" it arose. We need a version of that catches this error and turns it into a validation error with the current "path".
Oh... right, we should fix this in general, and not just wrap in . Maybe we should not have any automatic way to bubble up errors and require all sites to use ?
I think we should wrap it but put the wrapped thing into a helper function sow e can also use it for the other places. So basically, you want to use a different error type for validation, one that excludes all the other errors? I am open to refactorings here.
Let's start out with wrapping, and then I can experiment with the refactoring so we can have a look at the usability effect of it Instructions: wrap the call at in a macro invocation and capture the error. Emit a validation message about the fact that reading parts of a pointer is not possible during CTFE. Don't forget to add a test (the failing example from this issue works great as a test) and run the test with
There are quite a few calls in that will all have this problem, so ideally they should all be treated this way. To avoid code duplication, it will probably make sense to move this into a helper function.
Reopening this to track that is still called unguarded a few times in , so e.g. the issue can still arise with .

--> $DIR/issue-79690.rs:29:1 | LL | const G: Fat = unsafe { Transmute { t: FOO }.u }; <del> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered read of part of a pointer at .1.<deref>.size.foo </del> <ins> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ type validation failed: encountered (potentially part of) a pointer at .1.<deref>.size.foo, but expected plain (non-pointer) bytes </ins> | = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

CodeBlockKind::Fenced(ref lang) => { LangString::parse_without_check(&lang, self.check_error_codes, false) } <del> CodeBlockKind::Indented => LangString::all_false(), </del> <ins> CodeBlockKind::Indented => Default::default(), </ins> }; if !parse_result.rust { return Some(Event::Start(Tag::CodeBlock(kind)));


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

let block_info = match kind { CodeBlockKind::Fenced(ref lang) => { if lang.is_empty() { <del> LangString::all_false() </del> <ins> Default::default() </ins> } else { LangString::parse( lang,


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

) } } <del> CodeBlockKind::Indented => LangString::all_false(), </del> <ins> CodeBlockKind::Indented => Default::default(), </ins> }; if !block_info.rust { continue;


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

Some(Vec<String>), } <del> impl LangString { fn all_false() -> LangString { LangString { </del> <ins> impl Default for LangString { fn default() -> Self { Self { </ins> original: String::new(), should_panic: false, no_run: false, ignore: Ignore::None, <del> rust: true, // NB This used to be `notrust = false` </del> <ins> rust: true, </ins> test_harness: false, compile_fail: false, error_codes: Vec::new(),


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

edition: None, } } <ins> } impl LangString { </ins> fn parse_without_check( string: &str, allow_error_code_check: ErrorCodes,


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

let allow_error_code_check = allow_error_code_check.as_bool(); let mut seen_rust_tags = false; let mut seen_other_tags = false; <del> let mut data = LangString::all_false(); </del> <ins> let mut data = LangString::default(); </ins> let mut ignores = vec![]; data.original = string.to_owned();


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

CodeBlockKind::Fenced(syntax) => { let syntax = syntax.as_ref(); let lang_string = if syntax.is_empty() { <del> LangString::all_false() </del> <ins> Default::default() </ins> } else { LangString::parse(&*syntax, ErrorCodes::Yes, false, Some(extra_info)) };


Question:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first

assert_eq!(LangString::parse(s, ErrorCodes::Yes, true, None), lg) } <del> t(LangString::all_false()); t(LangString { original: "rust".into(), ..LangString::all_false() }); t(LangString { original: "sh".into(), rust: false, ..LangString::all_false() }); t(LangString { original: "ignore".into(), ignore: Ignore::All, ..LangString::all_false() }); </del> <ins> t(Default::default()); t(LangString { original: "rust".into(), ..Default::default() }); t(LangString { original: "sh".into(), rust: false, ..Default::default() }); t(LangString { original: "ignore".into(), ignore: Ignore::All, ..Default::default() }); </ins> t(LangString { original: "ignore-foo".into(), ignore: Ignore::Some(vec!["foo".to_string()]), <del> ..LangString::all_false() }); t(LangString { original: "should_panic".into(), should_panic: true, ..LangString::all_false() }); t(LangString { original: "no_run".into(), no_run: true, ..LangString::all_false() }); t(LangString { original: "test_harness".into(), test_harness: true, ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); <ins> t(LangString { original: "should_panic".into(), should_panic: true, ..Default::default() }); t(LangString { original: "no_run".into(), no_run: true, ..Default::default() }); t(LangString { original: "test_harness".into(), test_harness: true, ..Default::default() }); </ins> t(LangString { original: "compile_fail".into(), no_run: true, compile_fail: true, <del> ..LangString::all_false() }); t(LangString { original: "allow_fail".into(), allow_fail: true, ..LangString::all_false() }); t(LangString { original: "{.no_run .example}".into(), no_run: true, ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); <ins> t(LangString { original: "allow_fail".into(), allow_fail: true, ..Default::default() }); t(LangString { original: "{.no_run .example}".into(), no_run: true, ..Default::default() }); </ins> t(LangString { original: "{.sh .should_panic}".into(), should_panic: true, rust: false, <del> ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); <del> t(LangString { original: "{.example .rust}".into(), ..LangString::all_false() }); </del> <ins> t(LangString { original: "{.example .rust}".into(), ..Default::default() }); </ins> t(LangString { original: "{.test_harness .rust}".into(), test_harness: true, <del> ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); t(LangString { original: "text, no_run".into(), no_run: true, rust: false, <del> ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); t(LangString { original: "text,no_run".into(), no_run: true, rust: false, <del> ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); t(LangString { original: "edition2015".into(), edition: Some(Edition::Edition2015), <del> ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); t(LangString { original: "edition2018".into(), edition: Some(Edition::Edition2018), <del> ..LangString::all_false() </del> <ins> ..Default::default() </ins> }); }


Question:
The test in leaks memory, which makes a Miri run of the test suite fail: Running Miri on the test suite is helpful to find bugs, so we should avoid deliberate leaks to still be able to detect accidental ones. Can the test be changed to use some other means of ensuring that is not called, e.g. with a type? Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim I made the test I should fix it
thanks. :-) Let me know if you need any help.

use core::mem::*; <ins> #[cfg(panic = "unwind")] </ins> use std::rc::Rc; #[test]


Question:
The test in leaks memory, which makes a Miri run of the test suite fail: Running Miri on the test suite is helpful to find bugs, so we should avoid deliberate leaks to still be able to detect accidental ones. Can the test be changed to use some other means of ensuring that is not called, e.g. with a type? Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim I made the test I should fix it
thanks. :-) Let me know if you need any help.

#[test] fn uninit_write_slice_cloned_no_drop() { <del> let rc = Rc::new(()); </del> <ins> #[derive(Clone)] struct Bomb; impl Drop for Bomb { fn drop(&mut self) { panic!("dropped a bomb! kaboom") } } </ins> let mut dst = [MaybeUninit::uninit()]; <del> let src = [rc.clone()]; </del> <ins> let src = [Bomb]; </ins> MaybeUninit::write_slice_cloned(&mut dst, &src); <del> drop(src); assert_eq!(Rc::strong_count(&rc), 2); </del> <ins> forget(src); </ins> }


Question:
I'm afraid I haven't minimised this test case. This doesn't seem to be a very serious problem as the compiler has correctly pointed out syntax errors; fixing those syntax errors makes the ICE go away. But since it suggested filing a bug I repro'd with today's nightly and have done so. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</details<detailsthread 'rustc' panicked at 'Stack should be empty: finalbuf=FrameData { open: 156:12 (), inner: [(Token(Token { kind: BinOp(And), span: 156:13 () }), Alone), (Token(Token { kind: Ident("self", false), span: 156:17 () }), Joint), (Token(Token { kind: Comma, span: 156:18 () }), Alone), (Token(Token { kind: Ident("s", false), span: 156:20 () }), Joint), (Token(Token { kind: Colon, span: 156:21 () }), Alone), (Token(Token { kind: BinOp(And), span: 156:23 () }), Alone), (Token(Token { kind: Ident("dyn", false), span: 156:26 () }), Alone), (Token(Token { kind: Ident("AsRef", false), span: 156:32 () }), Joint), (Token(Token { kind: Lt, span: 156:33 () }), Alone), (Token(Token { kind: Ident("str", false), span: 156:36 () }), Joint), (Token(Token { kind: Gt, span: 156:37 () }), Alone), (Token(Token { kind: RArrow, span: 156:40 () }), Alone), (Token(Token { kind: Ident("String", false), span: 156:47 () }), Alone), (Delimited(DelimSpan { open: 156:49 (), close: 178:4 () }, Brace, TokenStream([(Token(Token { kind: Pound, span: 157:6 () }), Alone), (Delimited(DelimSpan { open: 157:7 (), close: 157:18 () }, Bracket, TokenStream([(Token(Token { kind: Ident("throws", false), span: 157:13 () }), Alone), (Delimited(DelimSpan { open: 157:14 (), close: 157:17 () }, Paren, TokenStream([(Token(Token { kind: Ident("AE", false), span: 157:16 () }), Alone)])), Alone)])), Alone), (Token(Token { kind: Ident("fn", false), span: 158:7 () }), Alone), (Token(Token { kind: Ident("inner", false), span: 158:13 () }), Alone), (Delimited(DelimSpan { open: 158:14 (), close: 178:4 () }, Paren, TokenStream([(Token(Token { kind: Ident("self", false), span: 158:19 () }), Joint), (Token(Token { kind: Colon, span: 158:20 () }), Alone), (Token(Token { kind: BinOp(And), span: 158:22 () }), Alone), (Token(Token { kind: Ident("Self", false), span: 158:26 () }), Joint), (Token(Token { kind: Comma, span: 158:27 () }), Alone), (Token(Token { kind: Ident("s", false), span: 158:29 () }), Joint), (Token(Token { kind: Colon, span: 158:30 () }), Alone), (Token(Token { kind: BinOp(And), span: 158:32 () }), Alone), (Token(Token { kind: Ident("dyn", false), span: 158:35 () }), Alone), (Token(Token { kind: Ident("AsRef", false), span: 158:41 () }), Joint), (Token(Token { kind: Lt, span: 158:42 () }), Alone), (Token(Token { kind: Ident("str", false), span: 158:45 () }), Joint), (Token(Token { kind: Gt, span: 158:46 () }), Alone), (Token(Token { kind: RArrow, span: 158:49 () }), Alone), (Token(Token { kind: Ident("String", false), span: 158:56 () }), Alone), (Delimited(DelimSpan { open: 158:58 (), close: 176:6 () }, Brace, TokenStream([(Token(Token { kind: Ident("let", false), span: 159:10 () }), Alone), (Token(Token { kind: Ident("s", false), span: 159:12 () }), Alone), (Token(Token { kind: Eq, span: 159:14 () }), Alone), (Token(Token { kind: Ident("s", false), span: 159:16 () }), Joint), (Token(Token { kind: Dot, span: 159:17 () }), Alone), (Token(Token { kind: Ident("asref", false), span: 159:23 () }), Alone), (Delimited(DelimSpan { open: 159:24 (), close: 159:25 () }, Paren, TokenStream([])), Alone), (Token(Token { kind: Semi, span: 159:26 () }), Alone), (Token(Token { kind: Ident("let", false), span: 160:10 () }), Alone), (Token(Token { kind: Ident("re", false), span: 160:13 () }), Alone), (Token(Token { kind: Eq, span: 160:15 () }), Alone), (Token(Token { kind: Ident("Regex", false), span: 160:21 () }), Joint), (Token(Token { kind: ModSep, span: 160:23 () }), Alone), (Token(Token { kind: Ident("new", false), span: 160:26 () }), Alone), (Delimited(DelimSpan { open: 160:27 (), close: 160:38 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: StrRaw(0), symbol: " suffix: None }), span: 160:37 () }), Alone)])), Alone), (Token(Token { kind: Dot, span: 160:39 () }), Alone), (Token(Token { kind: Ident("expect", false), span: 160:45 () }), Alone), (Delimited(DelimSpan { open: 160:46 (), close: 160:56 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Str, symbol: "bad re!", suffix: None }), span: 160:55 () }), Alone)])), Alone), (Token(Token { kind: Semi, span: 160:57 () }), Alone), (Token(Token { kind: Ident("let", false), span: 161:10 () }), Alone), (Token(Token { kind: Ident("mut", false), span: 161:14 () }), Alone), (Token(Token { kind: Ident("errs", false), span: 161:19 () }), Alone), (Token(Token { kind: Eq, span: 161:21 () }), Alone), (Token(Token { kind: Ident("vec", false), span: 161:25 () }), Joint), (Token(Token { kind: Not, span: 161:26 () }), Alone), (Delimited(DelimSpan { open: 161:27 (), close: 161:28 () }, Bracket, TokenStream([])), Alone), (Token(Token { kind: Semi, span: 161:29 () }), Alone), (Token(Token { kind: Ident("let", false), span: 162:10 () }), Alone), (Token(Token { kind: Ident("out", false), span: 162:14 () }), Alone), (Token(Token { kind: Eq, span: 162:16 () }), Alone), (Token(Token { kind: Ident("re", false), span: 162:19 () }), Joint), (Token(Token { kind: Dot, span: 162:20 () }), Alone), (Token(Token { kind: Ident("replaceall", false), span: 162:31 () }), Alone), (Delimited(DelimSpan { open: 162:32 (), close: 170:9 () }, Paren, TokenStream([(Token(Token { kind: Ident("s", false), span: 162:33 () }), Joint), (Token(Token { kind: Comma, span: 162:34 () }), Alone), (Token(Token { kind: BinOp(Or), span: 162:36 () }), Alone), (Token(Token { kind: Ident("caps", false), span: 162:40 () }), Joint), (Token(Token { kind: Colon, span: 162:41 () }), Alone), (Token(Token { kind: BinOp(And), span: 162:43 () }), Alone), (Token(Token { kind: Ident("regex", false), span: 162:48 () }), Joint), (Token(Token { kind: ModSep, span: 162:50 () }), Alone), (Token(Token { kind: Ident("Captures", false), span: 162:58 () }), Joint), (Token(Token { kind: BinOp(Or), span: 162:59 () }), Alone), (Delimited(DelimSpan { open: 162:61 (), close: 170:8 () }, Brace, TokenStream([(Token(Token { kind: Ident("let", false), span: 163:12 () }), Alone), (Token(Token { kind: Ident("kw", false), span: 163:15 () }), Alone), (Token(Token { kind: Eq, span: 163:17 () }), Alone), (Token(Token { kind: Ident("caps", false), span: 163:22 () }), Joint), (Token(Token { kind: Dot, span: 163:23 () }), Alone), (Token(Token { kind: Ident("get", false), span: 163:26 () }), Alone), (Delimited(DelimSpan { open: 163:27 (), close: 163:29 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Integer, symbol: "1", suffix: None }), span: 163:28 () }), Alone)])), Alone), (Token(Token { kind: Dot, span: 163:30 () }), Alone), (Token(Token { kind: Ident("expect", false), span: 163:36 () }), Alone), (Delimited(DelimSpan { open: 163:37 (), close: 163:51 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Str, symbol: "$1 missing!", suffix: None }), span: 163:50 () }), Alone)])), Alone), (Token(Token { kind: Dot, span: 163:52 () }), Alone), (Token(Token { kind: Ident("asstr", false), span: 163:58 () }), Alone), (Delimited(DelimSpan { open: 163:59 (), close: 163:60 () }, Paren, TokenStream([])), Alone), (Token(Token { kind: Semi, span: 163:61 () }), Alone), (Token(Token { kind: Ident("if", false), span: 164:11 () }), Alone), (Token(Token { kind: Ident("kw", false), span: 164:14 () }), Alone), (Token(Token { kind: EqEq, span: 164:17 () }), Alone), (Token(Token { kind: Literal(Lit { kind: Str, symbol: "", suffix: None }), span: 164:20 () }), Alone), (Delimited(DelimSpan { open: 164:22 (), close: 164:45 () }, Brace, TokenStream([(Token(Token { kind: Ident("return", false), span: 164:29 () }), Alone), (Token(Token { kind: Literal(Lit { kind: Str, symbol: "", suffix: None }), span: 164:32 () }), Joint), (Token(Token { kind: Dot, span: 164:33 () }), Alone), (Token(Token { kind: Ident("toowned", false), span: 164:41 () }), Alone), (Delimited(DelimSpan { open: 164:42 (), close: 164:43 () }, Paren, TokenStream([])), Alone)])), Alone), (Token(Token { kind: Ident("let", false), span: 165:12 () }), Alone), (Token(Token { kind: Ident("v", false), span: 165:14 () }), Alone), (Token(Token { kind: Eq, span: 165:16 () }), Alone), (Token(Token { kind: Ident("self", false), span: 165:21 () }), Joint), (Token(Token { kind: Dot, span: 165:22 () }), Alone), (Token(Token { kind: Ident("get", false), span: 165:25 () }), Alone), (Delimited(DelimSpan { open: 165:26 (), close: 165:29 () }, Paren, TokenStream([(Token(Token { kind: Ident("kw", false), span: 165:28 () }), Alone)])), Alone), (Token(Token { kind: Semi, span: 165:30 () }), Alone), (Token(Token { kind: Ident("v", false), span: 166:10 () }), Joint), (Token(Token { kind: Dot, span: 166:11 () }), Alone), (Token(Token { kind: Ident("unwraporelse", false), span: 166:25 () }), Alone), (Delimited(DelimSpan { open: 166:26 (), close: 169:11 () }, Paren, TokenStream([(Token(Token { kind: OrOr, span: 166:28 () }), Alone), (Delimited(DelimSpan { open: 166:29 (), close: 169:10 () }, Brace, TokenStream([(Token(Token { kind: Ident("errs", false), span: 167:15 () }), Joint), (Token(Token { kind: Dot, span: 167:16 () }), Alone), (Token(Token { kind: Ident("push", false), span: 167:20 () }), Alone), (Delimited(DelimSpan { open: 167:21 (), close: 167:35 () }, Paren, TokenStream([(Token(Token { kind: Ident("kw", false), span: 167:23 () }), Joint), (Token(Token { kind: Dot, span: 167:24 () }), Alone), (Token(Token { kind: Ident("toowned", false), span: 167:32 () }), Alone), (Delimited(DelimSpan { open: 167:33 (), close: 167:34 () }, Paren, TokenStream([])), Alone)])), Alone), (Token(Token { kind: Semi, span: 167:36 () }), Alone), (Token(Token { kind: Literal(Lit { kind: Str, symbol: "", suffix: None }), span: 168:13 () }), Joint), (Token(Token { kind: Dot, span: 168:14 () }), Alone), (Token(Token { kind: Ident("toowned", false), span: 168:22 () }), Alone), (Delimited(DelimSpan { open: 168:23 (), close: 168:24 () }, Paren, TokenStream([])), Alone)])), Alone)])), Alone)])), Alone)])), Alone), (Token(Token { kind: Semi, span: 170:10 () }), Alone), (Token(Token { kind: Ident("if", false), span: 171:9 () }), Alone), (Token(Token { kind: Not, span: 171:11 () }), Alone), (Token(Token { kind: Ident("errs", false), span: 171:16 () }), Joint), (Token(Token { kind: Dot, span: 171:17 () }), Alone), (Token(Token { kind: Ident("isempty", false), span: 171:25 () }), Alone), (Delimited(DelimSpan { open: 171:26 (), close: 171:27 () }, Paren, TokenStream([])), Alone), (Delimited(DelimSpan { open: 171:29 (), close: 174:8 () }, Brace, TokenStream([(Token(Token { kind: Ident("throw", false), span: 172:14 () }), Joint), (Token(Token { kind: Not, span: 172:15 () }), Alone), (Delimited(DelimSpan { open: 172:16 (), close: 173:34 () }, Paren, TokenStream([(Token(Token { kind: Ident("anyhow", false), span: 172:22 () }), Joint), (Token(Token { kind: Not, span: 172:23 () }), Alone), (Delimited(DelimSpan { open: 172:24 (), close: 173:33 () }, Paren, TokenStream([(Token(Token { kind: Literal(Lit { kind: Str, symbol: "bad substitution(s) {:?} in {:?}", suffix: None }), span: 172:58 () }), Joint), (Token(Token { kind: Comma, span: 172:59 () }), Alone), (Token(Token { kind: BinOp(And), span: 173:25 () }), Alone), (Token(Token { kind: Ident("errs", false), span: 173:29 () }), Joint), (Token(Token { kind: Comma, span: 173:30 () }), Alone), (Token(Token { kind: Ident("s", false), span: 173:32 () }), Alone)])), Alone)])), Alone), (Token(Token { kind: Semi, span: 173:35 () }), Alone)])), Alone), (Token(Token { kind: Ident("out", false), span: 175:10 () }), Joint), (Token(Token { kind: Dot, span: 175:11 () }), Alone), (Token(Token { kind: Ident("into", false), span: 175:15 () }), Alone), (Delimited(DelimSpan { open: 175:16 (), close: 175:17 () }, Paren, TokenStream([])), Alone)])), Alone), (Token(Token { kind: Ident("inner", false), span: 177:10 () }), Alone), (Delimited(DelimSpan { open: 177:11 (), close: 177:19 () }, Paren, TokenStream([(Token(Token { kind: Ident("self", false), span: 177:15 () }), Joint), (Token(Token { kind: Comma, span: 177:16 () }), Alone), (Token(Token { kind: Ident("s", false), span: 177:18 () }), Alone)])), Alone), (Token(Token { kind: Question, span: 177:20 () }), Alone)])), Alone)])), Alone)] } stack=[FrameData { open: 1:1 (), inner: [(Token(Token { kind: Ident("fn", false), span: 156:5 () }), Alone), (Token(Token { kind: Ident("subst", false), span: 156:11 () }), Alone)] }]', </details
Minimized: proc macro
modify labels -E-needs-mcve +A-proc-macros
Is the solution possibly to just remove the offending assertion? The token stream will be nonsense but some other error reporting should catch the mismatched delimiters, I'd assume?
I just quickly tried the suggestion above (removing the assertion) and this is the error I got without it: Note that I tried a slightly simpler version of the small repro above: This still fails with ICE with the assertion.
I think I'm seeing the same issue with code containing a similar syntax error: The error is the fn does not have the closing paren. I see this on both release and debug builds: stable: beta: Nightly: Here is the error and stack from Rust Playground:

use rustc_ast::NodeId; use rustc_ast::{mut_visit, visit}; use rustc_ast::{Attribute, HasAttrs, HasTokens}; <ins> use rustc_errors::PResult; </ins> use rustc_expand::base::{Annotatable, ExtCtxt}; use rustc_expand::config::StripUnconfigured; use rustc_expand::configure;