Merge branch 'main' into copilot/fix-24562

Author: eleanorjboyd

.github/actions/build-vsix/action.yml

@@ -22,7 +22,7 @@ runs:
   using: 'composite'
   steps:
     - name: Install Node
-      uses: actions/setup-node@v4
+      uses: actions/setup-node@v6
       with:
         node-version: ${{ inputs.node_version }}
         cache: 'npm'
@@ -32,7 +32,7 @@ runs:
 
     # Jedi LS depends on dataclasses which is not in the stdlib in Python 3.7.
     - name: Use Python 3.9 for JediLSP
-      uses: actions/setup-python@v5
+      uses: actions/setup-python@v6
       with:
         python-version: 3.9
         cache: 'pip'
@@ -93,7 +93,7 @@ runs:
         VSIX_NAME: ${{ inputs.vsix_name }}
 
     - name: Upload VSIX
-      uses: actions/upload-artifact@v4
+      uses: actions/upload-artifact@v6
       with:
         name: ${{ inputs.artifact_name }}
         path: ${{ inputs.vsix_name }}

.github/actions/lint/action.yml

@@ -10,7 +10,7 @@ runs:
   using: 'composite'
   steps:
     - name: Install Node
-      uses: actions/setup-node@v4
+      uses: actions/setup-node@v6
       with:
         node-version: ${{ inputs.node_version }}
         cache: 'npm'
@@ -36,7 +36,7 @@ runs:
       shell: bash
 
     - name: Install Python
-      uses: actions/setup-python@v5
+      uses: actions/setup-python@v6
       with:
         python-version: '3.x'
         cache: 'pip'

.github/instructions/learning.instructions.md

@@ -0,0 +1,34 @@
+---
+applyTo: '**'
+description: This document describes how to deal with learnings that you make. (meta instruction)
+---
+
+This document describes how to deal with learnings that you make.
+It is a meta-instruction file.
+
+Structure of learnings:
+
+-   Each instruction file has a "Learnings" section.
+-   Each learning has a counter that indicates how often that learning was useful (initially 1).
+-   Each learning has a 1 sentence description of the learning that is clear and concise.
+
+Example:
+
+```markdown
+## Learnings
+
+-   Prefer `const` over `let` whenever possible (1)
+-   Avoid `any` type (3)
+```
+
+When the user tells you "learn!", you should:
+
+-   extract a learning from the recent conversation
+    _ identify the problem that you created
+    _ identify why it was a problem
+    _ identify how you were told to fix it/how the user fixed it
+    _ generate only one learning (1 sentence) that helps to summarize the insight gained
+-   then, add the reflected learning to the "Learnings" section of the most appropriate instruction file
+
+Important: Whenever a learning was really useful, increase the counter!!
+When a learning was not useful and just caused more problems, decrease the counter.

.github/instructions/pytest-json-test-builder.instructions.md

@@ -0,0 +1,126 @@
+---
+applyTo: 'python_files/tests/pytestadapter/test_discovery.py'
+description: 'A guide for adding new tests for pytest discovery and JSON formatting in the test_pytest_collect suite.'
+---
+
+# How to Add New Pytest Discovery Tests
+
+This guide explains how to add new tests for pytest discovery and JSON formatting in the `test_pytest_collect` suite. Follow these steps to ensure your tests are consistent and correct.
+
+---
+
+## 1. Add Your Test File
+
+-   Place your new test file/files in the appropriate subfolder under:
+    ```
+    python_files/tests/pytestadapter/.data/
+    ```
+-   Organize folders and files to match the structure you want to test. For example, to test nested folders, create the corresponding directory structure.
+-   In your test file, mark each test function with a comment:
+    ```python
+    def test_function():  # test_marker--test_function
+        ...
+    ```
+
+**Root Node Matching:**
+
+-   The root node in your expected output must match the folder or file you pass to pytest discovery. For example, if you run discovery on a subfolder, the root `"name"`, `"path"`, and `"id_"` in your expected output should be that subfolder, not the parent `.data` folder.
+-   Only use `.data` as the root if you are running discovery on the entire `.data` folder.
+
+**Example:**
+If you run:
+
+```python
+helpers.runner([os.fspath(TEST_DATA_PATH / "myfolder"), "--collect-only"])
+```
+
+then your expected output root should be:
+
+```python
+{
+    "name": "myfolder",
+    "path": os.fspath(TEST_DATA_PATH / "myfolder"),
+    "type_": "folder",
+    ...
+}
+```
+
+---
+
+## 2. Update `expected_discovery_test_output.py`
+
+-   Open `expected_discovery_test_output.py` in the same test suite.
+-   Add a new expected output dictionary for your test file, following the format of existing entries.
+-   Use the helper functions and path conventions:
+    -   Use `os.fspath()` for all paths.
+    -   Use `find_test_line_number("function_name", file_path)` for the `lineno` field.
+    -   Use `get_absolute_test_id("relative_path::function_name", file_path)` for `id_` and `runID`.
+    -   Always use current path concatenation (e.g., `TEST_DATA_PATH / "your_folder" / "your_file.py"`).
+    -   Create new constants as needed to keep the code clean and maintainable.
+
+**Important:**
+
+-   Do **not** read the entire `expected_discovery_test_output.py` file if you only need to add or reference a single constant. This file is very large; prefer searching for the relevant section or appending to the end.
+
+**Example:**
+If you run discovery on a subfolder:
+
+```python
+helpers.runner([os.fspath(TEST_DATA_PATH / "myfolder"), "--collect-only"])
+```
+
+then your expected output root should be:
+
+```python
+myfolder_path = TEST_DATA_PATH / "myfolder"
+my_expected_output = {
+    "name": "myfolder",
+    "path": os.fspath(myfolder_path),
+    "type_": "folder",
+    ...
+}
+```
+
+-   Add a comment above your dictionary describing the structure, as in the existing examples.
+
+---
+
+## 3. Add Your Test to `test_discovery.py`
+
+-   In `test_discovery.py`, add your new test as a parameterized case to the main `test_pytest_collect` function. Do **not** create a standalone test function for new discovery cases.
+-   Reference your new expected output constant from `expected_discovery_test_output.py`.
+
+**Example:**
+
+```python
+@pytest.mark.parametrize(
+    ("file", "expected_const"),
+    [
+        ("myfolder", my_expected_output),
+        # ... other cases ...
+    ],
+)
+def test_pytest_collect(file, expected_const):
+    ...
+```
+
+---
+
+## 4. Run and Verify
+
+-   Run the test suite to ensure your new test is discovered and passes.
+-   If the test fails, check your expected output dictionary for path or structure mismatches.
+
+---
+
+## 5. Tips
+
+-   Always use the helper functions for line numbers and IDs.
+-   Match the folder/file structure in `.data` to the expected JSON structure.
+-   Use comments to document the expected output structure for clarity.
+-   Ensure all `"path"` and `"id_"` fields in your expected output match exactly what pytest returns, including absolute paths and root node structure.
+
+---
+
+**Reference:**
+See `expected_discovery_test_output.py` for more examples and formatting. Use search or jump to the end of the file to avoid reading the entire file when possible.

