[PATCH] D55394: Re-order type param children of ObjC nodes

Stephen Kelly via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jan 14 07:53:11 PST 2019


steveire marked an inline comment as done.
steveire added inline comments.


================
Comment at: test/AST/ast-dump-decl.m:90
 // CHECK-NEXT:   -ObjCProtocol {{.+}} 'P'
+// CHECK-NEXT:   -ObjCTypeParamDecl {{.+}} <col:33> col:33 T 'id':'id'
 
----------------
dblaikie wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > 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.
> > 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.
> >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?)
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.


Repository:
  rC Clang

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D55394/new/

https://reviews.llvm.org/D55394





More information about the cfe-commits mailing list