Trait inference is broken for unnamed structs

[gerben-stavenga]

I tried this code:

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=f985f43df2ad05edfb593d23248e46f3

I expected to see this happen: That this works both for structs with named fields as with structs with anonymous fields

Instead, this happened: Works as expected for named fields, but fails to compile for anonymous structs

[maxcabrajac]

I was trying to come up with a mcve and found out that the tuple-like struct initialization is not supported by associated types.
Your example can be boiled down to:

trait Trait {
    type Assoc;
    fn new_assoc(self) -> Self::Assoc;
}

struct TupleLike(u8);

impl Trait for () {
    type Assoc = TupleLike;

    fn new_assoc(self) -> Self::Assoc {
        Self::Assoc(8)
    }
}

Just like your example, this doesn't work, but we can get it to work by initializing Assoc as if it was a struct with named fields

trait Trait {
    type Assoc;
    fn new_assoc(self) -> Self::Assoc;
}

struct TupleLike(u8);

impl Trait for () {
    type Assoc = TupleLike;

    fn new_assoc(self) -> Self::Assoc {
        Self::Assoc{ 0: 8 }
    }
}

I find this to be quite unintuitive, but it makes sense if you think that the compiler would have to check whether or not Assoc is a tuple-like struct before enabling this syntax and falling back to the normal way of doing things is a supported (although unintuitive) fallback.
I think the syntax you used should be supported. If there is a reason why it isn't at least a better diagnostic would be great.

[gerben-stavenga]

As a noob I was unaware of the ability to initialize as regular struct. Thanks Still this seems both ways should work. Or indeed at least a nice error

…

On Fri, Sep 13, 2024 at 1:03 PM maxcabrajac ***@***.***> wrote: I was trying to come up with a mcve and found out that the tuple-like struct initialization is not supported by associative types. Your example can be boiled down to: trait Trait { type Assoc; fn new_assoc(self) -> Self::Assoc;} struct TupleLike(u8); impl Trait for () { type Assoc = TupleLike; fn new_assoc(self) -> Self::Assoc { Self::Assoc(8) }} Just like your example, this doesn't work, but we can get it to work by initializing Assoc as if it was a struct with named fields trait Trait { type Assoc; fn new_assoc(self) -> Self::Assoc;} struct TupleLike(u8); impl Trait for () { type Assoc = TupleLike; fn new_assoc(self) -> Self::Assoc { Self::Assoc{ 0: 8 } }} I find this to be quite unintuitive, but it makes sense if you think that the compiler would have to check whether or not Assoc is a tuple-like struct before enabling this syntax and falling back to the normal way of doing things is a supported (although unintuitive) fallback. I think the syntax you used should be supported. If there is a reason why it isn't at least a better diagnostic would be great. — Reply to this email directly, view it on GitHub <#130318 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANBGINLDKOV7MNRUELQZXGDZWNAKJAVCNFSM6AAAAABOF36H2GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGNJQGA3DQMRRGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[maxcabrajac]

I did some digging and I think I found where change is needed to allow this syntax.

While resolving the expression Self::Assoc(8) which is of kind Call the compiler goes through the function below with a TypeRelative qpath which results in a call to resolve_fully_qualified_call that (based on its description) righteously returns an error, as Self::Assoc is not a method.

rust/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs

