Implement logic to garble exported struct fields

[capnspacehook]

I was thinking we could implement 3 main strategies when dealing with exported struct fields. First, a flag could be introduced that when set will garble all exported struct fields. This would be helpful if the user knows that the input code does not need exported struct fields unchanged. Additionally, we could have a second flag that will only garble exported struct fields that do not have a struct tag, or maybe have struct tags that do/do not contain certain substrings (ie json:). This could be set as the safe default. Finally, a third flag could be created that when set will never garble any exported struct tags. This would be useful when the other two options break a user's code, and would be a last resort option.

I believe that giving the user some control over what gets garbled can help to overcome the difficulty of statically determining if exported struct fields can be safely renamed or not.

[mvdan]

I think this could be done for the vast majority of cases with static analysis. That is, by default, all types get their exported fields garbled. We avoid garbling a type's exported fields if we detect that reflection is being used on it, such as:

• reflect.TypeOf
• std APIs which call reflect, like json.Marshal

The big question there is what to do about third party libraries which indirectly use reflect. We could either not support automatically detecting those (and relying on the user adding a hint to garble, like var _ = reflect.TypeOf(MyType{})), or we could attempt to maintain a list of well-known third-party APIs that use reflection.

I think the former is probably the best option, though it could get annoying if one makes extensive use of reflection in an indirect way. It's already implemented for methods (see mvdan@8b898ad), so we would just need to update the code to work on fields too.

[mvdan]

And yes, I agree that relying on field tags is a good idea. If an exported field has a field tag, that probably means it's going to be inspected via reflection and shouldn't be touched.

[capnspacehook]

Ok, so basically, exported struct fields should not be garbled if:

• they have a field tag
• the field is used with a stdlib reflection function

I agree that we shouldn't bear the burden of maintaining a list of their-party APIs that use reflection. We could rely on the user provides hints like you mentioned, or if maybe they added a garble-specific comment, like //garble: norename to the field.

[mvdan]

A garble-specific comment is still a form of a hint, so I would rather make them self-explanatory with reflect no-ops. It's just a way to tell static analysis tools "look, I will use reflection on this type" in a very obvious way. The bonus points is that such a hint can work for many tools, whereas a special garble comment likely won't.

[mvdan]

If you would like to implement this idea, it is probably far less complex than #3, so I would suggest to tackle this first. For example, there is no need to modify how we hash the names, and no fancy static analysis is required such as obtaining a list of all defined interfaces in a program.