[Lazarus] Warning: FPDOC Editor can cause data loss

[Graeme Geldenhuys]

On 2010-06-07 09:01, Hans-Peter Diettrich wrote:
> Adem schrieb:
>
>>> And finally we'll have to talk about parsing invalid code, during 
>>> editing. This can be handled by the same hack as for conditionally 
>>> excluded code, so that after an syntax error the parser stops 
>>> parsing, and simply returns the tokens provided by the scanner. The 
>>> only question: how to make the parser resume parsing, once enough 
>>> tokens have been skipped?
>> OTOH, two approaches come to mind:
>>
>> First one is, introduce another token kind (or several new token 
>> kinds, if we need to take care of degrees of severity) for error, and 
>> add an 'error node' every time an error occurs and contniue 
>> regardless. Then, let the calling application decide what to do.
>>
>> Second one could be something like this:
>>
>> Call an event wherever halting occurs:
>
> The Semantics class will have according method(s).
>
> But when the parser is in an error state, inside some procedure, how 
> can the parser be instructed to exit this and further procedures in 
> the call stack? Exception handling could implement such detailed 
> recovery, but the compiler code does not use SEH for speed reasons.
I haven't studied the actual code, so it is entirely possible that I am 
talking through my (or even someone else's) hat.

I expect, in the current code, there are exit points that emit a 
reasonably suitable message to the compiler. Could we not replace these 
exit points with procedure/function calls to that decides whether (in 
the case of compiler use) it should exit immediately or (in the case of 
non-compiler use) it should consult with the calling class?

But, then, it's probably not as easy as that.

-- 
Cheers,

Adem