* main: (26 commits)
Use the common `OperatorPrecedence` for the parser (#16747)
[red-knot] Check subtype relation between callable types (#16804)
[red-knot] Check whether two callable types are equivalent (#16698)
[red-knot] Ban most `Type::Instance` types in type expressions (#16872)
Special-case value-expression inference of special form subscriptions (#16877)
[syntax-errors] Fix star annotation before Python 3.11 (#16878)
Recognize `SyntaxError:` as an error code for ecosystem checks (#16879)
[red-knot] add test cases result in false positive errors (#16856)
Bump 0.11.1 (#16871)
Allow discovery of venv in VIRTUAL_ENV env variable (#16853)
Split git pathspecs in change determination onto separate lines (#16869)
Use the correct base commit for change determination (#16857)
Separate `BitXorOr` into `BitXor` and `BitOr` precedence (#16844)
Server: Allow `FixAll` action in presence of version-specific syntax errors (#16848)
[`refurb`] Fix starred expressions fix (`FURB161`) (#16550)
[`flake8-executable`] Add pytest and uv run to help message for `shebang-missing-python` (`EXE003`) (#16855)
Show more precise messages in invalid type expressions (#16850)
[`flake8-executables`] Allow `uv run` in shebang line for `shebang-missing-python` (`EXE003`) (#16849)
Add `--exit-non-zero-on-format` (#16009)
[red-knot] Ban list literals in most contexts in type expressions (#16847)
...
base.shaappears to be the commit of the base branch when the pull request was opened, not the base commit that's used to construct the test merge commit — which can lead to incorrect "determine changes" results where commits made to the base ref since the pull request are opened are included in the results.We use
git merge-baseto find the correct sha, as I don't think that GitHub provides this. They providemerge_commit_shabut my understanding is that is equivalent to the actual merge commit we're testing in CI.I tested this locally on an example pull request. I don't think it's worth trying to reproduce a specific situation here.