Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [hibachi-dev] SourceRange for an AdaVariable
The model is intended to be a lightweight representation of an Ada source file. For those of you who aren't aware, we have a Google Summer of Code project currently in progress working on implementing an Ada AST for Hibachi similar to what is available for CDT (org.eclipse.cdt.core.dom.ast) and JDT (org.eclipse.jdt.core.dom). This AST will be what you would use if you need more complete information than what is in the model, for example if you are creating a pretty printer or implementing quick fixes. I would expect the initial version to be available mid-to-late August, if all goes well. 

Adam
----- Original Message ----- From: "David R. Phillips" <dphillips@xxxxxxxxxxxxxxxxx> 
To: "'Hibachi Dev list'" <hibachi-dev@xxxxxxxxxxx>
Sent: Wednesday, July 16, 2008 12:22 PM
Subject: RE: [hibachi-dev] SourceRange for an AdaVariable



Todd,
My initial reaction is similar to Adams. Is there a particular benefit that 
we would gain by splitting the parameter in the parse tree?  There are two
camps that we need to consider one would want the parse tree to match the
source as closely as possible and the other would want the tree to match the logical grouping of all of the parameters at the same level. There are good 
reasons for each approach.  I tend to be the first camp.
If we do consider deviating from what JDT is doing, we need to have a really good reason. We would appreciate any ideas on why this would be helpful to 
Hibachi so we could make an informed decision.

--David

-----Original Message-----
From: Adam Haselhuhn [mailto:adam.haselhuhn@xxxxxxxxx]
Sent: Wednesday, July 16, 2008 12:00 PM
To: Hibachi Dev list
Subject: Re: [hibachi-dev] SourceRange for an AdaVariable

Todd,
If I understand correctly, the situation you're mentioning only occurs when there are multiple variables declared with a single type, as in O1 and O2 in 
your example below.

IAdaVariable object refers to the name and type, so the range must include
both.  We could have the range for the O2 variable be "O2 : out Integer",
but I don't like the idea splitting up a declaration like that.


FWIW, I checked the JDT model, and for field declarations like this:

public int i1, i2;
Both the source range for both i1 and i2 is "public int i1, i2;", just like 
Hibachi is doing.

Does anyone else have an opinion on this?

Adam

----- Original Message -----
From: "Todd Wallentine" <tcw@xxxxxxx>
To: "Hibachi Dev list" <hibachi-dev@xxxxxxxxxxx>
Sent: Friday, July 11, 2008 4:51 PM
Subject: [hibachi-dev] SourceRange for an AdaVariable



Hibachi Devs,

While working with Hibachi's underlying object model I noticed something
that might be a bug. I wanted to run it by the devs list to see if it was
indeed a bug before I reported it as such.

What I am seeing is that the SourceRange instance is re-used for all
IAdaVariables that are declared in a list. For example, if I have the
following Ada code:

procedure P1 (I : in Integer; O1, O2 : out Integer)

the SourceRange would be the same for O1 and O2 (not only are the values
the same but the instance is the same).

I did find what is likely the cause of this. In the AdaASTParser class
(package: org.eclipse.hibachi.model.internal) the method
parseVariableDeclaration has the following snippets:

// Use the same source range for all variable declarations from
// the same list
ISourceRange range = ParserHelper.getElementRange(m_lineTracker,
sourceAst);

and then later does this:

IAdaVariable[] ret = new IAdaVariable[identifiers.size()];
for (int i = 0; i < identifiers.size(); ++i)
{
  ret[i] = new AdaVariable(parentMember.getCompilationUnit(), parentName,
(String)identifiers.get(i), false, flags, range, typeReference);
}
return ret;
So it would appear that this was done on purpose. But this doesn't seem to 


be correct - or at least I would prefer that the source ranges are
different. So is this a bug or just me not understanding what the
SourceRange should be?

thanks,
todd
_______________________________________________
hibachi-dev mailing list
hibachi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/hibachi-dev


_______________________________________________
hibachi-dev mailing list
hibachi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/hibachi-dev

_______________________________________________
hibachi-dev mailing list
hibachi-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/hibachi-dev

Back to the top