Lines 741 to 860 in f609b7e

	pub fn resolve_ty_and_res_fully_qualified_call(
	&self,
	qpath: &'tcx QPath<'tcx>,
	hir_id: HirId,
	span: Span,
	) -> (Res, Option<LoweredTy<'tcx>>, &'tcx [hir::PathSegment<'tcx>]) {
	let (ty, qself, item_segment) = match *qpath {
	QPath::Resolved(ref opt_qself, path) => {
	return (
	path.res,
	opt_qself.as_ref().map(|qself| self.lower_ty(qself)),
	path.segments,
	);
	}
	QPath::TypeRelative(ref qself, ref segment) => {
	// Don't use `self.lower_ty`, since this will register a WF obligation.
	// If we're trying to call a nonexistent method on a trait
	// (e.g. `MyTrait::missing_method`), then resolution will
	// give us a `QPath::TypeRelative` with a trait object as
	// `qself`. In that case, we want to avoid registering a WF obligation
	// for `dyn MyTrait`, since we don't actually need the trait
	// to be object-safe.
	// We manually call `register_wf_obligation` in the success path
	// below.
	let ty = self.lowerer().lower_ty(qself);
	(LoweredTy::from_raw(self, span, ty), qself, segment)
	}
	QPath::LangItem(..) => {
	bug!("`resolve_ty_and_res_fully_qualified_call` called on `LangItem`")
	}
	};
	if let Some(&cached_result) = self.typeck_results.borrow().type_dependent_defs().get(hir_id)
	{
	self.register_wf_obligation(
	ty.raw.into(),
	qself.span,
	ObligationCauseCode::WellFormed(None),
	);
	// Return directly on cache hit. This is useful to avoid doubly reporting
	// errors with default match binding modes. See #44614.
	let def = cached_result.map_or(Res::Err, |(kind, def_id)| Res::Def(kind, def_id));
	return (def, Some(ty), slice::from_ref(&**item_segment));
	}
	let item_name = item_segment.ident;
	let result = self
	.resolve_fully_qualified_call(span, item_name, ty.normalized, qself.span, hir_id)
	.map(|r| {
	// lint bare trait if the method is found in the trait
	if span.edition().at_least_rust_2021() {
	self.dcx().try_steal_modify_and_emit_err(
	qself.span,
	StashKey::TraitMissingMethod,
	|_err| {},
	);
	}
	r
	})
	.or_else(|error| {
	let guar = self
	.dcx()
	.span_delayed_bug(span, "method resolution should've emitted an error");
	let result = match error {
	method::MethodError::PrivateMatch(kind, def_id, _) => Ok((kind, def_id)),
	_ => Err(guar),
	};
	let trait_missing_method =
	matches!(error, method::MethodError::NoMatch(_)) && ty.normalized.is_trait();
	// If we have a path like `MyTrait::missing_method`, then don't register
	// a WF obligation for `dyn MyTrait` when method lookup fails. Otherwise,
	// register a WF obligation so that we can detect any additional
	// errors in the self type.
	if !trait_missing_method {
	self.register_wf_obligation(
	ty.raw.into(),
	qself.span,
	ObligationCauseCode::WellFormed(None),
	);
	}
	// Emit the diagnostic for bare traits. (We used to cancel for slightly better
	// error messages, but cancelling stashed diagnostics is no longer allowed because
	// it causes problems when tracking whether errors have actually occurred.)
	if span.edition().at_least_rust_2021() {
	self.dcx().try_steal_modify_and_emit_err(
	qself.span,
	StashKey::TraitMissingMethod,
	|_err| {},
	);
	}
	if item_name.name != kw::Empty {
	self.report_method_error(
	hir_id,
	ty.normalized,
	error,
	Expectation::NoExpectation,
	trait_missing_method && span.edition().at_least_rust_2021(), // emits missing method for trait only after edition 2021
	);
	}
	result
	});
	if result.is_ok() {
	self.register_wf_obligation(
	ty.raw.into(),
	qself.span,
	ObligationCauseCode::WellFormed(None),
	);
	}
	// Write back the new resolution.
	self.write_resolution(hir_id, result);
	(
	result.map_or(Res::Err, |(kind, def_id)| Res::Def(kind, def_id)),
	Some(ty),
	slice::from_ref(&**item_segment),
	)
	}

It seems like, this function must be able to resolve to (based on other debug messages I got) TupleLike::{constructor#0}, but I have no idea on how to do that... Can anyone give me some guidance?

@rustbot label +E-help-wanted
@rustbot claim