fix: qualify type references in @Generable macro to avoid name collisions#44
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 583c724b78
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| inheritanceClause: InheritanceClauseSyntax( | ||
| inheritedTypes: InheritedTypeListSyntax([ | ||
| InheritedTypeSyntax(type: TypeSyntax(stringLiteral: "Generable")) | ||
| InheritedTypeSyntax(type: TypeSyntax(stringLiteral: "Conduit.Generable")) |
There was a problem hiding this comment.
Conduit. qualification from generated type names
Using Conduit.Generable (and similar Conduit.* references generated throughout this macro) breaks expansion for normal clients because the Conduit module itself defines a top-level Conduit type (Sources/ConduitFacade/ConduitFacade.swift), so lookup resolves Conduit as struct Conduit instead of the module and emits errors like 'Generable' is not a member type of struct 'Conduit.Conduit'. Any project that imports Conduit and applies @Generable will hit this compile failure.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
This was added because Schema is a widely used type name, and if you import something that uses that name the macro will be ambiguous and your code fails to compile.
|
@kylebrowning yes this makes sense! |
2 participants
Summary
The
@Generablemacro emits unqualified type references (GenerationSchema,GeneratedContent,Generable, etc.) in its generated code. When a consumer imports both Conduit and another framework that defines types with the same names (e.g., FluentKit definesSchema, Vapor projects commonly import both), compilation fails with ambiguity errors:This PR qualifies all Conduit type references in the macro's generated code with the
Conduit.module prefix, so they resolve correctly regardless of what other modules the consumer imports.Changes
GenerationSchema→Conduit.GenerationSchemaGenerationSchema.Property→Conduit.GenerationSchema.PropertyGeneratedContent→Conduit.GeneratedContentGenerationID→Conduit.GenerationIDConvertibleFromGeneratedContent→Conduit.ConvertibleFromGeneratedContentGenerable→Conduit.GenerableOnly string literals producing generated code are changed — the macro plugin's own internal Swift code is untouched.
Test plan
swift buildpasses on the Conduit repoConduitandFluentKitcan use@Generablewithout ambiguity errors