-
Notifications
You must be signed in to change notification settings - Fork 194
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
Visibility errors when recompiling: "cannot override ... attempting to assign weaker access privileges; was public" #175
Comments
I was just trying to recreate a minimal test case here in IntelliJ using Geb. I saw the error twice while applying little changes to my code hierarchy, but have not managed to come up with a clear, repeatable list of instructions to reproduce it. I guess it had to do with a base class method If that gives you any clue as to what could be the reason and how I could go about reproducing it in a repeatable way, I would be grateful. |
The base type that contains the setup method, it it an interface, a trait or anything like that? Does it have AST transforms applied? Does your extending class have transforms? |
Aha, yes. Spock adds JUnit 4 @before to all the setup() methods. Not sure what else it might do. I'll try recreating in a Spock context and see what I can see. |
Error is logged from private void checkMethodForWeakerAccessPrivileges(MethodNode mn, ClassNode cn) {
if (mn.isPublic()) return;
Parameter[] params = mn.getParameters();
for (MethodNode superMethod : cn.getSuperClass().getMethods(mn.getName())) {
Parameter[] superParams = superMethod.getParameters();
if (!hasEqualParameterTypes(params, superParams)) continue;
if ((mn.isPrivate() && !superMethod.isPrivate()) ||
(mn.isProtected() && superMethod.isPublic())) {
addWeakerAccessError(cn, mn, params, superMethod);
return;
}
}
} |
|
If you mark |
Thanks for digging into this again, @eric-milles. I cannot test it at the moment, being on the road with only a tablet computer. Are you suggesting a ticket should be created for Spock in order to resolve this, or is is rather a Groovy-Eclipse issue? |
Definitely a groovy-elcipse issue. Active compilation unit has transforms applied, but parent source units do not. This causes this issue, and one I ran into with trait extending trait, and likely others.
|
Ping |
I haven't forgotten this. It has been assigned to the 3.0.0 milestone. And I have run some experiments for possible solutions. I don't yet have a complete solution. If you'd like to try what I have, you can follow the early-xforms branch. I may need to push some stuff to it that I have locally if you are really interested. |
I don't wanna push you too hard. That it is WIP and not forgotten is good enough for me. |
- disable redundant JDT error #175
I got this same error and we have a setup that looks like this:
When I moved the |
Lately I am seeing compile errors with my Spock/Geb classes when overriding methods like
setup()
orcleanup()
across three levels of class hierarchy:The errors only occur when doing an incremental recompile, full rebuild works. They go away when I manually recompile the base class.
All methods were defined like this without calling their parent methods because Spock calls each setup method in a defined order anyway:
Environment:
@aclement: This seems to be similar to grails/grails-core#619, an issue you already know.
The text was updated successfully, but these errors were encountered: