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

WiP feat: computeImports at the level of CU (which were before in DJPP) #2100

Closed
wants to merge 37 commits into from

Conversation

surli
Copy link
Collaborator

@surli surli commented Jun 22, 2018

This PR follows the work started in #2083.
The idea is to be able to compute imports in CU, to allow the user to call that method properly after their transformations: then I'm trying to extract everything regarding the imports from the DJPP to the CU.

@monperrus monperrus changed the title WiP feat: clean import API WiP feat: computeImports at the level of CU (which were before in DJPP) Jun 28, 2018
@@ -33,6 +36,7 @@
@Override
public void onObjectUpdate(CtElement currentElement, CtRole role,
CtElement newValue, CtElement oldValue) {
this.changeCu(currentElement);
Copy link
Collaborator

Choose a reason for hiding this comment

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

Let's rename this type from EmptyModelChangeListener to DefaultModelChangeListener ... because it is no more empty
WDYT?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Yes I did not plan to keep it like that ;)

private void changeCu(CtElement element) {
SourcePosition position = element.getPosition();
if (position != null && !(position instanceof NoSourcePosition)) {
position.getCompilationUnit().setIsChanged(true);
Copy link
Collaborator

Choose a reason for hiding this comment

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

If spoon needs that call to keep internal consistency, then it should be part of some listener, which is always used - cannot be replaced by a different custom listener. I guess spoon should allow to register more then one listener.
WDYT?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Not necessarily.
It should be part of a standard listener that the user should be able to extend but it also could create another listener and never call this method: he would have to manage manually the flags to compute back the new imports then.

@tdurieux
Copy link
Collaborator

I m afraid of the negative performance impact of this change

@surli
Copy link
Collaborator Author

surli commented Jun 28, 2018

I m afraid of the negative performance impact of this change

Actually it should not impact much the users: the imports are only computed back in case of pretty-printing after a change in the model... and this was already the case before

@tdurieux
Copy link
Collaborator

Actually it should not impact much the users: the imports are only computed back in case of pretty-printing after a change in the model... and this was already the case before

My issue is not this one. You are calling getParent(CtType.class) a lot of time and this method is not a light one. This will be call frequently during the creation of the model...

@surli
Copy link
Collaborator Author

surli commented Jun 29, 2018

You are calling getParent(CtType.class)

Actually I do this call only if the element has no attached source position to give me the CU.
So it should only happen for the newly added element on the AST if I'm correct.

@tdurieux
Copy link
Collaborator

Actually I do this call only if the element has no attached source position to give me the CU.
So it should only happen for the newly added element on the AST if I'm correct.

Some ast node does not have a position, and during the creation of the model, the elements do not have a position yet.

And I m pretty sure that all the compilation unit will be marked as changed with the current change.

@surli
Copy link
Collaborator Author

surli commented Jun 29, 2018

And I m pretty sure that all the compilation unit will be marked as changed with the current change.

Then I should only activate this listener when the model has been built. Is there a property somewhere that is set when the model has been built for the first time? Do you think it might be interesting to add this feature if it does not exist?

@pvojtechovsky
Copy link
Collaborator

Do you think it might be interesting to add this feature if it does not exist?

yes! I need that for Sniper mode too ...
I need something what avoids sending of change events at model creation time.

@spoon-bot
Copy link
Collaborator

API changes: 6 (Detected by Revapi)

Old API: fr.inria.gforge.spoon:spoon-core:jar:6.3.0-20180629.101005-191 / New API: fr.inria.gforge.spoon:spoon-core:jar:6.3.0-SNAPSHOT

Method was added to an interface.
Old none
New method CompilationUnit#computeImports()
Breaking binary: non_breaking,
Method was removed.
Old method DefaultJavaPrettyPrinter#computeImports(CtElement)
New none
Breaking binary: breaking,
Method was removed.
Old method DefaultJavaPrettyPrinter#computeImports(CtType)
New none
Breaking binary: breaking,
Method was added to an interface.
Old none
New method CompilationUnit#isChanged()
Breaking binary: non_breaking,
Method was added to an interface.
Old none
New method CompilationUnit#isImported(CtReference)
Breaking binary: non_breaking,
Method was added to an interface.
Old none
New method CompilationUnit#setIsChanged(boolean)
Breaking binary: non_breaking,

@monperrus
Copy link
Collaborator

close?

@pvojtechovsky
Copy link
Collaborator

The sniper mode still needs improvements in area of computation of imports, so this PR is probably (I haven't tried to understood it yet) still relevant. Simon has to decide.

I'm trying to extract everything regarding the imports from the DJPP to the CU.

this sounds like a very good way 👍

@monperrus
Copy link
Collaborator

@surli ok to close?

@surli
Copy link
Collaborator Author

surli commented Oct 20, 2018

I think it will be directly conflicting with Pavel's work on the subject in #2683, so ok to close it for now. I'll see if something in the same idea is still needed after #2683 and if I have more time to implement it :)

@surli surli closed this Oct 20, 2018
@pvojtechovsky
Copy link
Collaborator

@surli do not delete the branch of this PR. It is some chance that I fail with refactoring of import scanner and that we have to continue here.

@surli
Copy link
Collaborator Author

surli commented Oct 20, 2018

@surli do not delete the branch of this PR

wasn't intending to: as I said I might restart the work here :)

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.

5 participants