[cfe-dev] RFC: refactoring libclangDriver/libclangFrontend to share with Flang

[Andrzej Warzynski via cfe-dev]

Todd,

Thank you for your email!

At this stage we are only focusing on a relatively basic driver 
supporting a very small amount of options compared to Clang. Our main 
goal for now is to leverage libclangDriver without introducing the 
dependency on Clang. This means refactoring libclangDriver enough so 
that it can be moved to a dedicated subproject.

I agree that the way options are handled in libclangDriver could be a 
bit more sympathetic to customising the output of `-help`. Thank you for 
raising this! We feel that this could be improved at later time. Knowing 
that others face similar issue is re-assuring and will make any future 
refactoring worthwhile.

More comments inline.


On 06/08/2020 18:14, Snider, Todd wrote:
> 
> What about downstream compiler products that want to provide a more 
> succinct �help output (clang �help will write 900+ lines to stdout)?

In this RFC I only focus on the Flang driver (i.e. one specific customer 
of libclangDriver), which want to implement upstream.

> 
> It seems like there should be a toolchain-specific way to filter the 
> DriverOptTable further than driver mode and existing groups and flags.

I agree, but this is out-of-scope of this RFC and what we want to 
achieve at this stage. We propose this as a future enhancement.

> 
>  > * Add new Flang options for libClangDriver to the main DriverOptTable
> 
> [11] table, perhaps via a separate *.td file
> 
> This would still emit a unified Options.inc file, yes?
> 

Correct, nothing changes in this respect.

> As my immediate interest is in customizing the �help output in a 
> toolchain specific way, I think there are (at least) two concerns:
> 

I think that these concerns relate to how options are _currently_ 
handled in libclangDriver in general. We have no plans to change that in 
the near future. Instead, we want to leverage the current implementation 
and filter options in printHelp via option groups/flags.
> 
> I�m interested to learn what other downstream compiler products like 
> armclang have done to solve this problem.


In armclang that I'm familiar with (AFAIK, there's more than 1), 
filtering is done at the printHelp level via option groups (i.e. 
similarly that what we intend to use for Flang).
-Andrzej