Skip to content

Conversation

@hborla
Copy link
Member

@hborla hborla commented Feb 3, 2024

When resolving an attached macro, the constraint system needs to check whether a potential macro candidate is available in the current context. That triggers building a type refinement context, and when the macro is applied at the top-level, building the type refinement context needs to resolve extensions because extensions get their availability from the extended type. However, if the extended type is nested inside another type that has attached macros, those macros must be expanded to produce any member types that might be added by the macro. This leads to circularity errors that cannot be resolved.

This change opts extension declarations into lazily building a TRC to avoid needing to resolve the extended type while building a type refinement context to check availability at an unrelated source location in the same file.

Resolves rdar://115851283, resolves #66450, resolves #70096

@hborla hborla force-pushed the lazy-trc-extension branch from 28cabf8 to 48eb4b7 Compare February 3, 2024 01:34
@hborla
Copy link
Member Author

hborla commented Feb 3, 2024

@swift-ci please smoke test

@hborla
Copy link
Member Author

hborla commented Feb 3, 2024

@swift-ci please test source compatibility

@hborla hborla marked this pull request as ready for review February 3, 2024 20:02
@hborla hborla requested review from a team, slavapestov, tshortli and xedin as code owners February 3, 2024 20:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Circular reference resolving attached macro 'xxx' Extensions for subtype of a class marked @Observable generate compile error

2 participants