Commit some new solver tests #108522
Commit some new solver tests #108522
Conversation
rustbot
added
S-waiting-on-review
|
So, why not use revisions for different trait solvers? If these cases aren't covered under existing tests, then they should be. If they are, why the extra tests? I suppose this is more of a philosophical question. (Same question applies to chalk or NLL tests, for example). Either these tests represent expected new behavior (in which case this is fine) or they represent "hard" cases for the new trait solver (which brings up the question of "should these stick around when the solver is complete" or be around at all). I think probably applies to other tests, so r=me for now, but we should think about this. |
I have no idea if they're covered by existing tests -- probably, but also sorting through the existing test suite to look for UI tests that replicate these tests's behaviors is pretty difficult, given that the rest of the UI test suite absolutely explodes on the new solver. Generally, though, I'd like these tests to be mostly consolidated so that we don't have to run the whole test suite on the new solver when it's still in very early experimentation mode.
I mean, UI tests committed for ICEs have no equivalent concept. Basically all other UI tests are committed in perpetuity, so I don't see why a handful of new-solver tests are that much of an issue 😸
Yeah, it's definitely because of this. @bors r=jackh726 |
bors
added
S-waiting-on-bors
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#104265 (Move IpAddr, SocketAddr and V4+V6 related types to `core`) - rust-lang#107110 ([stdio][windows] Use MBTWC and WCTMB) - rust-lang#108308 (Allow building serde and serde_derive in parallel) - rust-lang#108363 (Move the unused extern crate check back to the resolver.) - rust-lang#108519 (Bages for easy access links to Rust community) - rust-lang#108522 (Commit some new solver tests) - rust-lang#108523 (Avoid `&str` to `String` conversions) - rust-lang#108533 (diagnostics: avoid querying `associated_item` in the resolver) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Lazy norm is hard.
<?0 as Trait>::Assoc = ?0... probably should emit an alias-eq goal, but currently we don't do that. Right now it fails with a cyclical ty error.Also committed a check-pass test that broken when I attempted to fix this (unsuccessfully).
r? types