assessing size overhead from this feature

[nikomatsakis]

As discussed today, we should create a custom lint that checks how big a closure is when using this feature (this can be done by looking at the results of min-capture analysis, even if the feature is disabled) and compares it to the size of a closure using only upvars-mentioned. The lint could trigger if the size increases by more than N% and we can do a crater run to get a sense of how often that occurs. Something like that.

[Mark-Simulacrum]

FWIW I'd be really interested in dumping "average size of a closure" or even ideally distribution data before/after, not just growth; if we have the compiler emit it in some standard-ish format for each closure then downloading all logs from crater (e.g. se available options here: https://crater-reports.s3.amazonaws.com/beta-1.50-1/downloads.html) and pulling the data should not be too hard, and lets us answer ~any question we want here.

[nikomatsakis]

I was thinking the same thing. Crater isn't really the right tool for this, what I really want is to get measurements. If there are options for that, it'd be great.

[Mark-Simulacrum]

I'm saying that I think we can use crater for this without too much difficulty - did my proposal not make sense?

[nikomatsakis]

Sorry, I typed too fast. What I meant is "causing warnings or errors is not the right tool for this". Scraping crater LOGS is a great idea.