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

[Chandler Carruth]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20120506/f7474d96/attachment.html>