<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 5 June 2017 at 17:01, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 6, 2017 at 8:37 AM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On 5 June 2017 at 08:41, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="m_-658589950571481927m_-5259567879185284594h5"><div>On Thu, Jun 1, 2017 at 2:02 PM, Richard Smith via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br></div></div></div><div class="gmail_extra"><div class="gmail_quote"><div><div class="m_-658589950571481927m_-5259567879185284594h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On 31 May 2017 at 06:21, Yuka Takahashi via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,</div><div><br></div><div>My name is Yuka Takahshi and I would like to ask few questions regarding to GSoC project : bash-autocompletion for clang.</div><div>We are now trying to build flag completions for which we call "value".</div><div>Eg. in -std=c++11, c++11 is a "value", and in -analyzer-checker=alpha.cplusp<wbr>lus, alpha.cplusplus is a "value".</div><div><br></div><div>We are planning to implement most of the code in OptTable.cpp, in order to reuse OptTable, which is generated by Options.inc.</div><div>Options.inc is generated via Tablegen from Options.td, so we are planning to add the information of values into Options.td.</div><div><br></div><div>I would like to ask for a advice regarding how to implement the flag like "-std=" and "-analyzer-checker=".</div><div>These flags are unique because their value information are already in LangStandards.def for "-std=", and Checkers.td for "-analyzer-checker=".</div><div>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.</div><div>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.</div><div><br></div><div>The problem is that, we are not sure what is the best way for this implementaion.</div><div>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">.</div><div>So we are looking for how to generate something like "libc++, libstdc++, platform" from LangStandards.def and Checkers.td for "-std=" and "-analyzer-checker=".</div></div></blockquote><div><br></div></span><div>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.)</div><div><br></div><div>Similar things can be done for other options that take values from .def files, such as -fsanitize= (Basic/Sanitizers.def).</div></div></div></div></blockquote><div><br></div></div></div><div>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?</div></div></div></div></blockquote><div><br></div></span><div>You can, but we don't run the C preprocessor on tablegen files, which means you couldn't generate this data from tablegen without some auxiliary work. We also want the "valid values" data for generated help text and command-line argument summary documentation; it's not only desired for tab completion. </div></div></div></div>
</blockquote></div><br></div></div></div><div class="gmail_extra">Are you saying that you want to have the "valid values" data not only for "-std=" and a few other options but for all options such as -flto={thin,full} or -fopenmp={libomp,libgomp,<wbr>libiomp}?</div></div>
</blockquote></div><br></div><div class="gmail_extra">Ideally, yes, we'd have the "valid values" data for all options that have a (small) enumerated set of options, for tab-completion, referemce documentation, and any other similar use cases that people might have (UI for configuring compiler flags?).</div></div>