Move generic information from decorated pointers to decorated tags #4114
Conversation
smowton
requested review from
cesaro,
cristina-david,
NathanJPhillips,
peterschrammel and
pkesseli
as code owners
|
I've prototyped this with test-gen btw and seems all tests pass with no changes to its code |
smowton
force-pushed
the
smowton/cleanup/generics-on-tags
branch
from
6724054 to
4195069
Compare
There was a problem hiding this comment.
✔️
Passed Diffblue compatibility checks (cbmc commit: 4195069).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/100136027
smowton
force-pushed
the
smowton/cleanup/generics-on-tags
branch
from
4195069 to
dd3afa1
Compare
There was a problem hiding this comment.
✔️
Passed Diffblue compatibility checks (cbmc commit: dd3afa1).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/100212017
src/util/irep_ids.def
Outdated
| IREP_ID_TWO(C_java_generics_class_type, #java_generics_class_type) | ||
| IREP_ID_TWO(C_java_implicitly_generic_class_type, #java_implicitly_generic_class_type) | ||
| IREP_ID_TWO(C_java_generic_symbol, #java_generic_symbol) | ||
| IREP_ID_TWO(generic_types, #generic_types) | ||
| IREP_ID_TWO(generic_types, generic_types) |
There was a problem hiding this comment.
Can this be IREP_ID_ONE now?
|
@kroening can I take your thumbs-up for an approval? |
|
@smowton clang-format seems unhappy. |
This means that a pointer is once again just a pointer, and can be removed and reapplied without risking losing information. On the other hand tags now carry decorations more often (they already played this role when expressing a superclass, which is implemented as a nested struct), so `ns.follow` returns a type missing its decorations -- however this is hopefully a small risk, as code using the decorated-pointer implementation would already need to know that following the pointer, never mind the tag at the end of it, could lose information.
smowton
force-pushed
the
smowton/cleanup/generics-on-tags
branch
from
f0bc22f to
6887863
Compare
|
It appears clang-format was flagging stuff that had nothing to do with this PR? I've rebased to see if that fixes things, will merge if/when CI passes. |
I've seen that quite a lot already, but admittedly never investigated properly. It does seem to happen when there are a lot of PRs in flight. |
There was a problem hiding this comment.
✔️
Passed Diffblue compatibility checks (cbmc commit: 6887863).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/100429555
java_generic_parametertis reimplemented as a plain pointer to a decoratedstruct_tag_typet(currently always ajava.lang.Object, but that will change when we support bounded generics).java_generic_typetis reimplemented as a plain pointer to the existing typejava_generic_struct_tag_typet, which already expressed nested superclasses and now also specifies references.The existing types (subclasses of
java_reference_typet) are retained, but do not store any data themselves and simply forward their accessors to the underlying tag, meaning no changes are needed to existing code.This means that a pointer is once again just a pointer, and can be removed and reapplied
without risking losing information. On the other hand tags now carry decorations more often
(they already played this role when expressing a superclass, which is implemented as a nested
struct), so
ns.followreturns a type missing its decorations -- however this is hopefullya small risk, as code using the decorated-pointer implementation would already need to know
that following the pointer, never mind the tag at the end of it, could lose information.