Skip to content

Conversation

@danakj
Copy link
Contributor

@danakj danakj commented Nov 27, 2025

Errors that occur while constructing a specific should be tied back to the facet type being identified. We don't have an InstId for the facet type during identify, so provide the means to Stringify a FacetTypeId.

Depends on #6435

@danakj danakj requested a review from a team as a code owner November 27, 2025 17:49
@danakj danakj requested review from geoffromer and removed request for a team November 27, 2025 17:49
@danakj
Copy link
Contributor Author

danakj commented Nov 27, 2025

The first new commit here is diagnostic-note-identifying

@danakj danakj force-pushed the diagnostic-note-identifying branch from d96ee28 to fd0ada4 Compare November 27, 2025 17:52
@danakj danakj force-pushed the diagnostic-note-identifying branch from fd0ada4 to 6f6edf8 Compare November 27, 2025 17:54
// CHECK:STDERR: fail_error_in_identifying_extend_require_facet_type.carbon:[[@LINE+6]]:37: error: array bound of -1 is negative [ArrayBoundNegative]
// CHECK:STDERR: extend require impls K(array(i32, N));
// CHECK:STDERR: ^
// CHECK:STDERR: fail_error_in_identifying_extend_require_facet_type.carbon:[[@LINE+3]]:3: note: in `require` used here [ResolvingSpecificHere]
Copy link
Contributor

Choose a reason for hiding this comment

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

In this test the locations of the ResolvingSpecificHere notes contain the locations of the errors they annotate. Will that be true in general? If not, is it feasible to have a test where that's not the case?

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