add getEnclosingBlock for Go

[Lslightly]

codeql/go/ql/lib/semmle/go/AST.qll

Lines 77 to 85 in 6fa6093

	/** Gets the parent node of this AST node, but without crossing function boundaries. */
	privateAstNodeparentInSameFunction(){
	result=this.getParent()and
	notthisinstanceofFuncDef
	}
	/** Gets the innermost function definition to which this AST node belongs, if any. */
	pragma[nomagic]
	FuncDefgetEnclosingFunction(){result=this.getParent().parentInSameFunction*()}

In rust and cpp, getEnclosingBlock is supported as shown by search result. Would Go support this?

/** Gets the parent node of this AST node, but without crossing block boundaries. */privateAstNodeparentInSameBlock(){result=this.getParent()andnotthisinstanceofBlockStmt}/** Gets the innermost block statement to which this AST node belongs, if any. */pragma[nomagic]BlockStmtgetEnclosingBlock(){result=this.getParent().parentInSameBlock*()}

[owen-mc]

Can I ask what you want to use it for?

The two examples you give are very much about syntactic blocks. Both of those languages have a BlockExpr or BlockStmt in their AST, which we don't have in the Go AST. We have something a bit similar in go: getEnclosingBlock on ControlFlow::Node, which returns a BasicBlock. But it uses the control flow graph, so it goes beyond the AST level to what is actually happening semantically. To see the difference, consider this function:

funcf() {
g()
h()
}

At a syntactic level it clearly has one block. But from the point of the view of control flow it has two basic blocks, because g might panic, in which case h would not be called after it.

[Lslightly]

Usage Scenario: decide whether the declaration of obj is in the same BlockStmt as GoStmt and assert that obj will not be accessed after GoStmt in execution(or semantically).

varobjSgofunc() { access(obj) }()

If they are not in same BlockStmt, then usually obj is declared in outer BlockStmt.

varobjSfor {
gofunc() { access(obj) }()
}

Both of those languages have a BlockExpr or BlockStmt in their AST, which we don't have in the Go AST

go-all package(4.2.5 version) in codeql v2.21.3 codeql qlpacks have BlockStmt. I also checked the latest codeql packs. BlockStmt exists. What do you mean by "which we don't have in the Go AST"?

We have something a bit similar in go: getEnclosingBlock on ControlFlow::Node

Thanks for your explanation! In the second example above, using AST level getEnclosingBlock to decide that obj might be used in later iteration is fast and simple, because I can easily get the GoStmt which references obj. The obj is categorized as class MovedToHeapVar extends LocalVariable by Location, which is provided by external predicates.

I will try to connect ControlFlow::Node with GoStmt and declaration Ident and use getASuccessor to assert that obj will not be accessed after GoStmt. But I doubt that it can be complex.

[owen-mc]

You're right, I missed BlockStmt in the codeql go library because I only searched in AST.qll. My apologies.

Thank you for explaining your use case. I have made a PR to add this as a member predicate: #21254 .

In the meantime, you can write the code that you want in a top-level predicate rather than a member predicate:

 /** Gets the innermost block statement to which this AST node belongs, if any. */
BlockStmt getEnclosingBlock(AstNode an) {
exists(AstNode p | p = an.getParent() |
result = p
or
not p instanceof BlockStmt and
result = p.getEnclosingBlock()
)
}

I should also mention the Scope class, which unfortunately isn't very useful in this case. We can only really talk about scopes of Entitys, like a variable, but I don't think we can get a Scope corresponding to a goStmt.

[owen-mc]

To be more specific, if you look at the results of LocalScope.getNode() you will see which AST nodes can introduce a new (local) scope. For example, you can define a new variable before the condition of an if statement and it will be in scope for the rest of the if statement. See also the QLDoc comment for ScopeNode for more examples. (For your use case you are probably only interested in a subset of scopes in which a GoStmt can appear, which may just be those created by BlockStmts.)

[Lslightly]

Thanks for your explanation about Scope and LocalScope. Actually, the way I try first to match the declaration block of variable and the block GoStmt resides in is comparing LocalScope.getNode() of variable, the declaration "block"(but actually it is FuncTypeExpr, not BlockStmt), and enclosing BlockStmt of GoStmt. I failed because FuncTypeExpr could not be equal to BlockStmt.

Then I turn to find the enclosing BlockStmt of variable declaration. So the same pattern of getEnclosingBlock appears twice and I'm here with the proposal.

[owen-mc]

#21254 has been merged, so this should be in release v2.24.2, which should be out in about two weeks.