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

Fix many small bugs with double usage of AST nodes in different subtrees, ... #645

Merged
merged 1 commit into from
May 9, 2016

Conversation

leventov
Copy link
Contributor

@leventov leventov commented May 4, 2016

…,

a couple of bugs in CtScanner and add checker which always checks AST correctness after model build.

…ees,

a couple of bugs in CtScanner and add checker which always checks AST correctness after model build
@leventov
Copy link
Contributor Author

leventov commented May 4, 2016

BTW I had really hard time figuring out that after altering CtScanner I also should change b/src/main/java/spoon/support/visitor/replace/ReplacementVisitor.java in order to make test passing..

@@ -573,10 +574,10 @@ public void visitCtIf(final CtIf ifElement) {
public <T> void visitCtNewClass(final CtNewClass<T> newClass) {
enter(newClass);
scan(newClass.getAnnotations());
scan(newClass.getType());
Copy link
Collaborator

Choose a reason for hiding this comment

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

why this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@monperrus because ctNewClass.getType() is not a "true" property of a ctNewClass, it delegates to getExecutable().getType(). In this case scanner shouldn't visit same node twice. Also see that CtNewClass extends CtConstructorCall, which have the same logic for getType(), but doesn't have scan(getType()) in it's visit method in CtScanner.

@monperrus
Copy link
Collaborator

interesting PR

@monperrus
Copy link
Collaborator

@GerardPaligot what do you think?

@@ -139,7 +139,7 @@ public CodeFactory(Factory factory) {
fieldReference.setDeclaringType(type);

CtFieldRead<Class<T>> fieldRead = factory.Core().createFieldRead();
fieldRead.setType(classType);
fieldRead.setType(factory.Core().clone(classType));
Copy link
Contributor

Choose a reason for hiding this comment

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

Do you have an use case where the type of the field read isn't equals of the field reference?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@GerardPaligot it's not the matter of equality. Any object cannot appear in ast more than once. Otherwise very subtle bugs with element.replace() appear.

@GerardPaligot
Copy link
Contributor

PR on your PR today.

@GerardPaligot
Copy link
Contributor

My mistake, PR not necessary. I merge it.

@GerardPaligot GerardPaligot merged commit 3af47b1 into INRIA:master May 9, 2016
@tdurieux tdurieux mentioned this pull request Jun 24, 2016
@leventov leventov deleted the pr_645 branch February 17, 2018 11:04
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