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

Problems resolving a NameExpr when it represents a private field name #2367

Closed
hecaidi opened this issue Sep 17, 2019 · 2 comments · Fixed by #2378
Closed

Problems resolving a NameExpr when it represents a private field name #2367

hecaidi opened this issue Sep 17, 2019 · 2 comments · Fixed by #2378
Labels
Question (JP usage) How to use JP to inspect/modify the AST - please close your question once answered! Symbol Solver
Milestone

Comments

@hecaidi
Copy link

hecaidi commented Sep 17, 2019

Hello,

I am having problems with
((NameExpr) node).resolve().getType().describe()
when the node represents the name of a private field.

An exception is thrown at the resolve() call. I think the problem comes from class com.github.javaparser.symbolsolver.javaparsermodel.contexts.ClassOrInterfaceDeclarationContext, at the method:

@Override
    public SymbolReference<? extends ResolvedValueDeclaration> solveSymbol(String name) {
        if (typeSolver == null) throw new IllegalArgumentException();

        if (this.getDeclaration().hasVisibleField(name)) {
            return SymbolReference.solved(this.getDeclaration().getVisibleField(name));
        }

        // then to parent
        return getParent().solveSymbol(name);
    }

I don't understand why it is only searching for visible fields, being the ClassOrInterfaceDeclaration a parent of my NameExpr node.

Should I do this in other way?

@matozoid matozoid added Question (JP usage) How to use JP to inspect/modify the AST - please close your question once answered! Symbol Solver help wanted labels Sep 17, 2019
@SimonBaars
Copy link
Contributor

SimonBaars commented Sep 18, 2019

Hey Hecaidi,

Thanks for submitting this issue! Could you please submit a reproducible case in which this error occurs? hasVisibleField is correct in the method you point out because the symbol solver traces to parent classes and this method should only be in effect in such cases.

I created the following class:

public class Issue2367 {

    private double privateField;

    public Issue2367(double localField) {
        privateField = localField;
    }
}

Resolving the privateField NameExpr in privateField = localField; succeeds.

@SimonBaars
Copy link
Contributor

Okay, hereby some further insight into solving this issue.

The method you pointed out breaks a test when hasVisibleField and getVisibleField are changed to hasField and getField respectively. However, the following (similar) method in the same file does not break tests when the same transformation is applied:

@Override
    public Optional<Value> solveSymbolAsValue(String name) {
        if (typeSolver == null) throw new IllegalArgumentException();

        if (this.getDeclaration().hasVisibleField(name)) {
            return Optional.of(Value.from(this.getDeclaration().getVisibleField(name)));
        }

        // then to parent
        return getParent().solveSymbolAsValue(name);
    }

Inspecting the incoming calls of both, it seems that solveSymbol is used when parsing through inheritance hierarchies but solveSymbolAsValue is not.

I solved the problem in my fork here:
https://github.com/SimonBaars/javaparser/tree/issue2367

If I can test this fix successfully using a case you can provide, I can open a pull request to close this issue.

matozoid added a commit that referenced this issue Sep 24, 2019
Fix and test for issue #2367, resolving NameExpr when it represents a private field name
@matozoid matozoid added this to the next release milestone Sep 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Question (JP usage) How to use JP to inspect/modify the AST - please close your question once answered! Symbol Solver
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants