Katze719 wrote:

> > thanks, that makes sense, my intention was not to make parameter names part 
> > of the function type, but to expose the `ParmVarDecls` stored in 
> > `FunctionProtoTypeLoc` as source information on the typedef or alias
> > would a separate representation for that information make more sense, or is 
> > it simply out of scope for the JSON AST dump? i would be happy to rework 
> > the patch if there is a suitable approach
> 
> Thank you for the offer! It's worth putting more thought into, but my initial 
> inclination is that this feels out of scope for AST dumping. The names of the 
> parameters aren't semantically meaningful within the type even if you can 
> write them (e.g., `(void (*)(int param))nullptr` is valid to write, but 
> `param` is entirely meaningless). So it doesn't really help anyone understand 
> the AST if we print it, but I can see how it's useful information for 
> tooling. But tooling needs are usually better handled via libclang or AST 
> matchers + the C++ APIs.

Got it, thanks for your time. i will keep handling this downstream in my tool 
ASTrein and close the PR

https://github.com/llvm/llvm-project/pull/218740
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to