Incorrect code generation when type exists inside and outside a macro

[efirestone]

If you have code like this:

#if DEBUG
        // @knit internal
        container.registerAbstract(Foo.self, name: "a")
#endif

        // @knit internal
        container.registerAbstract(Foo.self, name: "b")

then the generated code will have the definition for func foo(name: FooKey) inside of an #if DEBUG block, which means that there's no way to access resolver.foo(name: .b).

If you switch the order of the definitions then it won't be in the #if DEBUG block, but now you can access foo(name: .b) when you shouldn't be able to. And presumably, if the registration wasn't abstract then you might try to pull dependencies into your production code that you shouldn't.

I would expect some of the key values to be scoped within #if DEBUG, but the method itself would be outside of any if-defs.

[skorulis-ap]

Good catch, this case was never handled properly. #247 adds support.

• If a group of named registrations all have the same #if condition then the resolver and the enum are both wrapped in the same condition.
• If registrations in the group have different #if conditions, the resolver will not have a condition and the enum cases will be wrapped in #if conditions from the individual registrations.