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

Create CtTypeAccess/CtTypeReference for ArrayReferences in noclasspath mode and static context. #811

Closed

Conversation

msteinbeck
Copy link
Contributor

No description provided.

@msteinbeck
Copy link
Contributor Author

Once #809 is merged I can extend the provided example checking if getDeclaringType != null

@alcides
Copy link
Contributor

alcides commented Aug 31, 2016

I believe github now allows pull requests against other branches than master. I don't know if this might help here.

On 31 Aug 2016, at 10:03, Marcel notifications@github.com wrote:

Once #809 is merged I can extend the provided example checking if getDeclaringType != null


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

throw new SpoonException();
}
ref.setDeclaringType(typeAccess.getAccessedType());
} catch (final SpoonException e) { /* ignore */ }
Copy link
Collaborator

Choose a reason for hiding this comment

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

really all SpoonException?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Since it is noclasspath mode any of these function may throw a SpoonException if they were not able to create a type access. Do you have a better idea?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I could replace the SpoonException with a null return. It's up to you.

Copy link
Collaborator

Choose a reason for hiding this comment

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

An ignored exception is always a threat to debugging. Is it necessary? What if you don't catch anything in this method?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Ok, I will remove the exception handling.

Copy link
Collaborator

Choose a reason for hiding this comment

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

ok, thanks.

@monperrus
Copy link
Collaborator

do you have a test case?

@msteinbeck
Copy link
Contributor Author

Is comming

@msteinbeck
Copy link
Contributor Author

Added an example that shows that even multi dimensional arrays are processed.

@GerardPaligot
Copy link
Contributor

Big thanks for this PR @ReTuXx! I'm happy to see that someone else can contribute to these new JDT builders. (:

@GerardPaligot
Copy link
Contributor

This PR need a rebase.

@msteinbeck
Copy link
Contributor Author

I still need to remove the catch block and fix some other issues. I will try to fix it the next days, currently I'm in a rush. Sorry for that.

@@ -392,6 +395,28 @@ public boolean onAccess(char[][] tokens, int index) {
return typeAccess;
}

<T> CtTypeAccess<T> createTypeAccessNoClasspath(ArrayReference arrayReference) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add javadoc to explain what do you do your new method? (:

final CodeFactory codeFactory = jdtTreeBuilder.getFactory().Code();

final char[] readableName;
if (arrayReference.receiver instanceof ArrayReference) {
Copy link
Contributor

Choose a reason for hiding this comment

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

arrayReference.receiver can't never be null in noclasspath mode? If yes, you'll go here.

try {
final JDTTreeBuilderHelper helper = jdtTreeBuilder.getHelper();
final CtTypeAccess<T> typeAccess;
if (messageSend.receiver instanceof SingleNameReference) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Same here, messageSend.receiver can't never be null in noclasspath mode?

@monperrus
Copy link
Collaborator

@ReTuXx , should we close this old one?

@msteinbeck
Copy link
Contributor Author

I'm still working on it but it is hard to test. If I remove the catch blocks I get another error which only appears when using mvn test.

@monperrus
Copy link
Collaborator

#884 may help the mvn test problem. will be merged soon.

@msteinbeck
Copy link
Contributor Author

#884 may help the mvn test problem. will be merged soon.

The problem is, that when selecting one of the tests failing with mvn test and running them by their own, they do not fail any longer. That's very annoying...

@monperrus
Copy link
Collaborator

The problem is, that when selecting one of the tests failing with |mvn
test| and running them by their own
with "mvn test -Dtest=pack.myTest" or in the IDE?

@msteinbeck
Copy link
Contributor Author

I tried to run a particular test from withing the IDE in order to have breakpoints.

@monperrus
Copy link
Collaborator

monperrus commented Oct 20, 2016 via email

@msteinbeck
Copy link
Contributor Author

OK, so the difference is between MVN and IDE

I don't thing so. I'm using IntelliJ which simply runs maven without further processing. Running mvn test from withing IntelliJ fails as well.

Did you rebase against master recently?

Not yet.

@monperrus
Copy link
Collaborator

closing this old inactive PR. Don't hesitate to re-open it if required.

@monperrus monperrus closed this Nov 7, 2016
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