Caching trait solving can do a lot to speed. Unfortunately it also consume a huge amount of memory. Therefore, as part of the migration to the new solver Jack Huey disabled caching of trait solving (he made the query transparent).
The PR proposes a middle ground: do cache trait solving, but only for the same revision. This allows us to be safe because during a revision the inputs cannot change.
The result is hopefully much better performance to features that tend to do a bulk of trait solving, and also repeat the same query (e.g. inference then IDE features).
There is another limitation: results are only cached in the same thread, to remove the need for synchronization which will be expensive. More measurements are required to check whether it's better to use a synchronized global cache, or maybe stay with a thread-local cache but batch multiple feature requests (highlighting, inlay hints etc.) of the same file to the same thread.
Alongside the actual cache we store the revision, because we need to verify it (we can't eagerly clear caches when incrementing the revision), and also the address of the db to prevent multiple dbs from interleaving (this is mostly relevant in tests, although injected highlighting also uses a new db, therefore maybe it's better to move it to a separate thread).
This "games" analysis-stats to both be way faster and use way more memory; the former is because analysis-stats doesn't increment revisions, therefore all queries share the cache and hit ratio is way too good, the latter is because analysis-stats doesn't increment revisions and therefore the cache isn't cleared. Both are not representative of a typical IDE scenario.
And leave only the type stuff without it.
This is because most expression stores don't have anything but types (e.g. generics, fields, signatures) so this saves a lot of memory.
This saves 58mb on `analysis-stats .`.
Even when at curly braces, otherwise the parser can get stuck.
This has happened in the past in #18625, but it was just worked around instead of handling the root of the problem. Now this happened again in #20171. IMO we can't let `err_and_bump()` not bump, that's too confusing and invites errors. We can (as I did) workaround the worse recovery instead.
1. Err on unions on derive where it's required.
2. Err on `#[derive(Default)]` on enums without `#[default]` variant.
3. Don't add where bounds `T: Default` when expanding `Default` on enums (structs need that, enums not).
Also, because I was annoyed by that, in minicore, add a way to filter on multiple flags in the line-filter (`// :`). This is required for the `Debug` and `Hash` derives, because the derive should be in the prelude but the trait not.
