Community
Participate
Working Groups
Given only a variable binding, it is currently cumbersome to tell whether the variable binding resolves to a method argument declared as a vararg. As far as I understand, this can only be answered using an AST. Bindings do not seem to provide this information.
The method binding should provide this information.
Sure, but how do I tell based only on a variable binding whether it resolves to a varargs argument?
I don't see how this is relevant without the context of a method. The var args information is relevant only to invoke the method. So the question should be asked to the method binding, not the variable binding.
For the new move method implementation, I have to construct a method signature based on an array of existing IVariableBindings corresponding to existing method arguments. In order to correctly sort the arguments for the new method signature (additional arguments occur, but varargs are always last) and to generate the proper variable declaration nodes (VARARGS property), this information must be available from the binding
When you get the array of existing method arguments, you can get the information taht this method has a variable argument. I really don't see the need for an API on IVariableBinding. Jim, any comment?
An option to get the declaring method from a IVariableBinding (if it resolves to a method argument or to a local variable) would be sufficient as well.
Tobias, There's lots of info about variable bindings that is not surfaced on IVariableBinding; this has never come up as a problem in the past; I'd like to know what is different now. If I understand your comment #4 correctly, I would agree with Olivier's observation that you have the MethodDeclaration or IMethodBinding in hand and can get order and varags info from it rather than the IVariableBindings. Perhaps you could give us a snippet to show why that is not sufficient.
The new implementation of MoveInstanceMethodProcessor is a good example. To handle both types of method targets (method argument types and instance field types) in an uniform way, both are represented by an IVariableBinding. Coming from an AST to a particular variable binding is kind of a one way: Variable bindings for local variables and method arguments (obviously) do not return a java element, but neither can you easily get their declaring method bindings. It's true that the existing facilities are sufficient to determine whether a variable binding resolves to a field or a local variable/method argument. One can argue that IVariableBindings do not have to deliver the information about varargs, but then there has to be an easy/easier way to get the declaring method from a variable binding, if applicable.
As far as I can see, the grief stems from the decision to represent the target as an IVariableBinding, which provides only limited information. Your code clearly need more information that what the binding provides. So why use IVariableBinding at all in your algorithm? Why not use the VariableDeclaration node where the binding is introduced? Note that there has never been a direct way to navigate from any IBinding to the AST node that gives rise to it (if it comes from source code at all). The assumption has always been that the client would figure out this connection by themselves if needed (e.g., by searching and checking IBinding keys). Adding Dirk so that he can comment on how these kinds of problems have been dealt with in the past.
Looking at it there are two distinct problems: - having IVariableBinding.isVarArgs(). This is indeed questionable to add. If we do this then we have to add other methods like this as well. Currently non of the bindings answer context related informations. - the ability to navigate from a binding to its enclosing element. This is possible for all elements except variable bindings for locals. So to make this consistent there should be a method #getDeclaringMethod on IVariableBinding which returns the IMethodBinding for locals and null for fields.
The navigation from local variable binding to declaring method binding seems reasonable. Olivier, does this look implementable? /** * Returns the method binding representing the method containing the scope * in which this local variable is declared. * <p> * The declaring method of a method formal parameter is the method itself. * For a local variable declared somewhere within the body of a method, * the declaring method is the enclosing method. When local or anonymous * classes are involved, the declaring method is the innermost such method. * There is no declaring method for a field, or for a local variable * declared in a static or instance initializer; this method returns * <code>null</code> in those cases. * </p> * * @return the binding of the method or constructor that declares this * local variable, or <code>null</code> if none * @since 3.1 */ public IMethodBinding getDeclaringMethod();
This is not trivial since we don't have that link in the compiler world.
Fixed and released in HEAD. Regression tests added in ASTConverterTestAST3_2.test0578 and ASTConverter15Test.test0072. Let me know asap if this is what you wanted.
Test ASTConverter15Test.test0072 is using project "Converter" instead of project "Converter15". Thus it is testing a compilation unit that doesn't exist. Reopening to fix the test in 3.1 M5.
Created attachment 16581 [details] Apply on HEAD Patch ready to be applied on HEAD.
Fixing boggus test.
Verified for 3.1 M4 using build I200412142000 + ASTView 1.0.2.
*** Bug 67460 has been marked as a duplicate of this bug. ***
