goto_check_c: observe check pragmas annotated to individual expressions

[tautschnig]

This is required to make the conversion of __builtin_X_overflow not generate spurious conversion checks.

Please review commit-by-commit.

Fixes: #6452

• 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

Merging #6616 (25d3a9c) into develop (afc53d8) will increase coverage by 0.00%.
The diff coverage is 100.00%.

@@           Coverage Diff            @@
##           develop    #6616   +/-   ##
========================================
  Coverage    76.73%   76.73%           
========================================
  Files         1579     1579           
  Lines       181999   182016   +17     
========================================
+ Hits        139652   139671   +19     
+ Misses       42347    42345    -2     

Impacted Files	Coverage Δ
src/analyses/goto_check_c.cpp	90.92% <100.00%> (+0.11%)	⬆️
src/ansi-c/ansi_c_parser.cpp	90.26% <100.00%> (+1.87%)	⬆️
src/goto-programs/goto_convert_side_effect.cpp	95.66% <100.00%> (+0.03%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3f175c9...25d3a9c. Read the comment docs.

[chris-ryder]

Looks sensible to me.

[jimgrundy]

Where are we on this one?
It seems like there is a fairly straightforward work-around to not having this, which is to have a statement assigning the sub-expression to a temporary variable and wrapping that statement in a pragma. Am I wrong about that?
Is this easy and non-disruptive to CBMC? If so, can we check it in? If not, is it worth doing if there is a simple work around?