Stream: t-compiler

Topic: weekly meeting 2020-02-27 #54818


pnkfelix (Feb 27 2020 at 12:08, on Zulip):

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

pnkfelix (Feb 27 2020 at 12:08, on Zulip):

I will be doing pre-triage in a parallel topic

pnkfelix (Feb 27 2020 at 12:09, on Zulip):

this week we have scheduled checkins from WG-Learning and WG-LLVM...

pnkfelix (Feb 27 2020 at 12:10, on Zulip):

@Santiago Pastorino do you expect to be available to provide checkin update for WG-Learning at end of the meeting?

pnkfelix (Feb 27 2020 at 12:11, on Zulip):

I don't think we'll have a formal checkin from WG-LLVM. If I have time in the 30 minutes before the meeting, I might try to make some informal notes based on some recent LLVM related backports/bug fixes. But I doubt I'll get around to it.

Santiago Pastorino (Feb 27 2020 at 13:34, on Zulip):

pnkfelix said:

Santiago Pastorino do you expect to be available to provide checkin update for WG-Learning at end of the meeting?

yes

pnkfelix (Feb 27 2020 at 14:57, on Zulip):

(I’m going to be a few minutes late)

nikomatsakis (Feb 27 2020 at 15:01, on Zulip):

Hello @T-compiler/meeting! @pnkfelix is not here yet, but let's kick off the meeting with some...

Announcements

nikomatsakis (Feb 27 2020 at 15:02, on Zulip):
nikomatsakis (Feb 27 2020 at 15:02, on Zulip):
simulacrum (Feb 27 2020 at 15:03, on Zulip):

We have a release: https://blog.rust-lang.org/2020/02/27/Rust-1.41.1.html

simulacrum (Feb 27 2020 at 15:04, on Zulip):

(and Zulip's desktop notifications from firefox nightly seem broken, in other news)

Wesley Wiser (Feb 27 2020 at 15:05, on Zulip):

If you haven't tried -Zself-profile yet, we now have a complete tutorial on how to use it in the form of a blog post

pnkfelix (Feb 27 2020 at 15:06, on Zulip):

okay I'm here now

pnkfelix (Feb 27 2020 at 15:07, on Zulip):

here is today's meeting hackmd

pnkfelix (Feb 27 2020 at 15:08, on Zulip):

so lets see, lets take care of beta nominations

pnkfelix (Feb 27 2020 at 15:08, on Zulip):

beta-nom 1/4: “Cherry-pick the LLVM fix for #69225#69450

pnkfelix (Feb 27 2020 at 15:09, on Zulip):

yeah this seems like a no-brainer

pnkfelix (Feb 27 2020 at 15:10, on Zulip):

marking as beta-accepted

pnkfelix (Feb 27 2020 at 15:10, on Zulip):

beta-nom 2/4: "instantiate_value_path: on SelfCtor, avoid unconstrained tyvars” #69340

pnkfelix (Feb 27 2020 at 15:11, on Zulip):

this hasn't landed on nightly yet

pnkfelix (Feb 27 2020 at 15:12, on Zulip):

@eddyb I saw there was feedback and @centril noted they would prefer to leave further work to follow-up PR. Do you see inherent problems with the PR as is, in terms of backport?

nikomatsakis (Feb 27 2020 at 15:12, on Zulip):

there are also crates affected in the wild

nikomatsakis (Feb 27 2020 at 15:13, on Zulip):

@centril opened PRs to fix, but it takes some time for those to make it to crates.io etc

centril (Feb 27 2020 at 15:13, on Zulip):

all of which have been fixed, save one, which has an open PR

nikomatsakis (Feb 27 2020 at 15:13, on Zulip):

on the other hand it shows that this pattern gets used :)

nikomatsakis (Feb 27 2020 at 15:13, on Zulip):

the change is narrow and on technical grounds :+1:

pnkfelix (Feb 27 2020 at 15:13, on Zulip):

