Community
Participate
Working Groups
Spawned from an issue in https://git.eclipse.org/r/40855/ (Bug 458804) Given the following 2 source files when using ASTParser#setStatementsRecovery(true) : (1) package test; public class Foo { x. public void test () { } } (2) package test; public class Foo { public void test () { x. } } There is no ASTNode generated for 'x' in (1) while for (2) an ExpressionStatement with a SimpleName element is generated. Would it be possible to "recover" 'x' in (1) as an ExpressionStatement within an Initializer block, or maybe as an Expression inside a FieldAccess ?
I'm a bit skeptical about this request. Have you had a look at syntax recovery in the (internal) parser? It would probably have to jump through several hoops to achieve that effect. If we go by the letter, nobody should expect statements recovery outside a block that can hold statements. If we would recover it, it should probably be a QualifiedTypeReference since you might be about to declare x.C someField; Would that be OK for your purpose? Or do you definitely need an expression? Have you checked what happens if you have 'x' without the dot? I think in some situations we'd recover that to <missing type> x; i.e., x would be the name of a field. Any change here would need to be very careful not to break other similar-looking recovery scenarii.
(In reply to Stephan Herrmann from comment #1) > I'm a bit skeptical about this request. > > Have you had a look at syntax recovery in the (internal) parser? It would > probably have to jump through several hoops to achieve that effect. Doesn't the internal parser do this already ? I believe with InternalCompletionContext (from JavaContentAssistInvocationContext), there is access to the CompletionOn* type, which is sort of what we want in this case. Basically, any sort of API to get at the token(s) that would be the subject of any completions. > If we go by the letter, nobody should expect statements recovery outside a > block that can hold statements. > > If we would recover it, it should probably be a QualifiedTypeReference since > you might be about to declare > x.C someField; > > Would that be OK for your purpose? Or do you definitely need an expression? I think any ASTNode would be fine. > Have you checked what happens if you have 'x' without the dot? I think in > some situations we'd recover that to > <missing type> x; > i.e., x would be the name of a field. Any change here would need to be very > careful not to break other similar-looking recovery scenarii. Even without the dot, the nodes recovered are the same as with the dot.
If you see a useful node in the internal AST and if only converting this into a dom ast node is needed, then my worries are irrelevant.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
(In reply to Roland Grunberg from comment #2) > (In reply to Stephan Herrmann from comment #1) > > I'm a bit skeptical about this request. > > > > Have you had a look at syntax recovery in the (internal) parser? It would > > probably have to jump through several hoops to achieve that effect. > > Doesn't the internal parser do this already ? I believe with > InternalCompletionContext (from JavaContentAssistInvocationContext), there > is access to the CompletionOn* type, which is sort of what we want in this > case. Basically, any sort of API to get at the token(s) that would be the > subject of any completions. I should have noted, that CompletionParser and ASTParser are disjoint things, so the internal AST seen by ASTParser will never contain any CompletionOn* nodes, and changing that doesn't look like a good idea to me, since completion parsing has its very specific purpose that's different from generally providing an approximation AST from sources with syntax errors. @Roland do you still want this?
Looking back, it does seem like a pretty narrow case and if no one has explicitly complained about it I would either close or leave as low priority.
