Stream: t-compiler

Topic: extending everybody_loops


pnkfelix (Aug 02 2018 at 15:35, on Zulip):

Hey @eddyb I wanted to get your feedback on something here (@varkor may have opinions too?)

pnkfelix (Aug 02 2018 at 15:36, on Zulip):

the supposed goal is to include impl's that occur underneath fn bodies

pnkfelix (Aug 02 2018 at 15:36, on Zulip):

but those impl's might be implementing traits that are only defined in those fn bodies, or in mods that are only in those fn bodies, etc

nagisa (Aug 02 2018 at 15:37, on Zulip):

IMHO it is not correct for rustdoc to be collecting items with a visitor.

pnkfelix (Aug 02 2018 at 15:37, on Zulip):

A couple different options I see here are: 1. punt: If you impl a trait that was declared under fn, then you lose (as in, rustdoc might break in some way for you),

nagisa (Aug 02 2018 at 15:38, on Zulip):

And even then, it should be possible for rustdoc to make a visitor that does not visit bodies?

nagisa (Aug 02 2018 at 15:38, on Zulip):

AST is a tree after all.

pnkfelix (Aug 02 2018 at 15:39, on Zulip):

I guess we can categorize @nagisa's note as Option 2: tell rustdoc to stop doing it whatever way they're doing it now, and instead write a different visitor/folder implementation specialized totheir needs?

pnkfelix (Aug 02 2018 at 15:42, on Zulip):

option 3: make -Z everybody_loop include all sorts of items underneath fn bodies, beyond impl items. I would assume to be robust (in the sense that output from -Z everybody_loop is meant to be accepted by rustc whenever the original code was accepted) that we would have to include pretty much every kind of item. (And instead the filtering would be based on inspecting what kind of StmtKind we are looking at.)

pnkfelix (Aug 02 2018 at 15:47, on Zulip):

@eddyb assertly earlier (correctly, I think) that rustdoc is the only serious client of -Z unpretty=everybody_loops. Even I haven't used it in quite some time.

pnkfelix (Aug 02 2018 at 15:48, on Zulip):

I personally wanted to help with any adjustment that happened to it, in part because I feel responsible for whatever damage it has done, and also because I want to make sure that it keeps working for my own needs in the future.

pnkfelix (Aug 02 2018 at 15:48, on Zulip):

Having said that, I think I would be totally fine with having it include the items under fn bodies.

pnkfelix (Aug 02 2018 at 15:48, on Zulip):

(and effectively it would "just" be filtering out all expressions instead of the more invasive rewrite that it did before.)

pnkfelix (Aug 02 2018 at 15:49, on Zulip):

But either way, I don't think the relatively simple "block accumulation" strategy that @eddyb recommended last night on Discord is quite good enough ...

oli (Aug 02 2018 at 15:54, on Zulip):

There might also be things like

x = ["foo"; { impl Trait for Struct { ... } 3}];

which is not an item but contains an impl

oli (Aug 02 2018 at 15:57, on Zulip):

could the rustdoc driver just stop before item collection and do its stuff there? Without compiling everything we can basically never guarantee that we found everything.

oli (Aug 02 2018 at 15:58, on Zulip):

we might even prevent the generation of most MIR (of constants and const fn we'd still need it)

eddyb (Aug 02 2018 at 16:03, on Zulip):

@pnkfelix if you don't tab-complete me you won't ping me (e.g. @pnkfelix wouldn't ping you either)

pnkfelix (Aug 02 2018 at 16:04, on Zulip):

Arg yes I should know that by now

eddyb (Aug 02 2018 at 16:04, on Zulip):

and I assumed that the only sane thing to do is collect all items

eddyb (Aug 02 2018 at 16:04, on Zulip):

including the block nesting around them

eddyb (Aug 02 2018 at 16:04, on Zulip):

to not break { fn foo() {} } { fn foo() {} }

pnkfelix (Aug 03 2018 at 17:42, on Zulip):

You’d be surprised how far one might get with insane approaches

pnkfelix (Aug 03 2018 at 17:42, on Zulip):

This is the problem with a short user name

Last update: Nov 22 2019 at 05:30UTC