feat: MIR episode 5

[HKalbasi]

This PR inits drop support (it is very broken at this stage, some things are dropped multiple time, drop scopes are wrong, ...) and adds stdout support (println! doesn't work since its expansion is dummy, but stdout().write(b"hello world\n") works if you use RA_SYSROOT_HACK) for interpreting. There is no useful unit test that it can interpret yet, but it is a good sign that it didn't hit a major road block yet.

In MIR lowering, it adds support for slice pattern and anonymous const blocks, and some fixes so that we can evaluate SmolStr::new_inline in const eval. With these changes, 57 failed mir body remains.

[HKalbasi]

@bors r+

[bors]

📌 Commit cbcafd3 has been approved by HKalbasi

It is now in the queue for this repository.

[bors]

⌛ Testing commit cbcafd3 with merge 034d7c8...

[bors]

☀️ Test successful - checks-actions
Approved by: HKalbasi
Pushing 034d7c8 to master...

[HKalbasi]

This broke something. I'm on it. No it was #14820

[Veykril]

This increased memory usage on self by 200mb

[lnicola]

I think that's because we're including MIR in the measurement? There was a big increase when we added it to analysis-stats, too.

[Veykril]

Yes it is, but that will still accumulate for users over time since we build MIR for all opened files for diagnostics so it is something to keep in mind here. We might wanna LRU some of the queries there.

Also on another note, some PR (I imagine either this one or the change of format_args from lazy to eager) caused a bunch of unknown types for r-a, we went from 34 to 83

[Veykril]

Needless to say we need to do something about memory usage now again as this is quite a big increase overall now over the past month.

[HKalbasi]

This PR added many Drop blocks to mir, that probably explain the increase.

There are many low hanging fruit in optimizing memory of mir I guess. It doesn't even shrink_to_fit the mir body query.

[homersimpsons]

This increased memory usage on self by 200mb

For the record, this was reduced back to normal with #14847

[HKalbasi]

Not really, the increase of #14843 should be attributed to this PR as well. But I still see some low hanging fruits in MIR memory usage, it is not done yet.