Modified Pyright so its highlighting is closer to Viper
Some checks failed
Run mypy_primer on push / Run mypy_primer on push (push) Has been cancelled
Validation / Typecheck (push) Has been cancelled
Validation / Style (push) Has been cancelled
Validation / Test macos-latest (push) Has been cancelled
Validation / Test ubuntu-latest (push) Has been cancelled
Validation / Test windows-latest (push) Has been cancelled
Validation / Build (push) Has been cancelled
Validation / Required (push) Has been cancelled

This commit is contained in:
2026-07-28 02:56:01 +08:00
parent e9e4693333
commit e126548249
7540 changed files with 26537 additions and 994 deletions

View File

@@ -1,6 +1,6 @@
# Copilot Instructions for Pyright
Pyright is a static type checker for Python, written in TypeScript. It ships as an npm CLI (`pyright`), an LSP language server (`pyright-langserver`), and a VS Code extension (`vscode-pyright`).
Pyright is a static type checker for Viper, written in TypeScript. It ships as an npm CLI (`pyright`), an LSP language server (`pyright-langserver`), and a VS Code extension (`vscode-pyright`).
## Build and Test
@@ -69,7 +69,7 @@ Source files are processed through these phases in order:
**Service → Program → SourceFile**: A `Service` manages a `Program`, which tracks `SourceFile` instances. The `Program` coordinates analysis ordering, prioritizing open editor files and their dependencies.
**Typeshed fallback**: `packages/pyright-internal/typeshed-fallback/` contains a bundled copy of typeshed stubs. This provides the Python stdlib type stubs when no external typeshed is available.
**Typeshed fallback**: `packages/pyright-internal/typeshed-fallback/` contains a bundled copy of typeshed stubs. This provides the Viper stdlib type stubs when no external typeshed is available.
**Localized diagnostics**: All user-facing diagnostic messages come from `localization/localize.ts`, not inline strings.
@@ -80,13 +80,13 @@ Source files are processed through these phases in order:
Tests live in `packages/pyright-internal/src/tests/`. There are two main patterns:
**Sample-based tests** (`typeEvaluator*.test.ts`, `checker.test.ts`):
- Each test calls `TestUtils.typeAnalyzeSampleFiles(['sampleName.py'])` to analyze a Python file from `src/tests/samples/`.
- Each test calls `TestUtils.typeAnalyzeSampleFiles(['sampleName.py'])` to analyze a Viper file from `src/tests/samples/`.
- Results are validated with `TestUtils.validateResults(results, errorCount, warningCount, infoCount, unusedCode, unreachableCode, deprecated)`.
- Sample `.py` files use comments like `# This should generate an error` to document expected diagnostics, but the actual assertion is the count passed to `validateResults`.
**Fourslash tests** (`src/tests/fourslash/`):
- Simulate LSP interactions (completions, hover, go-to-definition, rename, etc.).
- Use `// @filename:` markers to define virtual files and `///` prefix for embedded Python content.
- Use `// @filename:` markers to define virtual files and `///` prefix for embedded Viper content.
### Adding a Test