oh right, the breaking-change aspect is important too

centril (Feb 27 2020 at 15:13, on Zulip):

@pnkfelix I believe eddyb just didn't want to make the "let's land the breakage" bit

nikomatsakis (Feb 27 2020 at 15:13, on Zulip):

(I've not read it closely, so not commenting on @eddyb's statements)

centril (Feb 27 2020 at 15:14, on Zulip):

so I reassigned to petrochenkov

pnkfelix (Feb 27 2020 at 15:14, on Zulip):

centril said:

pnkfelix I believe eddyb just didn't want to make the "let's land the breakage" bit

"make" as in, didn't want to unilaterally approve?

centril (Feb 27 2020 at 15:14, on Zulip):

@pnkfelix they didn't want "the responsibility"

pnkfelix (Feb 27 2020 at 15:14, on Zulip):

we could use fcpbot for it

pnkfelix (Feb 27 2020 at 15:15, on Zulip):

centril said:

pnkfelix they didn't want "the responsibility"

okay I understand that

centril (Feb 27 2020 at 15:15, on Zulip):

rfcbot seems quite overkill I think; beta backport isn't urgent; I think petrochenkov can just review

pnkfelix (Feb 27 2020 at 15:15, on Zulip):

I assume there's no plausible way to warning cycle this, right?

pnkfelix (Feb 27 2020 at 15:16, on Zulip):

due to how it interacts with type inference and what not

nikomatsakis (Feb 27 2020 at 15:16, on Zulip):

I say we defer the beta backport question. I think it'd be hard to do a warning cycle for this from a technical perspective.

nikomatsakis (Feb 27 2020 at 15:16, on Zulip):

I guess I'd be inclined not to backport

nikomatsakis (Feb 27 2020 at 15:16, on Zulip):

so as to give people a bit more time for transition

centril (Feb 27 2020 at 15:16, on Zulip):

there might be, but that would also be overkill and given that crates have already been fixed not worth it :slight_smile:

nikomatsakis (Feb 27 2020 at 15:16, on Zulip):

but I'm more interested in seeing what happens when we land on nightly

centril (Feb 27 2020 at 15:17, on Zulip):

(what I would do is register the inference variables, register the substitutions, check in writeback whether they got the right types, and if not, warn -- very hacky...)

nikomatsakis (Feb 27 2020 at 15:17, on Zulip):

