mypy_primer results

No ecosystem changes detected ✅

Most of the diffs in the mypy primer seem to be caused by the lack of support for Self

This one is a crash:

itsdangerous (https://github.com/pallets/itsdangerous)
+ 
+ thread '<unnamed>' panicked at /home/runner/.cargo/git/checkouts/salsa-e6f3bb7c2a062968/d758691/src/function/fetch.rs:154:25:
+ dependency graph cycle querying all_negative_narrowing_constraints_for_expression(Id(c413)); set cycle_fn/cycle_initial to fixpoint iterate
+ note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
+ Rayon: detected unexpected panic; aborting

OMG 😅 I’ll check the panic in the mypy primer first and then request review again.

I'm not sure if the panic is due to your PR. It is the same that @carljm has seen on other mypy primer projects.

I'm not sure if the panic is due to your PR. It is the same that @carljm has seen on other mypy primer projects.

It shows that this PR causes us to panic on code that we did not previously panic on. Maybe that's acceptable if we want to defer adding cycle handling to the relevant function for now, but it's going to lead to pretty confusing diffs if we include projects we panic on in mypy_primer. I think at the very least we should remove the project from the list in the workflow file of projects we run on in CI if we're going to start panicking on that project:

but also: adding cycle handling to a query probably isn't that difficult, and it's nice to at least not increase the amount of code we panic on. @cake-monotone, you can see an example of how to do it here: #16958 :-) I'd imagine adding cycle handling to all_negative_narrowing_constraints_for_expression probably won't look too different to the changes I made in that PR.

Agree. @carljm might be able to prioritize the fix real quick to unblock this PR

Agree. @carljm might be able to prioritize the fix real quick to unblock this PR

It's okay! I'll try to fix it soon...!

I'm not sure if the panic is due to your PR. It is the same that @carljm has seen on other mypy primer projects.

It shows that this PR causes us to panic on code that we did not previously panic on. Maybe that's acceptable if we want to defer adding cycle handling to the relevant function for now, but it's going to lead to pretty confusing diffs if we include projects we panic on in mypy_primer. I think at the very least we should remove the project from the list in the workflow file of projects we run on in CI if we're going to start panicking on that project:

ruff/.github/workflows/mypy_primer.yaml

Line 71 in 755ece0

--project-selector '/(mypy_primer|black|pyp|git-revise|zipp|arrow|isort|itsdangerous|rich|packaging|pybind11|pyinstrument|typeshed-stats|scrapy)$' \

but also: adding cycle handling to a query probably isn't that difficult, and it's nice to at least not increase the amount of code we panic on. @cake-monotone, you can see an example of how to do it here: #16958 :-) I'd imagine adding cycle handling to all_negative_narrowing_constraints_for_expression probably won't look too different to the changes I made in that PR.

I just need to define a custom cycle_recover function and cycle_initial for all_negative_narrowing_constraints_for_expression, right?
If I’m understanding that correctly, it shouldn’t take too long

I just need to define a custom cycle_recover function and cycle_initial for all_negative_narrowing_constraints_for_expression, right? If I’m understanding that correctly, it shouldn’t take too long

I think that's correct, yes!

Ah... it's still not working. the mypy primer still panics 😢

Here's the commit if you'd like to take a look:
cake-monotone@a737bfe

hmm, okay, we may need @carljm's advice on how to fix this; he's the fixpoint expert :-)

It turns out that there were actually two functions causing the panic: all_narrowing_constraints_for_expression and all_negative_narrowing_constraints_for_expression. After applying what Alex suggested to both of them, the panic was resolved.

@carjim Hmm, just checking, are you planning to open a separate PR to implement cycle_fn to these functions?
If not, I’d be happy to include it in this PR :)

Sorry for the long delay on this PR. I've been pretty drained over the past two weeks due to some other things going on, and didn’t have the energy to polish it to a state I was happy with.

Anyway, since the last review, a lot has changed — including improvements in handling dynamic types, fixes for incorrect enclosing class inference, and support for generic classes.

I'd really appreciate it if you could take another look. :)

Excellent work on this PR, thank you!!