Stream: t-compiler/meetings

Topic: [weekly meeting] 2020-07-02 #54818


Santiago Pastorino (Jul 01 2020 at 21:13, on Zulip):

Hi @T-compiler/meeting; the triage meeting will be starting in 16 hours 47 minutes

Santiago Pastorino (Jul 01 2020 at 21:13, on Zulip):

The @WG-prioritization have done pre-triage in #t-compiler/wg-prioritization-alerts

Santiago Pastorino (Jul 01 2020 at 21:14, on Zulip):

@WG-prioritization have prepared the meeting agenda, still polishing some details

Santiago Pastorino (Jul 01 2020 at 21:15, on Zulip):

We will have one checkin this time from @WG-traits

Santiago Pastorino (Jul 01 2020 at 21:15, on Zulip):

@nikomatsakis || @Jack Huey do you have something you want to share about @WG-traits?

Jack Huey (Jul 01 2020 at 21:16, on Zulip):

Sure :)

Santiago Pastorino (Jul 01 2020 at 21:17, on Zulip):

Jack Huey said:

Sure :)

feel free to fill it directly in https://hackmd.io/zg0MC_eEQkqvsXO0uQnXpA?both#WG-checkins

Santiago Pastorino (Jul 01 2020 at 21:18, on Zulip):

@Jack Huey for that I'm going to need to add your HackMD username in our HackMD Rust compiler team to give you write access

Jack Huey (Jul 01 2020 at 21:19, on Zulip):

@oHHHULaRQWucqVT5tvMj4g? I think?

Santiago Pastorino (Jul 01 2020 at 21:19, on Zulip):

and btw, everyone that wants to have access to our HackMD Rust compiler team space feel free to send me a PM with your Hackmd username

Santiago Pastorino (Jul 01 2020 at 21:20, on Zulip):

Jack Huey said:

@oHHHULaRQWucqVT5tvMj4g? I think?

doesn't seem to be that one

Santiago Pastorino (Jul 01 2020 at 21:21, on Zulip):

I think I need just the name you see above that id

Jack Huey (Jul 01 2020 at 21:22, on Zulip):

Try @jackh726

Jack Huey (Jul 01 2020 at 21:22, on Zulip):

(I didn't realize you can set it. So, maybe that was it)

Santiago Pastorino (Jul 01 2020 at 21:22, on Zulip):

added that username, check if you can now :)

Jack Huey (Jul 01 2020 at 21:24, on Zulip):

Yes :)

Santiago Pastorino (Jul 02 2020 at 13:35, on Zulip):

Hi @T-compiler/meeting; the triage meeting will be starting in 25 minutes

Santiago Pastorino (Jul 02 2020 at 13:36, on Zulip):

Check out the meeting agenda

pnkfelix (Jul 02 2020 at 14:05, on Zulip):

hi @T-compiler/meeting , sorry I'm late

pnkfelix (Jul 02 2020 at 14:06, on Zulip):

we will start off with 5 minutes for ...

Announcements

pnkfelix (Jul 02 2020 at 14:06, on Zulip):
pnkfelix (Jul 02 2020 at 14:07, on Zulip):

lets resolve this now

pnkfelix (Jul 02 2020 at 14:07, on Zulip):

I think it won't be terrible if we skip this cycle entirely

simulacrum (Jul 02 2020 at 14:07, on Zulip):

skipping seems good to me

nikomatsakis (Jul 02 2020 at 14:07, on Zulip):

I'm all about trying to relax a bit this summer

nikomatsakis (Jul 02 2020 at 14:08, on Zulip):

any summer, really, but especially this one

pnkfelix (Jul 02 2020 at 14:08, on Zulip):

okay lets skip this cycle. If anyone has strong objections, feel free to bring them up.

pnkfelix (Jul 02 2020 at 14:08, on Zulip):
nikomatsakis (Jul 02 2020 at 14:08, on Zulip):

Maybe we can use the time to clear out the old meetings that need minutes :P

