Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add tests for case-sensitive module resolution #16517

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

MichaReiser
Copy link
Member

@MichaReiser MichaReiser commented Mar 5, 2025

Summary

Python's module resolver is case sensitive.

This PR adds mdtests that assert that our module resolution is case sensitive.

The tests currently all pass because our in memory file system is case sensitive.
I'll add support for using the real file system to the mdtest framework in a separate PR.

This PR also adds support for specifying extra search paths to the mdtest framework.

Test Plan

The tests fail when running them using the real file system.

@MichaReiser MichaReiser added the red-knot Multi-file analysis & type inference label Mar 5, 2025
@MichaReiser MichaReiser marked this pull request as draft March 5, 2025 12:47
@MichaReiser MichaReiser force-pushed the micha/case-sensitive-module-resolver-tests branch from 1c4abaf to d11b254 Compare March 5, 2025 12:48
@MichaReiser MichaReiser marked this pull request as ready for review March 5, 2025 12:49
@MichaReiser MichaReiser force-pushed the micha/case-sensitive-module-resolver-tests branch 3 times, most recently from f7e3f8c to aebf24a Compare March 5, 2025 13:49
@MichaReiser MichaReiser force-pushed the micha/case-sensitive-module-resolver-tests branch from aebf24a to ad5e00e Compare March 5, 2025 13:49
`a.py`:

```py
class A:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: I think using a class named A in these tests is confusing for no benefit, when it could be named C or anything else

from db.A import A
```

## Incorrectly extension casing
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
## Incorrectly extension casing
## Incorrect extension casing

x: int = 1
```

```python
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't love having our mdtests start to use an essentially-random mix of py vs python, but IIRC your editor makes it hard for you to use py?

Copy link
Member Author

@MichaReiser MichaReiser Mar 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RustRover always suggests python and not py. It's also hard-coded in my brain because that's what I used consistently everywhere before red knot (there are more than 103 matches for ```python in our code base).

@@ -118,7 +118,7 @@ fn run_test(
}

assert!(
matches!(embedded.lang, "py" | "pyi" | "text"),
matches!(embedded.lang, "py" | "pyi" | "python" | "text"),
"Supported file types are: py, pyi, text"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the assertion message may now need to be updated to mention python? Which means we may also want to change the message so it talks about "language tags" rather than "file types"

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
red-knot Multi-file analysis & type inference
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants