<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 07/06/17 19:21, Rui Ueyama wrote:<br>
</div>
<blockquote
cite="mid:CAJENXgt4p-0sE6c=b4ux81LVS0sVmmn7RVME0fABukNkiwDMKw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>On Wed, Jun 7, 2017 at 5:02 AM, Vassil Vassilev <span
dir="ltr"><<a moz-do-not-send="true"
href="mailto:v.g.vassilev@gmail.com" target="_blank">v.g.vassilev@gmail.com</a>></span>
wrote:<br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div class="m_-125612743467795374moz-cite-prefix">On
05/06/17 17:41, Rui Ueyama via cfe-dev wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>On Thu, Jun 1, 2017 at 2:02 PM, Richard Smith
via cfe-dev <span dir="ltr"><<a
moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a>></span>
wrote:<br>
</div>
<div class="gmail_extra">
<div class="gmail_quote">
<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
moz-do-not-send="true"
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>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>
</span> 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.</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
</div>
</div>
</div>
</blockquote>
Yes, indeed. I see this also as documentation for options goes in
the .td files and the implementation in the driver...<br>
<blockquote
cite="mid:CAJENXgt4p-0sE6c=b4ux81LVS0sVmmn7RVME0fABukNkiwDMKw@mail.gmail.com"
type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div> </div>
<blockquote class="gmail_quote"
style="margin:0 0 0 .8ex;border-left:1px
#ccc solid;padding-left:1ex">______________________________<wbr>_________________<br>
cfe-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:cfe-dev@lists.llvm.org"
target="_blank">cfe-dev@lists.llvm.org</a><br>
<a moz-do-not-send="true"
href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev"
rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
<br>
</blockquote>
</div>
<br>
</div>
</div>
<br>
<fieldset
class="m_-125612743467795374mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
cfe-dev mailing list
<a moz-do-not-send="true" class="m_-125612743467795374moz-txt-link-abbreviated" href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>
<a moz-do-not-send="true" class="m_-125612743467795374moz-txt-link-freetext" href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a>
</pre>
</blockquote>
<p>
</p>
</span></div>
</blockquote></div>
</div></div>
</blockquote><p>
</p></body></html>