This is an archive of the discontinued LLVM Phabricator instance.

Re-order type param children of ObjC nodes
ClosedPublic

Authored by steveire on Dec 6 2018, 3:31 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

steveire created this revision.Dec 6 2018, 3:31 PM

I don't know enough about ObjC to feel comfortable saying whether this is a reasonable reordering or not, so adding some reviewers.

test/AST/ast-dump-decl.m
90 ↗(On Diff #177071)

It seems strange to me to print out the type parameter after the superclass information given the source order. My understanding of the AST dumping order is that we try to keep the order of nodes in source order whenever possible.

steveire marked an inline comment as done.Jan 12 2019, 12:08 PM
steveire added inline comments.
test/AST/ast-dump-decl.m
90 ↗(On Diff #177071)

That is not really a possible thing to try to do, because the AST dump doesn't relate to a single language. It should be seen as language independent.

The principle I'm follow is that nodes dump themselves in entirety before starting to dump their child nodes. That is a principle already followed by most nodes. Changing this seems to be low cost, low impact and high benefit to the code.

dblaikie added inline comments.
test/AST/ast-dump-decl.m
90 ↗(On Diff #177071)

That is not really a possible thing to try to do, because the AST dump doesn't relate to a single language. It should be seen as language independent.

Is this particular aspect different between the different source languages Clang supports? (could you give examples?)

steveire marked an inline comment as done.Jan 14 2019, 7:52 AM
steveire added inline comments.
test/AST/ast-dump-decl.m
90 ↗(On Diff #177071)

Hmm, maybe that wasn't a good point, particularly because these methods relate to ObjC.

Other languages (eg Go https://gobyexample.com/functions) have different order of param types and param names, and different order of params and return types etc. So, the more general AST nodes have less reason for their order based on 'the order in the source'.

Anyway, the principle I'm following is 'the node dumps itself before dumping its children'. That's the principle that will allow separating traversal from output.

aaron.ballman added a subscriber: rjmccall.

Adding @rjmccall as an Obj-C expert to see if he has opinions on the output changes. Also, pinging @rsmith in case he'd like to weigh in.

I think the change in behavior here is reasonable, especially because it eases the transition to a more generic AST dump traverser. If Richard and John don't have strong objections (or don't come back with opinions) in the next week or two, I think we should move this forward.

test/AST/ast-dump-decl.m
90 ↗(On Diff #177071)

I'm not opposed to changing the order of the nodes so long as the resulting output is still sufficiently clear. This test case looks reasonable to me, but it also has very little information printed between the ObjCInterfaceDecl node and the ObjCTypeParamDecl node. I don't know whether it's common to have long protocol lists in ObjC or not where that distance will widen to the point of being hard to understand the relationship between the two nodes.

I don't really have an opinion about this, sorry.

I don't really have an opinion about this, sorry.

Do you think ObjC users will find the new output to be harder to read or less understandable than the old output?

This is the AST dumper. This is not a user feature.

If I'm debugging a clang bug and calling D->dump(), I think it'll be just as clear as it used to be what the ObjCTypeParamDecl lines mean.

aaron.ballman accepted this revision.Jan 15 2019, 11:22 AM

This is the AST dumper. This is not a user feature.

Clang developers are users, too. However, the AST dumping does get used a bit by non-Clang developers too (such as people using clang-query, who see AST output).

If I'm debugging a clang bug and calling D->dump(), I think it'll be just as clear as it used to be what the ObjCTypeParamDecl lines mean.

Fantastic, that's the key bit. Thank you for weighing in!

If John doesn't think the change in output will cause confusion for people more familiar with ObjC, then I'm good with these changes.

This revision is now accepted and ready to land.Jan 15 2019, 11:22 AM
This revision was automatically updated to reflect the committed changes.