types.implementing with an extension?

[bejar37]

Hi,
I'm using a phantom protocol to guide my code generation, and I noticed something interesting.

I have a template that looks like this:

{% for types.implementing.MyProtocol %}
// Generate some stuff here...
{% endfor %}

This works fine when I declare conformance like this:

struct IntBag: MyProtocol {
   let int: Int
}

but not like this:

struct IntBag {
   let int: Int
}

extension IntBag: MyProtocol { }

Is there a particular reason why the second example isn't picked up?

[bejar37]

Could it be related to this comment?

In my particular case I'm not extending a third party framework, but a class defined in the same target in objective c.

[ilyapuchka]

Hi, @bejar37 . No, that comment addresses the case when you extend not your own types. I'll check what can be an issue.

[ilyapuchka]

"defined in the same target in objective c" - is the reason, I think. I think what happens is that we don't get information about Objective-C types, so we treat them as unknown. Then it is really related to that comment and looks like a valid use case to put that functionality back. @krzysztofzablocki
I think it will be easier than going for processing Objective-C (I know jazzy does that but never checked how)

[krzysztofzablocki]

Yeah we don't have that info, only Swift sources that are under that given directory, we can enable that functionality, but let's tweak the log warning because I think it should be there so people are aware, we already have isExtension reflection on Type that will only be true for those cases so we don't need to add anything special

[bejar37]

The type is defined in objective c but "conformed" in Swift, I don't know if that would make a difference.

So in Swift I've written:

extension MyObjCClass: MyProtocol {}

[krzysztofzablocki]

Once @ilyapuchka enables that use-case of exposing partial types, you'll find your type there but it won't contain metadata transferred from Objective-C, that's, unfortunately, a limitation right now.

So if you were e.g. adding some computed variables there, those you'll have access to in Sourcery

[bejar37]

Sure, that's not my use case, anyways! Thanks so much for the help.

[krzysztofzablocki]

I've released 0.3.9 version that should solve this issue, could you confirm it's working now @bejar37 ?

[bejar37]

I'm getting an error in my xcode build phase in 0.3.9 @krzysztofzablocki:

/Pods/Sourcery/bin/Sourcery: line 6: 66268 Illegal instruction: 4  "${parent_path}"/Sourcery.app/Contents/MacOS/Sourcery "$@"

Looking to see if that's something on my end.

[krzysztofzablocki]

aren't you calling Sourcery by mistake? it should be using sourcery (lowercase)

[krzysztofzablocki]

If not what arguments are you passing in? Does it work when you grab the binary from release tab on github?

[bejar37]

@krzysztofzablocki My build phase is the following:
"${PODS_ROOT}/Sourcery/bin/sourcery" Source/ Templates/ GeneratedCode/

The output is:

Scanning sources...
./Pods/Sourcery/bin/sourcery: line 6: 71216 Illegal instruction: 4  "${parent_path}"/Sourcery.app/Contents/MacOS/Sourcery "$@"

I'll try to get set up with the binary.

[bejar37]

@krzysztofzablocki yes, FWIW I'm having the same problem with the binary release. Kinda stumped, do you think there's anything else I can do to find the cause of the crash?

Thanks for all the help!

[krzysztofzablocki]

I don't think the Pathes are correct? can you try running against full paths? or using something like:

"${PODS_ROOT}/Sourcery/bin/sourcery" "${SRCROOT}/Sourcery-Example" "${SRCROOT}/Templates" "${SRCROOT}/CodeGenerated"

[bejar37]

Weird, I upgraded to 0.4.0 yesterday and the script was running again. I must have been doing something strange. And this feature works great! Thanks again.