pnkfelix (Jul 02 2020 at 14:09, on Zulip):
pnkfelix (Jul 02 2020 at 14:09, on Zulip):

Regarding compiler-team#315: @nikomatsakis was musing that the cargo report-future-incompat feature might warrant a project group

pnkfelix (Jul 02 2020 at 14:10, on Zulip):

So if you're a contributor interested in working on that, ping me and we'll see if we can put something together.

pnkfelix (Jul 02 2020 at 14:10, on Zulip):

(Of course the MCP itself has not yet been seconded, so suggesting a project group may be putting the cart before the horse)

nikomatsakis (Jul 02 2020 at 14:10, on Zulip):

imo it is obviously a good fit for a project group :)

pnkfelix (Jul 02 2020 at 14:11, on Zulip):
pnkfelix (Jul 02 2020 at 14:11, on Zulip):
pnkfelix (Jul 02 2020 at 14:11, on Zulip):
pnkfelix (Jul 02 2020 at 14:12, on Zulip):

WG checkins

@WG-traits checkin by @Jack Huey:

nikomatsakis (Jul 02 2020 at 14:14, on Zulip):

I think we expect to keep pushing on some of those points, but in a less structured fashion

Jack Huey (Jul 02 2020 at 14:14, on Zulip):

Agreed

nikomatsakis (Jul 02 2020 at 14:14, on Zulip):

I have to go over my notes from last meeting but in particular

nikomatsakis (Jul 02 2020 at 14:14, on Zulip):

I expect to be starting some MCPs to try and modify rustc to bring it more inline with chalk's IR (and vice versa)

nikomatsakis (Jul 02 2020 at 14:15, on Zulip):

I've been hesitating but I think the time has come to try and reconcile the two...

pnkfelix (Jul 02 2020 at 14:15, on Zulip):

Sigh; I neglected to put beta-approved on the approvals from last week's meeting

pnkfelix (Jul 02 2020 at 14:16, on Zulip):

I'm going to skip those parts of the beta-nominations on the agenda for this week

pnkfelix (Jul 02 2020 at 14:16, on Zulip):

Beta-nominations

T-compiler

pnkfelix (Jul 02 2020 at 14:16, on Zulip):
Santiago Pastorino (Jul 02 2020 at 14:17, on Zulip):

the fix makes sense to me but is it such a bad issue that's worth a backport?

pnkfelix (Jul 02 2020 at 14:18, on Zulip):

Yeah I personally think this can ride the trains

simulacrum (Jul 02 2020 at 14:18, on Zulip):

uh well it's fixing a regression?

simulacrum (Jul 02 2020 at 14:18, on Zulip):

seems strange not to fix that regression, and with a relatively minimal fix

pnkfelix (Jul 02 2020 at 14:18, on Zulip):

but it wasn't even clear whether this was a defined part of the language?

eddyb (Jul 02 2020 at 14:18, on Zulip):

it's some code that shouldn't have made it in but wasn't reviewed properly

eddyb (Jul 02 2020 at 14:19, on Zulip):

of questionable behavior and performance

eddyb (Jul 02 2020 at 14:19, on Zulip):

it would be nice to worry about it doing weird things in the wild

simulacrum (Jul 02 2020 at 14:19, on Zulip):

@eddyb are you referring to the previous state or this PR?

eddyb (Jul 02 2020 at 14:19, on Zulip):

the temporary state that accidentally got into beta

eddyb (Jul 02 2020 at 14:19, on Zulip):

(partly my fault I think)

simulacrum (Jul 02 2020 at 14:20, on Zulip):

okay -- well -- I think that further goes to support a backport here

eddyb (Jul 02 2020 at 14:20, on Zulip):

yeah I think it's one less thing to worry about if we backport the new implementation

pnkfelix (Jul 02 2020 at 14:20, on Zulip):

:shrug: okay

eddyb (Jul 02 2020 at 14:21, on Zulip):

(I'll review the PRs just in case I'm missing some details)

pnkfelix (Jul 02 2020 at 14:21, on Zulip):

libs-impl

