Skip to content

Conversation

danakj
Copy link
Contributor

@danakj danakj commented Aug 14, 2025

We test using .Self in a generic parameter of an interface and as the value of an associated constant.

@danakj danakj requested a review from zygoloid August 14, 2025 16:26
@github-actions github-actions bot requested a review from geoffromer August 14, 2025 16:26
@danakj
Copy link
Contributor Author

danakj commented Aug 14, 2025

I got a bad feeling I am getting the typish levels wrong here after continuing to stare at things.

@danakj danakj changed the title Add failing tests for using the return of a function that returns a facet value as a type Add failing tests for exposing the value of .Self through an interface Sep 8, 2025
@danakj danakj requested review from zygoloid and removed request for geoffromer September 8, 2025 17:41
@danakj danakj force-pushed the test-call-returning-facet-value branch from f75b1f7 to 96a1ffd Compare September 8, 2025 17:43
@danakj
Copy link
Contributor Author

danakj commented Sep 8, 2025

Thanks for that review, I removed the bogus test, and I have added a bunch more tests of .Self that I was using to test #5966 while working on it. It would be good to make sure we agree they are all supposed to pass as written.

@danakj danakj force-pushed the test-call-returning-facet-value branch from 38728ea to eecce58 Compare September 8, 2025 18:31
@danakj danakj force-pushed the test-call-returning-facet-value branch from eecce58 to fd9072a Compare September 8, 2025 19:24
@danakj
Copy link
Contributor Author

danakj commented Sep 8, 2025

Updated the nesting tests with what we discovered in open discussion today.

@danakj
Copy link
Contributor Author

danakj commented Sep 15, 2025

bump for review

Copy link
Contributor Author

@danakj danakj left a comment

Choose a reason for hiding this comment

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

PTAL

@danakj danakj requested a review from zygoloid September 18, 2025 15:11
@danakj danakj force-pushed the test-call-returning-facet-value branch 2 times, most recently from 5758d72 to cb85ed0 Compare September 18, 2025 15:19
@danakj danakj force-pushed the test-call-returning-facet-value branch from cb85ed0 to afc3467 Compare September 18, 2025 15:25
Comment on lines +282 to +287
// Shows both `I(.Self)` are `I(T)`.
// CHECK:STDERR: fail_todo_nested_period_self.carbon:[[@LINE+4]]:9: error: found cycle in facet type constraint for `.(I(T).A)` [FacetTypeConstraintCycle]
// CHECK:STDERR: T as (I(T) where .A = (I(T) where .A = {} and .B = {}));
// CHECK:STDERR: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// CHECK:STDERR:
T as (I(T) where .A = (I(T) where .A = {} and .B = {}));
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think this should actually be a cycle, but it's still being reported as one when I get .Self working more, so pointing this out to double check.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I agree this is a false positive. I guess our cycle checking is incorrectly thinking the .A nested inside the second where is a rewrite for the outer .A, or something like that?

Copy link
Contributor

@zygoloid zygoloid left a comment

Choose a reason for hiding this comment

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

Looks good, thanks. Some comments but nothing that needs another look I think.

// CHECK:STDERR: U as (I where .I1 = U);
// CHECK:STDERR: ^~~~~~~~~~~~~~~~~~~~~~
// CHECK:STDERR:
U as (I where .I1 = U);
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we have tests of the opposite condition somewhere too?

U as (I where .I1 = .Self);
(U as type) as (I where .I1 = .Self);

// CHECK:STDERR: u.(I.G)();
// CHECK:STDERR: ^~~~~~~
// CHECK:STDERR:
u.(I.G)();
Copy link
Contributor

Choose a reason for hiding this comment

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

Would it make sense to split this and the next line out from the file that contains the previous let declaration, so that we don't have a mixture of "should not fail but does" and "should fail and does" in the same file?

Comment on lines +282 to +287
// Shows both `I(.Self)` are `I(T)`.
// CHECK:STDERR: fail_todo_nested_period_self.carbon:[[@LINE+4]]:9: error: found cycle in facet type constraint for `.(I(T).A)` [FacetTypeConstraintCycle]
// CHECK:STDERR: T as (I(T) where .A = (I(T) where .A = {} and .B = {}));
// CHECK:STDERR: ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// CHECK:STDERR:
T as (I(T) where .A = (I(T) where .A = {} and .B = {}));
Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, I agree this is a false positive. I guess our cycle checking is incorrectly thinking the .A nested inside the second where is a rewrite for the outer .A, or something like that?

Comment on lines +15 to +16
// TODO: Improved error: no member named `I1` in `T` of type `type`.
//
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this ought to be valid: because T is a template parameter, we ought to defer the lookup until we have a non-template value for it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants