Restore member-of-union expressions in trace output

[tautschnig]

byte_extract operations precisely capture the semantics, but aren't
meaningful to users.

• Each commit message has a non-empty body, explaining why the change was made.
• n/a Methods or procedures I have added are documented, following the guidelines provided in CODING_STANDARD.md.
• n/a The feature or user visible behaviour I have added or modified has been documented in the User Guide in doc/cprover-manual/
• Regression or unit tests are included, or existing tests cover the modified code (in this case I have detailed which ones those are in the commit message).
• n/a My commit message includes data points confirming performance improvements (if claimed).
• My PR is restricted to a single feature or bugfix.
• n/a White-space or formatting changes outside the feature-related changed lines are in commits of their own.

[codecov]

Codecov Report

Base: 77.89% // Head: 77.89% // Increases project coverage by +0.00% 🎉

Coverage data is based on head (fafe838) compared to base (8115bb9).
Patch coverage: 82.35% of modified lines in pull request are covered.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop    #5633   +/-   ##
========================================
  Coverage    77.89%   77.89%           
========================================
  Files         1616     1616           
  Lines       186791   186834   +43     
========================================
+ Hits        145498   145538   +40     
- Misses       41293    41296    +3     

Impacted Files	Coverage Δ
.../src/java_bytecode/java_bytecode_convert_class.cpp	94.18% <ø> (ø)
...src/java_bytecode/java_bytecode_convert_method.cpp	97.69% <ø> (ø)
jbmc/src/java_bytecode/java_bytecode_language.cpp	92.81% <ø> (ø)
jbmc/src/java_bytecode/java_object_factory.cpp	94.40% <ø> (ø)
jbmc/src/java_bytecode/java_string_literals.cpp	94.54% <ø> (ø)
src/analyses/cfg_dominators.h	100.00% <ø> (ø)
...le-sensitivity/value_set_pointer_abstract_object.h	100.00% <ø> (ø)
src/ansi-c/ansi_c_convert_type.h	100.00% <ø> (ø)
src/ansi-c/ansi_c_internal_additions.cpp	90.12% <ø> (ø)
src/ansi-c/c_typecheck_base.h	100.00% <ø> (ø)
... and 43 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report at Codecov.
📢 Do you have feedback about the report comment? Let us know in this issue.

[kroening]

It seems a bit odd to do the 'restoring' in the output of a trace; wouldn't it be better to do that when that is built?

[tautschnig]

It seems a bit odd to do the 'restoring' in the output of a trace; wouldn't it be better to do that when that is built?

Indeed! I have reworked this, the patch is much smaller now.

[kroening]

The difference between original_condition and cond_expr is non-obvious, and does deserve a comment.
Do we really need both?

[tautschnig]

I was tempted to just re-purpose cond_expr, but it turns out it is actually used by goto-checker/bmc_util.cpp (I believe that is the only use). cond_expr is the SSA-renamed expression, while we'd want to provide an expression that is meaningful to the user. So maybe adding a comment is the right approach?