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



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to