Brian Anderson

One plausible way to fix this would be to have skeptic synthesize an entire cargo project from the original cargo project, for every test it generates, sharing target directories. Then...

I'm marking this help wanted, to try to implement the 'synthesize-a-cargo-project' solution I suggested previously. It doesn't seem all that complex to do.

@budziq if that route is viable then it sounds awesome. I did not know it was possible to correlate specified dependencies with the resulting crate names.

I've started hacking on a fix for this that emits every test case as an individual cargo project, sharing the target directory with the "master" project.

Another way to tackle this problem is to use cargo's unstable `--build-plan` flag, which looks like it contains enough metadata to find the correct libraries. I'm not pursuing that right...

Thanks for the feedback @budziq! I'm pretty far down this rabbit hole now, so I'll see for myself the problems you encountered. I do have an idea I mentioned in...

Ok, it's not in a mergable state yet, but here's a branch that overhauls how tests are run, using cargo to deal with resolution: https://github.com/budziq/rust-skeptic/compare/master...brson:next I think this approach is...

I pushed an additional commit that asserts that coalescing resulted in a free table, and I'm interested in other assertions I should be making.

> > (The benchmark workload is ineffective at triggering this optimization, but the forest_fuzz triggers it at all levels). > > Is this because the benchmark creates full batches, which...

I've resolved @matklad's reviews. Thanks! Have not resolved others yet.