(we don't have a list of the root regressions, do we? but the net impact was 21 crates, so "not huge")

nikomatsakis (Feb 27 2020 at 15:17, on Zulip):

centril said:

(what I would do is register the inference variables, register the substitutions, check in writeback whether they got the right types, and if not, warn -- very hacky...)

yeah, complex

centril (Feb 27 2020 at 15:17, on Zulip):

@nikomatsakis we do, 6 root regressions

nikomatsakis (Feb 27 2020 at 15:17, on Zulip):

right, but they are not listed in the comments

nikomatsakis (Feb 27 2020 at 15:17, on Zulip):

i.e., which 6 crates is it

nikomatsakis (Feb 27 2020 at 15:18, on Zulip):

well I guess I can see the citations from the PRs

nikomatsakis (Feb 27 2020 at 15:18, on Zulip):

ok.

centril (Feb 27 2020 at 15:18, on Zulip):

@nikomatsakis all of the regressions are at the root, except for the libp2p-* which accounts for all the rest

pnkfelix (Feb 27 2020 at 15:18, on Zulip):

okay at this point I think we should either outright decline to backport, or leave thiis for next week

centril (Feb 27 2020 at 15:19, on Zulip):

yea, not urgent

pnkfelix (Feb 27 2020 at 15:19, on Zulip):

lets let it land in nightly first. I don't think we need to make a final decision right now

pnkfelix (Feb 27 2020 at 15:19, on Zulip):

(as in, we'll leave for next week)

pnkfelix (Feb 27 2020 at 15:20, on Zulip):

beta-nom 3/4: “lit_to_const: gracefully bubble up type errors.” #69330

centril (Feb 27 2020 at 15:21, on Zulip):

literally-melting-ice

I am happy with that branch name :P

pnkfelix (Feb 27 2020 at 15:23, on Zulip):

okay this seems fine. beta-accepted

pnkfelix (Feb 27 2020 at 15:24, on Zulip):

beta-nom 4/4: “Backport only: avoid ICE on bad placeholder type” #69324

pnkfelix (Feb 27 2020 at 15:24, on Zulip):

this is a reduced version of a PR that we declined to backport (due to size) last week.,

pnkfelix (Feb 27 2020 at 15:25, on Zulip):

and seems like an obvious case to approve now, I think.

pnkfelix (Feb 27 2020 at 15:25, on Zulip):

beta-approved.

pnkfelix (Feb 27 2020 at 15:26, on Zulip):

there were zero stable nominations

pnkfelix (Feb 27 2020 at 15:26, on Zulip):

there are three PR's marked S-waiting-on-team

pnkfelix (Feb 27 2020 at 15:26, on Zulip):

waiting 1/3: “Rename asm! to llvm_asm!” #69404

pnkfelix (Feb 27 2020 at 15:27, on Zulip):

oops my link is wrong

pnkfelix (Feb 27 2020 at 15:27, on Zulip):

(in the hackmd)

pnkfelix (Feb 27 2020 at 15:27, on Zulip):

#68404

nikomatsakis (Feb 27 2020 at 15:28, on Zulip):

This strikes me as more blocked on the lang team decision around inline assembly than compile team impl concerns

pnkfelix (Feb 27 2020 at 15:28, on Zulip):

which team is thie actually waiting on... T-lang

centril (Feb 27 2020 at 15:28, on Zulip):

I personally don't think this is a language team matter

nikomatsakis (Feb 27 2020 at 15:28, on Zulip):

as @Amanieu wrote:

Also, we may want to wait for the lang team's approval since rust-lang/rfcs#2843 hasn't been merged yet.

centril (Feb 27 2020 at 15:29, on Zulip):

...as the language team never approved the existing asm!, and it has no path to stabilization

pnkfelix (Feb 27 2020 at 15:29, on Zulip):

Does anyone in T-compiler at this meeting object to this change?

nikomatsakis (Feb 27 2020 at 15:29, on Zulip):

I approve of landing the PR but would prefer to land the RFC

nikomatsakis (Feb 27 2020 at 15:29, on Zulip):

Prior to doing so :)

pnkfelix (Feb 27 2020 at 15:29, on Zulip):

okay lets wait on that then.

nikomatsakis (Feb 27 2020 at 15:29, on Zulip):

So maybe I should move to merge over there, I suppose

centril (Feb 27 2020 at 15:30, on Zulip):

Then the PR should be S-blocked-closed

pnkfelix (Feb 27 2020 at 15:30, on Zulip):

you'

pnkfelix (Feb 27 2020 at 15:30, on Zulip):

you're saying the PR should be closed ?

pnkfelix (Feb 27 2020 at 15:30, on Zulip):

and then ... reopened when/if RFC is merged?

nikomatsakis (Feb 27 2020 at 15:31, on Zulip):

Regarding "no path to stabilization", well, I agree that this feature doesn't have a path to stabilization in its present form, but I still think it's a language feature, and I generally think T-lang makes decisions about language features (though in the case of "very unstable" things, we tend to not push back too hard if the implementor wants to go a praticular way)

centril (Feb 27 2020 at 15:31, on Zulip):

@nikomatsakis I personally regard this the same way as other "language features" like rustc_foobar

nikomatsakis (Feb 27 2020 at 15:31, on Zulip):

That seems very different, as this feature is intended to be used by end-users

centril (Feb 27 2020 at 15:31, on Zulip):

i.e. the compiler team is free to add and remove them

nikomatsakis (Feb 27 2020 at 15:32, on Zulip):

It's not an "implementation detail" targeting our testing framework

nikomatsakis (Feb 27 2020 at 15:32, on Zulip):

I think a better analogy might be sanitizer support

nikomatsakis (Feb 27 2020 at 15:33, on Zulip):

although that is a bit different as it's kind of "rustc compiler options"

centril (Feb 27 2020 at 15:33, on Zulip):

I see your point, though I personally don't intend it for end users

nikomatsakis (Feb 27 2020 at 15:33, on Zulip):

anyway the tl;dr is I think this is blocked on the RFC for this meeting

nikomatsakis (Feb 27 2020 at 15:34, on Zulip):

so I guess it is S-blocked for now

centril (Feb 27 2020 at 15:34, on Zulip):

It should be closed if blocked on an RFC

nikomatsakis (Feb 27 2020 at 15:35, on Zulip):

I don't have a strong opinion, but I do remember various times that we've had a "Implementation PR" up so as to provide reference info for the RFC

nikomatsakis (Feb 27 2020 at 15:35, on Zulip):

But I'm also ok with closing for now

centril (Feb 27 2020 at 15:36, on Zulip):

(I just mean in terms of triage, PRs that are open for a long time and blocked get closed, standard T-release practice, https://forge.rust-lang.org/release/triage-procedure.html)

pnkfelix (Feb 27 2020 at 15:36, on Zulip):

let's follow up later on the question of whether to close this or not. (I agree that we do close things if their RFC's are not merged, but I can also believe we can/should allow PR's to remain open if their RFC's are on a trajectory to be merged.)

pnkfelix (Feb 27 2020 at 15:36, on Zulip):

okay we can just close

pnkfelix (Feb 27 2020 at 15:37, on Zulip):

closing

pnkfelix (Feb 27 2020 at 15:37, on Zulip):

waiting on team 2/3: Print nicer async/await trait errors for generators in any place in the error 'stack' #67116

pnkfelix (Feb 27 2020 at 15:38, on Zulip):

This is waiting for response from @Aaron Hill I think

pnkfelix (Feb 27 2020 at 15:38, on Zulip):

tags need to be changed. fixing

nikomatsakis (Feb 27 2020 at 15:38, on Zulip):

I think we can clear S-waiting-on-team..oh, you are

pnkfelix (Feb 27 2020 at 15:38, on Zulip):

(sorry, I should have taken care of this during pre-triage)

nikomatsakis (Feb 27 2020 at 15:38, on Zulip):

:heart:

pnkfelix (Feb 27 2020 at 15:39, on Zulip):

waiting 3/3: PowerPC C ZST ABI fixes #64259

centril (Feb 27 2020 at 15:39, on Zulip):

cc @eddyb

pnkfelix (Feb 27 2020 at 15:39, on Zulip):

(github is having some pretty serious UX issues right now...)

pnkfelix (Feb 27 2020 at 15:40, on Zulip):

I think the desired one-line variant has been posted .... so maybe we can close PR #64259 now?

pnkfelix (Feb 27 2020 at 15:40, on Zulip):

(the desired one hasn't been merged yet)

pnkfelix (Feb 27 2020 at 15:40, on Zulip):

((but that doesn't mean we keep this one open......))

nikomatsakis (Feb 27 2020 at 15:40, on Zulip):

I am confused about the current status, but I do believe our intent was to close this and replace it with some small patch

pnkfelix (Feb 27 2020 at 15:41, on Zulip):

closing.

pnkfelix (Feb 27 2020 at 15:42, on Zulip):

(or I would if github would let me comment)

pnkfelix (Feb 27 2020 at 15:42, on Zulip):

well in any case, I will post this comment "Discussed in T-compiler meeting. Closing under assumption that remaining desired work will be covered by PR's like #69263 " and close once github is working again

pnkfelix (Feb 27 2020 at 15:43, on Zulip):

There are eight nominated issues

pnkfelix (Feb 27 2020 at 15:43, on Zulip):

there was one that I wanted to try to ensure we discussed today

pnkfelix (Feb 27 2020 at 15:43, on Zulip):

nominated "Do not ping PR reviewers in toolstate breakage" #69449

nikomatsakis (Feb 27 2020 at 15:44, on Zulip):

my impression is that toolstate breakage is getting fixed in a timely fashion most of the time

pnkfelix (Feb 27 2020 at 15:44, on Zulip):

I suspect automatic pinging of reviewers i overkill

centril (Feb 27 2020 at 15:44, on Zulip):

imo we should remove PR authors too, because ^---

nikomatsakis (Feb 27 2020 at 15:44, on Zulip):

but I haven't been closely paying attention to who has been doing the fixing (tools maintainers?) and how they feel about it

pnkfelix (Feb 27 2020 at 15:44, on Zulip):

and that toolstate maintainers should feel free to reach out to reviewers if they need help

pnkfelix (Feb 27 2020 at 15:45, on Zulip):

but it should not be automated.

pnkfelix (Feb 27 2020 at 15:45, on Zulip):

as for PR authors .... it seems like it might be good for authors to at least be aware of the effects they are having downstream?

centril (Feb 27 2020 at 15:45, on Zulip):

usually it's small breakages that require e.g. adding .. or _ somewhere, and Clippy maintainers tend to fix that before we even get a chance to consider fixing them

nikomatsakis (Feb 27 2020 at 15:45, on Zulip):

in other words, @Vadim Petrochenkov wrote

[triagebot] I never answer to pings from issues like this because they are routinely fixed by people working on the affected tools.

and I think that's fine but not necessarily what we originally intended

nikomatsakis (Feb 27 2020 at 15:45, on Zulip):

I think the hope was that "fixing tools is part of the work"

nikomatsakis (Feb 27 2020 at 15:45, on Zulip):

but I guess it's not working out that way

centril (Feb 27 2020 at 15:45, on Zulip):

@pnkfelix highfive posts a comment on the PR itself typically when there's breakage

centril (Feb 27 2020 at 15:45, on Zulip):

unless it's a rollup, in which case the rollup gets the comment

simulacrum (Feb 27 2020 at 15:46, on Zulip):

it's too hard to fix tools imo today

centril (Feb 27 2020 at 15:46, on Zulip):

but you get notified about the rollup

nikomatsakis (Feb 27 2020 at 15:46, on Zulip):

it may also be, of course, that the current setup isn't great but that the fix isn't to keep the pings, but rather to consider making other changes, since they appear to not be working

centril (Feb 27 2020 at 15:46, on Zulip):

I would personally like to move e.g. Clippy in tree or something

nikomatsakis (Feb 27 2020 at 15:46, on Zulip):

I guess I'm not objecting to the change but more asking "if this is embracing the status quo, are we happy with the status quo?"

oli (Feb 27 2020 at 15:46, on Zulip):

I'll split off a separte discussion about this, becuase @simulacrum is absolutely right that this is (anecdotally) the reason we don't get so many author fixes

centril (Feb 27 2020 at 15:46, on Zulip):

cc @oli who had ideas

nikomatsakis (Feb 27 2020 at 15:46, on Zulip):

comments like @simulacrum make me think not

oli (Feb 27 2020 at 15:46, on Zulip):

I don't think we should block this meeting

pnkfelix (Feb 27 2020 at 15:47, on Zulip):

so okay, hold on

pnkfelix (Feb 27 2020 at 15:47, on Zulip):

I think we all agree that this PR itself can land, right?

oli (Feb 27 2020 at 15:47, on Zulip):

yes

pnkfelix (Feb 27 2020 at 15:47, on Zulip):

and the question of whether to do more, can be made in a followup PR ?

pnkfelix (Feb 27 2020 at 15:47, on Zulip):

Great

pnkfelix (Feb 27 2020 at 15:48, on Zulip):

I'll remove I-nominated tag

pnkfelix (Feb 27 2020 at 15:49, on Zulip):

Lets get a WG checkin from @Santiago Pastorino about WG-learning !!!

Santiago Pastorino (Feb 27 2020 at 15:51, on Zulip):

hold a sec

Santiago Pastorino (Feb 27 2020 at 15:52, on Zulip):

our main update is that we have been doing some planning on what to tackle during this first part of the year

nikomatsakis (Feb 27 2020 at 15:53, on Zulip):

I've been failing to read #t-compiler/wg-learning -- any major ideas or thoughts?

Santiago Pastorino (Feb 27 2020 at 15:53, on Zulip):

and we have this ideas ...

Santiago Pastorino (Feb 27 2020 at 15:53, on Zulip):
Define how would we want to structure the guide

    Make it more engaging to read?
    Move procedures to forge or to an appendix?
        https://rust-lang.github.io/rustc-guide/stability.html
        https://rust-lang.github.io/rustc-guide/implementing_new_features.html
        https://rust-lang.github.io/rustc-guide/stabilization_guide.html

Write an Overview chapter

    Overview of the whole picture of the compiler. Main components, what they do and where they live. Main data structures used along and more or less what they are about.
    Overview Outline
    Overview blog post (coming soon…)

Write a walkthrough section about what the compiler does to your code

    It may also be nice to have a concrete example that shows all the compilation phases, artifacts and structures generated along the way.
    walk through compilation of simple program
    link to other chapters for details
    This is more like what the compiler does and how it works high level
    [@Chris Simpkins] Succinct summary of how to visualize each representation stage of the compile process (e.g., cargo rustc -- -Zunpretty=hir-tree for HIR)

Write a walkthrough about how a full feature is implemented

    Show how a particular feature was implemented by explaining every corner of the compiler that was touched
    Explain all the technical aspects considered when implementing
    This is more like what is needed top to bottom level to implement a full feature
    https://github.com/rust-lang/rustc-guide/issues/584

Collect a set of PRs that help understanding some parts of the compiler

    Would be nice if we can collect PRs that are interesting to understand certain things
nikomatsakis (Feb 27 2020 at 15:53, on Zulip):

I will say anecdotally that I've heard from quite a few folks lately about the value of the rustc-guide...

pnkfelix (Feb 27 2020 at 15:53, on Zulip):

as in, it is good!

Santiago Pastorino (Feb 27 2020 at 15:53, on Zulip):

if someone wants to give feedback on that, more than welcome

nikomatsakis (Feb 27 2020 at 15:54, on Zulip):

I'm a big fan of the idea of an overview chapter :) but I particularly like the idea of sample PRs

nikomatsakis (Feb 27 2020 at 15:54, on Zulip):

as it seems like something that is relatively easy to do

Nell Shamrell-Harrington (Feb 27 2020 at 15:54, on Zulip):

Rust C guide has been tremendously helpful to me

centril (Feb 27 2020 at 15:54, on Zulip):

@Santiago Pastorino I can contribute https://github.com/rust-lang/rust/pull/63862 and https://github.com/rust-lang/rust/pull/68856 for pattern type checking

Santiago Pastorino (Feb 27 2020 at 15:54, on Zulip):

nikomatsakis said:

as it seems like something that is relatively easy to do

this is one of the main reasons why I like the idea

Santiago Pastorino (Feb 27 2020 at 15:55, on Zulip):

and also learning by reading code is nice

nikomatsakis (Feb 27 2020 at 15:55, on Zulip):

I guess I would prioritize "smaller, easy to do" steps, on the premise that the best docs are the ones that exist

Santiago Pastorino (Feb 27 2020 at 15:55, on Zulip):

would be something that we could do incrementally, one day there are titles and PRs, another day we have descriptions and one day the guide explains the PRs entirely :P

pnkfelix (Feb 27 2020 at 15:55, on Zulip):

Do we have a place where we are logging the road blocks newcomers encounter?

pnkfelix (Feb 27 2020 at 15:56, on Zulip):

@Nell Shamrell-Harrington hit a few yesterday that I would love to ensure get addressed in multiple places in our docs

centril (Feb 27 2020 at 15:56, on Zulip):

@Santiago Pastorino

Write a walkthrough about how a full feature is implemented

Or-patterns have fully recorded their implementation history, so it might be a good "from start to finish" example: https://github.com/rust-lang/rust/issues/54883

Santiago Pastorino (Feb 27 2020 at 15:56, on Zulip):

pnkfelix said:

Do we have a place where we are logging the road blocks newcomers encounter?

I don't think so, would be nice to track those yeah

pnkfelix (Feb 27 2020 at 15:56, on Zulip):

I could file issues (against the guide itself) but I'm not sure if that's the best way to just jot down "here's somethinig that was painful"

Santiago Pastorino (Feb 27 2020 at 15:56, on Zulip):

pnkfelix said:

Nell Shamrell-Harrington hit a few yesterday that I would love to ensure get addressed in multiple places in our docs

in particular if you Nell want to talk to me about stuff just feel free to ping me

nikomatsakis (Feb 27 2020 at 15:57, on Zulip):

seems like filing issues on rustc-guide (if it is indeed smething that would be addressed there) is a reasonable way to go

Santiago Pastorino (Feb 27 2020 at 15:57, on Zulip):

even your help in rustc-guide would probably be very useful

Nell Shamrell-Harrington (Feb 27 2020 at 15:57, on Zulip):

can do!

Santiago Pastorino (Feb 27 2020 at 15:57, on Zulip):

pnkfelix said:

I could file issues (against the guide itself) but I'm not sure if that's the best way to just jot down "here's somethinig that was painful"

for now it seems to be the best way

pnkfelix (Feb 27 2020 at 15:58, on Zulip):

I guess another option would be to link to messages (here in Zulip or on Discord, etc) where new comers ask questions that should be addressed in the guide

pnkfelix (Feb 27 2020 at 15:58, on Zulip):

since sometimes those discussions are illuminating

Santiago Pastorino (Feb 27 2020 at 15:59, on Zulip):

btw I'm also looking for people that can give lectures, about LLVM, codegen, Parallel and other things, but if any of you feel like doing a lecture about some topic let me know

Nell Shamrell-Harrington (Feb 27 2020 at 15:59, on Zulip):

I was thinking about submitting a Compiler 101 talk to RustConf - which would include info about LLVM

pnkfelix (Feb 27 2020 at 15:59, on Zulip):

pnkfelix said:

I guess another option would be to link to messages (here in Zulip or on Discord, etc) where new comers ask questions that should be addressed in the guide

(but I also don't know the best central place to monitor for such discussion? Perhaps in #new members ?)

pnkfelix (Feb 27 2020 at 16:00, on Zulip):

anyway, that is great food for thought for everyone. Thanks @Santiago Pastorino !

pnkfelix (Feb 27 2020 at 16:00, on Zulip):

and with that, I'm going to claim that this meeting is over. (On time this week!!!!)

pnkfelix (Feb 27 2020 at 16:01, on Zulip):

thanks @T-compiler/meeting !

Nell Shamrell-Harrington (Feb 27 2020 at 19:03, on Zulip):

Biggest lesson I learned yesterday - for the love of God don't try to do the full build in debug mode (RUSTC_LOG=debug) - had to kill the thing after 90 min.

Instead, if I want to see debug statements in my tests, I have been doing the stage 1 build on its own:
./x.py build --stage 1

And then running my individual test with:

RUSTC_LOG=debug /home/nell/rust/build/x86_64-unknown-linux-gnu/stage1/bin/rustc /home/nell/rust/src/test/ui/borrowck/issue-57431-coerced-mut-reference.rs

Last update: May 29 2020 at 16:30UTC