Stream: t-compiler

Topic: Reveal::UserFacing and associated types vs const


centril (Mar 26 2020 at 06:30, on Zulip):

@eddyb looks like the impl has inconsistencies then; cause omitting an associated type without further marking it as default does have the effect of locking in the type, per https://github.com/rust-lang/rust/pull/64564

eddyb (Mar 26 2020 at 06:31, on Zulip):

@Jonas Schievink yeah, this part here of "is implicitly default" should've been adjusted https://github.com/rust-lang/rust/blob/master/src/librustc_trait_selection/traits/project.rs#L1019-L1020

eddyb (Mar 26 2020 at 06:32, on Zulip):

@centril you're saying there's a required chain of defaults now?

centril (Mar 26 2020 at 06:33, on Zulip):

let me cook up an example

centril (Mar 26 2020 at 06:34, on Zulip):

@eddyb https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f211bc5670f7a50631fdfbff832afbba

eddyb (Mar 26 2020 at 06:34, on Zulip):

the implementation basically remains conservative, with small exceptions

centril (Mar 26 2020 at 06:36, on Zulip):

@eddyb I'd recommend going over Jonas's two PRs (esp. the tests) and reading over the RFC

eddyb (Mar 26 2020 at 06:37, on Zulip):

@centril I don't think the specialization graph was updated for this

centril (Mar 26 2020 at 06:37, on Zulip):

yea, the impl was partial

eddyb (Mar 26 2020 at 06:37, on Zulip):

to take advantage of this knowledge you need two trait/impl's, not just one

eddyb (Mar 26 2020 at 06:37, on Zulip):

the defaulter and the finalizer

eddyb (Mar 26 2020 at 06:37, on Zulip):

when they're equal, it's a non-default

eddyb (Mar 26 2020 at 06:38, on Zulip):

when not, and the finalizer isn't missing, you actually can treat something declared as default, as if it weren't

eddyb (Mar 26 2020 at 06:39, on Zulip):

but you need to tell apart the presence of the finalizer, which the current implementation just doesn't have a way to do, except when the default is from the trait

eddyb (Mar 26 2020 at 06:39, on Zulip):

because there's clearly a finalizer otherwise you wouldn't have matched the trait

eddyb (Mar 26 2020 at 06:40, on Zulip):

none of this would simplify the implementation, at least, and you'd still have cases where even miri/codegen can't normalize something because it hits the blanket impl with a default type or default const and has no finalizer

eddyb (Mar 26 2020 at 06:40, on Zulip):

so e.g. it wouldn't help with @davidtwco's polymorphization struggles

eddyb (Mar 26 2020 at 06:43, on Zulip):

uh oh, just realized https://github.com/rust-lang/rust/blob/master/src/librustc_ty/instance.rs#L90-L100 is missing this entire logic https://github.com/rust-lang/rust/blob/master/src/librustc_trait_selection/traits/project.rs#L1018-L1042

centril (Mar 26 2020 at 06:45, on Zulip):

I'm glad we would be able to ship associated type defaults without finalizing the specialization interactions :P

eddyb (Mar 26 2020 at 06:47, on Zulip):

is this unnecessary? I can't trigger the bad behavior I expected to on playground https://github.com/rust-lang/rust/blob/master/src/librustc_trait_selection/traits/project.rs#L1041

eddyb (Mar 26 2020 at 06:48, on Zulip):

ah nvm we use Reveal::All so I can't have generics which means... yeah nvm lol

eddyb (Mar 26 2020 at 06:48, on Zulip):

it doesn't matter how correct instance::resolve_associated_item is, since it's never used with UserFacing

eddyb (Mar 26 2020 at 06:49, on Zulip):

except by WF I guess?

eddyb (Mar 26 2020 at 06:50, on Zulip):

argh, no, the defaultness condition is first, which means it would override Reveal

eddyb (Mar 26 2020 at 06:54, on Zulip):

@Wesley Wiser why does this not constant fold? I was hoping to show a bad optimization :(
but I can't because it doesn't actually do what I want it to https://play.rust-lang.org/?version=nightly&mode=release&edition=2018&gist=d247d1ea11675ed855171a239cac7517

eddyb (Mar 26 2020 at 06:55, on Zulip):

maybe I can trick miri into evaluating something

eddyb (Mar 26 2020 at 07:26, on Zulip):

meh opened #70419, I don't want to care about this further

nikomatsakis (Mar 26 2020 at 20:55, on Zulip):

Hmm so I think that this example should get an error on the u8 case, but not () -- that meets your expectations, @centril ?

trait Trait {
    type Assoc;
}

impl<T> Trait for T {
    default type Assoc = bool;
}

impl Trait for () {}

fn foo<X: Trait<Assoc=bool>>() {}

fn main() {
    foo::<u8>(); //~ ERROR
    foo::<()>();
}

that is not, however, the current behavior, it's true.

nikomatsakis (Mar 26 2020 at 20:56, on Zulip):

I don't think this is covered by #70419

centril (Mar 26 2020 at 20:58, on Zulip):

@nikomatsakis I think that does meet them, but I haven't though deeply about it (slept too little today to do so now anyways :slight_smile:)

centril (Mar 26 2020 at 20:59, on Zulip):

Basic rationale being that for () has locked in the associated type

centril (Mar 26 2020 at 20:59, on Zulip):

so further specialization doesn't apply

nikomatsakis (Mar 26 2020 at 21:04, on Zulip):

Filed https://github.com/rust-lang/rust/issues/70442 to cover that particuar bug

Last update: May 29 2020 at 17:25UTC