<div dir="ltr">On Fri, Sep 27, 2013 at 1:19 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><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 class="im">>> * Add both to Options.td:<br>
>><br>
>> def fshow_column : Flag<["-"], "fshow-column">, Group<f_Group>,<br>
>> Flags<[CC1Option]>;<br>
>> def fno_show_column : Flag<["-"], "fno-show-column">, Group<f_Group>,<br>
>> Flags<[CC1Option]>,<br>
>>   HelpText<"Do not include column number on diagnostics">;<br>
>><br>
>> * Add it to some .def file.<br>
>><br>
>> DIAGOPT(ShowColumn, 1, 1)       /// Show column number on diagnostics.<br>
><br>
><br>
> I don't think this part of it is really an issue... this plus the bit of<br>
> code in lib/Frontend is sort of boilerplate, but I don't think it's worth<br>
> increasing the scope of the patch to cover it.  I would lean towards keeping<br>
> the options in the driver.<br>
<br>
</div>I agree that .td is currently the weakest link and I would try to fix<br>
that first. My inclination was to pass all -f options to -cc1 since it<br>
will have to parse them anyway, but I could also check them in the<br>
driver just to make sure all options are valid and not even run -cc1<br>
if they are not.<br>
<br>
What advantage do you see in parsing the -f options in the driver?<br>
<br><br></blockquote><div>Oh, you mean as opposed to -cc1?  Err, ignore that bit. :)<br><br></div><div>-Eli <br></div></div></div></div>