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

[Vassil Vassilev via cfe-dev]

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.
>
>     _______________________________________________
>     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
> 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/d33f3ee1/attachment.html>