Reject Self in PEP 695 type parameter bounds

[wolfgang-aura]

Closes #21960.

Mypy accepts Self as the bound of a PEP 695 type parameter, even though
Self is only valid in the locations defined by PEP 673. The same path also
fails to apply the existing Self validation consistently to constraints.

The cause was that PEP 695 bounds and constraints were analyzed without the
existing prohibit_self_type context. The fix passes the appropriate
prohibition context through both paths and adds regression coverage to the
existing invalid-Self test case.

How this was tested

At the reported base commit ae39cdb2fba8908eeff6ec8d6b88879c62495fcc, the
machine-checked reproduction accepted the invalid bound with
mypy_exit=0 and diagnostics=0. After the change, the final independent
verification selected the focused test case and reported 2 passed, 8225 deselected.

The checks ran on Windows 11. Mailman recorded Python 3.14.3 for the host
command metadata; the target test environment used Python 3.12.14. Provider
integration testing was not part of this focused type-checker regression.

An alternative not taken

The error could have been added as a special case at each PEP 695 analysis
call site. Reusing the existing prohibit_self_type context keeps bound,
constraint, nested, and typing_extensions.Self handling on one validation
path and avoids duplicate diagnostics logic.

AI disclosure

This change was drafted with AI assistance: codex (gpt-5.6-luna) wrote the
patch and codex (gpt-5.6-luna) reviewed it under Mailman. The test results
above were executed by the Mailman harness. Human review and filing remain
pending.

[EmmanuelNiyonshuti]

hmm...I think the ai description sounds plausible. But, b1f235a is prefixed wip: Is this ready for a review?

[EmmanuelNiyonshuti]

I think mypy already rejects Self in constraints. Why is this needed, would you elaborate?

[EmmanuelNiyonshuti]

I think mypy already rejects Self in constraints. Why is this needed, would you elaborate?

class Foo:
    # TypeVar constraint type cannot be parametrized by type variables
    def constrained[T: (Foo, Self)](self: T) -> None: pass

[EmmanuelNiyonshuti]

I don't know if there's a human behind this, but either way I've got a fix for this, just in case!

[wolfgang-aura]

Both fair questions. Taking the second one first, because it decides what is
left of this PR.

You are right about constraints. I checked it rather than argued it. On the
base commit ae39cdb, with no patch applied:

$ python -m mypy --no-incremental --python-version 3.12 probe.py
probe.py:5: error: TypeVar constraint type cannot be parametrized by type variables  [misc]
Found 1 error in 1 file (checked 1 source file)

where probe.py is:

from typing import Self

class C:
    def bounded[T: Self](self: T) -> None: ...
    def constrained[T: (C, Self)](self: T) -> None: ...

Line 5 is your case and it already errors. Line 4 is the bound, and the base
reports nothing for it. That silent accept is what #21960 is about, and it is
the half this PR actually adds.

So the constraint hunk does not add coverage. It changes an existing message
from "TypeVar constraint type cannot be parametrized by type variables" to
"Self type cannot be used in a type parameter constraint". I kept it because
the first message names the wrong reason: Self is not rejected there for
being generic, it is rejected for being Self, and the issue text names the
constraint alongside the bound. That is a judgement call, not a fix. Say the
word and I will drop it and leave the PR to the bound alone.

On the wip: commit: that was mine to clean up and I have. The two commits
are now one, fe2e1f5, with the same tree. The commit only existed because
the test parses PEP 695 syntax at collection time, so it had to move from
check-selftype.test to check-python312.test to stay off older runtimes.

And to answer the question you were careful enough to ask out loud: the patch
was written by an agent, and I am reviewing and standing behind everything it
sends. You should weigh it accordingly. If your own fix is further along than
this one, I would rather see yours land than spend your review time on mine.
Close this and I will not take it personally.

[github-actions]

According to mypy_primer, this change doesn't affect type check results on a corpus of open source code. ✅

[EmmanuelNiyonshuti]

I am more leaning towards this being closed. May be the issue was not very clear because I think this is not exactly about lexical positions.

from typing import Self

class C:
        def foo[T: Self](self: T) -> None: pass

Isn't Self in a valid location(PEP 695)?
I think this is having a type variable whose bound reference type variable. which I also think would be clearer to add a new error message for in message registry.

[wolfgang-aura]

You are right, and I checked it rather than argued it.

Before I saw #21967 I prototyped your framing on the base commit ae39cdb:
reject the bound when has_type_vars(upper_bound). It lands in the same place
and the same shape as your patch, and it catches two cases this PR does not.

class D[U]:
    def g[T: U](self, x: T) -> None: ...   # base: no error at all

That one has nothing to do with Self. And:

class F:
    def nested[T: list[Self]](self, x: T) -> None: ...   # base: no error

The typing spec puts the rule under generics, not under Self:

The bound itself cannot be parameterized by type variables.

So Self in a bound is one instance of a rule mypy is missing, not a PEP 673
location needing its own message. That is also why pyright and ty report it as
a generic upper bound. My framing covered the narrower half of yours, and the
new message would have named one case of a rule that should cover all of them.

Closing in favour of #21967. The probe notes are in a comment there.