This change depends on the ApplePropertyString helper that I sent spearately.
Not sure how you want this tested: as a tool test by adding a binary to dump, or as an llvm test starting from an IR file?
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Looks reasonable (apart from testing) - depends how you want to do it. I assume there are some existing tests that test properties that could be updated to use this feature? (does this not regress any existing tests?)
If there aren't any such tests, I imagine we want some - and they could just test this incidentally.
(I'm usually on the fence about writing tool tests separately from unit tests... *shrug* sometimes it's nice, sometimes it seems like overkill)
There aren't any. I discovered the discrepancy between the enum values yesterday by trying to produce some tests and the results didn't actually make sense. I can add an llvm test, sure, but my ObjC foo being what it is, I fear that the code won't make any sense :-) Thus it won't test much except the actual dumping.
Probably sensible enough then to just make it a dumping test - I think
that's generally 'better'/purist when adding dumper features, I just
understand it's sometimes a bit more fuss. So I'll never complain about you
doing it that way (checking a small sample source, a binary, etc - you can
see the other pure dwarfdump tests).
& since you guys are planning to make this more of a production tool, I
think it's a good idea to have more tests for dwarfdump itself - so that we
don't accidentally make holes in the dwarfdump test coverage when we
refactor tests.
Yep, looks good once we test this.
lib/DebugInfo/DWARFDebugInfoEntry.cpp | ||
---|---|---|
87 ↗ | (On Diff #14616) | This would output an extra trailing comma |
lib/DebugInfo/DWARFDebugInfoEntry.cpp | ||
---|---|---|
87 ↗ | (On Diff #14616) | Nope because the condition just above exits if we've handled the last bit. (The actual loop exit test is in the middle of the loop. I find this idiom less clumsy than having a bool lying around telling if you are in the first iteration or not, but I can understand opinions might differ on this point). |
lib/DebugInfo/DWARFDebugInfoEntry.cpp | ||
---|---|---|
87 ↗ | (On Diff #14616) | Oh, sorry, I missed that =/ The code is fine as is, I have no strong preference. |
test/DebugInfo/dwarfdump-objc.test | ||
---|---|---|
21 ↗ | (On Diff #14680) | (0x0c ( DW_APPLE_PROPERTY_foo, bar ) ) seems inconsistent use of space - there's no leading space before the 0x0c, but there's a leading space before DW (& then trailing spaces for both ')'. I'd probably be in favor of no leading or trailing spaces, but I'm not sure what this looks like compared to various other parts of the dump output. |
test/DebugInfo/dwarfdump-objc.test | ||
---|---|---|
21 ↗ | (On Diff #14680) | Agreed, it doesn't look nice. I just copied the formatting from the native dwarfdump, but I like it better with leading and trailing spaces (there isn't any prior example of that kind of dump input I think, so just pick what seems nicer). I'll resubmit shortly. |
Looks good to me - please submit.
(it seems most of our existing formatting doesn't put extra spaces - though we're not entirely consistent (strp has a leading space, exprloc (& maybe other FORM_data) has a trailing space (probably just because someone didn't handle the end case), etc)