Emit deprecated tag for deprecated LSP diagnostics

[mvanhorn]

Emits DiagnosticTag::DEPRECATED on LSP diagnostics for deprecated error codes.

Why this matters

Editors that support LSP diagnostic tags render strikethrough on deprecated names. Pyrefly was missing this tag. Now deprecated functions get the visual cue.

Changes

• pyrefly/lib/error/error.rs: Added DiagnosticTag import. Changed tags: None to emit DiagnosticTag::DEPRECATED when error_kind() == ErrorKind::Deprecated.

Testing

The change is a 6-line addition to a single file. ErrorKind derives PartialEq so the comparison is sound.

Fixes #2885

This contribution was developed with AI assistance (Claude Code).

[meta-cla]

Hi @mvanhorn!

Thank you for your pull request and welcome to our community.

Action Required

In order to merge any pull request (code, docs, etc.), we require contributors to sign our Contributor License Agreement, and we don't seem to have one on file for you.

Process

In order for us to review and merge your suggested changes, please sign at https://code.facebook.com/cla. If you are contributing on behalf of someone else (eg your employer), the individual CLA may not be sufficient and your employer may need to sign the corporate CLA.

Once the CLA is signed, our tooling will perform checks and validations. Afterwards, the pull request will be tagged with CLA signed. The tagging process may take up to 1 hour after signing. Please give it that time before contacting us about it.

If you have received this in error or have any questions, please contact us at cla@meta.com. Thanks!

[yangdanny97]

This should be tested somewhere. Did you verify the diagnostic ranges are correct for all the locations where this error is emitted?

[mvanhorn]

Added an LSP interaction test in 6a21eb5 that opens a file with a @deprecated function call and asserts the diagnostic includes tags: [2] (DEPRECATED).

On range correctness: the tag is applied in to_diagnostic() based on error_kind() == ErrorKind::Deprecated, so it's independent of which call site emits the error. All four sites (expr.rs, call.rs, overload.rs, stmt.rs) produce ErrorKind::Deprecated errors that flow through the same to_diagnostic() path. The range for each comes from the AST node at the call site (call expression, arguments, import statement), which is the same range used for the error message.

[yangdanny97]

To clarify: I'm saying we should emit the Deprecated error at the position of the call expression's subject, not the whole expression. That way, if we have something like deprecated_function(a, b, c) it's rendered as deprecated_function(a, b, c) rather than deprecated_function(a, b, c)

[github-actions]

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

[mvanhorn]

Looking at the call paths, freeform_call_infer already passes x.func.range() (the callee range) into as_call_target_or_error, so the deprecated diagnostic should already use just the function name for direct calls. The test shows range 0:12 for old_function() which is only the name, not the full call expression.

Is there a specific case where you're seeing the range cover the arguments?

[yangdanny97]

Understood, I'll try to get this merged. thanks

[meta-codesync]

@yangdanny97 has imported this pull request. If you are a Meta employee, you can view this in D98246395.

[kinto0]

Review automatically exported from Phabricator review in Meta.

[meta-codesync]

@yangdanny97 merged this pull request in 8c5b8f3.

[mvanhorn]

Thanks for pulling this in, @yangdanny97. Appreciate the back-and-forth on the diagnostic ranges.