Details
Diff Detail
Event Timeline
Looks good. AFAICT we're now only missing PUSHBOX and CONTROL. If these don't present any additional difficulty, maybe better to just add them now for the sake of completeness?
tools/llvm-rc/ResourceScriptParser.cpp | ||
---|---|---|
495 | This is OK for now, but in the future I think you'll need special code for style and exstyle because those are really expressions that don't work exactly like regular C-style bitwise operations. So I'm not sure how much readIntsWithCommas is buying versus reading the arguments into well-named variables like X, Y, Width, Height, etc., which would then make reading the Control c'tor calls a lot easier and would highlight the difference between the CONTROL syntax versus the syntax for the pre-defined control types. About a third of this function is special case handling for CONTROL when the only differences are two little tweaks to the syntax (position of style and the explicit class parameter). It feels like a lot of near-duplicate code (e.g., the TakeOptArg lambda has to be defined twice) to handle the tweaks. |
tools/llvm-rc/ResourceScriptStmt.cpp | ||
---|---|---|
146 | For CONTROL, where does the 0x2A come from? I know 0x5000000 is WS_CHILD | WS_VISIBLE. It would be nice to see the styles represented in a way that makes it easier to check the table. |
tools/llvm-rc/ResourceScriptStmt.cpp | ||
---|---|---|
146 | Oh, that 0x2A must be from the test file itself. Will fix. |
tools/llvm-rc/ResourceScriptParser.cpp | ||
---|---|---|
495 | I rewrote this, making it just one main function with minor exceptions for CONTROL vs others, making the similarities more visible, hopefully like you wanted. | |
tools/llvm-rc/ResourceScriptStmt.cpp | ||
146 | I'll leave splitting up the style hardcoded values into symbolic values to a separate patch, since it's already that way. |
Unified handling of CONTROL vs other controls, removed stray extra values in the CONTROL style base value.
This is OK for now, but in the future I think you'll need special code for style and exstyle because those are really expressions that don't work exactly like regular C-style bitwise operations.
So I'm not sure how much readIntsWithCommas is buying versus reading the arguments into well-named variables like X, Y, Width, Height, etc., which would then make reading the Control c'tor calls a lot easier and would highlight the difference between the CONTROL syntax versus the syntax for the pre-defined control types.
About a third of this function is special case handling for CONTROL when the only differences are two little tweaks to the syntax (position of style and the explicit class parameter). It feels like a lot of near-duplicate code (e.g., the TakeOptArg lambda has to be defined twice) to handle the tweaks.