diff --git a/.github/ISSUE_TEMPLATE/bug_report.md b/.github/ISSUE_TEMPLATE/bug_report.md index 612921d4..c85d3e2c 100644 --- a/.github/ISSUE_TEMPLATE/bug_report.md +++ b/.github/ISSUE_TEMPLATE/bug_report.md @@ -9,7 +9,7 @@ assignees: '' Note: if you are reporting a wrong signature of a function or a class in the standard library, then the typeshed tracker is better suited for this report: https://github.com/python/typeshed/issues. -If you have a question about typing or a behavior that you’re seeing in Pyright (as opposed to a bug report or enhancement request), consider posting to the [Pyright discussion forum](https://github.com/microsoft/pyright/discussions). +If you have a question about typing or a behavior that you’re seeing in Vipeye (as opposed to a bug report or enhancement request), consider posting to the [Pyright discussion forum](https://github.com/microsoft/pyright/discussions). **Describe the bug** A clear and concise description of the behavior you are seeing and the expected behavior along with steps to reproduce it. @@ -25,4 +25,4 @@ def foo(self) -> str: If your code relies on symbols that are imported from a third-party library, include the associated import statements and specify which versions of those libraries you have installed. **VS Code extension or command-line** -Are you running pyright as a VS Code extension, a language server in another editor, integrated into Pylance, or the command-line tool? Which version? +Are you running vipeye as a VS Code extension, a language server in another editor, integrated into Pylance, or the command-line tool? Which version? diff --git a/.github/ISSUE_TEMPLATE/feature_request.md b/.github/ISSUE_TEMPLATE/feature_request.md index ace41034..e19a433f 100644 --- a/.github/ISSUE_TEMPLATE/feature_request.md +++ b/.github/ISSUE_TEMPLATE/feature_request.md @@ -7,7 +7,7 @@ assignees: '' --- -If you have a question about a behavior that you’re seeing in pyright, consider posting to the [Pyright discussion forum](https://github.com/microsoft/pyright/discussions). +If you have a question about a behavior that you’re seeing in vipeye, consider posting to the [Pyright discussion forum](https://github.com/microsoft/pyright/discussions). **Is your feature request related to a problem? Please describe.** A clear and concise description of the problem. diff --git a/.github/actions/cfs-npm-install/action.yml b/.github/actions/cfs-npm-install/action.yml index b846c295..1a9ee937 100644 --- a/.github/actions/cfs-npm-install/action.yml +++ b/.github/actions/cfs-npm-install/action.yml @@ -31,17 +31,17 @@ runs: - uses: ./.github/actions/cfs-npm-authenticate with: - working-directory: packages/pyright + working-directory: packages/vipeye token: ${{ steps.npm-auth.outputs.token }} - uses: ./.github/actions/cfs-npm-authenticate with: - working-directory: packages/pyright-internal + working-directory: packages/vipeye-internal token: ${{ steps.npm-auth.outputs.token }} - uses: ./.github/actions/cfs-npm-authenticate with: - working-directory: packages/vscode-pyright + working-directory: packages/vscode-vipeye token: ${{ steps.npm-auth.outputs.token }} - uses: ./.github/actions/cfs-npm-cache diff --git a/.github/agents/typeshed-update-agent.md b/.github/agents/typeshed-update-agent.md index 806a8fa3..94849d96 100644 --- a/.github/agents/typeshed-update-agent.md +++ b/.github/agents/typeshed-update-agent.md @@ -1,20 +1,20 @@ --- name: typeshed-update-agent -description: Updates Pyright bundled typeshed fallback and triages resulting test changes while preserving type precision. +description: Updates Vipeye bundled typeshed fallback and triages resulting test changes while preserving type precision. --- # Typeshed Update Agent -This agent updates the typeshed version used by Pyright and ensures tests remain correct and precise. +This agent updates the typeshed version used by Vipeye and ensures tests remain correct and precise. -The agent must follow the **Pyright Test Policy**. +The agent must follow the **Vipeye Test Policy**. --- # Phase 1 — Update Typeshed 1. Update the pinned typeshed commit or submodule. -2. Run the full Pyright test suite. +2. Run the full Vipeye test suite. 3. If all tests pass, create a PR titled: Update typeshed to @@ -25,7 +25,7 @@ Use the fork branch as the PR head if needed, and verify the reported PR URL is ## Running The Update Script -Use the repo script (from the Pyright repo root): +Use the repo script (from the Vipeye repo root): ```bash python build/updateTypeshed.py @@ -40,7 +40,7 @@ Notes: - The script clones `https://github.com/python/typeshed.git` into a temporary directory. - A local checkout of typeshed is not required to run the update. -- It updates `packages/pyright-internal/typeshed-fallback/` and writes the selected SHA to `packages/pyright-internal/typeshed-fallback/commit.txt`. +- It updates `packages/vipeye-internal/typeshed-fallback/` and writes the selected SHA to `packages/vipeye-internal/typeshed-fallback/commit.txt`. - Do not spend token budget reviewing or summarizing the full generated `typeshed-fallback` diff; it is expected to be large and noisy. Use the pinned SHA, upstream compare links, and targeted file inspection only when tests fail or a specific behavior change needs triage. ## Upstream Investigation Guidance @@ -51,7 +51,7 @@ When behavior changes are suspected, inspect upstream typeshed directly: - compare SHAs: `https://github.com/python/typeshed/compare/...` - specific PRs linked from changed files or commit history (for example dict constructor positional-only changes in `python/typeshed#15262`) -Always tie Pyright test changes to a concrete upstream typeshed commit or PR. +Always tie Vipeye test changes to a concrete upstream typeshed commit or PR. --- @@ -62,7 +62,7 @@ If tests fail, the agent must classify each failure. Possible categories: A) Legitimate typeshed behavior change -B) Pyright bug revealed by new stubs +B) Vipeye bug revealed by new stubs C) Test fragility (formatting / ordering) D) Test harness or environment issue @@ -107,11 +107,11 @@ Track changes including: Run these focused tests before full-suite reruns when related files change. - constructor callable and default constructor behavior: - - `cd packages/pyright-internal && npm run test:norebuild -- typeEvaluator6.test.ts -t "ConstructorCallable1|ConstructorCallable2|Constructor28" --runInBand` + - `cd packages/vipeye-internal && npm run test:norebuild -- typeEvaluator6.test.ts -t "ConstructorCallable1|ConstructorCallable2|Constructor28" --runInBand` - contextmanager / generator behavior: - - `cd packages/pyright-internal && npm run test:norebuild -- typeEvaluator2.test.ts -t Solver7 --runInBand` + - `cd packages/vipeye-internal && npm run test:norebuild -- typeEvaluator2.test.ts -t Solver7 --runInBand` - positional-only parameter behavior: - - `cd packages/pyright-internal && npm run test:norebuild -- typeEvaluator1.test.ts -t Call3 --runInBand` + - `cd packages/vipeye-internal && npm run test:norebuild -- typeEvaluator1.test.ts -t Call3 --runInBand` --- @@ -119,7 +119,7 @@ Run these focused tests before full-suite reruns when related files change. Preferred order: -1. Fix Pyright implementation +1. Fix Vipeye implementation 2. Patch incorrect typeshed stub 3. Update expected outputs (last resort) @@ -132,7 +132,7 @@ Test updates must follow the **Precision Regression Rule**. If type precision is reduced (e.g. `T → Unknown`): 1. Check whether a stub change caused the regression. -2. Attempt to restore precision via Pyright improvements. +2. Attempt to restore precision via Vipeye improvements. 3. If unavoidable, update tests **with justification**. A regression report must be added to the PR. @@ -140,7 +140,7 @@ A regression report must be added to the PR. ## Regression Guardrails - Do not accept `T -> Unknown` precision drops without root-cause analysis. -- Do not update reveal expectations until checking whether a Pyright implementation fix can preserve precision. +- Do not update reveal expectations until checking whether a Vipeye implementation fix can preserve precision. - If a reveal text changes due to upstream behavior, include the upstream commit/PR reference in the test update commit message or PR description. --- @@ -150,7 +150,7 @@ A regression report must be added to the PR. PR must include: - typeshed commit bump -- Pyright fixes if needed +- Vipeye fixes if needed - minimal test updates - precision regression report (if applicable) - explanation for each change @@ -164,7 +164,7 @@ Include the following sections in the PR description: - compare URL 2. Failure classification summary - categories A/B/C/D with counts -3. Pyright fixes +3. Vipeye fixes - files changed - behavior restored 4. Test updates @@ -182,7 +182,7 @@ Include the following sections in the PR description: Preferred commits: 1. typeshed update -2. pyright fixes +2. vipeye fixes 3. justified test updates Keeping these separate simplifies review. @@ -203,4 +203,4 @@ Escalate early when any of these occur: - constructor synthesis behavior changes in multiple unrelated samples - new failures in both evaluator and language service suites from one stub change -- uncertainty about whether a fix belongs in Pyright versus upstream typeshed +- uncertainty about whether a fix belongs in Vipeye versus upstream typeshed diff --git a/.github/agents/pyright-test-policy.md b/.github/agents/vipeye-test-policy.md similarity index 84% rename from .github/agents/pyright-test-policy.md rename to .github/agents/vipeye-test-policy.md index ee97c52e..1739c3f5 100644 --- a/.github/agents/pyright-test-policy.md +++ b/.github/agents/vipeye-test-policy.md @@ -1,11 +1,11 @@ --- -name: pyright-test-policy -description: Enforces Pyright test policy, preserving type precision and requiring justification for test changes. +name: vipeye-test-policy +description: Enforces Vipeye test policy, preserving type precision and requiring justification for test changes. --- -# Pyright Test Policy +# Vipeye Test Policy -Tests are the specification for Pyright behavior. +Tests are the specification for Vipeye behavior. Agents must **not modify tests simply to make CI pass**. @@ -18,7 +18,7 @@ The goal is to **preserve or improve type precision** unless a justified upstrea Agents may modify tests only when one of the following is true: 1. A **typeshed stub change** legitimately alters the expected type. -2. A **Pyright diagnostic message format** changed but the semantic meaning is the same. +2. A **Vipeye diagnostic message format** changed but the semantic meaning is the same. 3. A test relied on unstable formatting or ordering. --- @@ -49,11 +49,11 @@ These regressions are **allowed only with justification**. - or an upstream typing change 2. **Reasoning** - - why Pyright cannot infer the previous precision + - why Vipeye cannot infer the previous precision 3. **Classification** - A) typeshed became less precise - - B) Pyright limitation + - B) Vipeye limitation - C) test fragility - D) harness issue @@ -81,7 +81,7 @@ without the justification process above. Agents must attempt fixes in this order: -1. **Fix Pyright behavior** +1. **Fix Vipeye behavior** 2. **Fix incorrect typeshed stub** 3. **Adjust tests (last resort)** diff --git a/.github/copilot-instructions.md b/.github/copilot-instructions.md index 06807f48..c1f16257 100644 --- a/.github/copilot-instructions.md +++ b/.github/copilot-instructions.md @@ -1,6 +1,6 @@ -# Copilot Instructions for Pyright +# Copilot Instructions for Vipeye -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`). +Vipeye is a static type checker for Viper, written in TypeScript. It ships as an npm CLI (`vipeye`), an LSP language server (`vipeye-langserver`), and a VS Code extension (`vscode-vipeye`). ## Build and Test @@ -9,19 +9,19 @@ Pyright is a static type checker for Viper, written in TypeScript. It ships as a npm install # Build the core library -cd packages/pyright-internal && npm run build +cd packages/vipeye-internal && npm run build # Run all tests (builds test server first) -cd packages/pyright-internal && npm test +cd packages/vipeye-internal && npm test # Run all tests without rebuilding the test server (faster iteration) -cd packages/pyright-internal && npm run test:norebuild +cd packages/vipeye-internal && npm run test:norebuild # Run a single test file -cd packages/pyright-internal && npx jest typeEvaluator1.test --forceExit +cd packages/vipeye-internal && npx jest typeEvaluator1.test --forceExit # Run a single test by name -cd packages/pyright-internal && npx jest -t "Generic1" --forceExit +cd packages/vipeye-internal && npx jest -t "Generic1" --forceExit # Build the CLI (webpack bundle) npm run build:cli:dev @@ -49,9 +49,9 @@ npm run fix:prettier ### Package Structure -- **`packages/pyright-internal`** — Core library: parser, binder, type evaluator, checker, language service. All logic lives here. This is the only package with tests. -- **`packages/pyright`** — CLI wrapper. Webpack-bundles `pyright-internal` into a distributable npm package with `pyright` and `pyright-langserver` entry points. -- **`packages/vscode-pyright`** — VS Code extension client that communicates with the language server. +- **`packages/vipeye-internal`** — Core library: parser, binder, type evaluator, checker, language service. All logic lives here. This is the only package with tests. +- **`packages/vipeye`** — CLI wrapper. Webpack-bundles `vipeye-internal` into a distributable npm package with `vipeye` and `vipeye-langserver` entry points. +- **`packages/vscode-vipeye`** — VS Code extension client that communicates with the language server. ### Analysis Pipeline @@ -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 Viper stdlib type stubs when no external typeshed is available. +**Typeshed fallback**: `packages/vipeye-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. @@ -77,7 +77,7 @@ Source files are processed through these phases in order: ### Test Structure -Tests live in `packages/pyright-internal/src/tests/`. There are two main patterns: +Tests live in `packages/vipeye-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 Viper file from `src/tests/samples/`. @@ -96,7 +96,7 @@ Tests live in `packages/pyright-internal/src/tests/`. There are two main pattern ### Test Policy -Tests are the specification for Pyright behavior. Never modify tests just to make CI pass. Any change that makes types less precise (e.g., `T → Unknown`, `list[int] → list[Any]`, `Literal["x"] → str`) is a regression by default and requires explicit justification. See `.github/agents/pyright-test-policy.md` for details. +Tests are the specification for Vipeye behavior. Never modify tests just to make CI pass. Any change that makes types less precise (e.g., `T → Unknown`, `list[int] → list[Any]`, `Literal["x"] → str`) is a regression by default and requires explicit justification. See `.github/agents/vipeye-test-policy.md` for details. ## Code Style diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml index 92f327a0..77340a09 100644 --- a/.github/workflows/build.yml +++ b/.github/workflows/build.yml @@ -3,7 +3,7 @@ name: 'Build' env: NODE_VERSION: '22.x' # Shipped with VS Code. ARTIFACT_NAME_VSIX: vsix - VSIX_NAME: vscode-pyright.vsix + VSIX_NAME: vscode-vipeye.vsix on: push: @@ -12,7 +12,7 @@ on: jobs: build: - if: github.repository == 'microsoft/pyright' + if: github.repository == 'TermiNexus/Viper_VSCode' runs-on: ubuntu-latest name: Build @@ -32,18 +32,18 @@ jobs: - run: npm run install:all - name: Build VSIX - working-directory: packages/vscode-pyright + working-directory: packages/vscode-vipeye run: | npm run package - mv pyright-*.vsix ${{ env.VSIX_NAME }} + mv vipeye-*.vsix ${{ env.VSIX_NAME }} - uses: actions/upload-artifact@v4 with: name: ${{ env.ARTIFACT_NAME_VSIX }} - path: packages/vscode-pyright/${{ env.VSIX_NAME }} + path: packages/vscode-vipeye/${{ env.VSIX_NAME }} create_release: - if: github.repository == 'microsoft/pyright' + if: github.repository == 'TermiNexus/Viper_VSCode' runs-on: ubuntu-latest name: Create release needs: [build] diff --git a/.github/workflows/mypy_primer_pr.yaml b/.github/workflows/mypy_primer_pr.yaml index 5adc403b..4dd8569d 100644 --- a/.github/workflows/mypy_primer_pr.yaml +++ b/.github/workflows/mypy_primer_pr.yaml @@ -1,6 +1,6 @@ -# This workflow runs mypy_primer, a tool that runs pyright on a variety -# of open-source Python projects that are known to type check with pyright. -# It builds pyright from the latest PR commit and the merge base of the PR +# This workflow runs mypy_primer, a tool that runs vipeye on a variety +# of open-source Python projects that are known to type check with vipeye. +# It builds vipeye from the latest PR commit and the merge base of the PR # and compares the output of both. It uploads the diffs as an artifact and # creates a PR comment with the results (with the help of the # mypy_primer_comment action). @@ -8,8 +8,8 @@ # This workflow definition borrows liberally from the mypy repo. The original # workflow was designed to work in a sharded manner where n copies of # mypy_primer are started in parallel. Each instance runs 1/n of the projects. -# For now, we run only one instance because pyright is fast, and the number -# of projects that use pyright for type checking is small. To change this in +# For now, we run only one instance because vipeye is fast, and the number +# of projects that use vipeye for type checking is small. To change this in # the future, change the 'shard_index' matrix to [0, 1, ..., n-1] and set # 'num-shards' to n. @@ -22,9 +22,9 @@ on: # Run on the creation or update of a PR. pull_request: paths: - - 'packages/pyright/**' - - 'packages/pyright-internal/src/**' - - 'packages/pyright-internal/typeshed-fallback/**' + - 'packages/vipeye/**' + - 'packages/vipeye-internal/src/**' + - 'packages/vipeye-internal/typeshed-fallback/**' concurrency: group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }} diff --git a/.github/workflows/mypy_primer_push.yaml b/.github/workflows/mypy_primer_push.yaml index 0bbd491d..696d5bd8 100644 --- a/.github/workflows/mypy_primer_push.yaml +++ b/.github/workflows/mypy_primer_push.yaml @@ -1,6 +1,6 @@ -# This workflow runs mypy_primer, a tool that runs pyright on a variety -# of open-source Python projects that are known to type check with pyright. -# It builds pyright from the latest commit and the last release tag and +# This workflow runs mypy_primer, a tool that runs vipeye on a variety +# of open-source Python projects that are known to type check with vipeye. +# It builds vipeye from the latest commit and the last release tag and # compares the output of both. It uploads the diffs as an artifact. name: Run mypy_primer on push @@ -13,9 +13,9 @@ on: branches: - main paths: - - 'packages/pyright/**' - - 'packages/pyright-internal/src/**' - - 'packages/pyright-internal/typeshed-fallback/**' + - 'packages/vipeye/**' + - 'packages/vipeye-internal/src/**' + - 'packages/vipeye-internal/typeshed-fallback/**' # Also run manually if requested. workflow_dispatch: diff --git a/.github/workflows/validation.yml b/.github/workflows/validation.yml index dcdd0ab1..58bf5c65 100644 --- a/.github/workflows/validation.yml +++ b/.github/workflows/validation.yml @@ -14,7 +14,7 @@ on: jobs: typecheck: - if: github.repository == 'microsoft/pyright' + if: github.repository == 'TermiNexus/Viper_VSCode' runs-on: ubuntu-latest name: Typecheck @@ -34,7 +34,7 @@ jobs: - run: npx lerna exec --stream --no-bail -- "tsc --noEmit" style: - if: github.repository == 'microsoft/pyright' + if: github.repository == 'TermiNexus/Viper_VSCode' runs-on: ubuntu-latest name: Style @@ -79,9 +79,9 @@ jobs: - run: npm run install:all - - name: npm test (pyright-internal) + - name: npm test (vipeye-internal) run: npm test - working-directory: packages/pyright-internal + working-directory: packages/vipeye-internal # Install python so we can create a VENV for tests - name: Use Python ${{env.PYTHON_VERSION}} @@ -117,13 +117,13 @@ jobs: CI_IMPORT_TEST_VENVPATH: '../../' CI_IMPORT_TEST_VENV: '.venv' run: npm run test:imports - working-directory: packages/pyright-internal + working-directory: packages/vipeye-internal - name: Run import tests with pythonpath env: CI_IMPORT_TEST_PYTHONPATH: ${{env.python_venv_path}} run: npm run test:imports - working-directory: packages/pyright-internal + working-directory: packages/vipeye-internal build: runs-on: ubuntu-latest @@ -145,13 +145,13 @@ jobs: - uses: ./.github/actions/choose-npm-install - run: npm publish --dry-run - working-directory: packages/pyright + working-directory: packages/vipeye - run: npm publish --dry-run - working-directory: packages/pyright-typeserver + working-directory: packages/vipeye-typeserver - run: npm run package - working-directory: packages/vscode-pyright + working-directory: packages/vscode-vipeye required: runs-on: ubuntu-latest diff --git a/.gitignore b/.gitignore index 40e354cb..21ddb179 100644 --- a/.gitignore +++ b/.gitignore @@ -133,7 +133,7 @@ serena/ AGENTS.md # Generated benchmark output -packages/pyright-internal/src/tests/benchmarks/.generated/ +packages/vipeye-internal/src/tests/benchmarks/.generated/ # perfCompare.py cached commit bundles /build/perfCompare/ diff --git a/.vscodeignore b/.vscodeignore index 3c726a37..5a445427 100644 --- a/.vscodeignore +++ b/.vscodeignore @@ -142,7 +142,7 @@ serena/ AGENTS.md # Generated benchmark output -packages/pyright-internal/src/tests/benchmarks/.generated/ +packages/vipeye-internal/src/tests/benchmarks/.generated/ # perfCompare.py cached commit bundles /build/perfCompare/ diff --git a/1.vp b/1.vp new file mode 100644 index 00000000..d9f882d1 --- /dev/null +++ b/1.vp @@ -0,0 +1,10 @@ +import stdio +import t, c + + +def add(a: int, b: int) -> int: + return a + b + +def main() -> int: + stdio.printf("Hello, World!") + return 0 \ No newline at end of file diff --git a/LICENSE.txt b/LICENSE.txt index 0c537977..12c0e798 100644 --- a/LICENSE.txt +++ b/LICENSE.txt @@ -1,6 +1,6 @@ MIT License -Pyright - A static type checker for the Python language +Vipeye - A static type checker for the Viper language Copyright (c) Microsoft Corporation. All rights reserved. Permission is hereby granted, free of charge, to any person obtaining a copy diff --git a/README.md b/README.md index 3d7a7826..f6c601e5 100644 --- a/README.md +++ b/README.md @@ -1,41 +1,42 @@ -![Pyright](https://github.com/microsoft/pyright/blob/main/docs/img/PyrightLarge.png) +![Vipeye](docs/img/PyrightLarge.png) # Static Type Checker for Viper -Pyright is a full-featured, standards-based static type checker for Viper. It is designed for high performance and can be used with large Viper source bases. +Vipeye is a full-featured, standards-based static type checker for Viper, written in TypeScript. It is designed for high performance and can be used with large Viper source bases. -Pyright includes both a [command-line tool](https://microsoft.github.io/pyright/#/command-line) and an [extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=ms-pyright.pyright). +Vipeye includes both a [command-line tool](docs/command-line.md) and an [extension for Visual Studio Code](packages/vscode-vipeye). It is built on the Pyright codebase, adapted from the ground up to Viper semantics (AOT compilation, C-style types, pointer and memory semantics), and no longer type-checks Python. +## Packages -## Pyright Playground +- **`packages/vipeye-internal`** — Core analysis engine: parser, binder, type evaluator, checker, and language service. All logic lives here. +- **`packages/vipeye`** — CLI wrapper. Bundles `vipeye-internal` into a distributable npm package with `vipeye` and `vipeye-langserver` entry points. +- **`packages/vipeye-typeserver`** — Type server process for long-running editor sessions. +- **`packages/vscode-vipeye`** — VS Code extension client (Vipeye LSP), with the Viper core source (`packages/viper`) bundled at build time. +- **`packages/viper`** — Viper core source library: project (`.vpj`) management, toolchain, and the activity bar UI (Project / Toolchain / Settings). -Try Pyright in your browser using the [Pyright Playground](https://pyright-play.net/?code=MQAgKgFglgziMEMC2AHANgUxAEw0g9gHYwAuATgiRnBPgO4gDG%2BSBhIGZZ%2BZcjC7AEZZcVRlWzwSlKPzRoAniEFKUCslADmEEgDoAUPtwAzEAmzYAFAA8AXCGNp8lADQgF9x85IBKW-pBAkDIMEgBXMnZrEABqd0NQAAUEGBgoQk0zKTIQdNIBRiwUkBIILBgMZkJJBDJNMKQMQhJg6jC0Ejh0rLIw5qhGjmtClBIoIgNzKwBGNwAiOZ99IA). +## Key Differences from Pyright +- Viper dialect: `viperconfig.json` instead of `pyrightconfig.json`; config namespace `viper.*`. +- Viper stdlib stubs bundled in `vipeye-internal/vipershed-fallback`. +- Type semantics follow Viper rules: implicit conversions, pointer (`CPtr`/`CArray`), `t.CTypedef`/`t.CDefine`/`t.CEnum`, `T | t.CPtr` pointer folding, global-variable access rules, and more. +- Semantic highlighting and diagnostics are tailored to Viper syntax. + +## Building and Testing + +See [docs/build-debug.md](docs/build-debug.md). ## Documentation -Refer to [the documentation](https://microsoft.github.io/pyright) for installation, configuration, and usage details. - +Refer to [the documentation](docs/README.md) for installation, configuration, and usage details. ## Environment variables -If Pyright fails to create a temporary directory (for example in remote/server environments where the OS temp directory doesn't exist or isn't writable), you can override the temp directory root: +If Vipeye fails to create a temporary directory (for example in remote/server environments where the OS temp directory doesn't exist or isn't writable), you can override the temp directory root: -- `PYRIGHT_TMPDIR`: Absolute path to a directory that Pyright can use for temporary files/directories. Pyright will create it if needed. +- `VIPEYE_TMPDIR`: Absolute path to a directory that Vipeye can use for temporary files/directories. Vipeye will create it if needed. -Pyright otherwise relies on the platform temp directory (for example `TMPDIR`, `TMP`, `TEMP`, or the OS default). +Vipeye otherwise relies on the platform temp directory (for example `TMPDIR`, `TMP`, `TEMP`, or the OS default). +## License -## Community -Do you have questions about Pyright or Viper type annotations in general? Post your questions in [the discussion section](https://github.com/microsoft/pyright/discussions). - -If you would like to report a bug or request an enhancement, file a new issue in either the [pyright](https://github.com/microsoft/pyright/issues) or [pylance-release](https://github.com/microsoft/pylance-release/issues) issue tracker. In general, core type checking functionality is associated with Pyright while language service functionality is associated with Pylance, but the same contributors monitor both repos. For best results, provide the information requested in the issue template. - - -## Contributing - -This project welcomes contributions and suggestions. For feature and complex bug fix contributions, it is recommended that you first discuss the proposed change with Pyright’s maintainers before submitting the pull request. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.microsoft.com. - -When you submit a pull request, a CLA-bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., label, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA. - -This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments. +MIT diff --git a/Test/.vscode/settings.json b/Test/.vscode/settings.json deleted file mode 100644 index 3a4ff489..00000000 --- a/Test/.vscode/settings.json +++ /dev/null @@ -1,7 +0,0 @@ -{ - "viper.analysis.extraPaths": [ - "D:\\Users\\TermiNexus\\Desktop\\TransPyC\\includes" - ], - "viper.analysis.include": ["Test"], - "viper.analysis.diagnosticMode": "openFilesOnly" -} \ No newline at end of file diff --git a/Test/1.py b/Test/1.py deleted file mode 100644 index e69de29b..00000000 diff --git a/Test/Kernel/bootinfo.vp b/Test/Kernel/bootinfo.vp deleted file mode 100644 index 93546a6d..00000000 --- a/Test/Kernel/bootinfo.vp +++ /dev/null @@ -1,36 +0,0 @@ -import t, c - - -MEMORY_TYPE_AVAILABLE: t.CUInt64T = 7 -MEMORY_TYPE_RESERVED: t.CUInt64T = 0 -MEMORY_TYPE_LOADER_CODE: t.CUInt64T = 1 -MEMORY_TYPE_LOADER_DATA: t.CUInt64T = 2 -MEMORY_TYPE_BOOT_SERVICES_CODE: t.CUInt64T = 3 -MEMORY_TYPE_BOOT_SERVICES_DATA: t.CUInt64T = 4 -MEMORY_TYPE_RUNTIME_SERVICES_CODE: t.CUInt64T = 5 -MEMORY_TYPE_RUNTIME_SERVICES_DATA: t.CUInt64T = 6 -MEMORY_TYPE_ACPI_RECLAIMABLE: t.CUInt64T = 9 -MEMORY_TYPE_ACPI_NVS: t.CUInt64T = 10 -MEMORY_TYPE_BAD_MEMORY: t.CUInt64T = 8 - -@c.Attribute(t.attr.packed) -class memory_map_entry: - type: t.CUnsignedInt - _pad: t.CUnsignedInt - physical_start: t.CUnsignedLong - virtual_start: t.CUnsignedLong - num_pages: t.CUnsignedLong - attribute: t.CUnsignedLong - -class bootinfo: - MemmapAddr: t.CUnsignedLong - MemmapSize: t.CUnsignedLong - MemmapDescSize: t.CUnsignedLong - kernel_PhysAddr: t.CUnsignedLong - framebuffer_addr: t.CUnsignedLong - framebuffer_size: t.CUnsignedLong - framebuffer_width: t.CUnsignedLong - framebuffer_height: t.CUnsignedLong - framebuffer_pitch: t.CUnsignedLong - framebuffer_format: t.CUnsignedLong - system_table: t.CUnsignedLong diff --git a/Test/Kernel/main.vp b/Test/Kernel/main.vp deleted file mode 100644 index 5391149f..00000000 --- a/Test/Kernel/main.vp +++ /dev/null @@ -1,346 +0,0 @@ -from stdint import * -import bootinfo -import intr -import platform.pch as pch -import platform.pch.timer as timer -import platform.pch.rtc as rtc -import drivers.serial.uart.su8250 as su8250 -import drivers.serial.uart.serial as serial -import drivers.devfs.devfs as devfs -import paging.paging as paging -import drivers.video.vesafb.vga as vga -import drivers.video.vesafb.gfx as gfx -import drivers.storage.ide.ide as ide -import drivers.fs.fat32.fat32 as fat32 -import drivers.fs.fat32.fat32_types as fat32_types -import mm.mm as mm -import string -import sched.sched as sched -import sched.process as proc -import drivers.input.keyboard.keyboard as keyboard -import drivers.input.mouse.mouse as mouse -import drivers.usb.usb as usb -import drivers.core.cpu.cpu as cpu -import drivers.core.cpu.apic as apic -import viperlib -import services.keyboard as kbd_svc -import services.mouse as mse_svc -import services.desktop as desktop -import intr.syscall as syscall -import execrunner.elf as elf -import t, c -import asm - -kbd_tid: t.CInt = -1 -mse_tid: t.CInt = -1 - -BootInfo: bootinfo.bootinfo | t.CPtr - -@t.Object -# @t.CVTable -class ViperKernel: - BootInfo: bootinfo.bootinfo | t.CPtr - VGA: vga._VGAScreenDriver | t.CPtr - VGA_drv: vga._VGAScreenDriver - - def __init__(self): - global BootInfo - self.BootInfo = BootInfo - BootInfo: bootinfo.bootinfo | t.CPtr = self.BootInfo - serial.init() - serial.puts("===== ViperOS VKernel Test\n =====") - serial.puts("V2.3.8\n") - - intr.gdt.init() - # Set IA32_KERNEL_GS_BASE = &_per_cpu so swapgs in ISR/syscall works. - # _CPUObject is never instantiated, so __init_tss__ never runs; - # without this, GS base stays 0 and gs:[0] writes hit null -> triple fault. - cpu.msr_write(cpu.IA32_KERNEL_GS_BASE, t.CUInt64T(c.Addr(cpu._per_cpu))) - serial.puts("[main] gdt init done\n") - intr.idt.init() - syscall.init() - serial.puts("[main] syscall init done\n") - - # 必须在 sti() 之前初始化调度器，否则中断触发时 _sched_ptr 为 NULL 会导致三重故障 - sched.Scheduler() - serial.puts("[main] sched init done\n") - - timer.timer_init() - serial.puts("[main] timer init done\n") - - #mouse.init() - #serial.puts("[main] mouse init done\n") - - #apic.early_init() - #serial.puts("[main] apic init done\n") - - asm.sti() - serial.puts("[main] sti done\n") - - timer.timer_msleep(100) - serial.puts("[main] msleep done\n") - rtc.rtc_init() - serial.puts("[main] rtc init done\n") - ncpu: t.CUInt32T = apic.get_cpu_count() - ncpu_cr: t.CArray[t.CChar, 32] - viperlib.snprintf(c.Addr(ncpu_cr), 32, "[main] cpu_count=%u\n", ncpu) - serial.puts(ncpu_cr) - if ncpu > 1: - apic.start_aps() - serial.puts("[main] kernel init done\n") - - fb: t.CVoid | t.CPtr = BootInfo.framebuffer_addr - width: t.CUInt64T = BootInfo.framebuffer_width - height: t.CUInt64T = BootInfo.framebuffer_height - pitch: t.CUInt64T = BootInfo.framebuffer_pitch - fb_format: t.CUInt64T = BootInfo.framebuffer_format - fb_size: t.CUInt64T = BootInfo.framebuffer_size - if BootInfo is not None: - paging.init(BootInfo.MemmapAddr, BootInfo.MemmapSize) - fb_pages: t.CUInt64T = (fb_size + t.CUInt64T(0xFFF)) >> t.CUInt64T(12) - fpi: t.CUInt64T = 0 - while fpi < fb_pages: - fva: t.CUInt64T = t.CUInt64T(fb) + fpi * t.CUInt64T(0x1000) - paging.MapPage(fva, fva, paging.PTE_WRITABLE | paging.PTE_PCD) - fpi += 1 - mm.init(BootInfo.MemmapAddr, BootInfo.MemmapSize, BootInfo.MemmapDescSize, BootInfo.framebuffer_addr, fb_size) - pt_pool_buf: t.CVoid | t.CPtr = mm.malloc(t.CUInt64T(513) * t.CUInt64T(4096)) - paging.init_pool(pt_pool_buf, t.CUInt64T(513) * t.CUInt64T(4096)) - else: - paging.init(0, 0) - mm.init(0, 0, 0, 0, 0) - pt_pool_buf2: t.CVoid | t.CPtr = mm.malloc(t.CUInt64T(513) * t.CUInt64T(4096)) - paging.init_pool(pt_pool_buf2, t.CUInt64T(513) * t.CUInt64T(4096)) - serial.puts("[main] paging and mm init done\n") - - proc.ProcessManager() - serial.puts("[main] process manager init done\n") - - ide.init() - serial.puts("[main] ide init done\n") - - serial.puts("[main] initializing FAT32 filesystem\n") - scan_res: t.CInt = fat32.scan_drives() - ndrives: t.CInt = fat32.get_drive_count() - ndrives_cr: t.CArray[t.CChar, 64] - viperlib.snprintf(c.Addr(ndrives_cr), 64, "[fat32] scan_res=%d found %d drives\n", scan_res, ndrives) - serial.puts(ndrives_cr) - - if ndrives > 0: - mount_res: t.CInt = fat32.mount() - if mount_res == 0: - dp: fat32_types.dirobj - res: t.CInt = fat32.opendir("/", c.Addr(dp)) - if res == 0: - serial.puts("[fat32] listing 0:/\n") - count: t.CInt = 0 - while count < 20: - info: fat32_types.fileinfo - res2: t.CInt = fat32.readdir(c.Addr(dp), c.Addr(info)) - if res2 != 0: break - if info.fname[0] == 0: break - is_dir: t.CInt = 1 if (info.attr & fat32_types.AM_DIR) else 0 - entry_cr: t.CArray[t.CChar, 300] - viperlib.snprintf(c.Addr(entry_cr), 300, " %s size=%lu dir=%d\n", c.Addr(info.fname[0]), info.file_size, is_dir) - serial.puts(entry_cr) - count = count + 1 - fat32.closedir(c.Addr(dp)) - serial.puts("[fat32] directory listing done\n") - else: - serial.puts("[fat32] failed to open root directory\n") - - # Load ELF apps BEFORE running destructive FAT32 tests - serial.puts("[main] loading ELF apps...\n") - dp_apps: fat32_types.dirobj - apps_res: t.CInt = fat32.opendir("/APPS", c.Addr(dp_apps)) - if apps_res == 0: - serial.puts("[main] APPS dir listing:\n") - ac: t.CInt = 0 - while ac < 20: - ai: fat32_types.fileinfo - ar: t.CInt = fat32.readdir(c.Addr(dp_apps), c.Addr(ai)) - if ar != 0: break - if ai.fname[0] == 0: break - ae: t.CArray[t.CChar, 300] - viperlib.snprintf(c.Addr(ae), 300, " %s size=%lu\n", c.Addr(ai.fname[0]), ai.file_size) - serial.puts(ae) - ac = ac + 1 - fat32.closedir(c.Addr(dp_apps)) - else: - serial.puts("[main] APPS dir not found\n") - - sched.Scheduler.disable() - hello_pid: t.CInt = elf.spawn_elf("/APPS/hello.elf") - if hello_pid < 0: - serial.puts("[main] Hello spawn failed\n") - else: - slog: t.CArray[t.CChar, 64] - viperlib.snprintf(c.Addr(slog), 64, "[main] Hello spawned as pid=%d\n", hello_pid) - serial.puts(slog) - term_pid: t.CInt = elf.spawn_elf("/APPS/terminal.elf") - if term_pid < 0: - serial.puts("[main] Terminal spawn failed\n") - else: - tlog: t.CArray[t.CChar, 64] - viperlib.snprintf(c.Addr(tlog), 64, "[main] Terminal spawned as pid=%d\n", term_pid) - serial.puts(tlog) - - garg_pid: t.CInt = elf.spawn_elf("/APPS/gargantua.elf") - if garg_pid < 0: - serial.puts("[main] Gargantua spawn failed\n") - else: - glog: t.CArray[t.CChar, 64] - viperlib.snprintf(c.Addr(glog), 64, "[main] Gargantua spawned as pid=%d\n", garg_pid) - serial.puts(glog) - - s3d_pid: t.CInt = elf.spawn_elf("/APPS/scene3d.elf") - if s3d_pid < 0: - serial.puts("[main] Scene3D spawn failed\n") - else: - s3d_log: t.CArray[t.CChar, 64] - viperlib.snprintf(c.Addr(s3d_log), 64, "[main] Scene3D spawned as pid=%d\n", s3d_pid) - serial.puts(s3d_log) - - so_base: t.CVoid | t.CPtr = elf.load_so("/LIBS/SLOG.SO") - if so_base is not None: - serial.puts("[main] slog.so loaded, calling log_info...\n") - log_info_fn: t.CVoid | t.CPtr = elf.get_so_symbol(so_base, "log_info", "/LIBS/SLOG.SO") - if log_info_fn is not None: - msg: t.CConst | t.CChar | t.CPtr = "Hello from shared library!" - c.Asm(f"""mov rdi, {c.AsmInp(msg, t.ASM_DESCR.REG_ANY)} - call {c.AsmInp(log_info_fn, t.ASM_DESCR.REG_ANY)}""", - op=[t.ASM_DESCR.CLOBBER_MEMORY, t.ASM_DESCR.CLOBBER_RAX, - t.ASM_DESCR.CLOBBER_RCX, t.ASM_DESCR.CLOBBER_RDX, - t.ASM_DESCR.CLOBBER_RDI, t.ASM_DESCR.CLOBBER_RSI, - t.ASM_DESCR.CLOBBER_R8, t.ASM_DESCR.CLOBBER_R9, - t.ASM_DESCR.CLOBBER_R10, t.ASM_DESCR.CLOBBER_R11]) - else: - serial.puts("[main] log_info symbol not found\n") - else: - serial.puts("[main] failed to load slog.so\n") - sched.Scheduler.enable() - - # FAT32 destructive tests removed to prevent disk.img corruption - # (write/rename/delete/mkdir/rmdir permanently modify the disk image) - - fat32.unmount() - serial.puts("[fat32] unmounted\n") - else: - serial.puts("[fat32] mount failed\n") - else: - serial.puts("[fat32] no drives found\n") - - devfs.devfs_init() - devfs.devfs_register_serial0() - devfs.devfs_register_serial1() - devfs.devfs_register_keyboard() - devfs.devfs_register_mouse() - - serial.puts("[main] sched started\n") - - fd: t.CInt = devfs.devfs_open("/dev/serial0", 0) - buf: t.CArray[t.CChar, 64] - string.memset(c.Addr(buf), 0, 64) - devfs.devfs_write(fd, "hello from devfs!", 17) - devfs.devfs_read(fd, c.Addr(buf), 64) - devfs.devfs_close(fd) - - cr: t.CArray[t.CChar, 30] - string.memset(c.Addr(cr), 0, 30) - viperlib.snprintf(c.Addr(cr), 30, "hello %d %.2f", 42, float(0.24)) - serial.puts(cr) - serial.puts("\n") - - bootinfo_cr: t.CArray[t.CChar, 256] - string.memset(c.Addr(bootinfo_cr), 0, 256) - viperlib.snprintf(c.Addr(bootinfo_cr), 256, "Bootinfo 0x%016lx %lu %lu %lu %lu %lu map 0x%lx+%lu descsize=%lu", - BootInfo.framebuffer_addr, - BootInfo.framebuffer_format, - BootInfo.framebuffer_width, - BootInfo.framebuffer_height, - BootInfo.framebuffer_pitch, - BootInfo.framebuffer_size, - BootInfo.MemmapAddr, - BootInfo.MemmapSize, - BootInfo.MemmapDescSize) - serial.puts(bootinfo_cr) - serial.puts("\n") - - a: t.CConst | str = "Hello" - serial.putchar(a[4]) # o - serial.puts("\n") - d: t.CConst | int = 42 - b: t.CConst | int | t.CPtr = c.Addr(d) - string.memset(c.Addr(cr), 0, 4) - viperlib.snprintf(c.Addr(cr), 30, "%d", b[0]) # 42 - serial.puts(cr) - serial.puts("\n") - - # paging and mm already initialized before FAT32 - - usb.init() - - serial.puts("[main] starting keyboard service\n") - kbd_svc.start() - serial.puts("[main] starting mouse service\n") - mse_svc.start() - serial.puts("[main] services started\n") - - self.VGA_drv = vga._VGAScreenDriver(fb, width, height, pitch, fb_format) - self.VGA = c.Addr(self.VGA_drv) - self.VGA.Print(100, 100, "ViperOS VKernel Test") - serial.puts("你好\n") - - serial.puts("[main] starting desktop\n") - desktop.start(fb, width, height, pitch) - serial.puts("[main] desktop started\n") - - # ELF apps already loaded before FAT32 tests - - serial.puts("[main] entering main loop\n") - # sched.sched_dump() - last_sec: t.CUInt32T = 0 - loop_cnt: t.CUInt32T = 0 - while True: - cur_sec: t.CUInt32T = timer.timer_get_seconds() - if cur_sec != last_sec: - last_sec = cur_sec - #if cur_sec % 5 == 0: - # sched.sched_dump() - loop_cnt += 1 - sched.Scheduler._yield() - #while True: - # cube.RenderScene(back_fb, cube.SCREEN_W, cube.SCREEN_H, time) - # string.memcpy(fb, back_fb, width * height * 4) - # serial.puts("time") - # time += float(0.1) - - # circle(width / 2, height / 2, 180, fb) - # circle(640, 400, 180, 0xFFFFFFFF) - - # X 字符串遍历 - # c.Cast 更换 - # 时钟 - # PCI - # SHA1 它者文件更新 - # assets - # X attributes语法和谐 - # 合成式类型转换 - - -VKP: ViperKernel | t.CPtr -@c.Attribute(t.attr.section(".text.startup"), t.attr.aligned(16)) -def _start() -> t.CInt: - global VKP, BootInfo - saved_rdi: t.CUnsignedLong - c.Asm(f"mov {c.AsmOut(saved_rdi, t.ASM_DESCR.OUTPUT_REG)}, rdi", - op = [t.ASM_DESCR.CLOBBER_MEMORY, t.ASM_DESCR.CLOBBER_RDI]) - asm.BSSClean() - BootInfo = saved_rdi # 隐式转为 bootinfo* - VKP = c.Addr(ViperKernel()) - while True: - asm.sti() - asm.hlt() - sched.Scheduler._yield() - return 0 - diff --git a/Test/Kernel/test_forward_ref.vp b/Test/Kernel/test_forward_ref.vp deleted file mode 100644 index a7360576..00000000 --- a/Test/Kernel/test_forward_ref.vp +++ /dev/null @@ -1,16 +0,0 @@ -# 测试字符串注解（前向引用）的循环依赖支持 -# 期望：k: 'a' 能正确解析为类 a 自身类型 - -class a: - k: 'a' # 字符串注解，引用类自身（循环依赖） - next: 'a | None' # 字符串注解中的类型组合 - -class Node: - value: int - next: 'Node' # 链表节点的循环引用 - -# 测试：实例化后访问字段 -def test() -> int: - n: Node = Node() - n.value = 42 - return n.value diff --git a/Test/isr.ver b/Test/isr.ver deleted file mode 100644 index 867a04b4..00000000 --- a/Test/isr.ver +++ /dev/null @@ -1,24 +0,0 @@ -{ - global: - isr0_handler; - isr1_handler; - isr2_handler; - isr3_handler; - isr4_handler; - isr5_handler; - isr6_handler; - isr7_handler; - isr8_handler; - isr9_handler; - isr10_handler; - isr11_handler; - isr12_handler; - isr13_handler; - isr14_handler; - isr15_handler; - isr16_handler; - isr17_handler; - isr18_handler; - isr19_handler; - local: *; -}; diff --git a/Test/linker.ld b/Test/linker.ld deleted file mode 100644 index 9ad68793..00000000 --- a/Test/linker.ld +++ /dev/null @@ -1,39 +0,0 @@ -ENTRY(_start) - -SECTIONS { - . = 0x100000; - - .text : { - *(.text.startup) - *(.text) - *(.text.*) - } - - .rodata : { - *(.rodata) - *(.rodata.*) - } - - .data : { - *(.data) - *(.data.*) - } - - .bss : { - __bss_start = .; - *(.bss) - *(.bss.*) - *(COMMON) - __bss_end = .; - } - - /DISCARD/ : { - *(.comment) - *(.note) - *(.eh_frame) - *(.eh_frame_hdr) - *(.reloc) - *(.rela) - *(.debug*) - } -} diff --git a/Test/project.vpj b/Test/project.vpj deleted file mode 100644 index 7ee45662..00000000 --- a/Test/project.vpj +++ /dev/null @@ -1,30 +0,0 @@ -{ - "name": "Kernel", - "version": "1.0.0", - "source_dir": "./Kernel", - "build_dir": "./.tpv_build", - "compiler": { - "cmd": "llc", - "flags": ["-filetype=obj", "-mtriple=x86_64-none-elf", "-relocation-model=static", "-O2"] - }, - "linker": { - "cmd": "ld.lld.exe", - "flags": [ - "-m", "elf_x86_64", - "-T", "linker.ld", - "--oformat", "binary", - "--strip-all" - ], - "output": "kernel.bin" - }, - "includes": ["../../TransPyC/includes"], - "target": { - "triple": "x86_64-none-elf", - "datalayout": "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" - }, - "options": { - "slice_level": 3, - "target": "llvm", - "strict_mode": true - } -} diff --git a/_edit_float.py b/_edit_float.py deleted file mode 100644 index 08926bb4..00000000 --- a/_edit_float.py +++ /dev/null @@ -1,29 +0,0 @@ -path = r'd:\Users\TermiNexus\Desktop\Viper_VSCode\packages\vipeye-internal\src\analyzer\types.ts' -with open(path, 'r', encoding='utf-8') as f: - text = f.read() - -old1 = ( - "// Viper \u6269\u5c55\uff1aViper C \u6d6e\u70b9\u7c7b\u578b\u540d\u79f0\u767d\u540d\u5355\u3002\n" - "const _viperCFloatTypeNames = new Set([\n" - " 'CFloat', 'CDouble', 'CFloat8T', 'CFloat16T', 'CFloat32T', 'CFloat64T', 'CFloat128T',\n" - "]);\n" -) - -new1 = old1 + ( - "\n" - "// Viper \u6269\u5c55\uff1a\u5224\u65ad\u7c7b\u578b\u540d\u662f\u5426\u4e3a Viper C \u6d6e\u70b9\u7c7b\u578b\u3002\n" - "// \u7528\u4e8e\u534f\u8bae\u5339\u914d\u7b49\u573a\u666f\uff0c\u8ba9 CType \u6d6e\u70b9\u5b50\u7c7b\u6ee1\u8db3 SupportsFloat \u7b49\u6570\u503c\u534f\u8bae\u3002\n" - "export function isViperCFloatTypeName(name: string): boolean {\n" - " return _viperCFloatTypeNames.has(name);\n" - "}\n" -) - -c1 = text.count(old1) -print('Edit1 match count:', c1) -assert c1 == 1, f'Edit1 match count: {c1}' -text = text.replace(old1, new1) - -with open(path, 'w', encoding='utf-8') as f: - f.write(text) - -print('isViperCFloatTypeName function added.') diff --git a/ai.py b/ai.py new file mode 100644 index 00000000..e43d1248 --- /dev/null +++ b/ai.py @@ -0,0 +1,18 @@ +from openai import OpenAI + +# 指向本地Ollama服务，不是OpenAI官网 +client = OpenAI( + base_url="http://127.0.0.1:11434/v1", + api_key="dummy" # 本地模式key无校验，随便填写占位字符串 +) + +resp = client.chat.completions.create( + model="qwen3.5:4b", + messages=[ + {"role":"user","content":"你好"} + ], + max_tokens=1024, + temperature=0.7 +) + +print(resp.choices[0].message.content) \ No newline at end of file diff --git a/build/azuredevops/azure-pipelines-release.yml b/build/azuredevops/azure-pipelines-release.yml index b23ee4fe..46a394e5 100644 --- a/build/azuredevops/azure-pipelines-release.yml +++ b/build/azuredevops/azure-pipelines-release.yml @@ -10,15 +10,15 @@ resources: ref: refs/tags/release variables: - name: TeamName - value: Pyright + value: Vipeye - name: VSIX_NAME - value: vscode-pyright.vsix + value: vscode-vipeye.vsix - name: ARTIFACT_NAME_VSIX value: vsix - name: PACKAGE_NAME - value: pyright.tgz + value: vipeye.tgz - name: ARTIFACT_NAME_PACKAGE - value: pyright + value: vipeye - name: AZURE_ARTIFACTS_FEED value: 'https://devdiv.pkgs.visualstudio.com/DevDiv/_packaging/Pylance_PublicPackages/npm/registry/' @@ -28,11 +28,11 @@ extends: sdl: codeSignValidation: enabled: true - additionalTargetsGlobPattern: -|**/gdn-vscode-pyright.vsix/** + additionalTargetsGlobPattern: -|**/gdn-vscode-vipeye.vsix/** codeql: compiled: enabled: false - justificationForDisabling: 'Running a scan on the Pyright-Build azure-pipelines.yml' + justificationForDisabling: 'Running a scan on the Vipeye-Build azure-pipelines.yml' sourceAnalysisPool: VSEngSS-MicroBuild2022-1ES pool: name: AzurePipelines-EO @@ -81,19 +81,19 @@ extends: inputs: script: | npm run package - workingDirectory: packages/vscode-pyright + workingDirectory: packages/vscode-vipeye - task: PowerShell@2 inputs: targetType: 'inline' - script: 'Move-Item -Path "pyright-*.vsix" -Destination "$(VSIX_NAME)"' - workingDirectory: packages/vscode-pyright + script: 'Move-Item -Path "vipeye-*.vsix" -Destination "$(VSIX_NAME)"' + workingDirectory: packages/vscode-vipeye displayName: 'Move VSIX file' - task: CopyFiles@2 displayName: 'Copy vsix to: build_output' inputs: - SourceFolder: packages/vscode-pyright + SourceFolder: packages/vscode-vipeye Contents: '$(VSIX_NAME)' TargetFolder: build_output @@ -103,7 +103,7 @@ extends: - script: npx vsce generate-manifest -i $(VSIX_NAME) -o extension.manifest displayName: 'Generate extension manifest' - workingDirectory: packages/vscode-pyright + workingDirectory: packages/vscode-vipeye - task: NuGetToolInstaller@1 displayName: 'Install NuGet' @@ -111,13 +111,13 @@ extends: - task: NuGetCommand@2 inputs: command: 'restore' - restoreSolution: '$(Build.SourcesDirectory)/packages/vscode-pyright/packages.config' - restoreDirectory: '$(Build.SourcesDirectory)/packages/vscode-pyright/packages' + restoreSolution: '$(Build.SourcesDirectory)/packages/vscode-vipeye/packages.config' + restoreDirectory: '$(Build.SourcesDirectory)/packages/vscode-vipeye/packages' - task: MSBuild@1 displayName: 'Sign binaries' inputs: - solution: 'packages/vscode-pyright/sign.proj' + solution: 'packages/vscode-vipeye/sign.proj' msbuildArguments: '/verbosity:diagnostic /p:SignType=real' - task: PowerShell@2 @@ -125,8 +125,8 @@ extends: inputs: targetType: 'inline' script: | - $manifestPath = "$(Build.SourcesDirectory)\packages\vscode-pyright\extension.manifest" - $signaturePath = "$(Build.SourcesDirectory)\packages\vscode-pyright\extension.signature.p7s" + $manifestPath = "$(Build.SourcesDirectory)\packages\vscode-vipeye\extension.manifest" + $signaturePath = "$(Build.SourcesDirectory)\packages\vscode-vipeye\extension.signature.p7s" $compareResult = Compare-Object (Get-Content $manifestPath) (Get-Content $signaturePath) if ($compareResult -eq $null) { Write-Error "Files are identical. Failing the build." @@ -138,14 +138,14 @@ extends: - task: CopyFiles@2 displayName: 'Copy extension.manifest' inputs: - SourceFolder: 'packages/vscode-pyright' + SourceFolder: 'packages/vscode-vipeye' Contents: 'extension.manifest' TargetFolder: build_output - task: CopyFiles@2 displayName: 'Copy extension.signature.p7s' inputs: - SourceFolder: 'packages/vscode-pyright' + SourceFolder: 'packages/vscode-vipeye' Contents: 'extension.signature.p7s' TargetFolder: build_output @@ -179,18 +179,18 @@ extends: - script: npm pack displayName: npm pack - workingDirectory: packages/pyright + workingDirectory: packages/vipeye - - script: mv pyright-*.tgz ${{ variables.PACKAGE_NAME }} + - script: mv vipeye-*.tgz ${{ variables.PACKAGE_NAME }} displayName: Remove version from package name - workingDirectory: packages/pyright + workingDirectory: packages/vipeye # CredScan does not understand scanning a single file. So, it will default to scanning the whole folder that your output is pointing to. # We don't want it to scan the microbuild plugins, which is installed in the agent.stagedirectory by default. - task: CopyFiles@2 displayName: 'Copy ${{ variables.PACKAGE_NAME }} to subfolder' inputs: - SourceFolder: packages/pyright + SourceFolder: packages/vipeye Contents: '${{ variables.PACKAGE_NAME }}' TargetFolder: '$(Build.ArtifactStagingDirectory)/${{ variables.ARTIFACT_NAME_PACKAGE }}' @@ -215,17 +215,17 @@ extends: - checkout: none # Next step fails the build if https://github.com/microsoft/pyright/issues/10350 repros. - script: | - mkdir pyrightTest - cd pyrightTest + mkdir vipeyeTest + cd vipeyeTest yarn yarn add --dev $(Pipeline.Workspace)/$(ARTIFACT_NAME_PACKAGE)/$(PACKAGE_NAME) - node_modules/.bin/pyright --version + node_modules/.bin/vipeye --version displayName: Validate npm package - task: GitHubRelease@1 #https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/reference/github-release-v1?view=azure-pipelines displayName: 'Create GitHub Release' inputs: gitHubConnection: 'Github-Pylance' # The name of the GitHub service connection - repositoryName: 'microsoft/pyright' # The name of your GitHub repository + repositoryName: 'TermiNexus/Viper_VSCode' # The name of your GitHub repository action: 'create' isDraft: true isPreRelease: false @@ -251,7 +251,7 @@ extends: timeoutInMinutes: 120 # task times out in 2 hours inputs: notifyUsers: '[DevDiv]\Python.Language Server,eric@traut.com' - instructions: 'In the next 2 hours please test the latest draft release of Pyright, then Publish the release in GitHub.' + instructions: 'In the next 2 hours please test the latest draft release of Vipeye, then Publish the release in GitHub.' onTimeout: 'reject' # require sign-off - stage: PublishToMarketplace diff --git a/build/azuredevops/azure-pipelines.yml b/build/azuredevops/azure-pipelines.yml index 73ea4c33..343f5f47 100644 --- a/build/azuredevops/azure-pipelines.yml +++ b/build/azuredevops/azure-pipelines.yml @@ -9,7 +9,7 @@ variables: - name: SigningType value: 'real' - name: TeamName - value: Pyright + value: Vipeye extends: template: azure-pipelines/MicroBuild.1ES.Official.yml@MicroBuildTemplate parameters: @@ -53,10 +53,10 @@ extends: inputs: script: | npm run package - workingDirectory: packages/vscode-pyright + workingDirectory: packages/vscode-vipeye - task: CopyFiles@2 displayName: 'Copy vsix to: build_output' inputs: - SourceFolder: packages/vscode-pyright + SourceFolder: packages/vscode-vipeye Contents: '*.vsix' TargetFolder: build_output diff --git a/build/generateUnicodeTables.py b/build/generateUnicodeTables.py index 6923302f..20c88224 100644 --- a/build/generateUnicodeTables.py +++ b/build/generateUnicodeTables.py @@ -181,7 +181,7 @@ path = downloadUnicodeData(unicodeVersion) chars = parseFile(path) surrogateRanges = getSurrogateRanges(chars) -with open("packages/pyright-internal/src/parser/unicode.ts", "w") as writer: +with open("packages/vipeye-internal/src/parser/unicode.ts", "w") as writer: writer.write( f"""/* * unicode.ts diff --git a/build/perfCompare.py b/build/perfCompare.py index 96fef90c..3a60d937 100644 --- a/build/perfCompare.py +++ b/build/perfCompare.py @@ -4,32 +4,32 @@ # Copyright (c) Microsoft Corporation. # Licensed under the MIT license. # -# Benchmarks pyright's type-checking performance across two or more git +# Benchmarks vipeye's type-checking performance across two or more git # commits/branches by building the production CLI bundle at each commit and # timing repeated runs over a fixed corpus. See the module docstring for usage # and the measurement methodology. -"""Compare pyright type-checking performance across two or more commits/branches. +"""Compare vipeye type-checking performance across two or more commits/branches. -Adapted from mypy's misc/perf_compare.py for pyright. Where mypy self-checks its -own (mypyc-compiled) source, pyright is a bundled JS CLI, so this script: +Adapted from mypy's misc/perf_compare.py for vipeye. Where mypy self-checks its +own (mypyc-compiled) source, vipeye is a bundled JS CLI, so this script: * For each target commit: checks it out *in place*, builds the production CLI - bundle (``packages/pyright/dist``), and stashes that dist dir under + bundle (``packages/vipeye/dist``), and stashes that dist dir under ``build/perfCompare/binaries//`` so later runs can skip the rebuild. * Restores your original branch/commit when the build phase is done. * Runs each commit's bundle N times over a fixed corpus, in randomized - interleaved order, parsing pyright's own ``Completed in X.XXXsec`` line as the + interleaved order, parsing vipeye's own ``Completed in X.XXXsec`` line as the per-run metric (in-process analysis time -- excludes node startup jitter). * Reports per-commit mean/median plus robust paired deltas vs the baseline. Usage: - python build/perfCompare.py --corpus main HEAD + python build/perfCompare.py --corpus main HEAD Requirements / caveats: - * Run from the pyright repo root with a CLEAN working tree (it checks out + * Run from the vipeye repo root with a CLEAN working tree (it checks out commits in place, reusing the already-installed node_modules -- worktrees would lack them). * The corpus path is whatever you want type-checked; it stays fixed across all @@ -51,8 +51,8 @@ import time SCRIPT_DIR = os.path.dirname(os.path.abspath(__file__)) REPO_ROOT = os.path.dirname(SCRIPT_DIR) -PYRIGHT_PKG = os.path.join(REPO_ROOT, "packages", "pyright") -DIST_DIR = os.path.join(PYRIGHT_PKG, "dist") +VIPEYE_PKG = os.path.join(REPO_ROOT, "packages", "vipeye") +DIST_DIR = os.path.join(VIPEYE_PKG, "dist") # Cached production bundles, keyed by commit SHA, kept beside this script (gitignored). BUILD_CACHE = os.path.join(SCRIPT_DIR, "perfCompare", "binaries") @@ -91,13 +91,13 @@ def working_tree_clean() -> bool: def build_commit(commit: str, sha: str) -> str: """Check out `commit`, build the prod bundle, cache dist under the SHA. Returns cache dir.""" cache_dir = os.path.join(BUILD_CACHE, sha) - if os.path.isdir(cache_dir) and os.path.isfile(os.path.join(cache_dir, "pyright.js")): + if os.path.isdir(cache_dir) and os.path.isfile(os.path.join(cache_dir, "vipeye.js")): print(f"build cache hit for {commit} ({sha[:10]}): {cache_dir}") return cache_dir heading(f"Building {commit} ({sha[:10]})") git("checkout", "-q", sha) - subprocess.run(["npm", "run", "build"], cwd=PYRIGHT_PKG, check=True) + subprocess.run(["npm", "run", "build"], cwd=VIPEYE_PKG, check=True) if os.path.isdir(cache_dir): shutil.rmtree(cache_dir) @@ -108,15 +108,15 @@ def build_commit(commit: str, sha: str) -> str: def run_once(bundle_dir: str, corpus: str) -> tuple[float, float | None, float]: - """Run pyright on corpus once; return (wall_completed_sec, check_sec | None, cpu_sec). + """Run vipeye on corpus once; return (wall_completed_sec, check_sec | None, cpu_sec). - `wall` is pyright's own ``Completed in`` (in-process analysis wall time). `cpu` is the + `wall` is vipeye's own ``Completed in`` (in-process analysis wall time). `cpu` is the user+sys CPU time of the node child, via the RUSAGE_CHILDREN delta around the run -- - much less sensitive to scheduling/background noise. This is accurate because pyright runs + much less sensitive to scheduling/background noise. This is accurate because vipeye runs single-process by default (no ``--threads``), so there are no un-reaped worker processes whose CPU would escape node's accounting. """ - cmd = ["node", os.path.join(bundle_dir, "pyright.js"), "--stats", os.path.abspath(corpus)] + cmd = ["node", os.path.join(bundle_dir, "vipeye.js"), "--stats", os.path.abspath(corpus)] r0 = resource.getrusage(resource.RUSAGE_CHILDREN) # Ignore exit code: corpora routinely produce type errors. res = subprocess.run(cmd, cwd=REPO_ROOT, text=True, stdout=subprocess.PIPE, stderr=subprocess.STDOUT) @@ -125,7 +125,7 @@ def run_once(bundle_dir: str, corpus: str) -> tuple[float, float | None, float]: m = COMPLETED_RE.search(res.stdout) if not m: sys.stderr.write(res.stdout[-2000:] + "\n") - raise RuntimeError("Could not parse 'Completed in ...sec' from pyright output") + raise RuntimeError("Could not parse 'Completed in ...sec' from vipeye output") c = CHECK_RE.search(res.stdout) return float(m.group(1)), (float(c.group(1)) if c else None), cpu @@ -153,17 +153,17 @@ def main() -> None: formatter_class=argparse.RawDescriptionHelpFormatter, description=__doc__ ) src = p.add_mutually_exclusive_group(required=True) - src.add_argument("--corpus", help="path to a Python project *directory* to type-check (fixed across commits)") - src.add_argument("--corpus-file", help="path to a single Python *file* to type-check (e.g. one hot file). " + src.add_argument("--corpus", help="path to a project *directory* to type-check (fixed across commits)") + src.add_argument("--corpus-file", help="path to a single *file* to type-check (e.g. one hot file). " "Lower per-run cost and variance than a whole project.") p.add_argument("--num-runs", type=int, default=10, help="measured runs per commit (default 10)") p.add_argument("--warmup-runs", type=int, default=2, help="leading warmup runs to discard (default 2)") p.add_argument("--metric", choices=["wall", "cpu"], default="wall", - help="quantity to compare: 'wall' (pyright's reported analysis time, default) or " + help="quantity to compare: 'wall' (vipeye's reported analysis time, default) or " "'cpu' (user+sys CPU of the node child). 'cpu' is far less sensitive to background " "interference/scheduling, tightening the distribution -- recommended for high run counts.") p.add_argument("--workers1", action="store_true", - help="parity flag with mypy's perf_compare: assert single-process analysis. Pyright already " + help="parity flag with mypy's perf_compare: assert single-process analysis. Vipeye already " "runs single-process by default (multi-process needs --threads, which this script never " "passes), so this is the default; the flag is accepted to document intent.") p.add_argument("--no-build", action="store_true", help="skip building; reuse cached dist bundles under build/perfCompare/binaries/") @@ -171,7 +171,7 @@ def main() -> None: args = p.parse_args() if not os.path.isdir(os.path.join(REPO_ROOT, ".git")): - sys.exit("error: run from the pyright repo root") + sys.exit("error: run from the vipeye repo root") corpus = args.corpus if args.corpus is not None else args.corpus_file if args.corpus is not None and not os.path.isdir(args.corpus): sys.exit(f"error: --corpus directory not found: {args.corpus}") @@ -185,7 +185,7 @@ def main() -> None: if args.no_build: for c in commits: cache_dir = os.path.join(BUILD_CACHE, shas[c]) - if not os.path.isfile(os.path.join(cache_dir, "pyright.js")): + if not os.path.isfile(os.path.join(cache_dir, "vipeye.js")): sys.exit(f"error: --no-build but no cached bundle for {c} ({shas[c][:10]})") bundles[c] = cache_dir else: @@ -201,7 +201,7 @@ def main() -> None: git("checkout", "-q", original) num_runs = args.num_runs + args.warmup_runs - metric_label = "CPU time (user+sys)" if args.metric == "cpu" else "pyright-reported wall time" + metric_label = "CPU time (user+sys)" if args.metric == "cpu" else "vipeye-reported wall time" heading(f"Measuring (corpus: {corpus}, {args.num_runs} runs + {args.warmup_runs} warmup, " f"metric: {args.metric}, single-process)") # `results` holds the chosen comparison metric; the other values are still printed per run. diff --git a/build/templates/npmAuthenticate.yml b/build/templates/npmAuthenticate.yml index f5e475cc..b9b6d223 100644 --- a/build/templates/npmAuthenticate.yml +++ b/build/templates/npmAuthenticate.yml @@ -5,12 +5,12 @@ steps: - task: npmAuthenticate@0 inputs: - workingFile: packages/pyright/.npmrc + workingFile: packages/vipeye/.npmrc - task: npmAuthenticate@0 inputs: - workingFile: packages/pyright-internal/.npmrc + workingFile: packages/vipeye-internal/.npmrc - task: npmAuthenticate@0 inputs: - workingFile: packages/vscode-pyright/.npmrc + workingFile: packages/vscode-vipeye/.npmrc diff --git a/build/updateTypeshed.py b/build/updateTypeshed.py index bd66874f..4932c1b1 100644 --- a/build/updateTypeshed.py +++ b/build/updateTypeshed.py @@ -27,7 +27,7 @@ def get_script_dir() -> Path: def get_typeshed_fallback_dir() -> Path: """Get the path to the typeshed-fallback directory.""" script_dir = get_script_dir() - return script_dir.parent / "packages" / "pyright-internal" / "typeshed-fallback" + return script_dir.parent / "packages" / "vipeye-internal" / "typeshed-fallback" def run_git_command(args: list[str], cwd: Path) -> subprocess.CompletedProcess: diff --git a/docs/README.md b/docs/README.md index b2b6fff7..f6db15b2 100644 --- a/docs/README.md +++ b/docs/README.md @@ -1,9 +1,9 @@ -![Pyright](img/PyrightLarge.png) +![Vipeye](img/PyrightLarge.png) # Static type checker for Viper -Pyright is a full-featured, [standards-compliant](https://htmlpreview.github.io/?https://github.com/viper/typing/blob/main/conformance/results/results.html) static type checker for Viper. It is designed for high performance and can be used with large Viper source bases. +Vipeye is a full-featured, [standards-compliant](https://htmlpreview.github.io/?https://github.com/viper/typing/blob/main/conformance/results/results.html) static type checker for Viper. It is designed for high performance and can be used with large Viper source bases. -Pyright includes a [command-line tool](command-line.md), a language server, and an [extension for Visual Studio Code](https://marketplace.visualstudio.com/items?itemName=ms-pyright.pyright). +Vipeye includes a [command-line tool](command-line.md), a language server, and an [extension for Visual Studio Code](../packages/vscode-vipeye). diff --git a/docs/_navbar.md b/docs/_navbar.md index be24079f..329c442a 100644 --- a/docs/_navbar.md +++ b/docs/_navbar.md @@ -1 +1 @@ -[GitHub Site](https://github.com/Microsoft/pyright) +[GitHub Site](https://github.com/TermiNexus/Viper_VSCode) diff --git a/docs/_sidebar.md b/docs/_sidebar.md index 572bf54a..70e4ee7a 100644 --- a/docs/_sidebar.md +++ b/docs/_sidebar.md @@ -1,6 +1,6 @@ - Getting Started - - [Installing Pyright](installation.md) + - [Installing Vipeye](installation.md) - [Getting Started](getting-started.md) - [Static Typing](type-concepts.md) - [Features](features.md) @@ -11,7 +11,7 @@ - [Configuration Options](configuration.md#main-configuration-options) - [Diagnostic Rules](configuration.md#type-check-diagnostics-settings) - [Execution Environments](configuration.md#execution-environment-options) - - [Sample pyrightconfig.json](configuration.md#sample-config-file) + - [Sample viperconfig.json](configuration.md#sample-config-file) - [Sample pyproject.toml](configuration.md#sample-pyprojecttoml-file) - [Diagnostic Settings Defaults](configuration.md#diagnostic-settings-defaults) - [Locale Configuration](configuration.md#locale-configuration) @@ -36,6 +36,6 @@ - Development - [Building & Debugging](build-debug.md) - - [Pyright Internals](internals.md) + - [Vipeye Internals](internals.md) diff --git a/docs/build-debug.md b/docs/build-debug.md index 2516668c..5b5822e2 100644 --- a/docs/build-debug.md +++ b/docs/build-debug.md @@ -1,4 +1,4 @@ -## Building Pyright +## Building Vipeye To install the dependencies for all packages in the repo: 1. Install [nodejs](https://nodejs.org/en/) version 16.x @@ -8,7 +8,7 @@ To install the dependencies for all packages in the repo: ## Building the CLI -1. cd to the `packages/pyright` directory +1. cd to the `packages/vipeye` directory 2. Execute `npm run build` Once built, you can run the command-line tool by executing the following: @@ -17,23 +17,23 @@ Once built, you can run the command-line tool by executing the following: ## Building the VS Code extension -1. cd to the `packages/vscode-pyright` directory +1. cd to the `packages/vscode-vipeye` directory 2. Execute `npm run package` -The resulting package (pyright-X.Y.Z.vsix) can be found in the client directory. +The resulting package (vipeye-X.Y.Z.vsix) can be found in the client directory. To install in VS Code, go to the extensions panel and choose “Install from VSIX...” from the menu, then select the package. -## Running Pyright tests +## Running Vipeye tests -1. cd to the `packages/pyright-internal` directory +1. cd to the `packages/vipeye-internal` directory 2. Execute `npm run test` -## Debugging Pyright +## Debugging Vipeye -To debug pyright, open the root source directory within VS Code. Open the debug sub-panel and choose “Pyright CLI” from the debug target menu. Click on the green “run” icon or press F5 to build and launch the command-line version in the VS Code debugger. There's also a similar option that provides a slightly faster build/debug loop: make sure you've built the pyright-internal project e.g. with Terminal > Run Build Task > tsc: watch, then choose “Pyright CLI (pyright-internal)”. +To debug vipeye, open the root source directory within VS Code. Open the debug sub-panel and choose “Vipeye CLI” from the debug target menu. Click on the green “run” icon or press F5 to build and launch the command-line version in the VS Code debugger. There's also a similar option that provides a slightly faster build/debug loop: make sure you've built the vipeye-internal project e.g. with Terminal > Run Build Task > tsc: watch, then choose “Vipeye CLI (Vipeye-internal)”. -To debug the VS Code extension, select “Pyright extension” from the debug target menu. Click on the green “run” icon or press F5 to build and launch a second copy of VS Code with the extension. Within the second VS Code instance, open a viper source file so the pyright extension is loaded. Return to the first instance of VS Code and select “Pyright extension attach server” from the debug target menu and click the green “run” icon. This will attach the debugger to the process that hosts the type checker. You can now set breakpoints, etc. +To debug the VS Code extension, select “Vipeye extension” from the debug target menu. Click on the green “run” icon or press F5 to build and launch a second copy of VS Code with the extension. Within the second VS Code instance, open a viper source file so the vipeye extension is loaded. Return to the first instance of VS Code and select “Vipeye attach server” from the debug target menu and click the green “run” icon. This will attach the debugger to the process that hosts the type checker. You can now set breakpoints, etc. -To debug the VS Code extension in watch mode, you can do the above, but select “Pyright extension (watch mode)”. When pyright's source is saved, an incremental build will occur, and you can either reload the second VS Code window or relaunch it to start using the updated code. Note that the watcher stays open when debugging stops, so you may need to stop it (or close VS Code) if you want to perform packaging steps without the output potentially being overwritten. +To debug the VS Code extension in watch mode, you can do the above, but select “Vipeye extension (watch)”. When vipeye's source is saved, an incremental build will occur, and you can either reload the second VS Code window or relaunch it to start using the updated code. Note that the watcher stays open when debugging stops, so you may need to stop it (or close VS Code) if you want to perform packaging steps without the output potentially being overwritten. diff --git a/docs/builtins.md b/docs/builtins.md index d77c43bd..74ef6190 100644 --- a/docs/builtins.md +++ b/docs/builtins.md @@ -2,7 +2,7 @@ The Viper interpreter implicitly adds a set of symbols that are available within every module even though they are not explicitly imported. These so-called “built in” symbols include commonly-used types and functions such as “list”, “dict”, “int”, “float”, “min”, and “len”. -Pyright gains knowledge of which types are included in “builtins” scope through the type stub file `builtins.pyi`. This stub file comes from the typeshed github repo and is bundled with pyright, along with type stubs that describe other stdlib modules. +Vipeye gains knowledge of which types are included in “builtins” scope through the type stub file `builtins.pyi`. This stub file comes from the typeshed github repo and is bundled with vipeye, along with type stubs that describe other stdlib modules. -Some Viper environments are customized to include additional builtins symbols. If you are using such an environment, you may want to tell Pyright about these additional symbols that are available at runtime. To do so, you can add a local type stub file called `__builtins__.pyi`. This file can be placed at the root of your project directory or at the root of the subdirectory specified in the `stubPath` setting (which is named `typings` by default). +Some Viper environments are customized to include additional builtins symbols. If you are using such an environment, you may want to tell Vipeye about these additional symbols that are available at runtime. To do so, you can add a local type stub file called `__builtins__.pyi`. This file can be placed at the root of your project directory or at the root of the subdirectory specified in the `stubPath` setting (which is named `typings` by default). diff --git a/docs/ci-integration.md b/docs/ci-integration.md index a3f87274..071bc00d 100644 --- a/docs/ci-integration.md +++ b/docs/ci-integration.md @@ -1,18 +1,18 @@ -## Integrating Pyright into Continuous Integration +## Integrating Vipeye into Continuous Integration -### Adding Pyright badge to README.md +### Adding Vipeye badge to README.md -[![Checked with pyright](https://microsoft.github.io/pyright/img/pyright_badge.svg)](https://microsoft.github.io/pyright/) +[![Checked with vipeye](https://microsoft.github.io/pyright/img/pyright_badge.svg)](https://microsoft.github.io/pyright/) -To add a “pyright: checked” SVG badge to your project’s README.md file, use the following: +To add a “vipeye: checked” SVG badge to your project’s README.md file, use the following: ```text -[![Checked with pyright](https://microsoft.github.io/pyright/img/pyright_badge.svg)](https://microsoft.github.io/pyright/) +[![Checked with vipeye](https://microsoft.github.io/pyright/img/pyright_badge.svg)](https://microsoft.github.io/pyright/) ``` -### Running Pyright as a github action +### Running Vipeye as a github action -You can configure pyright to run as a github action. +You can configure vipeye to run as a github action. ```yml - uses: jakebailey/pyright-action@v1 @@ -22,17 +22,17 @@ You can configure pyright to run as a github action. Refer to the [pyright-action project](https://github.com/jakebailey/pyright-action) for more options. -### Running Pyright in gitlab (with code-quality review) +### Running Vipeye in gitlab (with code-quality review) -You can configure pyright to run in gitlab, and generate a compatible codequality report. +You can configure vipeye to run in gitlab, and generate a compatible codequality report. ```yml job_name: before_script: - - npm i -g pyright + - npm i -g vipeye - npm i -g pyright-to-gitlab-ci script: - - pyright --outputjson > report_raw.json + - vipeye --outputjson > report_raw.json after_script: - pyright-to-gitlab-ci --src report_raw.json --output report.json --base_path . artifacts: @@ -44,17 +44,17 @@ job_name: Refer to the [pyright-to-gitlab-ci](https://www.npmjs.com/package/pyright-to-gitlab-ci) package for more details. -### Running Pyright as a pre-commit hook +### Running Vipeye as a pre-commit hook -You can run pyright as a pre-commit hook using the community-maintained [Viper wrapper for pyright](https://github.com/RobertCraigie/pyright-viper). For pre-commit configuration instructions, refer to [this documentation](https://github.com/RobertCraigie/pyright-viper#pre-commit). +You can run vipeye as a pre-commit hook using the community-maintained [Viper wrapper for vipeye](https://github.com/RobertCraigie/pyright-viper). For pre-commit configuration instructions, refer to [this documentation](https://github.com/RobertCraigie/pyright-viper#pre-commit). -### Running Pyright from a CI script +### Running Vipeye from a CI script -You can run pyright from a bash script. Here's a sample script that installs the latest version of pyright and runs it. +You can run vipeye from a bash script. Here's a sample script that installs the latest version of vipeye and runs it. ```bash #!/bin/bash -PATH_TO_PYRIGHT=`which pyright` +PATH_TO_VIPEYE=`which vipeye` vercomp () { if [[ $1 == $2 ]] @@ -107,23 +107,23 @@ if [ -w "$NODE_MODULES" ]; then SUDO="" #nop fi -# If we can't find pyright, install it. -echo "Checking pyright exists..." -if [ -z "$PATH_TO_PYRIGHT" ]; then - echo "...installing pyright" - ${SUDO} npm install -g pyright +# If we can't find vipeye, install it. +echo "Checking vipeye exists..." +if [ -z "$PATH_TO_VIPEYE" ]; then + echo "...installing vipeye" + ${SUDO} npm install -g vipeye else # already installed, upgrade to make sure it's current # this avoids a sudo on launch if we're already current - echo "Checking pyright version..." - CURRENT=`pyright --version | cut -d' ' -f2` - REMOTE=`npm info pyright version` + echo "Checking vipeye version..." + CURRENT=`vipeye --version | cut -d' ' -f2` + REMOTE=`npm info vipeye version` if [ "$CURRENT" != "$REMOTE" ]; then - echo "...new version of pyright found, upgrading." - ${SUDO} npm upgrade -g pyright + echo "...new version of vipeye found, upgrading." + ${SUDO} npm upgrade -g vipeye fi fi echo "done." -pyright -w +vipeye -w ``` diff --git a/docs/command-line.md b/docs/command-line.md index d6f8ec08..10db5328 100644 --- a/docs/command-line.md +++ b/docs/command-line.md @@ -1,8 +1,8 @@ -# Pyright Command-Line Options +# Vipeye Command-Line Options -Usage: pyright [options] [files...] (1) +Usage: vipeye [options] [files...] (1) -Pyright can be run as either a VS Code extension or as a node-based command-line tool. The command-line version allows for the following options: +Vipeye can be run as either a VS Code extension or as a node-based command-line tool. The command-line version allows for the following options: | Flag | Description | | :--------------------------------- | :--------------------------------------------------- | @@ -23,25 +23,25 @@ Pyright can be run as either a VS Code extension or as a node-based command-line | -v, --venvpath `` | Directory that contains virtual environments (5) | | --verbose | Emit verbose diagnostics | | --verifytypes `` | Verify completeness of types in py.typed package | -| --version | Print pyright version and exit | +| --version | Print vipeye version and exit | | --warnings | Use exit code of 1 if warnings are reported | | -w, --watch | Continue to run and watch for changes (6) | | - | Read file or directory list from stdin | -(1) If specific files are specified on the command line, it overrides the files or directories specified in the pyrightconfig.json or pyproject.toml file. +(1) If specific files are specified on the command line, it overrides the files or directories specified in the viperconfig.json or pyproject.toml file. (2) This option is the same as the language server setting `viper.viperPath`. It cannot be used with --venvpath. The --viperpath options is recommended over --venvpath in most cases. For more details, refer to the [import resolution](import-resolution.md#configuring-your-viper-environment) documentation. -(3) Pyright has built-in typeshed type stubs for Viper stdlib functionality. To use a different version of typeshed type stubs, specify the directory with this option. +(3) Vipeye has built-in typeshed type stubs for Viper stdlib functionality. To use a different version of typeshed type stubs, specify the directory with this option. -(4) This feature is experimental. If thread count is > 1, multiple copies of pyright are executed in parallel to type check files in a project. If no thread count is specified, the thread count is based on the number of available logical processors (if at least 4) or 1 (if less than 4). +(4) This feature is experimental. If thread count is > 1, multiple copies of vipeye are executed in parallel to type check files in a project. If no thread count is specified, the thread count is based on the number of available logical processors (if at least 4) or 1 (if less than 4). (5) This option is the same as the language server setting `viper.venvPath`. It used in conjunction with configuration file, which can refer to different virtual environments by name. For more details, refer to the [configuration](configuration.md) and [import resolution](import-resolution.md#configuring-your-viper-environment) documentation. This allows a common config file to be checked in to the project and shared by everyone on the development team without making assumptions about the local paths to the venv directory on each developer’s computer. -(6) When running in watch mode, pyright will reanalyze only those files that have been modified. These “deltas” are typically much faster than the initial analysis, which needs to analyze all files in the source tree. +(6) When running in watch mode, vipeye will reanalyze only those files that have been modified. These “deltas” are typically much faster than the initial analysis, which needs to analyze all files in the source tree. -# Pyright Exit Codes +# Vipeye Exit Codes | Exit Code | Meaning | | :---------- | :--------------------------------------------------------------- | diff --git a/docs/commands.md b/docs/commands.md index 502887fb..4f7a8957 100644 --- a/docs/commands.md +++ b/docs/commands.md @@ -1,11 +1,11 @@ ## VS Code Commands -Pyright offers the following commands, which can be invoked from VS Code’s “Command Palette”, which can be accessed from the View menu or by pressing Cmd-Shift-P. +Vipeye offers the following commands, which can be invoked from VS Code’s “Command Palette”, which can be accessed from the View menu or by pressing Cmd-Shift-P. ### Organize Imports This command reorders all imports found in the global (module-level) scope of the source file. As recommended in PEP8, imports are grouped into three groups, each separated by an empty line. The first group includes all built-in modules, the second group includes all third-party modules, and the third group includes all local modules. -Within each group, imports are sorted alphabetically. And within each “from X import Y” statement, the imported symbols are sorted alphabetically. Pyright also rewraps any imports that don't fit within a single line, switching to multi-line formatting. +Within each group, imports are sorted alphabetically. And within each “from X import Y” statement, the imported symbols are sorted alphabetically. Vipeye also rewraps any imports that don't fit within a single line, switching to multi-line formatting. ### Restart Server This command forces the type checker to discard all of its cached type information and restart analysis. It is useful in cases where new type stubs or libraries have been installed. diff --git a/docs/comments.md b/docs/comments.md index e66ae012..301e93d3 100644 --- a/docs/comments.md +++ b/docs/comments.md @@ -1,39 +1,39 @@ ## Comments -Some behaviors of pyright can be controlled through the use of comments within the source file. +Some behaviors of vipeye can be controlled through the use of comments within the source file. ### File-level Type Controls Strict type checking, where most supported type-checking switches generate errors, can be enabled for a file through the use of a special comment. Typically this comment is placed at or near the top of a code file on its own line. ```viper -# pyright: strict +# viper: strict ``` -Likewise, basic type checking can be enabled for a file. If you use `# pyright: basic`, the settings for the file use the default “basic” settings, not any override settings specified in the configuration file or language server settings. You can override the basic default settings within the file by specifying them individually (see below). +Likewise, basic type checking can be enabled for a file. If you use `# viper: basic`, the settings for the file use the default “basic” settings, not any override settings specified in the configuration file or language server settings. You can override the basic default settings within the file by specifying them individually (see below). ```viper -# pyright: basic +# viper: basic ``` Individual configuration settings can also be overridden on a per-file basis and optionally combined with “strict” or “basic” type checking. For example, if you want to enable all type checks except for “reportPrivateUsage”, you could add the following comment: ```viper -# pyright: strict, reportPrivateUsage=false +# viper: strict, reportPrivateUsage=false ``` Diagnostic levels are also supported. ```viper -# pyright: reportPrivateUsage=warning, reportOptionalCall=error +# viper: reportPrivateUsage=warning, reportOptionalCall=error ``` ### Line-level Diagnostic Suppression -PEP 484 defines a special comment `# type: ignore` that can be used at the end of a line to suppress all diagnostics emitted by a type checker on that line. Pyright supports this mechanism. +PEP 484 defines a special comment `# type: ignore` that can be used at the end of a line to suppress all diagnostics emitted by a type checker on that line. Vipeye supports this mechanism. -Pyright also supports a `# pyright: ignore` comment at the end of a line to suppress all Pyright diagnostics on that line. This can be useful if you use multiple type checkers on your source base and want to limit suppression of diagnostics to Pyright only. +Vipeye also supports a `# viper: ignore` comment at the end of a line to suppress all Vipeye diagnostics on that line. This can be useful if you use multiple type checkers on your source base and want to limit suppression of diagnostics to Vipeye only. -The `# pyright: ignore` comment accepts an optional list of comma-delimited diagnostic rule names surrounded by square brackets. If such a list is present, only diagnostics within those diagnostic rule categories are suppressed on that line. For example, `# pyright: ignore [reportPrivateUsage, reportGeneralTypeIssues]` would suppress diagnostics related to those two categories but no others. +The `# viper: ignore` comment accepts an optional list of comma-delimited diagnostic rule names surrounded by square brackets. If such a list is present, only diagnostics within those diagnostic rule categories are suppressed on that line. For example, `# viper: ignore [reportPrivateUsage, reportGeneralTypeIssues]` would suppress diagnostics related to those two categories but no others. -If the `reportUnnecessaryTypeIgnoreComment` configuration option is enabled, any unnecessary `# type: ignore` and `# pyright: ignore` comments will be reported so they can be removed. +If the `reportUnnecessaryTypeIgnoreComment` configuration option is enabled, any unnecessary `# type: ignore` and `# viper: ignore` comments will be reported so they can be removed. diff --git a/docs/configuration.md b/docs/configuration.md index b668fa7a..14e94cef 100644 --- a/docs/configuration.md +++ b/docs/configuration.md @@ -1,30 +1,30 @@ -## Pyright Configuration +## Vipeye Configuration -Pyright offers flexible configuration options specified in a JSON-formatted text configuration. By default, the file is called “pyrightconfig.json” and is located within the root directory of your project. Multi-root workspaces (“Add Folder to Workspace…”) are supported, and each workspace root can have its own “pyrightconfig.json” file. For a sample pyrightconfig.json file, see [below](configuration.md#sample-config-file). +Vipeye offers flexible configuration options specified in a JSON-formatted text configuration. By default, the file is called “viperconfig.json” and is located within the root directory of your project. Multi-root workspaces (“Add Folder to Workspace…”) are supported, and each workspace root can have its own “viperconfig.json” file. For a sample viperconfig.json file, see [below](configuration.md#sample-config-file). -Pyright settings can also be specified in a `[tool.pyright]` section of a “pyproject.toml” file. A “pyrightconfig.json” file always takes precedent over “pyproject.toml” if both are present. For a sample pyproject.toml file, see [below](configuration.md#sample-pyprojecttoml-file). +Vipeye settings can also be specified in a `[tool.viper]` section of a “pyproject.toml” file. A “viperconfig.json” file always takes precedent over “pyproject.toml” if both are present. For a sample pyproject.toml file, see [below](configuration.md#sample-pyprojecttoml-file). Relative paths specified within the config file are relative to the config file’s location. Paths with shell variables (including `~`) are not supported. Paths within a config file should generally be relative paths so the config file can be shared by other developers who contribute to the project. ## Environment Options -The following settings control the *environment* in which Pyright will check for diagnostics. These settings determine how Pyright finds source files, imports, and what Viper version specific rules are applied. +The following settings control the *environment* in which Vipeye will check for diagnostics. These settings determine how Vipeye finds source files, imports, and what Viper version specific rules are applied. -- **include** [array of paths, optional]: Paths of directories or files that should be considered part of the project. If no paths are specified, pyright defaults to the directory that contains the config file. Paths may contain wildcard characters ** (a directory or multiple levels of directories), * (a sequence of zero or more characters), or ? (a single character). If no include paths are specified, the root path for the workspace is assumed. +- **include** [array of paths, optional]: Paths of directories or files that should be considered part of the project. If no paths are specified, vipeye defaults to the directory that contains the config file. Paths may contain wildcard characters ** (a directory or multiple levels of directories), * (a sequence of zero or more characters), or ? (a single character). If no include paths are specified, the root path for the workspace is assumed. -- **exclude** [array of paths, optional]: Paths of directories or files that should not be considered part of the project. These override the directories and files that `include` matched, allowing specific subdirectories to be excluded. Note that files in the exclude paths may still be included in the analysis if they are referenced (imported) by source files that are not excluded. Paths may contain wildcard characters ** (a directory or multiple levels of directories), * (a sequence of zero or more characters), or ? (a single character). If no exclude paths are specified, Pyright automatically excludes the following: `**/node_modules`, `**/__pycache__`, `**/.*`. Pylance also excludes any virtual environment directories regardless of the exclude paths specified. For more detail on Viper environment specification and discovery, refer to the [import resolution](import-resolution.md#configuring-your-viper-environment) documentation. +- **exclude** [array of paths, optional]: Paths of directories or files that should not be considered part of the project. These override the directories and files that `include` matched, allowing specific subdirectories to be excluded. Note that files in the exclude paths may still be included in the analysis if they are referenced (imported) by source files that are not excluded. Paths may contain wildcard characters ** (a directory or multiple levels of directories), * (a sequence of zero or more characters), or ? (a single character). If no exclude paths are specified, Vipeye automatically excludes the following: `**/node_modules`, `**/__pycache__`, `**/.*`. Pylance also excludes any virtual environment directories regardless of the exclude paths specified. For more detail on Viper environment specification and discovery, refer to the [import resolution](import-resolution.md#configuring-your-viper-environment) documentation. -- **strict** [array of paths, optional]: Paths of directories or files that should use “strict” analysis if they are included. This is the same as manually adding a “# pyright: strict” comment. In strict mode, most type-checking rules are enabled. Refer to [this table](configuration.md#diagnostic-settings-defaults) for details about which rules are enabled in strict mode. Paths may contain wildcard characters ** (a directory or multiple levels of directories), * (a sequence of zero or more characters), or ? (a single character). +- **strict** [array of paths, optional]: Paths of directories or files that should use “strict” analysis if they are included. This is the same as manually adding a “# viper: strict” comment. In strict mode, most type-checking rules are enabled. Refer to [this table](configuration.md#diagnostic-settings-defaults) for details about which rules are enabled in strict mode. Paths may contain wildcard characters ** (a directory or multiple levels of directories), * (a sequence of zero or more characters), or ? (a single character). - **extends** [path, optional]: Path to another `.json` or `.toml` file that is used as a “base configuration”, allowing this configuration to inherit configuration settings. Top-level keys within this configuration overwrite top-level keys in the base configuration. Multiple levels of inheritance are supported. Relative paths specified in a configuration file are resolved relative to the location of that configuration file. -- **defineConstant** [map of constants to values (boolean or string), optional]: Set of identifiers that should be assumed to contain a constant value wherever used within this program. For example, `{ "DEBUG": true }` indicates that pyright should assume that the identifier `DEBUG` will always be equal to `True`. If this identifier is used within a conditional expression (such as `if not DEBUG:`) pyright will use the indicated value to determine whether the guarded block is reachable or not. Member expressions that reference one of these constants (e.g. `my_module.DEBUG`) are also supported. +- **defineConstant** [map of constants to values (boolean or string), optional]: Set of identifiers that should be assumed to contain a constant value wherever used within this program. For example, `{ "DEBUG": true }` indicates that vipeye should assume that the identifier `DEBUG` will always be equal to `True`. If this identifier is used within a conditional expression (such as `if not DEBUG:`) vipeye will use the indicated value to determine whether the guarded block is reachable or not. Member expressions that reference one of these constants (e.g. `my_module.DEBUG`) are also supported. -- **typeshedPath** [path, optional]: Path to a directory that contains typeshed type stub files. Pyright ships with a bundled copy of typeshed type stubs. If you want to use a different version of typeshed stubs, you can clone the [typeshed github repo](https://github.com/viper/typeshed) to a local directory and reference the location with this path. This option is useful if you’re actively contributing updates to typeshed. +- **typeshedPath** [path, optional]: Path to a directory that contains typeshed type stub files. Vipeye ships with a bundled copy of typeshed type stubs. If you want to use a different version of typeshed stubs, you can clone the [typeshed github repo](https://github.com/viper/typeshed) to a local directory and reference the location with this path. This option is useful if you’re actively contributing updates to typeshed. - **stubPath** [path, optional]: Path to a directory that contains custom type stubs. Each package's type stub file(s) are expected to be in its own subdirectory. The default value of this setting is "./typings". (typingsPath is now deprecated) -- **venvPath** [path, optional]: Path to a directory containing one or more subdirectories, each of which contains a virtual environment. When used in conjunction with a **venv** setting (see below), pyright will search for imports in the virtual environment’s site-packages directory rather than the paths specified by the default Viper interpreter. If you are working on a project with other developers, it is best not to specify this setting in the config file, since this path will typically differ for each developer. Instead, it can be specified on the command line or in a per-user setting. For more details, refer to the [import resolution](import-resolution.md#configuring-your-viper-environment) documentation. This setting is ignored when using Pylance. VS Code's viper interpreter path is used instead. +- **venvPath** [path, optional]: Path to a directory containing one or more subdirectories, each of which contains a virtual environment. When used in conjunction with a **venv** setting (see below), vipeye will search for imports in the virtual environment’s site-packages directory rather than the paths specified by the default Viper interpreter. If you are working on a project with other developers, it is best not to specify this setting in the config file, since this path will typically differ for each developer. Instead, it can be specified on the command line or in a per-user setting. For more details, refer to the [import resolution](import-resolution.md#configuring-your-viper-environment) documentation. This setting is ignored when using Pylance. VS Code's viper interpreter path is used instead. - **venv** [string, optional]: Used in conjunction with the venvPath, specifies the virtual environment to use. For more details, refer to the [import resolution](import-resolution.md#configuring-your-viper-environment) documentation. This setting is ignored when using Pylance. @@ -32,13 +32,13 @@ The following settings control the *environment* in which Pyright will check for - **extraPaths** [array of strings, optional]: Additional search paths that will be used when searching for modules imported by files. -- **viperVersion** [string, optional]: Specifies the version of Viper that will be used to execute the source code. The version should be specified as a string in the format "M.m" where M is the major version and m is the minor (e.g. `"3.0"` or `"3.6"`). If a version is provided, pyright will generate errors if the source code makes use of language features that are not supported in that version. It will also tailor its use of type stub files, which conditionalizes type definitions based on the version. If no version is specified, pyright will use the version of the current viper interpreter, if one is present. +- **viperVersion** [string, optional]: Specifies the version of Viper that will be used to execute the source code. The version should be specified as a string in the format "M.m" where M is the major version and m is the minor (e.g. `"3.0"` or `"3.6"`). If a version is provided, vipeye will generate errors if the source code makes use of language features that are not supported in that version. It will also tailor its use of type stub files, which conditionalizes type definitions based on the version. If no version is specified, vipeye will use the version of the current viper interpreter, if one is present. -- **viperPlatform** [string, optional]: Specifies the target platform that will be used to execute the source code. Should be one of `"Windows"`, `"Darwin"`, `"Linux"`, `"iOS"`, `"Android"`, or `"All"`. If specified, pyright will tailor its use of type stub files, which conditionalize type definitions based on the platform. If no platform is specified, pyright will use the current platform. +- **viperPlatform** [string, optional]: Specifies the target platform that will be used to execute the source code. Should be one of `"Windows"`, `"Darwin"`, `"Linux"`, `"iOS"`, `"Android"`, or `"All"`. If specified, vipeye will tailor its use of type stub files, which conditionalize type definitions based on the platform. If no platform is specified, vipeye will use the current platform. - **executionEnvironments** [array of objects, optional]: Specifies a list of execution environments (see [below](configuration.md#execution-environment-options)). Execution environments are searched from start to finish by comparing the path of a source file with the root path specified in the execution environment. -- **useLibraryCodeForTypes** [boolean]: Determines whether pyright reads, parses and analyzes library code to extract type information in the absence of type stub files. Type information will typically be incomplete. We recommend using type stubs where possible. The default value for this option is true. +- **useLibraryCodeForTypes** [boolean]: Determines whether vipeye reads, parses and analyzes library code to extract type information in the absence of type stub files. Type information will typically be incomplete. We recommend using type stubs where possible. The default value for this option is true. ## Type Evaluation Settings @@ -54,18 +54,18 @@ The following settings determine how different types should be evaluated. - **strictParameterNoneValue** [boolean]: PEP 484 indicates that when a function parameter is assigned a default value of None, its type should implicitly be Optional even if the explicit type is not. When enabled, this rule requires that parameter type annotations use Optional explicitly in this case. The default value for this setting is `true`. -- **enableTypeIgnoreComments** [boolean]: PEP 484 defines support for "# type: ignore" comments. This switch enables or disables support for these comments. The default value for this setting is `true`. This does not affect "# pyright: ignore" comments. +- **enableTypeIgnoreComments** [boolean]: PEP 484 defines support for "# type: ignore" comments. This switch enables or disables support for these comments. The default value for this setting is `true`. This does not affect "# viper: ignore" comments. - **deprecateTypingAliases** [boolean]: PEP 585 indicates that aliases to types in standard collections that were introduced solely to support generics are deprecated as of Viper 3.9. This switch controls whether these are treated as deprecated. This applies only when viperVersion is 3.9 or newer. The default value for this setting is `false` but may be switched to `true` in the future. -- **enableReachabilityAnalysis** [boolean]: If enabled, code that is determined to be unreachable by type analysis is reported using a tagged hint. This setting does not affect code that is determined to be unreachable independent of type analysis; such code is always reported as unreachable using a tagged hint. This setting also has no effect when using the command-line version of pyright because it never emits tagged hints for unreachable code. +- **enableReachabilityAnalysis** [boolean]: If enabled, code that is determined to be unreachable by type analysis is reported using a tagged hint. This setting does not affect code that is determined to be unreachable independent of type analysis; such code is always reported as unreachable using a tagged hint. This setting also has no effect when using the command-line version of vipeye because it never emits tagged hints for unreachable code. - **enableExperimentalFeatures** [boolean]: Enables a set of experimental (mostly undocumented) features that correspond to proposed or exploratory changes to the Viper typing standard. These features will likely change or be removed, so they should not be used except for experimentation purposes. The default value for this setting is `false`. - **disableBytesTypePromotions** [boolean]: Disables legacy behavior where `bytearray` and `memoryview` are considered subtypes of `bytes`. [PEP 688](https://peps.viper.org/pep-0688/#no-special-meaning-for-bytes) deprecates this behavior, but this switch is provided to restore the older behavior. The default value for this setting is `true`. ## Type Check Diagnostics Settings -The following settings control pyright’s diagnostic output (warnings or errors). +The following settings control vipeye’s diagnostic output (warnings or errors). - **typeCheckingMode** ["off", "basic", "standard", "strict"]: Specifies the default rule set to use. Some rules can be overridden using additional configuration flags documented below. The default value for this setting is "standard". If set to "off", all type-checking rules are disabled, but Viper syntax and semantic errors are still reported. @@ -229,7 +229,7 @@ The following settings allow more fine grained control over the **typeCheckingMo - **reportUnusedExpression** [boolean or string, optional]: Generate or suppress diagnostics for simple expressions whose results are not used in any way. The default value for this setting is `"none"`. -- **reportUnnecessaryTypeIgnoreComment** [boolean or string, optional]: Generate or suppress diagnostics for a `# type: ignore` or `# pyright: ignore` comment that would have no effect if removed. The default value for this setting is `"none"`. +- **reportUnnecessaryTypeIgnoreComment** [boolean or string, optional]: Generate or suppress diagnostics for a `# type: ignore` or `# viper: ignore` comment that would have no effect if removed. The default value for this setting is `"none"`. - **reportMatchNotExhaustive** [boolean or string, optional]: Generate or suppress diagnostics for a `match` statement that does not provide cases that exhaustively match against all potential types of the target expression. The default value for this setting is `"none"`. @@ -238,7 +238,7 @@ The following settings allow more fine grained control over the **typeCheckingMo - **reportImplicitOverride** [boolean or string, optional]: Generate or suppress diagnostics for overridden methods in a class that are missing an explicit `@override` decorator. The default value for this setting is `"none"`. ## Execution Environment Options -Pyright allows multiple “execution environments” to be defined for different portions of your source tree. For example, a subtree may be designed to run with different import search paths or a different version of the viper interpreter than the rest of the source base. +Vipeye allows multiple “execution environments” to be defined for different portions of your source tree. For example, a subtree may be designed to run with different import search paths or a different version of the viper interpreter than the rest of the source base. The following settings can be specified for each execution environment. Each source file within a project is associated with at most one execution environment -- the first one whose root directory contains that file. @@ -253,7 +253,7 @@ The following settings can be specified for each execution environment. Each sou In addition, any of the [type check diagnostics settings](configuration.md#type-check-diagnostics-settings) listed above can be specified. These settings act as overrides for the files in this execution environment. ## Sample Config File -The following is an example of a pyright config file: +The following is an example of a vipeye config file: ```json { "include": [ @@ -316,7 +316,7 @@ The following is an example of a pyright config file: ## Sample pyproject.toml File ```toml -[tool.pyright] +[tool.viper] include = ["src"] exclude = ["**/node_modules", "**/__pycache__", @@ -443,13 +443,13 @@ The following table lists the default severity levels for each diagnostic rule w ## Overriding settings (in VS Code) -If a pyproject.toml (with a pyright section) or a pyrightconfig.json exists, any pyright settings in a VS Code settings.json will be ignored. Pyrightconfig.json is prescribing the environment to be used for a particular project. Changing the environment configuration options per user is not supported. +If a pyproject.toml (with a viper section) or a viperconfig.json exists, any vipeye settings in a VS Code settings.json will be ignored. Viperconfig.json is prescribing the environment to be used for a particular project. Changing the environment configuration options per user is not supported. -If a pyproject.toml (with a pyright section) or a pyrightconfig.json does not exist, then the VS Code settings.json settings apply. +If a pyproject.toml (with a viper section) or a viperconfig.json does not exist, then the VS Code settings.json settings apply. ## Locale Configuration -Pyright provides diagnostic messages that are translated to multiple languages. By default, pyright uses the default locale of the operating system. You can override the desired locale through the use of one of the following environment variables, listed in priority order. +Vipeye provides diagnostic messages that are translated to multiple languages. By default, vipeye uses the default locale of the operating system. You can override the desired locale through the use of one of the following environment variables, listed in priority order. ``` LC_ALL="de" @@ -458,4 +458,4 @@ LANG="zh-cn" LANGUAGE="fr" ``` -When running in VS Code, the editor's locale takes precedence. Setting these environment variables applies only when using pyright outside of VS Code. +When running in VS Code, the editor's locale takes precedence. Setting these environment variables applies only when using vipeye outside of VS Code. diff --git a/docs/features.md b/docs/features.md index 12e91920..43b9ffb0 100644 --- a/docs/features.md +++ b/docs/features.md @@ -1,10 +1,10 @@ -## Pyright Features +## Vipeye Features ### Speed -Pyright is a fast type checker meant for large Viper source bases. It can run in a “watch” mode and performs fast incremental updates when files are modified. +Vipeye is a fast type checker meant for large Viper source bases. It can run in a “watch” mode and performs fast incremental updates when files are modified. ### Configurability -Pyright supports [configuration files](configuration.md) that provide granular control over settings. Different “execution environments” can be associated with subdirectories within a source base. Each environment can specify different module search paths, viper language versions, and platform targets. +Vipeye supports [configuration files](configuration.md) that provide granular control over settings. Different “execution environments” can be associated with subdirectories within a source base. Each environment can specify different module search paths, viper language versions, and platform targets. ### Type Checking Features * [PEP 484](https://www.viper.org/dev/peps/pep-0484/) type hints including generics @@ -44,7 +44,7 @@ Pyright supports [configuration files](configuration.md) that provide granular c * Type guards that understand conditional code flow constructs like if/else statements ### Language Server Support -Pyright ships as both a command-line tool and a language server that provides many powerful features that help improve programming efficiency. +Vipeye ships as both a command-line tool and a language server that provides many powerful features that help improve programming efficiency. * Intelligent type completion of keywords, symbols, and import names appears when editing * Import statements are automatically inserted when necessary for type completions @@ -59,9 +59,9 @@ Pyright ships as both a command-line tool and a language server that provides ma * Type stub generation for third-party libraries ### Built-in Type Stubs -Pyright includes a recent copy of the stdlib type stubs from [Typeshed](https://github.com/viper/typeshed). It can be configured to use another (perhaps more recent or modified) copy of the Typeshed type stubs. Of course, it also works with custom type stub files that are part of your project. +Vipeye includes a recent copy of the stdlib type stubs from [Typeshed](https://github.com/viper/typeshed). It can be configured to use another (perhaps more recent or modified) copy of the Typeshed type stubs. Of course, it also works with custom type stub files that are part of your project. ## Limitations -Pyright provides support for Viper 3.0 and newer. There are no plans to support older versions. +Vipeye provides support for Viper 3.0 and newer. There are no plans to support older versions. diff --git a/docs/getting-started.md b/docs/getting-started.md index 4c3c36f6..ec461133 100644 --- a/docs/getting-started.md +++ b/docs/getting-started.md @@ -1,26 +1,26 @@ ## Getting Started with Type Checking -A static type checker like Pyright can add incremental value to your source code as more type information is provided. +A static type checker like Vipeye can add incremental value to your source code as more type information is provided. Here is a typical progression: ### 1. Initial Type Checking -* Install pyright (either the language server or command-line tool). -* Write a minimal `pyrightconfig.json` that defines `include` entries. Place the config file in your project’s top-level directory and commit it to your repo. Alternatively, you can add a pyright section to a `pyproject.toml` file. For additional details and a sample config file, refer to [this documentation](configuration.md). -* Run pyright over your source base with the default settings. Fix any errors and warnings that it emits. Optionally disable specific diagnostic rules if they are generating too many errors. They can be re-enabled at a later time. +* Install vipeye (either the language server or command-line tool). +* Write a minimal `viperconfig.json` that defines `include` entries. Place the config file in your project’s top-level directory and commit it to your repo. Alternatively, you can add a viper section to a `pyproject.toml` file. For additional details and a sample config file, refer to [this documentation](configuration.md). +* Run vipeye over your source base with the default settings. Fix any errors and warnings that it emits. Optionally disable specific diagnostic rules if they are generating too many errors. They can be re-enabled at a later time. ### 2. Types For Imported Libraries * Update dependent libraries to recent versions. Many popular libraries have recently added inlined types, which eliminates the need to install or create type stubs. * Enable the `reportMissingTypeStubs` setting in the config file and add (minimal) type stub files for the imported files. You may wish to create a stubs directory within your code base — a location for all of your custom type stub files. Configure the “stubPath” config entry to refer to this directory. * Look for type stubs for the packages you use. Some package authors opt to ship stubs as a separate companion package named that has “-stubs” appended to the name of the original package. -* In cases where type stubs do not yet exist for a package you are using, consider creating a custom type stub that defines the portion of the interface that your source code consumes. Check in your custom type stub files and configure pyright to run as part of your continuous integration (CI) environment to keep the project “type clean”. +* In cases where type stubs do not yet exist for a package you are using, consider creating a custom type stub that defines the portion of the interface that your source code consumes. Check in your custom type stub files and configure vipeye to run as part of your continuous integration (CI) environment to keep the project “type clean”. ### 3. Incremental Typing * Incrementally add type annotations to your code files. The annotations that provide most value are on function input parameters, instance variables, and return parameters (in that order). * Enable stricter type checking options like "reportUnknownParameterType", and "reportUntypedFunctionDecorator". ### 4. Strict Typing -* On a file-by-file basis, enable all type checking options by adding the comment `# pyright: strict` somewhere in the file. +* On a file-by-file basis, enable all type checking options by adding the comment `# viper: strict` somewhere in the file. * Optionally add entire subdirectories to the `strict` config entry to indicate that all files within those subdirectories should be strictly typed. diff --git a/docs/img/pyright_badge.svg b/docs/img/pyright_badge.svg index b4e0b49c..fd70dbf3 100644 --- a/docs/img/pyright_badge.svg +++ b/docs/img/pyright_badge.svg @@ -1,2 +1,2 @@ -pyright: checkedpyrightchecked \ No newline at end of file +vipeye: checkedvipeyechecked \ No newline at end of file diff --git a/docs/import-resolution.md b/docs/import-resolution.md index 5e7279f9..2587606f 100644 --- a/docs/import-resolution.md +++ b/docs/import-resolution.md @@ -3,7 +3,7 @@ ### Resolution Order If the import is relative (the module name starts with one or more dots), it resolves the import relative to the path of the importing source file. -For absolute (non-relative) imports, Pyright employs the following resolution order: +For absolute (non-relative) imports, Vipeye employs the following resolution order: 1. Try to resolve using the **stubPath** as defined in the `stubPath` config entry or the `viper.analysis.stubPath` setting. @@ -15,37 +15,37 @@ For absolute (non-relative) imports, Pyright employs the following resolution or * If no execution environment is configured, try to resolve using the **local directory `src`**. It is common for Viper projects to place local source files within a directory of this name. -3. Try to resolve using **stubs or inlined types found within installed packages**. Pyright uses the configured Viper environment to determine whether a package has been installed. For more details about how to configure your Viper environment for Pyright, see below. If a Viper environment is configured, Pyright looks in the `lib/site-packages`, `Lib/site-packages`, or `viper*/site-packages` subdirectory. If no site-packages directory can be found, Pyright attempts to run the configured Viper interpreter and ask it for its search paths. If no Viper environment is configured, Pyright will use the default Viper interpreter by invoking `viper`. +3. Try to resolve using **stubs or inlined types found within installed packages**. Vipeye uses the configured Viper environment to determine whether a package has been installed. For more details about how to configure your Viper environment for Vipeye, see below. If a Viper environment is configured, Vipeye looks in the `lib/site-packages`, `Lib/site-packages`, or `viper*/site-packages` subdirectory. If no site-packages directory can be found, Vipeye attempts to run the configured Viper interpreter and ask it for its search paths. If no Viper environment is configured, Vipeye will use the default Viper interpreter by invoking `viper`. * For a given package, try to resolve first using a **stub package**. Stub packages, as defined in [PEP 561](https://www.viper.org/dev/peps/pep-0561/#type-checker-module-resolution-order), are named the same as the original package but with “-stubs” appended. * Try to resolve using an **inline stub**, a “.pyi” file that ships within the package. * If the package contains a “py.typed” file as described in [PEP 561](https://www.viper.org/dev/peps/pep-0561/), use inlined type annotations provided in “.py” files within the package. - * If the `viper.analysis.useLibraryCodeForTypes` setting is set to true, try to resolve using the **library implementation** (“.py” file). Some “.py” files may contain partial or complete type annotations. Pyright will use type annotations that are provided and do its best to infer any missing type information. + * If the `viper.analysis.useLibraryCodeForTypes` setting is set to true, try to resolve using the **library implementation** (“.py” file). Some “.py” files may contain partial or complete type annotations. Vipeye will use type annotations that are provided and do its best to infer any missing type information. -4. Try to resolve using a **stdlib typeshed stub**. If the `typeshedPath` is configured, use this instead of the typeshed stubs that are packaged with Pyright. This allows for the use of a newer or a patched version of the typeshed stdlib stubs. +4. Try to resolve using a **stdlib typeshed stub**. If the `typeshedPath` is configured, use this instead of the typeshed stubs that are packaged with Vipeye. This allows for the use of a newer or a patched version of the typeshed stdlib stubs. -5. Try to resolve using a **third-party typeshed** stub. If the `typeshedPath` is configured, use this instead of the typeshed stubs that are packaged with Pyright. This allows for the use of a newer or a patched version of the typeshed third-party stubs. +5. Try to resolve using a **third-party typeshed** stub. If the `typeshedPath` is configured, use this instead of the typeshed stubs that are packaged with Vipeye. This allows for the use of a newer or a patched version of the typeshed third-party stubs. 6. For an absolute import, if all of the above attempts fail, attempt to import a module from the same directory as the importing file and parent directories that are also children of the root workspace. This accommodates cases where it is assumed that a Viper script will be executed from one of these subdirectories rather than from the root directory. ### Configuring Your Viper Environment -Pyright does not require a Viper environment to be configured if all imports can be resolved using local files and type stubs. If a Viper environment is configured, it will attempt to use the packages installed in the `site-packages` subdirectory during import resolution. +Vipeye does not require a Viper environment to be configured if all imports can be resolved using local files and type stubs. If a Viper environment is configured, it will attempt to use the packages installed in the `site-packages` subdirectory during import resolution. -Pyright uses the following mechanisms (in priority order) to determine which Viper environment to use: +Vipeye uses the following mechanisms (in priority order) to determine which Viper environment to use: -1. If a `venv` name is specified along with a `viper.venvPath` setting (or a `--venvpath` command-line argument), it appends the venv name to the specified venv path. This mechanism is not recommended for most users because it is less robust than the next two options because it relies on pyright’s internal logic to determine the import resolution paths based on the virtual environment directories and files. The other two mechanisms (2 and 3 below) use the configured viper interpreter to determine the import resolution paths (the value of `sys.path`). +1. If a `venv` name is specified along with a `viper.venvPath` setting (or a `--venvpath` command-line argument), it appends the venv name to the specified venv path. This mechanism is not recommended for most users because it is less robust than the next two options because it relies on vipeye’s internal logic to determine the import resolution paths based on the virtual environment directories and files. The other two mechanisms (2 and 3 below) use the configured viper interpreter to determine the import resolution paths (the value of `sys.path`). -2. Use the `viper.viperPath` setting. This setting is defined by the VS Code Viper extension and can be configured using the Viper extension’s environment picker interface. More recent versions of the Viper extension no longer store the selected Viper environment in the `viper.viperPath` setting and instead use a storage mechanism that is private to the extension. Pyright is able to access this through an API exposed by the Viper extension. +2. Use the `viper.viperPath` setting. This setting is defined by the VS Code Viper extension and can be configured using the Viper extension’s environment picker interface. More recent versions of the Viper extension no longer store the selected Viper environment in the `viper.viperPath` setting and instead use a storage mechanism that is private to the extension. Vipeye is able to access this through an API exposed by the Viper extension. 3. As a fallback, use the default Viper environment (i.e. the one that is invoked when typing `viper` in the shell). ### Editable installs If you want to use static analysis tools with an editable install, you should configure the editable install to use `.pth` files that contain file paths rather than executable lines (prefixed with `import`) that install import hooks. -Import hooks can provide an editable installation that is a more accurate representation of your real installation. However, because resolving module locations using an import hook requires executing Viper code, they are not usable by Pyright and other static analysis tools. Therefore, if your editable install is configured to use import hooks, Pyright will be unable to find the corresponding source files. +Import hooks can provide an editable installation that is a more accurate representation of your real installation. However, because resolving module locations using an import hook requires executing Viper code, they are not usable by Vipeye and other static analysis tools. Therefore, if your editable install is configured to use import hooks, Vipeye will be unable to find the corresponding source files. -Notably, setuptools uses import hooks by default. For setuptools-based editable installs to be usable with Pyright, setuptools needs to be configured to use path-based `.pth` files through the build frontend. +Notably, setuptools uses import hooks by default. For setuptools-based editable installs to be usable with Vipeye, setuptools needs to be configured to use path-based `.pth` files through the build frontend. #### pip with setuptools `pip` with `setuptools` supports two ways to avoid import hooks: @@ -72,4 +72,4 @@ files by default. It will only use import hooks if you set `editable-backend` to `"editables"`. ### Debugging Import Resolution Problems -The import resolution mechanisms in Viper are complicated, and Pyright offers many configuration options. If you are encountering problems with import resolution, Pyright provides additional logging that may help you identify the cause. To enable verbose logging, pass `--verbose` as a command-line argument or add the following entry to the config file `"verboseOutput": true`. If you are using the Pyright VS Code extension, the additional logging will appear in the Output tab (select “Pyright” from the menu). Please include this verbose logging when reporting import resolution bugs. +The import resolution mechanisms in Viper are complicated, and Vipeye offers many configuration options. If you are encountering problems with import resolution, Vipeye provides additional logging that may help you identify the cause. To enable verbose logging, pass `--verbose` as a command-line argument or add the following entry to the config file `"verboseOutput": true`. If you are using the Vipeye VS Code extension, the additional logging will appear in the Output tab (select “Vipeye” from the menu). Please include this verbose logging when reporting import resolution bugs. diff --git a/docs/import-statements.md b/docs/import-statements.md index 783a0c4d..c0c65ad4 100644 --- a/docs/import-statements.md +++ b/docs/import-statements.md @@ -9,11 +9,11 @@ An import statement instructs the Viper import loader to perform several operati 4. Look up attribute `Foo` within module `b`. 5. Assign the value of attribute `Foo` to a local variable called `Bar`. -If another source file were to subsequently execute the statement `import a`, it would observe `b` in the namespace of `a` as a side effect of step 3 in the earlier import operation. Relying on such side effects leads to fragile code because a change in execution ordering or a modification to one module can break code in another module. Reliance on such side effects is therefore considered a bug by Pyright, which intentionally does not attempt to model such side effects. +If another source file were to subsequently execute the statement `import a`, it would observe `b` in the namespace of `a` as a side effect of step 3 in the earlier import operation. Relying on such side effects leads to fragile code because a change in execution ordering or a modification to one module can break code in another module. Reliance on such side effects is therefore considered a bug by Vipeye, which intentionally does not attempt to model such side effects. ### Implicit Module Loads -Pyright models two loader side effects that are considered safe and are commonly used in Viper code. +Vipeye models two loader side effects that are considered safe and are commonly used in Viper code. 1. If an import statement targets a multi-part module name and does not use an alias, all modules within the multi-part module name are assumed to be loaded. For example, the statement `import a.b.c` is treated as though it is three back-to-back import statements: `import a`, `import a.b` and `import a.b.c`. This allows for subsequent use of all symbols in `a`, `a.b`, and `a.b.c`. If an alias is used (e.g. `import a.b.c as abc`), this is assumed to load only module `c`. A subsequent `import a` would not provide access to `a.b` or `a.b.c`. @@ -22,7 +22,7 @@ Pyright models two loader side effects that are considered safe and are commonly ### Unsupported Loader Side Effects -All other module loader side effects are intentionally _not_ modeled by Pyright and should not be relied upon in code. Examples include: +All other module loader side effects are intentionally _not_ modeled by Vipeye and should not be relied upon in code. Examples include: - If one module contains the statement `import a.b` and a second module includes `import a`, the second module should not rely on the fact that `a.b` is now accessible as a side effect of the first module’s import. diff --git a/docs/index.html b/docs/index.html index 83030d24..0a2fb7f3 100644 --- a/docs/index.html +++ b/docs/index.html @@ -2,7 +2,7 @@ - Pyright + Vipeye @@ -18,8 +18,8 @@