Community
Participate
Working Groups
For example, linkage specs go like this: linkage.enterScope( requestor, astFactory.getReferenceManager() ); declaration(linkage, null, null, KeywordSetKey.DECLARATION); linkage.exitScope( requestor, astFactory.getReferenceManager() ); if there is an exception or backtrack out of the declaration, the callback will never receive the exitScope, and if it keeping track of scopes it will become unbalanced. This was causing memory growth when doing large searches.
I will investigate, this may not make it into 2.0, it could be a bit risky. Irregardless, Search requestor should clean itself up.
This affects any ISourceElementRequestor enter/exit callbacks.
There's a few cases to think about: 1. Parse within a scope { } fails, and error handling causes us to fall outside of where the final '}' is: for this, we need to make the errorHandling aware of what type of scope it is trying to handle out of. This will require the parser keeping track of {'s and }'s as we recursively decend. 2. Catastrophic failure requires something a bit more precise, like perhaps 'undoing' a previous callback.
This cannot be fixed for 2.0. Setting to Future.
Setting milestone to 2.0.l ...
Fix has been applied to HEAD, along w/JUnit test cases to validate them. When we merge this with the 2.0.1 branch I shall mark the defect as resolved.
Description of Solution: The parser communicates to the client through a callback. My fix uses Java "try{} finally{}" blocks to guarrantee that for every enter() call to the callback, there shall be an exit() call corresponding to it.
The merge from HEAD to 2_0 branch is complete. JUnits validating these fixes have been committed to both branches. Marking as RESOLVED - FIXED. The next available 2.0.1 build shall contain these fixes along with Parser performance/scalability improvements.
