Change:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after reporting some other errors, so I guess low priority. Affected versions: nightly 2022-04-22 does show the ICE, but beta 1.61.0-beta.3 does not show the ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
searched nightlies: from nightly-2022-04-01 to nightly-2022-04-22 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.2</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
A invocation should be replaced by and producing an error type as the adjustment result
I think this is still open and it looks like a fun problem to dig into. Please let me know if I should let someone else work on it though please! claim
I also found this issue in that version's nightly rustc. I consider that is a nontrival problem worth digging into.
I have opened a PR () that I believe addresses the ICE. I think I pretty much implemented what Oli described, but I'm a little unclear as to whether this is the actual solution or is the fact that there's an adjustment on a never type at all the real bug? I also wasn't able to reduce the minimal error case much beyond what Badel2 posted. Do you happen to have a simpler error case, Peter?
I'm assigned to your PR, and looked into this issue really quickly. So this is due to the new argument type compatibility algorithm implemented in (cc: The after  has been called once before during the "good" path of . This is somewhat problematic, since this means that typeck code deeper in the stack attemps to apply adjustments twice and sometimes panicks because of this. A similar bug was fixed in when other diagnostic code called several times on a bad path. Since this will only reasonably happen during diagnostic code, I think it's fine for now to delay a bug.
Thank you for the background! That helps a lot to clarify things. I clearly need to do a lot more reading.
Yeah, I also just have a simple ICE from rustc. But there has been some expositions from , so I think maybe this issue would be solved in the future.

Discussion:
// While we don't allow *arbitrary* coercions here, we *do* allow // coercions from ! to `expected`. if ty.is_never() { <del> assert!( !self.typeck_results.borrow().adjustments().contains_key(expr.hir_id), "expression with never type wound up being adjusted" ); </del> <ins> if let Some(adjustments) = self.typeck_results.borrow().adjustments().get(expr.hir_id) { self.tcx().sess.delay_span_bug( expr.span, "expression with never type wound up being adjusted", ); return if let [Adjustment { kind: Adjust::NeverToAny, target }] = &adjustments[..] { target.to_owned() } else { self.tcx().ty_error() }; } </ins> let adj_ty = self.next_ty_var(TypeVariableOrigin { kind: TypeVariableOriginKind::AdjustmentType, span: expr.span,

<ins> fn main() { 0.....{loop{}1}; //~^ ERROR unexpected token //~| ERROR mismatched types } </ins>

<ins> error: unexpected token: `...` --> $DIR/issue-96335.rs:2:6 | LL |     0.....{loop{}1}; |      ^^^ | help: use `..` for an exclusive range | LL |     0....{loop{}1}; |      ~~ help: or `..=` for an inclusive range | LL |     0..=..{loop{}1}; |      ~~~ error[E0308]: mismatched types --> $DIR/issue-96335.rs:2:9 | LL |     0.....{loop{}1}; |     ----^^^^^^^^^^^ |     |   | |     |   expected integer, found struct `RangeTo` |     arguments to this function are incorrect | = note: expected type `{integer}` found struct `RangeTo<{integer}>` note: associated function defined here --> $SRC_DIR/core/src/ops/range.rs:LL:COL | LL |     pub const fn new(start: Idx, end: Idx) -> Self { |                  ^^^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0308`. </ins>