Skip to content

Handle error types gracefully in cat_deref#153903

Closed
ViewWay wants to merge 2 commits intorust-lang:mainfrom
ViewWay:fix/ice-153733-cat-deref
Closed

Handle error types gracefully in cat_deref#153903
ViewWay wants to merge 2 commits intorust-lang:mainfrom
ViewWay:fix/ice-153733-cat-deref

Conversation

@ViewWay
Copy link

@ViewWay ViewWay commented Mar 15, 2026

Fixes #153733.

When type resolution fails (e.g., due to combining unstable features like pin_ergonomics with min_generic_const_args), structurally_resolve_type returns an error type.

When builtin_deref is called on this error type, it returns None, causing the code to panic with "explicit deref of non-derefable type".

The fix checks if the resolved type contains an error using error_reported_in_ty and returns early if so, allowing compilation to continue and report the actual error instead of ICE-ing.

yimiliya added 2 commits March 14, 2026 21:37
… trait object types

This is a cherry-pick of PR #153738

Problem:
- PR #150843 introduced a regression where eager type aliases containing
  dyn Trait (with associated consts) would incorrectly report
  'trait is not dyn compatible' errors
- This affected 254 crates depending on old bitvec versions

Root cause:
- When checking for unspecified assoc items in trait object types,
  we were filtering for all associated consts (is_const())
- But eager type aliases don't get wfchecked at definition site
- This broke the assumption that dyn-incompatible traits would be
  rejected early

Fix:
- Changed is_const() to is_type_const() to only check type-level
  associated consts, not regular associated consts
- Regular associated consts cannot be bound in trait object types
  anyway, so checking them was unnecessary

Modified files:
- compiler/rustc_hir_analysis/src/hir_ty_lowering/dyn_trait.rs
- compiler/rustc_middle/src/ty/assoc.rs
- compiler/rustc_middle/src/ty/sty.rs
- compiler/rustc_sanitizers/src/cfi/typeid/itanium_cxx_abi/transform.rs
- tests/ui/type-alias/lack-of-wf.rs (new test)

Fixes: #153731
The issue was that when type resolution fails (e.g., due to combining
unstable features like pin_ergonomics with min_generic_const_args),
`structurally_resolve_type` returns an error type.

When `builtin_deref` is called on this error type, it returns `None`,
causing the code to panic with "explicit deref of non-derefable type".

The fix checks if the resolved type contains an error using
`error_reported_in_ty` and returns early if so, allowing compilation
to continue and report the actual error instead of ICE-ing.
@rustbot
Copy link
Collaborator

rustbot commented Mar 15, 2026

HIR ty lowering was modified

cc @fmease

Some changes occurred in compiler/rustc_sanitizers

cc @rcvalle

@rustbot rustbot added PG-exploit-mitigations Project group: Exploit mitigations S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Mar 15, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 15, 2026

r? @mati865

rustbot has assigned @mati865.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

  • Owners of files modified in this PR: compiler
  • compiler expanded to 69 candidates
  • Random selection from 15 candidates

@rustbot
Copy link
Collaborator

rustbot commented Mar 15, 2026

⚠️ Warning ⚠️

  • There are issue links (such as #123) in the commit messages of the following commits.
    Please move them to the PR description, to avoid spamming the issues with references to the commit, and so this bot can automatically canonicalize them to avoid issues with subtree.

@rust-log-analyzer
Copy link
Collaborator

The job tidy failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
[TIMING:end] tool::Tidy { compiler: Compiler { stage: 0, host: x86_64-unknown-linux-gnu, forced_compiler: false }, target: x86_64-unknown-linux-gnu } -- 0.000
fmt check
Diff in /checkout/compiler/rustc_hir_typeck/src/expr_use_visitor.rs:1513:
         let resolved_ty = self
             .cx
             .structurally_resolve_type(self.cx.tcx().hir_span(base_place.hir_id), base_curr_ty);
-        
+
         // If the type is an error (e.g., from prior inference failure), return early
         self.cx.error_reported_in_ty(resolved_ty)?;
-        
+
         let Some(deref_ty) = resolved_ty.builtin_deref(true) else {
             debug!("explicit deref of non-derefable type: {:?}", base_curr_ty);
             return Err(self
fmt: checked 6743 files
Bootstrap failed while executing `test src/tools/tidy tidyselftest --extra-checks=py,cpp,js,spellcheck`
Build completed unsuccessfully in 0:00:49
  local time: Sun Mar 15 04:35:28 UTC 2026
  network time: Sun, 15 Mar 2026 04:35:28 GMT

Copy link
Member

@fmease fmease left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For the love of god, please drop your cherry-pick of the commit I authored in open PR RUST-153738. It makes no sense whatsoever to take ownership of it & to include it here and in your ~5 other PRs. Your PRs can't proceed otherwise.

View changes since this review

@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 15, 2026
@rustbot
Copy link
Collaborator

rustbot commented Mar 15, 2026

Reminder, once the PR becomes ready for a review, use @rustbot ready.

@rustbot rustbot removed the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 15, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PG-exploit-mitigations Project group: Exploit mitigations T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[ICE]: explicit deref of non-derefable type

5 participants