Store "is hidden" attribute of goto functions in the symbol table [blocks: #4167]

[tautschnig]

There should only be a single place to hold type information, including
attributes, to ensure consistency. Future changes will remove the "type" member
of goto_functiont, making the type information stored in the symbol table the
single, authoritative source of information.

With this commit the information will remain available in both places, but all
read accesses only use the information in the symbol table.

This is a further, meant-to-be-non-breaking step towards removing goto_functiont::type, which #4167 tries to achieve.

• Each commit message has a non-empty body, explaining why the change was made.
• 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.

[allredj]

✔️
Passed Diffblue compatibility checks (cbmc commit: a9cd423).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/102911510

[smowton]

Though I note this is yet another candidate for symbolt having an attributes member for function attributes that aren't really part of its type signature.

[tautschnig]

Though I note this is yet another candidate for symbolt having an attributes member for function attributes that aren't really part of its type signature.

I guess we already have a ton of attributes in symbolt? I do know you suggested that rather than adding more binary flags we should have some data structure. I'm wondering whether, on this occasion, we should just use the existing is_auxiliary flag. We really have a very limited number of users of all this information here, and it's just advisory.

[tautschnig]

I'm wondering whether, on this occasion, we should just use the existing is_auxiliary flag. We really have a very limited number of users of all this information here, and it's just advisory.

I just did this. The is_hidden/set_hidden are now API functions of symbolt rather than code_typet.

[allredj]

⚠️
This PR failed Diffblue compatibility checks (cbmc commit: ebfab8d).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/103025037
Status will be re-evaluated on next push.
Common spurious failures:

• the cbmc commit has disappeared in the mean time (e.g. in a force-push)

• the author is not in the list of contributors (e.g. first-time contributors).

• the compatibility was already broken by an earlier merge.