Meeting here in ~30 minutes. I've updated the sprint document to contain more of the details from this sprint. I've also tried to open more issues and things, though I suspect we could do better at "opening up" smaller steps and filing issues.

That's what I mean ..

I guess we can briefly overview what's there

@Keith Yeung is looking at extending chalk with dyn and impl types, laying the groundwork for trait objects; once that work is done, we'll want to discuss how to integrate those rules into implied bounds (@scalexm has a proposal here)

@Sunjay Varma is looking at some of the "basics of specialization. I'm separating that work into a few parts. This part is the simpler part, I think. It focuses on "if have a legal specialization (for some definition), how do we adjust the chalk lowering to take that into account"

(this is partly why I had such a fine-grained division of crates to start)

new insights mean new create structures :slight_smile:

so I guess the main work item remains trying to implement the 'non-enumerable idea', or come up with a better one; I left some high-level notes on how that should work but I'd like to spend more time on it.

there are many setups which would be fine

the main observation is that what is presently the "root crate" is really just an elaborate testing harness

so it'd probably be better to have chalk-solve by the "root crate", and move that harness and supporting infrastructure into other crates; one way to do this would be to use the cargo tests directory to houes the tests themselves

Yup, seems natural

:check_mark:

# Goal: rustc-chalk interation improvements

there is actually more we could write here, I realize, but I feel like the most important is probably to try and "run the solve" and get more specific about what goes wrong. I still feel like there are some unknowns. One thing we do know is a problem is region solving, but I'd sort of like to try and factor that out and see what other problems we hit. Anyway, this is presently unassigned, but I also don't have very discrete tasks broken out because it feels a bit 'exploratory'

(Also, it's worth pointing out that the "reproducing rustc" work around built-in bounds etc ought to directly affect rust-analyzer)

I've been wondering about creating some goals around rust-analyzer and trying to populate them a bit

Ah, one other thing I jsut remembered is that I'm pretty sure the existing solver has a bug around co-inductive cycles (rustc had a similar bug...) and I need to file an issue with a test case for that...