`@x.setter` / `@x.getter` / `@x.deleter` are the property-descriptor
protocol, not references to corpus symbols named setter/getter/deleter.
The Python decorator-edge pass (#2154) ran `ensure_named_node` on the
decorator's head symbol, so every property with a setter/deleter/getter
redefinition fabricated a sourceless stub node and a false `references`
(context=decorator) edge onto it — the same provenance pollution the
builtin-decorator noise list already guards against for `@property`.
`_python_is_property` already recognizes the `.getter` form for the
read-semantics; the decorator-edge path now mirrors it and skips any
`.setter`/`.getter`/`.deleter` decorator. Imported decorators reached
through an attribute (`@app.route`) are unaffected.
Regression test asserts no decorator edge and no sourceless stub for a
property with setter and deleter accessors.
(cherry picked from commit 2dc8972c67)
The decorator reference edges added in #2154 fabricated sourceless stub
nodes for @property/@staticmethod/@dataclass/@functools.wraps and, via
the unique-function rewire, could stamp a false edge onto a corpus's own
def wraps(). Add _PYTHON_DECORATOR_NOISE (mirroring _PYTHON_ANNOTATION_NOISE)
and skip those names, same accepted tradeoff as patch/Mock in annotations.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Nine cases: the issue's imported-decorator repro, same-file resolution to
the local definition, called and attribute decorators, stacked
decorators, class-qualified method owners, a decorated class, the #1050
@property class-qualification regression guard, and an absence control.
rajatnagda45