@Table macro misbehaves on nested Types

[dirk68-fu]

Description

The following

struct Outer{
    @Table struct Inner1:Identifiable{
        let id:Int
    }
    
    @Table struct Inner2:Identifiable{
        let id:Int
        let inner1ID:Inner1.ID
    }
}

results in an error: 'Inner1' in scope inside the macro expansion.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• I have determined whether this bug is also reproducible in a vanilla GRDB project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

The Swift compiles has no problem with Inner1.ID but the macro does. You have to revert to Outer.Inner1.ID to make it work.
Unfortunately swifts error message is not very helpful.

Actual behavior

No response

Reproducing project

No response

SharingGRDB version information

No response

Sharing version information

No response

GRDB version information

No response

Destination operating system

No response

Xcode version information

No response

Swift Compiler version information

[mbrandonw]

Hi @dirk68-fu, I'm not sure there is much we can do about this. The problem is that the macro expands an extension of Inner2 that looks like this:

nonisolated extension Outer.Inner2: Table, PrimaryKeyedTable {
  public nonisolated init(decoder: inout some QueryDecoder) throws {
    let inner1ID = try decoder.decode(Inner1.ID.self)
    …
  }
  …
}

In this extension, a bare Inner1 does not resolve to Outer.Inner1 like it does when writing code directly nested inside struct Outer. Here is a simplified version of what is going on:

struct Outer {
  struct Inner1 {}
  struct Inner2 {
    typealias A = Inner1 // ✅
  }
}

extension Outer.Inner2 {
  typealias B = Inner1 // 🛑
}

And on top of this, we do not have enough information from the syntax to determine if we should fully qualify your types with Outer.. So I think this is just a quirk of how extension macros work in general. You will just need to know to fully qualify your types in certain situations.

Since this isn't an issue with the library I am going to convert it to a discussion. Please feel free to continue the conversation over there!

[dirk68-fu]

Could you do anything about the error message?

[mbrandonw]

I don’t really see how. If we could determine that there was going to be a problem in order to provide a better error message, then we could probably just generate the macro code without the problem in the first place. The difficulty is figuring out there will be a problem with nested types.