[cfe-dev] [GSoC][clang] Bash completion for clang project

[Vassil Vassilev via cfe-dev]

On 07/06/17 19:21, Rui Ueyama wrote:
> On Wed, Jun 7, 2017 at 5:02 AM, Vassil Vassilev 
> <v.g.vassilev at gmail.com <mailto:v.g.vassilev at gmail.com>> wrote:
>
>     On 05/06/17 17:41, Rui Ueyama via cfe-dev wrote:
>>     On Thu, Jun 1, 2017 at 2:02 PM, Richard Smith via cfe-dev
>>     <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>         On 31 May 2017 at 06:21, Yuka Takahashi via cfe-dev
>>         <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>             Hello,
>>
>>             My name is Yuka Takahshi and I would like to ask few
>>             questions regarding to GSoC project : bash-autocompletion
>>             for clang.
>>             We are now trying to build flag completions for which we
>>             call "value".
>>             Eg. in -std=c++11, c++11 is a "value", and in
>>             -analyzer-checker=alpha.cplusplus, alpha.cplusplus is a
>>             "value".
>>
>>             We are planning to implement most of the code in
>>             OptTable.cpp, in order to reuse OptTable, which is
>>             generated by Options.inc.
>>             Options.inc is generated via Tablegen from Options.td, so
>>             we are planning to add the information of values into
>>             Options.td.
>>
>>             I would like to ask for a advice regarding how to
>>             implement the flag like "-std=" and "-analyzer-checker=".
>>             These flags are unique because their value information
>>             are already in LangStandards.def for "-std=", and
>>             Checkers.td for "-analyzer-checker=".
>>             We are thinking to reuse these information and add these
>>             information to Options.inc, so that we can handle the
>>             flag completion in unified manner.
>>             This way of implementation has further benefits from this
>>             GSoC project, because from this we can make documentation
>>             more simply and reduce custom handling of each value and
>>             code duplication.
>>
>>             The problem is that, we are not sure what is the best way
>>             for this implementaion.
>>             For flags which are not like "-std=" and
>>             "-analyzer-checker=", we decided to add a class to hold
>>             the value information in Options.td. Eg. for "-stdlib=",
>>             ArgValues<"libc++, libstdc++, platform">.
>>             So we are looking for how to generate something like
>>             "libc++, libstdc++, platform" from LangStandards.def and
>>             Checkers.td for "-std=" and "-analyzer-checker=".
>>
>>
>>         One way to do this would be to rewrite LangStandards.def as a
>>         .td file, and extend clang-tblgen to generate something like
>>         the current .def file from that .td file. Then you can
>>         include LangStandards.td into Options.td and somehow specify
>>         that all of the LangStandard records define possible values
>>         for the -std= flag. (You could use something like
>>         ArgValueClass<"LangStandard"> for this case,
>>         ArgValueClass<"Checker"> for -analyzer-checker=, and so on.
>>         Your tablegen backend is able to do arbitrary queries over
>>         the tablegen records, so there are a variety of ways to
>>         express this.)
>>
>>         Similar things can be done for other options that take values
>>         from .def files, such as -fsanitize= (Basic/Sanitizers.def).
>>
>>
>>     I don't know if rewriting LangStandards.def just for shell
>>     autocompletion is worth the effort, unless there's other reason
>>     to do that. It seems you can define LANGSTANDARD macro before
>>     including this file to get a list of all possible language
>>     options. You can use that information to return all possible
>>     options when `-std=<tab>` is hit, can't you?
>     The advantage outside of autocompletion would be that we can
>     reduce the amount of StringSwitch cases handling the argument
>     values in the driver and centralize it in a common place. This
>     would give us the opportunity to diagnose enhance `error: invalid
>     value "c+-11" for flag "-std="` with `Did you mean one of c++11,
>     c++14, c++17` and alike.
>
>
> Ah, that sounds nice. One concern I had is that, if we enumerate all 
> possible values for each option in .td files, we have to modify both a 
> C++ file and a .td file when we add a new option value for an exiting 
> flag, but that's probably not that bad.
Yes, indeed. I see this also as documentation for options goes in the 
.td files and the implementation in the driver...
>
>
>>         _______________________________________________
>>         cfe-dev mailing list
>>         cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>         http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>         <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>>
>>
>>
>>
>>     _______________________________________________
>>     cfe-dev mailing list
>>     cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>>     http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>     <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170607/c1333323/attachment.html>