Python: simplify decorator-detection predicates to pure AST match

[yoff]

Factor-out from the Python shared-CFG dataflow migration stack (#21919/#21920/#21921/#21923/#21925).

The internal predicates isStaticmethod, isClassmethod, and hasPropertyDecorator (in DataFlowDispatch.qll) previously required the decorator's NameNode to satisfy isGlobal() — i.e. no SSA definition reaches the name use. That filter was correct but unnecessarily indirect:

• staticmethod, classmethod, and property are builtins.
• Even when a class body redefines one (staticmethod = ... inside the class), the class body has not started executing yet at the decorator position, so Python uses the builtin at that point.

This PR matches the decorator's AST Name directly instead, dropping the CFG/SSA detour.

Semantic change

There is a small behavioural difference. The previous isGlobal() check rejected module-level shadowing of these builtins, e.g.:

def staticmethod(x): ...  # shadows the builtin in this module

class C:
    @staticmethod
    def foo(): ...  # at the decorator position, `staticmethod` is the local one

With the previous code, foo was not classified as a staticmethod. With the new code, it is. Shadowing these three names at module scope is essentially never seen in practice, so this is a negligible false-positive risk in exchange for much cleaner code. Documented in a change note.

Why not hasContextmanagerDecorator / hasOverloadDecorator too?

Those predicates also use the NameNode.isGlobal() pattern, but their target names (contextmanager from contextlib, overload from typing) are imported, not builtin. The isGlobal() check legitimately filters out cases where these names refer to a local variable rather than the imported one, which is a more realistic shadowing scenario. So they stay as-is.

Verification

• All 361 python/ql/{src,lib} queries compile.
• All 88 tests in library-tests/dataflow, library-tests/PointsTo/general, and query-tests/Functions pass.

This PR has no dependencies on the rest of the migration stack and can land independently. After it merges, the corresponding predicate changes in yoff/python-shared-cfg-dataflow-flip (#21925) collapse to a noop (just the Cfg:: qualification on the two remaining contextmanager/overload predicates).

[Copilot]

Pull request overview

Simplifies internal Python dataflow decorator-detection predicates by matching decorator AST Name nodes directly (instead of going through CFG/SSA isGlobal()), as part of the shared-CFG dataflow migration refactoring stack.

Changes:

• Updated isStaticmethod, isClassmethod, and hasPropertyDecorator to match func.getADecorator().(Name).getId() against builtin decorator names.
• Added/updated rationale comments in DataFlowDispatch.qll explaining the shift to a syntactic AST match.
• Added a minorAnalysis change note documenting the (rare) behavior change for shadowed builtin decorator names.

Show a summary per file

File	Description
python/ql/lib/semmle/python/dataflow/new/internal/DataFlowDispatch.qll	Switched builtin decorator predicates from CFG/SSA-based resolution checks to direct AST Name matching and added explanatory comments.
python/ql/lib/change-notes/2026-06-01-decorator-predicate-simplification.md	Added change note describing the predicate simplification and its (rare) semantic impact.

Copilot's findings

• Files reviewed: 2/2 changed files
• Comments generated: 2

[tausbn]

Seems reasonable to me. Even in cases where these built-ins are overloaded, I would still expect staticmethod to indicate that something is a static method. (Just as we assume decorators don't fundamentally change the functions/classes they decorate.)

[yoff]

Seems reasonable to me. Even in cases where these built-ins are overloaded, I would still expect staticmethod to indicate that something is a static method. (Just as we assume decorators don't fundamentally change the functions/classes they decorate.)

That is a good point, actually :-) DCA does not seem alarming; some slower stages, but no overall slowdown.