@mw is there a single scenario where invoking a collector in check mode is a correct course of action?
I figure that in case there isn't one it would make sense to add the condition inside the collector query.
@mw do you have any idea why cargo check would end up invoking the full codegen?
I had hoped that fixing metadata generation code to not use the optimising context would work.
but now it is invoking the regular one...
but this in general goes against my intuition about what cargo check ought to be doing
I think it basically uses the existing pipeline to pack the metadata into the rlib
(i.e. generate metadata and quit)
you should be able to just add an early exit in the query provider
doing the same check as the metadata encoder does
but I agree that this isn't the cleanest setup
yaeh so I was wondering, why not add such an early exit to the partition query in the first place.
it seems fine for me for partitioner to return an empty set of CUs when it knows that it would fail collecting either way
for now I’ll just make sure that non-optimising context is used in ssa backend as well
It's a bit tricky. Technically we don't know that it will fail. We know the current build is only producing metadata data but upstream crates might have been compiled the regular way in which case everything would work fine.
in practice this does not usually occur