chore(deps): bump pyright from 1.1.347 to 1.1.348 in /language-server

[dependabot]

Bumps pyright from 1.1.347 to 1.1.348.

Release notes

Sourced from pyright's releases.

Published 1.1.348

Breaking Changes:

Many pyright users have requested finer-grained control over diagnostics — especially for diagnostics that were previously lumped under the catch-all rule reportGeneralTypeIssues. I was hesitant to do this because it is a breaking change and could be disruptive for some pyright users. However, the time has come to make this change.

The list of new diagnostic rules includes:

• reportAbstractUsage
• reportArgumentType
• reportAssertTypeFailure
• reportAssignmentType
• reportAttributeAccessIssue
• reportCallIssue
• reportInconsistentOverload
• reportIndexIssue
• reportInvalidTypeArguments
• reportInvalidTypeForm
• reportNoOverloadImplementation
• reportOperatorIssue
• reportPossiblyUnboundVariable
• reportRedeclaration
• reportReturnType
• reportUnusedExcept

Refer to the configuration documentation for more details about each of these.

This is a breaking change for code bases that were previously overriding the diagnostic severity for reportGeneralTypeIssues in the config file, in file-level pyright comments or in # type: ignore or # pyright: ignore comments. You will need to update your configuration settings and comments to use the new diagnostic rule names.

Bug Fixes:

• Fixed bug in pyright's "type printer" that resulted in an incorrect output when printing a specialized type alias parameterized by a TypeVarTuple that has a value that contains a tuple with an indeterminate length.
• Fixed a bug that resulted in an incorrect type evaluation when a generator uses an await operator within the left-most for. This shouldn't result in an AsyncGenerator despite what the Python documentation indicates.
• Fixed a bug in the isinstance type narrowing logic when type is filtered using a metaclass instance.
• Fixed recent regression that resulted in a crash when using certain language server features with an absolute extraPaths value.
• Fixed spec conformance issue with TypeVarTuple constraint solving. The spec indicates that if a TypeVarTuple is used multiple times in a callee's signature, the tuple must "match exactly".
• Addressed a bug that led to a false positive (missing error) when a "bare" TypeVar is used as a base class in a class statement.
• Fixed a bug that masked an error (false negative) under certain circumstances when evaluating a lambda.
• Fixed a bug that resulted in a false positive error and incorrect type evaluation when an assignment expression (walrus operator) is used in a comprehension.
• Changed diagnostic rule for the case where Callable is missing a second type argument. It should use reportMissingTypeArgument.
• Fixed a bug that led to a false negative when an illegal form of tuple was used: tuple[*tuple[str], ...].

Behavior Changes:

• Changed handling of tuple[Any, ...] so it is treated as though it's bidirectionally type compatible with all tuples regardless of length. This change is made in response to a clarification in the typing spec. It brings pyright in alignment with mypy's behavior in this regard.

Enhancements:

• Added check for name mismatch for enum classes defined using the functional syntax.
• Improved handling of custom Enum classes (those that derive from Enum or use EnumMeta).
• Added special-case logic for enum classes that are invoked as though they are being constructed.
• Added type enforcement for the _value_ type in an Enum class. Also added enforcement for custom __new__ and __init__ method signatures.
• Improved handling of Annotated and other special forms when they are used in runtime value expressions rather than annotations.
• Added error reporting for the situation where a generic instance variable is accessed through a class object.
• Updated typeshed stubs to the latest version.

Commits

• a168f42 Published 1.1.348
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[github-actions]

Following are the schema changes in the new version. Make sure that those are reflected in LSP-pyright.sublime-settings and sublime-package.json files.

No updates done to sublime-package.json.

[rchl]

Sorry for reverting this but it seemed like an over-engineering. The main benefit of generators is that the caller can break the loop at any point. In this case we're collecting and returning all keys so I don't see the point.
Even if performance doesn't matter here, I don't like over complicating things.