Skip to content
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

review: fix PotentialVariableDeclarationFunction ignoring the static scope #1536

Merged
merged 5 commits into from
Sep 25, 2017

Conversation

pvojtechovsky
Copy link
Collaborator

As reported in #1513 the PotentialVariableDeclarationFunction returns non static field test as potential variable declaration of local variable reference declared in static method.

int test = 0;  //this one should not be returned, because it is not static
public static void main(String[] args)
{
	int test = 1; 
	assertEqualst(1, test); //reference to local test variable
}

@pvojtechovsky pvojtechovsky force-pushed the fixPotVariableAccessScope branch 2 times, most recently from 74b7293 to 794ae41 Compare September 23, 2017 21:35
@pvojtechovsky
Copy link
Collaborator Author

pvojtechovsky commented Sep 23, 2017

This PR is now based on #1541 because it was needed to debug problem of MainTest

The implementation of this PR fixes two more problems

  1. this implementation contains first lambda expression in Spoon java sources ... and that lambda expression code was not accepted by MainTest#testMain. See my change here @monperrus please check this test fix.

  2. The MavenLauncherTest#spoonMavenLauncherTest is quite fragile - we are probably going to change these number quite often. Should we change it?

This PR is finished from my point of view too.

@pvojtechovsky pvojtechovsky changed the title WiP: fix PotentialVariableDeclarationFunction ignoring the static scope review: fix PotentialVariableDeclarationFunction ignoring the static scope Sep 23, 2017
@@ -19,7 +19,7 @@ public void spoonMavenLauncherTest() {
// with the tests
launcher = new MavenLauncher("./", MavenLauncher.SOURCE_TYPE.ALL_SOURCE);
// 235 because of the sub folders of src/main/java and src/test/java
assertEquals(235, launcher.getModelBuilder().getInputSources().size());
assertEquals(236, launcher.getModelBuilder().getInputSources().size());
Copy link
Collaborator

Choose a reason for hiding this comment

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

Maybe we can remove this assertion because it will be horrible to maintain.

@@ -883,16 +884,16 @@ public void testClassCastExceptionOnForEach() throws Exception {
{
Context context = new Context();
//contract: if the query produces elements which cannot be cast to forEach consumer, then they are ignored
launcher.getFactory().Package().getRootPackage().filterChildren(f->{return true;}).forEach((CtType t)->{
launcher.getFactory().Package().getRootPackage().filterChildren(null).forEach((CtType t)->{
Copy link
Collaborator

Choose a reason for hiding this comment

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

why do you need to change this contract?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

it is not change. It is just shorter way how write the same: "no filter = return all children"

try {
launcher.getFactory().Package().getRootPackage().filterChildren(f->{return true;}).forEach((CtType t)->{
launcher.getFactory().Package().getRootPackage().filterChildren(null).forEach((CtType t)->{
Copy link
Collaborator

Choose a reason for hiding this comment

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

same question

@@ -177,6 +178,9 @@ public void scan(CtElement element) {
if (reference.getParameters().get(i) instanceof CtArrayTypeReference && ((CtArrayTypeReference) reference.getParameters().get(i)).getComponentType() instanceof CtTypeParameterReference) {
continue;
}
if (executableDeclaration instanceof CtLambda) {
Copy link
Collaborator

Choose a reason for hiding this comment

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

could you add a comment line to explain why we can not make the assertion for Lambdas?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I do not know whether we cannot make assertions about lambdas. Lambdas are too different (comparing to method) and they are not supported yet by this test. So may be there is necessary to write lambda specific assertion. But I did not understood the purpose of this test, so I would rather let You to fix it.

@monperrus
Copy link
Collaborator

looks good, commented with minor questions.

@monperrus
Copy link
Collaborator

monperrus commented Sep 24, 2017 via email

@pvojtechovsky
Copy link
Collaborator Author

I have removed commits which belongs to #1541, so this PR is simpler now. The minor problems were fixed. So it can be merged

@monperrus monperrus merged commit ef93941 into INRIA:master Sep 25, 2017
@pvojtechovsky pvojtechovsky deleted the fixPotVariableAccessScope branch September 27, 2017 19:18
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.

3 participants