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. > ==== > 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? -Chris _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
