[cfe-dev] [PATCH] Fix clang test failures on MIPS

[Manuel Klimek]

On Mon, May 7, 2012 at 8:41 AM, Chandler Carruth <chandlerc at google.com> wrote:
> On Sun, May 6, 2012 at 10:12 PM, Manuel Klimek <klimek at google.com> wrote:
>>
>> On Sat, May 5, 2012 at 12:24 PM, Matthieu Monrocq
>> <matthieu.monrocq at gmail.com> wrote:
>> > On Fri, May 4, 2012 at 10:30 PM, Manuel Klimek <klimek at google.com>
>> > wrote:
>> >>
>> >> On Fri, May 4, 2012 at 9:56 PM, Simon Atanasyan <satanasyan at mips.com>
>> >> wrote:
>> >> > On Fri, May 4, 2012 at 7:39 PM, Manuel Klimek <klimek at google.com>
>> >> > wrote:
>> >> >> I haven't put too much thought into the interface yet, but I'd
>> >> >> imagine
>> >> >> something along the lines of
>> >> >> class ArgumentAdjuster {
>> >> >> public:
>> >> >>  vector<std::string> Adjust(const vector<std::string> &Arguments) =
>> >> >> 0;
>> >> >> };
>> >> >>
>> >> >> class ClangSyntaxOnlyAdjuster : public ArgumentAdjuster { ... };
>> >> >>
>> >> >> Then, for people who have command lines that are for gcc for some
>> >> >> reasons:
>> >> >> class GccToClangAdjuster : public ArgumentAdjuster { ... };
>> >> >>
>> >> >> Then we can install a ClangSyntaxOnlyAdjuster per default and add a
>> >> >> method to ClangTool:
>> >> >> void setArgumentAdjuster(ArgumentAdjuster *Adjuster);
>> >> >>
>> >> >> I think the argument adjusting is orthogonal to the tool, so I'd
>> >> >> rather avoid inheritance on the ClangTool level.
>> >> >
>> >> > Now I see your point and like this approach. I will implement and
>> >> > send
>> >> > a patch for review.
>> >>
>> >> Thx! Looking forward to it :)
>> >>
>> >
>> > It always bothered me a bit, so since this is going to be adjusted...
>> >
>> > Is there a fundamental reason to reason in terms of `string` here ?
>> >
>> > Or more accurately, I understand that parsing the command line requires
>> > strings in input, but why should it produce strings in output, instead
>> > of a
>> > more canonical form ?
>>
>> Do you have a proposal what you mean with a 'more canonical form' here?
>
>
> Some of the refactoring that James and I have been talking about to the
> driver would directly enabled this -- specifically modeling everything as
> serialization and deserialization of options using the table-generated
> parsers.
>
> Given such a model, you could use the driver to load the arguments,
> manipulate them, and even if you needed to write them back out in textual
> form, do so.
>
> Any baby steps we can take in that direction seem good.

So we could of course do:
typedef std::vector<std::string> CommandLineArguments;
in order to remember that we want something typed there... but I'm not
sure how much that helps for now.

Cheers,
/Manuel