Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
Looks good.
lib/ubsan/ubsan_flags.inc | ||
---|---|---|
26 ↗ | (On Diff #32753) | Do we care that much about keeping the "always say 'undefined-behavior'" behavior around? |
lib/ubsan/ubsan_flags.inc | ||
---|---|---|
26 ↗ | (On Diff #32753) | Yes, there are users who grep for "SUMMARY: .* undefined-behavior" lines in their logs. We should stay backwards-compatible for a while. |
lib/ubsan/ubsan_handlers.cc | ||
---|---|---|
57–58 ↗ | (On Diff #32753) | Can we pass the error type to Diag in the place of DL_Error instead of specifying it separately? |
lib/ubsan/ubsan_handlers.cc | ||
---|---|---|
57–58 ↗ | (On Diff #32753) | We still need error type somewhere outside Diag, because it will be used later when we print (or not print) summary, after several Diag invocations (for DL_Error and DL_Note). |
lib/ubsan/ubsan_handlers.cc | ||
---|---|---|
57–58 ↗ | (On Diff #32753) | We would make exactly one invocation to Diag with an error type, wouldn't we? Is the summary information computed separately from diagnostic emission? |
lib/ubsan/ubsan_handlers.cc | ||
---|---|---|
57–58 ↗ | (On Diff #32753) | The answer to last question is "yes". Diag object prints the diagnostic message in destructor (and there can be several Diag objects). We need to print summary information after all the diagnostics (DL_Error and DL_Note), so we do this in ScopedReport destructor. There is a different benefit in passing error kind to Diag() object - we can print the actual error kind instead of generic runtime error: line, but that's a different problem, which can probably be addressed afterwards. |