-
Notifications
You must be signed in to change notification settings - Fork 274
Parse bridge flag [TG-4115] #2527
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
TG PR: diffblue/test-gen#2034 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Passed Diffblue compatibility checks (cbmc commit: 10ac97e).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/78217964
#ifdef _MSC_VER | ||
#define UNUSED | ||
#else | ||
#define UNUSED __attribute__((unused)) | ||
#endif | ||
|
||
/// Represents the bit flag from class access and property flags | ||
/// https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-4.html#jvms-4.1-200-E.1 | ||
namespace class_access_flagst |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Using enum class
should remove this weird namespace.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately using enum class
means it cannot be implicitly converted to int
(to be used in the logical and later). I could replace the word namespace
with class
, but that feels weirder. @thomasspriggs suggested writing a method called read_flag
, but as they would all be unique types I'd either have to write one per type, or template it and lose type safety (not too bad, but I prefer this option) - let me know what you'd prefer me to do.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How about doing away with the defines / enums and using this approach instead?
struct flagst {
bool is_public : 1;
bool is_private : 1;
bool is_protected : 1;
bool is_static : 1;
bool is_final : 1;
void : 4;
bool is_interface : 1;
bool is_abstract : 1;
void : 1;
bool is_synthetic : 1;
bool is_annotation : 1;
bool is_enum : 1;
void : 1;
} flags = *reinterpret_cast<flagst*>(&access_flags);
parsed_class.is_abstract = flags.is_abstract;
parsed_class.is_enum = flags.is_enum;
parsed_class.is_final = flags.is_final;
parsed_class.is_interface = flags.is_interface;
parsed_class.is_synthetic = flags.is_synthetic;
parsed_class.is_annotation = flags.is_annotation;
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterschrammel I really like Tom's suggestion above, if you'd like it I'll go ahead and change it for that with some unit tests to check we get each method correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@peterschrammel Going to pull this refactor out into a different PR to unblock this - but could you express an opinion on whether you like Toms suggested approach (I think I'd probably put the struct directly into parse_treet::classt
to avoid the is_abstract=is_abstract
duplication.
This is used for compiler generated methods to deal with type erasure.
10ac97e
to
ac9bc2d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This PR failed Diffblue compatibility checks (cbmc commit: ac9bc2d).
Build URL: https://travis-ci.com/diffblue/test-gen/builds/78728751
Status will be re-evaluated on next push.
Please contact @peterschrammel, @thk123, or @allredj for support.
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).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@thomasspriggs, needs a rebase. |
Replaced by #2582. |
Based on #2526 ✅
tidy up removed to separate PR
First some tidy up - there are four different tables in the java bytecode spec that have different values but were all using the same macros in the parser. This is confusing (and led to some nonsense lines, readingACC_PROTECTED
on a class for example, which isn't legal. Instead pulled each table into an enum, linking to the docs. To allow bitwise & and name scoping, namespaces were required.Then the actual work - parse the ACC_BRIDGE which is a flag for methods that the compiler generates to deal with type erasure.
I didn't add a method to
code_typet
as this is very Java specific. Is it worth introducing ajava_code_typet
for java method types?