.github/instructions/python-quality-checks.instructions.md

@@ -0,0 +1,97 @@
+---
+applyTo: 'python_files/**'
+description: Guide for running and fixing Python quality checks (Ruff and Pyright) that run in CI
+---
+
+# Python Quality Checks — Ruff and Pyright
+
+Run the same Python quality checks that run in CI. All checks target `python_files/` and use config from `python_files/pyproject.toml`.
+
+## Commands
+
+```bash
+npm run check-python              # Run both Ruff and Pyright
+npm run check-python:ruff         # Linting and formatting only
+npm run check-python:pyright      # Type checking only
+```
+
+## Fixing Ruff Errors
+
+**Auto-fix most issues:**
+
+```bash
+cd python_files
+python -m ruff check . --fix
+python -m ruff format
+npm run check-python:ruff  # Verify
+```
+
+**Manual fixes:**
+
+-   Ruff shows file, line number, rule code (e.g., `F841`), and description
+-   Open the file, read the error, fix the code
+-   Common: line length (100 char max), import sorting, unused variables
+
+## Fixing Pyright Errors
+
+**Common patterns and fixes:**
+
+-   **Undefined variable/import**: Add the missing import
+-   **Type mismatch**: Correct the type or add type annotations
+-   **Missing return type**: Add `-> ReturnType` to function signatures
+    ```python
+    def my_function() -> str:  # Add return type
+        return "result"
+    ```
+
+**Verify:**
+
+```bash
+npm run check-python:pyright
+```
+
+## Configuration
+
+-   **Ruff**: Line length 100, Python 3.9+, 40+ rule families (flake8, isort, pyupgrade, etc.)
+-   **Pyright**: Version 1.1.308 (or whatever is found in the environment), ignores `lib/` and 15+ legacy files
+-   Config: `python_files/pyproject.toml` sections `[tool.ruff]` and `[tool.pyright]`
+
+## Troubleshooting
+
+**"Module not found" in Pyright**: Install dependencies
+
+```bash
+python -m pip install --upgrade -r build/test-requirements.txt
+nox --session install_python_libs
+```
+
+**Import order errors**: Auto-fix with `ruff check . --fix`
+
+**Type errors in ignored files**: Legacy files in `pyproject.toml` ignore list—fix if working on them
+
+## When Writing Tests
+
+**Always format your test files before committing:**
+
+```bash
+cd python_files
+ruff format tests/  # Format all test files
+# or format specific files:
+ruff format tests/unittestadapter/test_utils.py
+```
+
+**Best practice workflow:**
+
+1. Write your test code
+2. Run `ruff format` on the test files
+3. Run the tests to verify they pass
+4. Run `npm run check-python` to catch any remaining issues
+
+This ensures your tests pass both functional checks and quality checks in CI.
+
+## Learnings
+
+-   Always run `npm run check-python` before pushing to catch CI failures early (1)
+-   Use `ruff check . --fix` to auto-fix most linting issues before manual review (1)
+-   Pyright version must match CI (1.1.308) to avoid inconsistent results between local and CI runs (1)
+-   Always run `ruff format` on test files after writing them to avoid formatting CI failures (1)