Stream: t-compiler/rust-analyzer

Topic: check-in at T-compiler mtg

pnkfelix (Feb 26 2019 at 14:38, on Zulip):

hey @matklad , are you available during the compiler triage meeting this Thursday (15:00 - 16:00 UTC)?

pnkfelix (Feb 26 2019 at 14:39, on Zulip):

@nikomatsakis and I were thinking it would be great for the WG-rls-2.0 to be part of this week "Working Group check-in", especially to get feedback on the short-term planning we have sketched out so far

nikomatsakis (Feb 26 2019 at 14:39, on Zulip):

(cc @Igor Matuszewski)

pnkfelix (Feb 26 2019 at 14:40, on Zulip):

and I was thinking that if you (or @Igor Matuszewski , yes) were available, even just for the 15:30 -- 16:00 UTC portion of the meeting, then having one of you drive the presentation would be great

nikomatsakis (Feb 26 2019 at 14:41, on Zulip):

In particular I was thinking it would be good to "broadcast" the overall theme we seemed to have arrived at yesterday, and that the compiler time might be able to help sharpen the "it would be useful to exclude this part of Rust to simplify things".

(Actually, on that note, I think it would be great to run some of those thoughts by @Vadim Petrochenkov, not sure if they'll be present at the meeting...)

Vadim Petrochenkov (Feb 26 2019 at 15:32, on Zulip):

Random thoughts:
- Most of code in librustc_resolve is about diagnostics at this point.
- I'd like to have a standalone model that's "pure", simplified, formalized and doesn't have all that diagnostic cruft and language features irrelevant to resolution.
- I'm unlikely to work on such a model.
- That standalone model probably won't be directly reusable in rustc due to diagnostics, and its source will need to be expanded and integrated in rustc.
- I'm generally unhappy about the compiler moving from the "monorepo" model to separate crates, repos, organizations.
- My preferences can probably be ignored since I'm unlikely to participate in the rls 2.0 / frontend 2.0 work in any significant capacity.

pnkfelix (Feb 26 2019 at 15:45, on Zulip):

Hmm. I admit I had not given much proper thought as to how to architect diagnostic-support if we do indeed try to make the model directly testable in rustc itself

pnkfelix (Feb 26 2019 at 15:46, on Zulip):

but I certainly agree that if it doesn't have diagnostic support, then there's no way rustc could switch to it as the primary implementation.

matklad (Feb 26 2019 at 16:35, on Zulip):

yup, added to my calendar.

I'm generally unhappy about the compiler moving from the "monorepo" model to separate crates, repos, organizations.

My personal end goal is a monorepo setup, but a monorepo of fairly independent libraries. I see the current setup with a separate repo as a temporary one.

matklad (Feb 26 2019 at 16:36, on Zulip):

Will also prepare the summary document for the yesterday's discussion by thursday

nikomatsakis (Feb 26 2019 at 18:28, on Zulip):

On this note, leaving aside the mono/poly-repo question (which is very technical), I think that the goal of working groups (i.e., the "organizations" part of your sentence) is really to allow us to scale and do more things without fragmenting too much. That is, a key point is to find ways to keep us all aware of what's going on (to the extent we wish to follow along). If that's not working, we should definitely tinker with the model. (I would say it's too early to tell this as of yet, since we're not really "up and running" yet)

centril (Feb 26 2019 at 22:28, on Zulip):

:heart: ; I think we should aspire to this for most of the things in the language including syntax (lexical + abstract), resolution, traits, type system, abstract machine, etc.

matklad (Feb 28 2019 at 14:59, on Zulip):

Is the meeting on IRC?

matklad (Feb 28 2019 at 15:00, on Zulip):

Calendar says: "The meeting occurs in #rustc on IRC." I thought we've moved off of IRC?

Last update: Jul 26 2021 at 12:30UTC