On Fri, Apr 8, 2011 at 8:01 PM, Chris Lattner <[email protected]> wrote:
> On Apr 7, 2011, at 2:42 PM, nobled wrote:
>> I'm working on a patch series to extend clang to parse GLSL, and I
>> came up with these generic cleanups along the way -- the GLSL patches
>> depend on the last three, at least, going in first.
>
> This is scary to me and doesn't seem like a good thing for Clang to do, but 
> the cleanups sound fine.
>
>> ====
>> 2. refactor -ccc-gcc-name code
>>
>> Put the logic for deciding the default name for gcc/g++
>> in the only place that actually cares about it.
>>
>> This also pushes an ifdef out of the generic driver code
>> to a little further down, when the target is actually known.
>> Hopefully it can be changed into just a runtime check
>> in the future.
>
> Seems nice, go for it.
>
>> ====
>> 3. refactor flags for TokenKinds.def
>>
>> Make KEYALL a combination of all other flags instead
>> of its own separate flag. Also rewrite the enum
>> definitions in hex instead of decimal.
>
> Ok.

Thanks; committed these as r129212 and 129213.

>
>> ====
>> 4. complete TokenKinds.def documentation
>>
>> It was missing a description of BOOLSUPPORT.
>
> I just committed this before I realized that you have commit access.
>
>> ====
>> 5. generalize number parsing for directives other than #line
>>
>> This makes way for sharing code with GLSL's #version directive.
>
> I don't think that this is a cleanup.  It adds generality for something that 
> Clang doesn't need.  The GLSL grammar is only vaguely related to C, why does 
> cramming a GLSL parser into Clang make sense?

You're probably right - never mind the last patch. At this point I'm
mostly just experimenting to see if it's even feasible, which from
what you say it won't be; but it's also helping to familiarize myself
with the codebase better.

>
> -Chris
>
>
>

_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits

Reply via email to