Coercion sites are not consistent between struct tuples and structs

[nox]

pub struct Struct<K: 'static> {
    pub field: K,
}

static STRUCT: Struct<&'static [u8]> = Struct {
    field: &[1]
};

pub struct Tuple<K: 'static>(K);

static TUPLE: Tuple<&'static [u8]> = Tuple(&[1]);

STRUCT fails to type check, while TUPLE succeeds.

<anon>:7:40: 9:2 error: mismatched types:
 expected `Struct<&'static [u8]>`,
    found `Struct<&[_; 1]>`
(expected slice,
    found array of 1 elements) [E0308]
<anon>:7 static STRUCT: Struct<&'static [u8]> = Struct {
<anon>:8     field: &[1]
<anon>:9 };
<anon>:7:40: 9:2 help: see the detailed explanation for E0308

[SimonSapin]

This coercion is important when using b"…" byte string literals.

[eddyb]

The tuple struct case is actually the function call "expected type" propagation, which would have to be adapted to struct literals as well.

[nox]

Yes.

[SimonSapin]

Coercion already happens in non-generic struct literals:

struct Foo { s: &'static [u8] }
static FOO: Foo = Foo { s: b"foo" };

[eddyb]

@SimonSapin Yes, but the field types are taken from the struct and not combined with the overall expected type for the struct literal.

[abonander]

I just discovered this bug/unexpected behavior today (#34240). I would like to see some movement on it because it's surprising that these two don't work the same way.

Here's a workaround I found; it's ugly as hell but I'm using it in a generated file that no human would want to look through anyway: https://is.gd/boA5ut

I tried type ascription but it seems to not cue coercion, it just moves the type error: https://is.gd/yut0EK

It seems that forcing a concrete type on the struct literal works as well (I didn't expect this syntax to work, honestly): https://is.gd/ZipLo1 Unfortunately this won't work for me because I'm using phf_codegen too and I can't add this extra syntax myself.

[nox]

Any news on this?

[KalitaAlexey]

Is anyone working on it?

[nikomatsakis]

It seems like @eddyb implemented a partial fix in #40398 but suggests that there are backwards incompatibility issues to be considered that preventing him from going further. I'm not quite sure what he had in mind there, perhaps he can elaborate.

[arielb1]

Making sure we remember to look at this.

[eddyb]

@nikomatsakis What I did is I computed a "light hint" (which becomes "strong hint", i.e. forcing coercion, if it reaches a block, and it's enough to help integer inference for #40355).

This is a common problem with coercion hints, in that unless there's enough type information to prevent them from triggering, they will trigger early even if that breaks later on.

The thing to try here is to replace these two lines with the simpler:

self.check_expr_coercable_to_type(&field.expr, field_type_hint)

final_field_type doesn't even need to be computed if that works, since field_type_hint is at least as specific - AFAICT, we already have that "specificity" with function calls, but since it hasn't been used with struct literals before, crater/cargobomb might reveal regressions.

[nikomatsakis]

@eddyb ok, I was mostly wondering if you encountered actual regressions in practice, or just theorize that this might lead to problems.

[eddyb]

@nikomatsakis I don't think I got the chance to do a crater run and then I lost track of it.

[nikomatsakis]

@arielb1 will open a PR and we can try a crater run at least.

[burdges]

There is still a similar problem with the type inference of temporaries when you have an array that should be interpreted as a slice buried in a tuple inside an outer slice.