Statement encloses itself

[intrigus-lgtm]

Description of the issue
It is possible for a Stmt to enclose itself.
Is this expected behavior? If yes, maybe add a note to the docs?

import java

from Stmt s
where s.getEnclosingStmt() = s
select s

Link to query:
https://lgtm.com/query/4871075667428522469/

[Marcono1234]

Looks like this is done on purpose for ThisConstructorInvocationStmt and SuperConstructorInvocationStmt:

codeql/java/ql/src/semmle/code/java/Statement.qll

Line 778 in cafbe14

override Stmt getEnclosingStmt() { result = this }

codeql/java/ql/src/semmle/code/java/Statement.qll

Line 820 in cafbe14

override Stmt getEnclosingStmt() { result = this }

Though I personally would expect the result to be none because there cannot be a statement before an explicit constructor invocation.

[aschackmull]

Thanks for reporting this - the TL;DR is that the end result that you observe is not intended, so we'll want to fix that.

The longer background explanation is that before switch expressions were added to Java, we didn't have Stmt.getEnclosingStmt(), instead Stmt.getParent() was used in a number of places. With the addition of switch expressions we can suddenly nest statements inside expressions, which gives the need for a Stmt.getEnclosingStmt() that is different from Stmt.getParent(). So before this addition the getEnclosingStmt() predicate was mostly just relevant for expressions. Now calls are mostly expressions (except for the two classes quoted above, ThisConstructorInvocationStmt and SuperConstructorInvocationStmt) and thus the Call class had a similar getEnclosingStmt() predicate which was just equal to the one on Expr, but also had to give reasonable results for the few calls that aren't expressions, so the two overrides quoted above are really motivated by the context of also being part of Call.getEnclosingStmt(). This is one of the corner cases of QL virtual dispatch interacting with multiple inheritance, which caused us to miss that the introduction of Stmt.getEnclosingStmt() already had clashing overrides. Fixing this will involve revisiting what we expect Call.getEnclosingStmt() to mean for these two classes.