pnkfelix (Jul 02 2020 at 14:21, on Zulip):

T-rustdoc

pnkfelix (Jul 02 2020 at 14:22, on Zulip):

(same as cases I elided above; we don't need to discuss; I just need to go add the beta-accepted labels, with notes when necessary)

eddyb (Jul 02 2020 at 14:22, on Zulip):

@simulacrum oh I was thinking of #71372 but I guess #71487 had bugs too ugh

pnkfelix (Jul 02 2020 at 14:23, on Zulip):

Stable-nominations

T-compiler

pnkfelix (Jul 02 2020 at 14:24, on Zulip):

so, yeah, again, I'll deal with this after the meeting

pnkfelix (Jul 02 2020 at 14:24, on Zulip):

libs-impl

T-rustdoc

pnkfelix (Jul 02 2020 at 14:25, on Zulip):

PRs S-waiting-on-team

T-compiler

nikomatsakis (Jul 02 2020 at 14:25, on Zulip):

I'm open to objections there :)

nikomatsakis (Jul 02 2020 at 14:26, on Zulip):

but it seemed like we might be in a state of someone being willing to say "yeah, go for it"

eddyb (Jul 02 2020 at 14:26, on Zulip):

@simulacrum so to revise my earlier statement, what I was worried about didn't end up in beta (was superseded), and #73596 only fixes one kind of situation that ended up being a regression, my bad :(

eddyb (Jul 02 2020 at 14:27, on Zulip):

maybe I shouldn't speak about things I haven't caught up on

pnkfelix (Jul 02 2020 at 14:27, on Zulip):

okay thanks for clarification @eddyb

pnkfelix (Jul 02 2020 at 14:27, on Zulip):

I was staring at that code thinking "what performance pitfall is eddyb talking about ....?"

eddyb (Jul 02 2020 at 14:28, on Zulip):

yeah that was #71372 which #71487 redid

pnkfelix (Jul 02 2020 at 14:28, on Zulip):

libs-impl

pnkfelix (Jul 02 2020 at 14:29, on Zulip):

Issues of Note

Short Summary

pnkfelix (Jul 02 2020 at 14:29, on Zulip):

P-critical

T-compiler

pnkfelix (Jul 02 2020 at 14:29, on Zulip):
Santiago Pastorino (Jul 02 2020 at 14:30, on Zulip):

IMO we should re-label this issue but we've left it in the agenda just in case, to see what people think about the test that covers a P-critical issue

nikomatsakis (Jul 02 2020 at 14:30, on Zulip):

yeah if it's just needs-test, definitely not criticial

Santiago Pastorino (Jul 02 2020 at 14:31, on Zulip):

I guess that could just be P-medium

pnkfelix (Jul 02 2020 at 14:31, on Zulip):

Lets lower priority to P-medium, yeah?

Santiago Pastorino (Jul 02 2020 at 14:31, on Zulip):

:+1: doing so

DPC (Jul 02 2020 at 14:31, on Zulip):

(will look into getting the test added in a few days)

pnkfelix (Jul 02 2020 at 14:31, on Zulip):

does anyone think there is need to try to confirm where fix was injected?

pnkfelix (Jul 02 2020 at 14:31, on Zulip):

it sounds like the codebase is very large

pnkfelix (Jul 02 2020 at 14:32, on Zulip):

anyway we can move along

pnkfelix (Jul 02 2020 at 14:32, on Zulip):
pnkfelix (Jul 02 2020 at 14:32, on Zulip):

I'll take this one: I'm trying to make certain days of the week be "Windows development" days

Santiago Pastorino (Jul 02 2020 at 14:33, on Zulip):

we could ping windows group but I'm not 100% if it's a windows only issue or just winRT in some way is triggering the error

pnkfelix (Jul 02 2020 at 14:34, on Zulip):

right, we'll find out

Santiago Pastorino (Jul 02 2020 at 14:34, on Zulip):

anyway, let's ping windows group

DPC (Jul 02 2020 at 14:34, on Zulip):

Peter was indicating that it is a winrt issue

pnkfelix (Jul 02 2020 at 14:34, on Zulip):

they (windows) were already pinged 6 days ago

Santiago Pastorino (Jul 02 2020 at 14:34, on Zulip):

yeah I was checking and I already pinged them :+1:

pnkfelix (Jul 02 2020 at 14:35, on Zulip):

libs-impl

T-rustdoc

pnkfelix (Jul 02 2020 at 14:35, on Zulip):

Unassigned P-high regressions

Beta regressions

Nightly regressions

pnkfelix (Jul 02 2020 at 14:35, on Zulip):

Performance logs

Triage done by njn. Latest revision: 0ca7f74dbd23a3e8ec491cd3438f490a3ac22741.
Three regressions, two of them on rollups; two improvements, one on a rollup.

Regressions:

Improvements:

nikomatsakis (Jul 02 2020 at 14:37, on Zulip):

deep-vector does use macros I think to generate tons of code, right?

nikomatsakis (Jul 02 2020 at 14:37, on Zulip):

I guess that makes sense

simulacrum (Jul 02 2020 at 14:38, on Zulip):

(another note here is that we've upgraded script-servo to a more recent version)

pnkfelix (Jul 02 2020 at 14:38, on Zulip):

I'm having trouble finding why the aaforementioned revert happened

pnkfelix (Jul 02 2020 at 14:38, on Zulip):

i guess #72389 broke clippy

simulacrum (Jul 02 2020 at 14:38, on Zulip):

but that shouldn't matter for most people

pnkfelix (Jul 02 2020 at 14:39, on Zulip):

it would have been nice if we had opened up a dedicated issue describing that problem

pnkfelix (Jul 02 2020 at 14:39, on Zulip):

(I'm referencing conversation here )

pnkfelix (Jul 02 2020 at 14:40, on Zulip):

interesting, we have landed a take-two of #72389 in #73708

pnkfelix (Jul 02 2020 at 14:41, on Zulip):

hey @Santiago Pastorino , it probably would be as good thing if we tweaked @Nicholas Nethercote 's report to include issue numbers explicitly

pnkfelix (Jul 02 2020 at 14:41, on Zulip):

they are currently present in the links themselves, but that is harder to reference when scrolling

eddyb (Jul 02 2020 at 14:41, on Zulip):

random aside: it would be really nice if Zulip had at least on-hover previews of links. maybe I should try to find an extension that does this

DPC (Jul 02 2020 at 14:42, on Zulip):

@eddyb you can request in #zulip

pnkfelix (Jul 02 2020 at 14:42, on Zulip):

@eddyb you mean previewing the content behind the link?

eddyb (Jul 02 2020 at 14:42, on Zulip):

just the title would be enough

pnkfelix (Jul 02 2020 at 14:42, on Zulip):

it does have a preview of the link itself when I hover

pnkfelix (Jul 02 2020 at 14:42, on Zulip):

(the url that is)

nikomatsakis (Jul 02 2020 at 14:42, on Zulip):

(file a bug on zulip, I wouldn't surprised if they fixed it relatively quickly)

eddyb (Jul 02 2020 at 14:42, on Zulip):

huh I need to try the app again, been using Zulip in firefox for a while

eddyb (Jul 02 2020 at 14:42, on Zulip):

sorry for the derail

nikomatsakis (Jul 02 2020 at 14:43, on Zulip):

I don't see any hover of the title, just the full URL, which I don't think is what eddyb wanted

eddyb (Jul 02 2020 at 14:43, on Zulip):

oh right I didn't see "the url that is"

pnkfelix (Jul 02 2020 at 14:43, on Zulip):

right, I tried to clarify that. The url suffices for this particular purpose, but its not ideal

eddyb (Jul 02 2020 at 14:43, on Zulip):

I'm talking about issue/PR numbers. I never recognize them (by number)

pnkfelix (Jul 02 2020 at 14:44, on Zulip):

but ... is it normal to provide that? Is there any risk involved?

DPC (Jul 02 2020 at 14:44, on Zulip):

done on your behalf in #zulip :slight_smile:

pnkfelix (Jul 02 2020 at 14:44, on Zulip):

in terms of following a link to a site when the user hasn't actually clicked.

simulacrum (Jul 02 2020 at 14:44, on Zulip):

I think normally it's only done for e.g. github specifically

pnkfelix (Jul 02 2020 at 14:44, on Zulip):

actually, never mind, that discussion would be a derailing of the meeting

simulacrum (Jul 02 2020 at 14:44, on Zulip):

anyway, let's not derail

pnkfelix (Jul 02 2020 at 14:45, on Zulip):

in this case, the reason I wanted issue numbers in the report

pnkfelix (Jul 02 2020 at 14:45, on Zulip):

is becasaue take two landed in PR #73708

pnkfelix (Jul 02 2020 at 14:45, on Zulip):

but that landed as part of a rollup

pnkfelix (Jul 02 2020 at 14:45, on Zulip):

and so I wanted to see if one of the regressing rollups

pnkfelix (Jul 02 2020 at 14:45, on Zulip):

had that PR in it

pnkfelix (Jul 02 2020 at 14:46, on Zulip):

but as far as I can tell, the rollup holding PR #73708 was either of the two that were in the report

pnkfelix (Jul 02 2020 at 14:46, on Zulip):

Nominated Issues

T-compiler

pnkfelix (Jul 02 2020 at 14:46, on Zulip):
Joshua Nelson (Jul 02 2020 at 14:47, on Zulip):

This has been blocking intra-doc links for a couple weeks now

pnkfelix (Jul 02 2020 at 14:47, on Zulip):

oh yeah, I've been following this discussion the sidelines

Joshua Nelson (Jul 02 2020 at 14:47, on Zulip):

currently waiting on a crater run for that PR but I brought it up for discussion since I'm not sure it's a great approach in the first place

pnkfelix (Jul 02 2020 at 14:47, on Zulip):

mainly because I'm totally :tada: about us decoupling everybody_loops from rustdoc

nikomatsakis (Jul 02 2020 at 14:47, on Zulip):

"everybody_loops is causing bugs in rustdoc" shocking :)

pnkfelix (Jul 02 2020 at 14:48, on Zulip):

I mean, in a sense it is shocking

simulacrum (Jul 02 2020 at 14:48, on Zulip):

hm so two bullets seem in conflict? "Has no clear path for a fix, thus would benefit from discussion in a T-compiler meeting." vs. "Has a proposed fix by Joshua Nelson: #73566

pnkfelix (Jul 02 2020 at 14:48, on Zulip):

in that someone who knew of each of those components independently should be shocked. that they are coupled together

simulacrum (Jul 02 2020 at 14:48, on Zulip):

is this mostly resolved? what do we need to discuss?

Joshua Nelson (Jul 02 2020 at 14:48, on Zulip):

@simulacrum well my 'fix' has a lot of trade-offs

pnkfelix (Jul 02 2020 at 14:48, on Zulip):

simulacrum said:

hm so two bullets seem in conflict? "Has no clear path for a fix, thus would benefit from discussion in a T-compiler meeting." vs. "Has a proposed fix by Joshua Nelson: #73566

I. think the proposed fix from @Joshua Nelson is to resolve the rustdoc problem

Joshua Nelson (Jul 02 2020 at 14:49, on Zulip):

for starters, anytime rustdoc does typechecking now causes an ICE

Joshua Nelson (Jul 02 2020 at 14:49, on Zulip):

@pnkfelix I'm not sure if it needs to be fixed other than the rustdoc problem? for -Z unpretty=everybody_loops it never needs to look at the defids

pnkfelix (Jul 02 2020 at 14:49, on Zulip):

pnkfelix said:

I. think the proposed fix from Joshua Nelson is to resolve the rustdoc problem

but the issue of #71104 goes beyond just rustdoc

pnkfelix (Jul 02 2020 at 14:50, on Zulip):

or at least, that's my reading of the description of #71104

simulacrum (Jul 02 2020 at 14:50, on Zulip):

ah, okay

pnkfelix (Jul 02 2020 at 14:50, on Zulip):

but then one might ask, why does PR #73566 say it closes #71104

nikomatsakis (Jul 02 2020 at 14:50, on Zulip):

so, longish term, it seems like we ought to be able to ignore item bodies...oh, well, I guess that's not necessarily true, as there may be nested items.

Joshua Nelson (Jul 02 2020 at 14:51, on Zulip):

We'd need to ask @marmeladema about how it affects things other than rustdoc I think

nikomatsakis (Jul 02 2020 at 14:51, on Zulip):

(I'm skimming the PR write-up...)

Joshua Nelson (Jul 02 2020 at 14:51, on Zulip):

the write up is a little long, https://github.com/rust-lang/rust/issues/71104#issuecomment-651142977 has a summary

pnkfelix (Jul 02 2020 at 14:52, on Zulip):

personally, I think its fine if rustdoc runs a different set of lints from rustc

pnkfelix (Jul 02 2020 at 14:52, on Zulip):

(that is, as I understand it, the heart of the expected change in semantics here)

eddyb (Jul 02 2020 at 14:53, on Zulip):

Joshua Nelson said:

for starters, anytime rustdoc does typechecking now causes an ICE

this doesn't seem necessary to me? this should only happen if there were name resolutions errors hidden

Joshua Nelson (Jul 02 2020 at 14:53, on Zulip):

right, that's what I mean

Joshua Nelson (Jul 02 2020 at 14:53, on Zulip):

if there were hidden errors and rustdoc does type checking

pnkfelix (Jul 02 2020 at 14:53, on Zulip):

(because the lints being run today by rustdoc rely on type-checking the fn bodies, which is going to be disabled)

Joshua Nelson (Jul 02 2020 at 14:53, on Zulip):

pnkfelix said:

(because the lints being run today by rustdoc rely on type-checking the fn bodies, which is going to be disabled)

not all of them

eddyb (Jul 02 2020 at 14:53, on Zulip):

it should still be completely fine for most of the type-checking it needs to do, like constants (or even const fns) which may be used from types

Joshua Nelson (Jul 02 2020 at 14:54, on Zulip):

https://github.com/rust-lang/rust/pull/73566#issuecomment-650213058

pnkfelix (Jul 02 2020 at 14:54, on Zulip):

right, but you are in part proposing to disable the lints that do rely on such type checking of fn bodies, right?

Joshua Nelson (Jul 02 2020 at 14:54, on Zulip):

Correct, those will certainly be disabled

simulacrum (Jul 02 2020 at 14:54, on Zulip):

perhaps an interesting question -- will this run into problems with the opaque types work Niko has been doing? I imagine we'll not have definitions if we're not running type checking

Joshua Nelson (Jul 02 2020 at 14:54, on Zulip):

and all the lints that look at things outside bodies will need an option not to look inside if we want to keep them in rustdoc

eddyb (Jul 02 2020 at 14:54, on Zulip):

if we could have name resolution be on-demand there wouldn't be any ICEs to worry about at all, we would just want to e.g. disable most lints in order to avoid showing errors in platform-specific code

eddyb (Jul 02 2020 at 14:55, on Zulip):

@simulacrum we're not "not running type-checking"

simulacrum (Jul 02 2020 at 14:55, on Zulip):

well I mean that the definitions (being in bodies) would no longer exist, right?

eddyb (Jul 02 2020 at 14:55, on Zulip):

opaque types will just work, assuming there is no per-platform code involved that doesn't pass name resolution

simulacrum (Jul 02 2020 at 14:55, on Zulip):

okay :)

nikomatsakis (Jul 02 2020 at 14:55, on Zulip):

if we want to document the hidden type, that'd be an issue

simulacrum (Jul 02 2020 at 14:55, on Zulip):

nikomatsakis said:

if we want to document the hidden type, that'd be an issue

This is what I was referring to

Joshua Nelson (Jul 02 2020 at 14:55, on Zulip):

@nikomatsakis you can't document things inside function bodies anyway

eddyb (Jul 02 2020 at 14:55, on Zulip):

@simulacrum that's what everybody_loops does today with some heuristics for not breaking things

Joshua Nelson (Jul 02 2020 at 14:56, on Zulip):

you can only document pub items

nikomatsakis (Jul 02 2020 at 14:56, on Zulip):

(it feels to me like the right answer for "cross-platform docs" is probably generating for each platform and merging the outputs, but I'm sure that's been considered and rejected)

Joshua Nelson (Jul 02 2020 at 14:56, on Zulip):

I have to go but I'll have time in an hour for more questions

pnkfelix (Jul 02 2020 at 14:56, on Zulip):

I suspect we don't want to document the hidden type, no? Or do we do so today?

nikomatsakis (Jul 02 2020 at 14:56, on Zulip):

(and I'm not really trying to revisit that question in this moment, just musing)

nikomatsakis (Jul 02 2020 at 14:56, on Zulip):

I don't think we do so today

eddyb (Jul 02 2020 at 14:56, on Zulip):

@Joshua NelsonI believe @nikomatsakis is referring to -> impl Trait

eddyb (Jul 02 2020 at 14:56, on Zulip):

not something inside the fn body

eddyb (Jul 02 2020 at 14:57, on Zulip):

nikomatsakis said:

if we want to document the hidden type, that'd be an issue

you mean the platform-specific code, right?

nikomatsakis (Jul 02 2020 at 14:57, on Zulip):

although @Joshua Nelson may been responding to me saying that if you just skipped name resolution (similar to your suggestion to make it lazy, eddyb) then we wouldn't be able to expand macros which might contain items/impls etc

pnkfelix (Jul 02 2020 at 14:57, on Zulip):

okay. In any case, I now can at least see a reason why one might want to run the type-inference from within rustdoc

Joshua Nelson (Jul 02 2020 at 14:57, on Zulip):

this skips late resolution, not macro resolution

eddyb (Jul 02 2020 at 14:57, on Zulip):

@Joshua Nelson do you skip it or just the errors?

Joshua Nelson (Jul 02 2020 at 14:58, on Zulip):

just the errors, yeah

eddyb (Jul 02 2020 at 14:58, on Zulip):

my suggestion was to only skip emitting errors, but still do as much resolution as possible

eddyb (Jul 02 2020 at 14:58, on Zulip):

okay so I guess there's a lot of confusion stemmed from imprecise descriptions

pnkfelix (Jul 02 2020 at 14:58, on Zulip):

I think we should move forward with @Joshua Nelson 's PR, personally

pnkfelix (Jul 02 2020 at 14:58, on Zulip):

but maybe this actually warrants an MCP ?

pnkfelix (Jul 02 2020 at 14:59, on Zulip):

I suppose it depends on the details that we were just discussing

eddyb (Jul 02 2020 at 14:59, on Zulip):
  1. name resolution does as much as possible but hides errors coming from bodies
  2. everything that might depend on that information isn't ran by default (in a for each body in crate loop) but because it's all queries, if something needs something else, it will run
pnkfelix (Jul 02 2020 at 15:00, on Zulip):

okay well I don't think we have time to discuss the other nominated issues

eddyb (Jul 02 2020 at 15:00, on Zulip):

this would be so much easier and nicer if we had querified name resolution :(

pnkfelix (Jul 02 2020 at 15:00, on Zulip):

well I'll mention this one:

pnkfelix (Jul 02 2020 at 15:00, on Zulip):
pnkfelix (Jul 02 2020 at 15:00, on Zulip):

because that's just nominated to raise awareness

eddyb (Jul 02 2020 at 15:01, on Zulip):

oh I should make sure that's marked as blocked on #73751, because they conflict

pnkfelix (Jul 02 2020 at 15:01, on Zulip):

thanks to everyone in @T-compiler/meeting for attending!

Joshua Nelson (Jul 02 2020 at 18:50, on Zulip):

pnkfelix said:

I suspect we don't want to document the hidden type, no? Or do we do so today?

We don't document the hidden type, it shows up in the docs as impl Trait:

image.png

The behavior today was that we skipped the ReplaceBodyWithLoop pass because ! breaks impl Trait (it can't infer the type, so tcx.analyse() returned an error). That meant it used to be you couldn't have name errors in functions returning impl trait. But since we no longer run type checking at all, there should be no problem. It looks like it's doing typechecking anyway though, it gave an ICE when I tried it out locally.

pub fn f() -> impl std::fmt::Debug {
    content::doesnt::matter();
}

With stable:

error[E0433]: failed to resolve: use of undeclared type or module `content`

With my PR:

error: internal compiler error: TyKind::Error constructed but no error reported
Joshua Nelson (Jul 02 2020 at 18:50, on Zulip):

I'll add this as a test case, I don't expect it to derail the PR

simulacrum (Jul 02 2020 at 18:51, on Zulip):

well this is a different hidden type from type Foo = impl Debug, where I imagine it might be more interesting to showcase it, since there it's actually observable within the module(?) IIRC

simulacrum (Jul 02 2020 at 18:51, on Zulip):

but maybe I'm misremembering actually

simulacrum (Jul 02 2020 at 18:51, on Zulip):

and it's just like impl debug in a return type, in which case this seems fien

Joshua Nelson (Jul 02 2020 at 18:52, on Zulip):

For type Foo = impl Debug; we don't hide errors so there's no change from the current behavior.

Joshua Nelson (Jul 02 2020 at 18:57, on Zulip):

oh hold on I lied, apparently those docs aren't showing up at all?

Joshua Nelson (Jul 02 2020 at 18:58, on Zulip):

I have lots of new tests to add :laughing:

marmeladema (Jul 05 2020 at 20:37, on Zulip):

Joshua Nelson said:

We'd need to ask marmeladema about how it affects things other than rustdoc I think

Sorry for my very late response, but I don't think ReplaceBodyWithLoop is used for anything else but rustdoc nowadays.
For the record https://github.com/rust-lang/rust/issues/71104 was more a placeholder issue for all the cases I found when promoting LocalDefIds. All cases found have been fixed when migrating save_analysis to HIR. The remaining issue about ReplaceBodyWithLoop is tracked at https://github.com/rust-lang/rust/issues/71820 and is really the one @Joshua Nelson is fighting against.

pnkfelix (Jul 06 2020 at 19:03, on Zulip):

ReplaceBodyWithLoop is still used as the basis for -Z everybody_loops, no?

pnkfelix (Jul 06 2020 at 19:04, on Zulip):

That is the purpose it was originally added for, and I at least still use it on occasion for test case reduction, as documented here: http://blog.pnkfx.org/blog/2019/11/18/rust-bug-minimization-patterns/#L..loopification.....via.pretty-printer

Joshua Nelson (Jul 07 2020 at 22:48, on Zulip):

Yes, at least now that https://github.com/rust-lang/rust/pull/73523 is merged

Joshua Nelson (Jul 07 2020 at 22:51, on Zulip):

(it was broken for a while)

Joshua Nelson (Oct 31 2020 at 22:11, on Zulip):

nikomatsakis said:

(it feels to me like the right answer for "cross-platform docs" is probably generating for each platform and merging the outputs, but I'm sure that's been considered and rejected)

@nikomatsakis extremely late response, but this is oldest open rustdoc issue: https://github.com/rust-lang/rust/issues/1998. there's a summary by QuietMisdreavus of why this is hard: https://github.com/rust-lang/rust/issues/1998#issuecomment-318800909. tl;dr rustdoc sees things after macro-expansion, but to handle all platforms at once, it would need to somehow see them before.

Joshua Nelson (Oct 31 2020 at 22:13, on Zulip):

and there needs to be someway to distinguish between items that overlap and have the same name

Last update: Nov 25 2020 at 03:00UTC