Remove function from source_locationt [depends-on: #4131] #3514
Conversation
tautschnig
requested review from
cesaro,
chrisr-diffblue,
cristina-david,
kroening,
martin-cs,
NathanJPhillips,
peterschrammel,
pkesseli,
smowton and
thk123
as code owners
|
Personally this seems like a step backwards -- a source location doesn't need to be a (row, col) coordinate, it seems appropriate for it to identify other source-code-level properties of a piece of |
|
We should discuss this with @kroening. Certainly it seems that at the moment there is considerable abuse of this information in the code base: anything stored in the source location should only be used for the purpose of reporting back to the user, and not affect program semantics. So maybe we keep it, but just clean up all usage. |
|
Is there scope to just modify the API (and then hence, the corresponding cleanup) so that it's API becomes 'store or output' only ? |
Sounds like a good idea to me. Yet I don't recall whether in a discussion with @kroening we had more reasons for the change, it's a while ago. So, @kroening, input much appreciated. |
tautschnig
force-pushed
the
remove-source-loc-function
branch
3 times, most recently
from
f68080d to
696f443
Compare
tautschnig
requested review from
danpoe and
hannes-steffenhagen-diffblue
as code owners
A source location is a place in a text file, and the function information stored in there need not coincide with the name we use in the goto model. Part 1: label_properties should use the actual function name so that properties in different instantiations of a function (as may happen when linking static functions) get unique names.
A source location is a place in a text file, and the function information stored in there need not coincide with the name we use in the goto model. Part 2: Wherever we generate fresh symbols or function-specific objects we should use the actual function name to ensure fewer name collisions (for fresh symbols) or actually unique objects.
…ion() Even though we use it as an index into a data structure, ambiguity is not a problem here.
This user-level heuristics is no more or less reliable than the file-name test that's also used here.
None of the existing flags (nor any combination thereof) would enable us to distinguish procedure-local type declarations from translation-unit wide ones.
tautschnig
changed the title
tautschnig
force-pushed
the
remove-source-loc-function
branch
from
696f443 to
8d162bb
Compare
|
Closing due to age (no further comment on PR content), please reopen with rebase on develop if you intent to continue this work. |
A source location is a place in a text file, it does not have syntactic
information.
This is work in progress, known to require quite a bit more work to re-introduce the information about functions where needed. The current state also includes some additional hacks to detect where problems will arise.