[Aayushyaash]

Summary

In Pyrefly, check_variance_violations_and_mismatches warns when an invariant TypeVar in a Protocol could be declared with a narrower variance to preserve structural subtyping. However, emitting variance-mismatch for constrained type variables produces a false positive because the suggested variance change is not valid for constrained TypeVars.

This PR fixes the issue by excluding constrained type variables from the variance-mismatch diagnostic:

1. Updates the metadata.is_protocol() guard in solve.rs to ignore Restriction::Constraints(_), avoiding unnecessary calls to infer_variance_ignoring_declared when all invariant parameters are constrained.
2. Skips Restriction::Constraints(_) inside the parameter loop while preserving variance-mismatch checks for unconstrained and bounded (Restriction::Bound(_)) type variables.

Fixes #3655

• I am a human, and I fully understand the code I am submitting.

Test Plan

Added unit tests in pyrefly/lib/test/variance_inference.rs (test_constrained_typevar_protocol_variance_mismatch) covering:

• A protocol returning a constrained TypeVar (def value(self) -> T: ...) without triggering variance-mismatch.
• A protocol accepting a constrained TypeVar in a parameter position (def consume(self, x: T) -> None: ...) without triggering variance-mismatch.
• Ensuring bounded (bound=...) and unconstrained TypeVars in protocols continue to be checked for variance mismatch.

Validation

cargo check
cargo test -p pyrefly variance_inference -j 2
cargo test -p pyrefly test::protocol -j 2
cargo fmt -- --check

[meta-codesync]

This pull request has been imported. If you are a Meta employee, you can view this in D129256923. (Because this pull request was imported automatically, there will not be any future comments.)

[stroxler]

I think the conformance results need an update, and I think the comment wording is a little too strong here

[stroxler]

Let's soften the wording here. Variance actually can be declared on them.

In many cases the variance doesn't matter, but if some types are subtypes of other it can, e.g. with (int, float) as a constraint there's a real distinction between covariance and contravariance.

I think it would be more precise to just say that invariance usually makes sense, so complaining about it is too noisy

[Aayushyaash]

Updated the comment:

// Constrained TypeVars are excluded because invariance is a sound default for a fixed
// set of constraints, and the narrower-variance suggestion is usually noise.

[github-actions]

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

[Aayushyaash]

Thanks for the review!
Updated the comment and regenerated the conformance output snapshots via conformance_output.py. All local tests and lint checks are green.

[stroxler]

Review automatically exported from Phabricator review in Meta.

[stroxler]

I'm not sure why this didn't auto-close, the commit landed in e01f27f