Skip to content

Remove wrong assumption on opaque methods #2857

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

Merged
merged 1 commit into from
Aug 30, 2018

Conversation

allredj
Copy link
Contributor

@allredj allredj commented Aug 29, 2018

When converting a method call, set the access identifier to ID_private instead of ID_public.
The latter lead to directly accessing protected methods from generated tests that do not inherit from the class where that method is defined.
Assuming that the method is not accessible is the only safe guess at this point.
To avoid over-using PowerMock, the strategies that discard the classes (such as --load-containing-class-only) need to be altered/amended so that we keep that information.

This PR has no tests as changes are only visible in test-gen.

Copy link
Contributor

@thk123 thk123 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This of course needs a TG bump

@@ -2213,7 +2208,7 @@ void java_bytecode_convert_methodt::convert_invoke(
symbol.pretty_name = id2string(arg0.get(ID_C_class)).substr(6) + "." +
id2string(symbol.base_name) + "()";
symbol.type = arg0.type();
symbol.type.set(ID_access, ID_public);
symbol.type.set(ID_access, ID_private);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on the above argument - can we assume it is in fact protected?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not guaranteed. It can well be private. The previous assumption (ID_public) was based on the fact that we wouldn't call these functions in generated tests. But I don't think we can completely exclude finding calls to private methods in generated tests, e.g. when mocking private methods (if we do partial mocking in the future), so we need to know consider that the method can be private. Anyway it's too early to make assumptions on how we'll be calling these methods, so we need to stay accurate.
Should I make the comment clearer?

@allredj
Copy link
Contributor Author

allredj commented Aug 29, 2018

@allredj allredj force-pushed the fix-opaque-accessibility branch from 584344f to 3caa28b Compare August 30, 2018 08:44
When converting a method call, set the access identifier to
`ID_private` instead of `ID_public`.
The latter lead to directly accessing protected methods from generated
tests that do not inherit from the class where that method is defined.
@allredj allredj force-pushed the fix-opaque-accessibility branch from 3caa28b to 1d8c735 Compare August 30, 2018 13:57
@allredj allredj merged commit 141503e into diffblue:develop Aug 30, 2018
@allredj allredj deleted the fix-opaque-accessibility branch August 30, 2018 15:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants