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

[Snider, Todd via cfe-dev]

Hi Andrzej,

Thanks for the quick response. 

I realize that customization of the DriverOptTable is not quite in the scope of your RFC, but regarding ...

>> 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).

It sounds like the armclang solution might freely be adding to/editing the Options.td file (special group filter + custom HelpText fields), yes?

If that is the case, it is not something that would likely be upstreamed.

Is there someone familiar with how armclang implements a custom help display that could provide more details?

~ Todd

-----Original Message-----
From: Andrzej Warzynski [mailto:andrzej.warzynski at arm.com] 
Sent: Friday, August 7, 2020 10:55 AM
To: Snider, Todd
Cc: 'cfe-dev at lists.llvm.org'
Subject: [EXTERNAL] Re: [cfe-dev] RFC: refactoring libclangDriver/libclangFrontend to share with Flang

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