[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-core-dev] ICElement line number
|
>
> > It was one example, other modules use the information.
> > For example, some on the future/current work on the debugger:
> > - BreakpointValidation, trying to set a breakpoint on non-statement
> > i.e #include
> > empty lines .. etc..
>
> The CModel cannot help you with things that are beyond its scope
> (i.e. empty lines within a function body, which it has no bearing
> upon).
>
The non-existence of ICElement for certain line is an indication
that no breakpoint can be set. And the existence of ICElement like
IInclude, IFunctionDeclaration, etc can be another tip.
JDT/Debug do much more smarter deductions, see for example
BreakpointLocationVerifier.java.
So far, we have start short in doing those things because of
the preprocessing problems.
#ifdef __X86__
....
..
#endif
Suddenly, the world become a much more complex/unfriendly place.
> > - Run/Jump to line, validation. Run to line should only be enable for
> > line whitin the stackframe, outside it is undefine behaviour
>
> If you have getStartLine() & getEndLine() for an IFunction (or similar)
> object, you should be able to figure this out.
>
Yes. ... but you were saying that you want to remove them !!?
> > > There will be another mechanism to convert from offsets to line
> numbers
> > > for other modules to use. So It will be provided but only when needed
> and
> > > not with every call to parse.
> >
> > Cool.
> >
> > > Maybe JohnC could elaborate some more on the effect on performance.
> > >
> >
> > Ok.
> >
>
> Its purely a memory vs. runtime performance issue.
> If it turns out that most parser clients are require line number
> information then it can be integrated into the AST/tokens to benefit
> performance at the cost of memory.
>
Ok. Then we can call the parser ourselves instead of going through the model
for costly operation.
> In any case, the infrastructure is available to implement a solution for
> 1.2 if someone wishes.
>
We are always looking at ways to improve.
Did you something in mind?
