Page MenuHomePhabricator

APINotes: add property models for YAML attributes
ClosedPublic

Authored by compnerd on Nov 9 2020, 2:55 PM.

Details

Summary

This adds internal representation of the attributes in a more usable
form. This is meant to allow programmatic access to the attributes that
are specified in the YAML data.

Diff Detail

Event Timeline

compnerd created this revision.Nov 9 2020, 2:55 PM
Herald added a project: Restricted Project. · View Herald TranscriptNov 9 2020, 2:55 PM
compnerd requested review of this revision.Nov 9 2020, 2:55 PM
compnerd added a comment.EditedNov 9 2020, 2:57 PM

@martong since you hard expressed interest in the "user-visible" version of the data types for the notes, I opted to get them out first. This set of data types are user-facing rather than the previous one that were mistook for them. Subsequent changes will actually add interfaces to APINotesWriter which will allow you to add new information to the writer to serialize out.

I figured that even though this is a NFC change and doesn't contain anything interesting, since you had expressed interest, I'd create a pre-commit review for it. Additionally, the size was large enough that I thought it might be better to simply do the NFC change here and the usage subsequently. If you feel like it is better to have both integrated, that is fine by me, but it will result in a larger change.

Ping; I'd let to get this sorted out so I can continue to make progress towards serialization and deserialization.

martong added inline comments.Nov 19 2020, 6:34 AM
clang/include/clang/APINotes/Types.h
60

I was wondering whether Swift specific properties are meaningful to all descendants of CommonEntityInfo. With other words, can we attach the swift private attribute to all kind of declarations? If not, perhaps then we need a "middle" base class injected into the class hierarchy.

And I have the same question for CommonTypeInfo, regarding SwiftBridge and other Swift sweeties.

125

This comment is probably off.

529

Do we document somewhere that the 0 index means the return type? Maybe adding a constant like ReturnIdx could resolve this magic number.

531

Probably this comment is off.

clang/lib/APINotes/APINotesTypes.cpp
21

Perhaps it would be worth to add dump methods for the other Info classes.

compnerd marked 2 inline comments as done.Nov 19 2020, 9:54 AM
compnerd added inline comments.
clang/include/clang/APINotes/Types.h
60

The __swift_private__ attribute applies to all declarations, so I think that it makes sense as is. I suppose that we can do multiple inheritance if you want to separate the Swift and ObjC attributes.

The __swift_bridge__ attribute only applies to tags, typedefs, ObjC interfaces and protocols. The __swift_name__ attribute applies to all declarations.

The __ns_error_domain__ attribute is ObjC specific, though Swift does care about it. It only applies to enum types though.

The vast majority of the Swift attributes do apply to a wide variety of types, and I think that the current structure makes sense. It seems a bit unnecessary to split them out further into a structure and loose the packing, but I suppose that one option would be to add wrapper structs around all the language specific options, but that comes at the cost of higher memory usage for clang, which is already significant at times.

125

I think that this comment is correct, it is describing the SwiftBridge field.

529

Sure, I can add a constant for that. I don't think that we have that documented, but, I think that the constant should be sufficient for that no?

compnerd updated this revision to Diff 306487.Nov 19 2020, 11:15 AM
compnerd marked 5 inline comments as done.

Address review comments

clang/include/clang/APINotes/Types.h
529

Rather, we don't have it commented outside of the header (we document it in the nullability payload internal docs above ~491).

clang/lib/APINotes/APINotesTypes.cpp
21

Well, I don't think it really hurts, the dump methods should get dropped in released toolchains, so this is just painful to write the dumps is all. Added.

martong accepted this revision.Nov 20 2020, 2:35 AM

Thanks, looks good to me!

This revision is now accepted and ready to land.Nov 20 2020, 2:35 AM
This revision was landed with ongoing or failed builds.Nov 23 2020, 1:33 PM
This revision was automatically updated to reflect the committed changes.