lazy_normalization_consts breaks unsize coercion in rare cases

@nikomatsakis

#![feature(lazy_normalization_consts)]
struct P<T: ?Sized>([u8; 1 + 4], T);

fn main() {
    let x: Box<P<[u8; 0]>> = Box::new(P(Default::default(), [0; 0]));
    let _: Box<P<[u8]>> = x;
}

This works on stable but fails with the following error when using lazy_normalization_consts

error[E0308]: mismatched types
 --> src/main.rs:6:27
  |
6 |     let _: Box<P<[u8]>> = x;
  |            ------------   ^ expected slice `[u8]`, found array `[u8; 0]`
  |            |
  |            expected due to this
  |
  = note: expected struct `Box<P<[u8]>>`
             found struct `Box<P<[u8; 0]>>`

For this to fail the struct has to contain a type referencing an unevaluated constant, struct P<T: ?Sized>([u8; 5], T) does work.

assigning to myself, but won't get to this right away. If you are interested in working on this before that feel free to do so.

cc @nikomatsakis @varkor

@oli-obk

The issue is here

rust/compiler/rustc_trait_selection/src/traits/select/confirmation.rs

Lines 846 to 854 in f5230fb

    
           for field in prefix_fields { 
        
               for arg in tcx.type_of(field.did).walk() { 
        
                   if let Some(i) = maybe_unsizing_param_idx(arg) { 
        
                       if unsizing_params.contains(i) { 
        
                           return Err(Unimplemented); 
        
                       } 
        
                   } 
        
               } 
        
           }

in combination with

rust/compiler/rustc_middle/src/ty/walk.rs

Line 199 in f5230fb

stack.extend(substs.iter().rev());

We currently look at all substs while we should only look at the generic params which are actually mentioned by the constant.
The correct solution would be to instead walk the AbstractConst in case it exists, but for that we would have to move that to rustc_middle and also need to access the TyCtxt everywhere which seems difficult.

I am currently thinking about moving AbstractConsts directly into ConstKind as the current ConstKind::Unevaluated is really unhelpful when dealing with anonymous constants. That would simplify dealing with them as we can then just treat them pretty much exactly like other projections, 🤔 would be a big change though, so it might make sense allocate some time to discuss this before doing anything stupid here...

cc @oli-obk

I don't think we can remove Unevaluated. There are cases where we can neither build an abstract const nor evaluate it to a concrete constant. And once we have an abstract const, we can't turn that abstract const into a concrete one, so we'd need to keep the information about the uneavluated source around anyway. Can you elaborate on the changes you were thinking about?

I am not too sure how to actually do this yet... probably by adding an optional reference to &'tcx [Node<'tcx>] to Unevaluated 🤔

we might not be able to just evaluate mir_abstract_const eagerly as that can cause query cycles though. I forgot what actually causes the cycles without lazy normalization

At that point you're just talking about caching, so one thing that we could also do is change the Unevaluated variant to be a tuple variant around an UnevaluatedConst which has methods for evaluating or converting to an abstract const, without exposing the internal fields anymore. The evaluation is already cached via the query system, and I think the abstract const building, too? So this would just be an API change to make it less painful to use.

@BoxyUwU

will be replaced by MGCA cc @BoxyUwU

Navigation Menu

Repository navigation

lazy_normalization_consts breaks unsize coercion in rare cases #78369

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	for field in prefix_fields {
	for arg in tcx.type_of(field.did).walk() {
	if let Some(i) = maybe_unsizing_param_idx(arg) {
	if unsizing_params.contains(i) {
	return Err(Unimplemented);
	}
	}
	}
	}

lazy_normalization_consts breaks unsize coercion in rare cases #78369

Description

Activity

lcnr commented on Nov 16, 2020

oli-obk commented on Nov 16, 2020

lcnr commented on Nov 16, 2020

oli-obk commented on Nov 16, 2020

lcnr commented on Nov 11, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions