Stream: t-compiler/rust-analyzer

Topic: Steering meeting


matklad (Jan 13 2021 at 13:45, on Zulip):

Placeholder message. Stay tuned!

matklad (Jan 13 2021 at 13:56, on Zulip):

@WG-rls2.0 (and @nikomatsakis especially), I think we have a pretty awesome cadence with weekly releases , delivering new features and bugs like a clockwork! Shoutouts to @Jeremy Kolb, @Laurențiu Nicola, @Lukas Wirth , and @Kirill Bulatov for helping a lot with keeping the rolling stone in the air, or whatever is the appropriate idiom.

However, I've noticed that we've run out of steam a bit with respect to longer term roadmaps and projects. Ie, what is the next big thing we are working on? I personally don't know :sad:

To take a more proactive approach here, I've decided to cannibalize every sixsth weekly meeting and hold a steering meeting instead.

matklad (Jan 13 2021 at 13:58, on Zulip):

The next one will happen next Monday, in this stream. The purpose is to force us to think in a more long-term way, and, well, to steer the direction of the project!

Laurențiu (Jan 13 2021 at 13:58, on Zulip):

weekly releases , delivering new features and bugs

Yaay for new bugs each week

Laurențiu (Jan 13 2021 at 14:01, on Zulip):

I guess not much has changed, but https://rust-analyzer.github.io/blog/2020/05/18/next-few-years.html is probably worth a re-read. The VFS should be in a much better state now, though.

Edwin Cheng (Jan 13 2021 at 14:15, on Zulip):

And I have solved a lot of personal things in the last six months, and hopefully will have more time to contribute, especially for macro related stuffs.

matklad (Jan 13 2021 at 14:25, on Zulip):

Yeah, it's also true that the last n months were pretty challenging for a lot of folks, so a bit of a slowdown is expected and I would say healthy )

matklad (Jan 13 2021 at 14:25, on Zulip):

@Laurențiu Nicola thanks for that link, it's still a good read!

Laurențiu (Jan 13 2021 at 14:28, on Zulip):

Filed https://github.com/rust-lang/rust/pull/80984 to update the version shipped with rustup, we had one from September

Laurențiu (Jan 13 2021 at 14:29, on Zulip):

We should include this in the release workflow

Jonas Schievink [he/him] (Jan 13 2021 at 14:29, on Zulip):

I was going to say that we should probably start doing that more regularly, thanks!

Kirill Bulatov (Jan 13 2021 at 15:12, on Zulip):

I still consider myself more like a rust-analyzer user rather then a developer and apparently percepting the majority of the features things from this standpoint (mainly due to complete absence of fundamental knowledge on the compiler/ide domain).
This puts me into a weird position, where I understand the necessity of the things mentioned in the blogpost above, but don't care about any of those :smile:

Insead, I have a bunch of scattered semi-formed ideas (and rants apparently, after re-reading) about what I want to see in RA eventually, maybe some of them can be useful:

IMO this is not just big, it's huge (for the resources it will require and for the impact it can bring) and heavily underrated: when I see things like https://github.com/intellij-rust/intellij-rust/pull/5189 I'm really excited to see this in action and sad, thinking of how far we're from there.

Feels like this can be done at this stage already, although not sure if feasible still: it also seems huge.

RA is still more like a CLI Linux tool for me, with a ton of parameters and not that many docs related to them, with almost no UI elements to hide them behind.

For instance, when I see this

image.png

I'm always dreaming of some sort of intelli-like panel where I could have adjusted those instead.
There are more I can come up with and I understand that there are big limitations on the editor + LSP side for those, but still current UX (and the documentation) look as crafted by the professional developers, not by the professional designers :)

That is far-streched, but still: currently all we have is our codebase and almost zero knowledge on how to add, say, custom macro syntax highlighting & completion plugin.
(a few other good examples, remembering the new intellij-rust, would be the ML completion and repl integration)

Maybe it's too early to think of this now, since we're still "expetimental", but nice to mention nonetheless.
There were a bunch of "I've reinstalled the RA and now it works" reports (I think I've hit it myself recently) and lots of closed issues with "it had been fixed at some point, please recheck" resolution.

Basically, we have no idea what breaks and how bad it's broken, there's no clearly visible indication of whether the plugin is up-to-date, whether something panics inside or not, etc.
Worse, usually we get to know about this from the flood of issues/reddit/other external places, not our tests.
And the users have to make some sorcery to provide us some way to detect what's wrong, which is not always optimal too.

Surprisingly, there's plenty of people (especially the new ones, which is super weird) unaware of RA and difference between RA, RLS and others.

Maybe it's time to close the RLS-RA gap finally and propagate the knowledge a bit better.

Just a neverending task that consumes plenty of time and will consume more and more as the time goes and the features become more abundant.

I'm pretty surprised by the fact that we were not only able to maintain the same good development pace we've had before the greater popularity had struck RA project, but also kept on reviewing, houskeeping, mentoring and doing whatever public things needed to be done.

Yet I'm still concerned that the development is done by ~3 persons on the payroll and otherwise enthusiastic volunteers without liabilities.
I understand the compexity of the situation (especially with the rustc events on the background) and stunned by the results that had been achieved by the people during the time I observe the development, but still would appreciate more support from big players on the market here.

Joshua Nelson (Jan 13 2021 at 15:13, on Zulip):

Yet I'm still concerned that the development is done by ~3 persons on the payroll and otherwise enthusiastic volunteers without liabilities.

lol you clearly haven't seen how few people are on the other rust teams

Joshua Nelson (Jan 13 2021 at 15:14, on Zulip):

3 people on payroll is giant

Laurențiu (Jan 13 2021 at 15:19, on Zulip):

lack of stability and ways to diagnose the issue

This doesn't seem so bad to me. We've had some badly-reported issues, and other older ones got fixed without being referenced in the PRs, but that's because people have been doing a great job at fixing long-standing stuff.

lack of RA awareness

Because none of the official materials mention RA, but indeed, a lot of people only know about RLS.

Jonas Schievink [he/him] (Jan 13 2021 at 15:21, on Zulip):

Joshua Nelson said:

3 people on payroll is giant

To be clear, it's not 3 people working full-time, the open collective doesn't even fund one full-time position IIRC (but I was able to do a lot of paid work last year, so it ended up being more than 1 full-time position, which is a nice improvement)

Joshua Nelson (Jan 13 2021 at 15:22, on Zulip):

right, sure, but docs.rs, clippy, rustup, don't even have a single full-time person

Joshua Nelson (Jan 13 2021 at 15:22, on Zulip):

or forget full-time, anyone who's paid at all

Jonas Schievink [he/him] (Jan 13 2021 at 15:23, on Zulip):

The IntelliJ plugin has a couple of full-time employees working on it I think

Florian Diebold (Jan 13 2021 at 15:24, on Zulip):

Laurențiu Nicola said:

lack of stability and ways to diagnose the issue

This doesn't seem so bad to me. We've had some badly-reported issues, and other older ones got fixed without being referenced in the PRs, but that's because people have been doing a great job at fixing long-standing stuff.

I think there's more _perceived_ instability than actual instability (though we had some real problems recently), caused mostly by misconfigurations and by introducing new diagnostics that show things not working that were previously just invisible. That perception does annoy me, but I don't know if it's actually worth doing much about

Laurențiu (Jan 13 2021 at 15:26, on Zulip):

Yeah, the new diagnostics affected a lot of people, but we've fixed a ton of bugs thanks to them

Florian Diebold (Jan 13 2021 at 15:29, on Zulip):

Yeah certainly. I expect a similar wave when we add type checking / body name resolution diagnostics

Laurențiu (Jan 13 2021 at 15:30, on Zulip):

Can't wait for that. At least there we have a good number of false positives in RA itself

Jeremy Kolb (Jan 13 2021 at 15:30, on Zulip):

One thing I'd like to do if I find the time is figure out how to upstream some of our LSP modifications (especially around snippets and inlay hints) and get them into the protocol like matklad did with the extend selection request.

Jonas Schievink [he/him] (Jan 13 2021 at 15:31, on Zulip):

Is there any progress on rust-analyzer support in the official plugin since that was added initially?

Laurențiu (Jan 13 2021 at 15:32, on Zulip):

Last commit on 22 Jul 2020

Laurențiu (Jan 13 2021 at 15:33, on Zulip):

I think it's pretty much broken, but of course, a lot of users try it then complain that RA doesn't work

Jeremy Kolb (Jan 13 2021 at 15:34, on Zulip):

Laurențiu Nicola said:

I think it's pretty much broken, but of course, a lot of users try it then complain that RA doesn't work

I've noticed that too.

Jeremy Kolb (Jan 13 2021 at 15:35, on Zulip):

We need to get the message out somehow (we also get a lot of duplicate bug reports)

nikomatsakis (Jan 13 2021 at 16:53, on Zulip):

matklad said:

To take a more proactive approach here, I've decided to cannibalize every sixsth weekly meeting and hold a steering meeting instead.

big fan

Edwin Cheng (Jan 13 2021 at 18:48, on Zulip):

I think there's more _perceived_ instability than actual instability (though we had some real problems recently), caused mostly by misconfigurations and by introducing new diagnostics that show things not working that were previously just invisible. That perception does annoy me, but I don't know if it's actually worth doing much about

Some of these misconfigurations bug is related to https://github.com/rust-analyzer/rust-analyzer/issues/6448 , and I think we could enable it as default ?

Edwin Cheng (Jan 13 2021 at 18:53, on Zulip):

Yeah certainly. I expect a similar wave when we add type checking / body name resolution diagnostics

Can't wait for that too! And other thing is attrib proc-macro. One of difficulties is attrib proc-macro is "rewrite" (compare to derive macro which is additive), it will generate tons of problem if it generate incorrect ouptuts.

Joshua Nelson (Jan 13 2021 at 18:56, on Zulip):

about https://github.com/rust-analyzer/rust-analyzer/issues/6448#issuecomment-759646837: I know because bootstrapping is hard :( https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/What.20does.20this.20compile.20error.20mean.3F/near/222529165

Jonas Schievink [he/him] (Jan 13 2021 at 18:59, on Zulip):

"Load out dirs from check" (which really should be renamed, since it loads all kinds of stuff) seems like something we might want to integrate with check-on-save, no?

Jonas Schievink [he/him] (Jan 13 2021 at 18:59, on Zulip):

As in, we'll start analysis without this information, and feed the cargo check data back into the analysis everytime the user saves

Jonas Schievink [he/him] (Jan 13 2021 at 19:00, on Zulip):

Right now we only "load out dirs from check" once on startup, which means that proc macros don't get properly refreshed if they change

matklad (Jan 13 2021 at 19:03, on Zulip):

oh, https://github.com/rust-lang/cargo/pull/9071 is relevant

Edwin Cheng (Jan 13 2021 at 19:14, on Zulip):

"Load out dirs from check" (which really should be renamed, since it loads all kinds of stuff) seems like something we might want to integrate with check-on-save, no?

It should be, but how about people whom don't use check on save but still want to use proc-macro ? IIRC @matklad mentioned he does not use check on save too :)

Kirill Bulatov (Jan 13 2021 at 19:37, on Zulip):

I don't use check on save and would appreciate if you spare me from using it: I occasionally work on some projects with tremendous amounts of dependencies that take extended time to rebuild incrementally and have weird build.rs that retrigger crate rebuilds even though there were no real changes (seems also that rustc has some issues with that too).
That also impacts my laptop battery severely.

matklad (Jan 15 2021 at 11:13, on Zulip):

Finally caught up with the therad. Thanks @Kirill Bulatov for taking time to write that comment, it's very helpful! I think it will be a great starting point for the discussion on Monday; in the meantime, let me think about it a bit more :)

matklad (Jan 18 2021 at 15:02, on Zulip):

Welcome @WG-rls2.0 to our first ever steering meeting!

matklad (Jan 18 2021 at 15:03, on Zulip):

The rough agenda for today's meeting:

matklad (Jan 18 2021 at 15:04, on Zulip):

Let's start with the current state

matklad (Jan 18 2021 at 15:05, on Zulip):

The biggest goal for last year was to cross the rubicon and to make rust-analyzer official

matklad (Jan 18 2021 at 15:05, on Zulip):

Sadly, this is blocked at the moment: moving rust-analyzer into rust-lang org softly waits on the foundation stuff

matklad (Jan 18 2021 at 15:06, on Zulip):

This I think is the reason why we sort-of missed the big goal by the end of the year

matklad (Jan 18 2021 at 15:07, on Zulip):

I think this is not a big problem though: there's a lot of things we can do keeping rust-analyzer in its current steady state.

matklad (Jan 18 2021 at 15:08, on Zulip):

And yeah, one bit here is to figuring out goals process, so that we know what we are working on )

matklad (Jan 18 2021 at 15:10, on Zulip):

I have a couple of questions about that:

Jonas Schievink [he/him] (Jan 18 2021 at 15:11, on Zulip):

6 weeks makes sense to me. It also coincides with the Rust release schedule, so we could sync submodule updates to the steering meetings.

Laurențiu (Jan 18 2021 at 15:12, on Zulip):

Re scheduling, there's a minor risk of forgetting about them because 6 weeks is hard to keep track of, but it's probably not much of a problem

Jonas Schievink [he/him] (Jan 18 2021 at 15:12, on Zulip):

We can make a recurring calendar entry

Jonas Schievink [he/him] (Jan 18 2021 at 15:13, on Zulip):

And mention the steering meeting in the preceding weekly sync

matklad (Jan 18 2021 at 15:13, on Zulip):

@Jonas Schievink already did that

matklad (Jan 18 2021 at 15:13, on Zulip):

We could also time it to be the Monday after rust-lang release...

matklad (Jan 18 2021 at 15:14, on Zulip):

https://calendar.google.com/calendar/u/0/embed?src=6u5rrtce6lrtv07pfi3damgjus@group.calendar.google.com

Jonas Schievink [he/him] (Jan 18 2021 at 15:14, on Zulip):

If we do want to sync the submodule update I'd prefer the monday before a Rust release (which is always on a thursday)

matklad (Jan 18 2021 at 15:14, on Zulip):

that's the calendar where the meeting it

Jonas Schievink [he/him] (Jan 18 2021 at 15:14, on Zulip):

Since otherwise people will be 6 more weeks behind

Jonas Schievink [he/him] (Jan 18 2021 at 15:15, on Zulip):

oh, nice, I keep forgetting about that calendar

oliver (Jan 18 2021 at 15:15, on Zulip):

there are both sync and steering meetings

matklad (Jan 18 2021 at 15:15, on Zulip):

@Jonas Schievink hm, do you want to be the cheif submodule updater(/

Jonas Schievink [he/him] (Jan 18 2021 at 15:16, on Zulip):

Yeah I can do that

matklad (Jan 18 2021 at 15:16, on Zulip):

@oliver that's intentional -- it is a meeting stealing algorithm!

oliver (Jan 18 2021 at 15:17, on Zulip):

then to 'sync the submodule update' would be a steering meeting?

matklad (Jan 18 2021 at 15:17, on Zulip):

yup

matklad (Jan 18 2021 at 15:17, on Zulip):

Ok, I guess 6 weeks is ok, and ther's calendar, and it makes to nail down that as we go

matklad (Jan 18 2021 at 15:18, on Zulip):

The next question is how do we track descisons and progress?

matklad (Jan 18 2021 at 15:18, on Zulip):

I've thought about creating a GitHub project for that , but maybe just a pinned issue would do?

matklad (Jan 18 2021 at 15:19, on Zulip):

The issue:

matklad (Jan 18 2021 at 15:19, on Zulip):
Jonas Schievink [he/him] (Jan 18 2021 at 15:20, on Zulip):

we're already using 3/3 pinned issues

matklad (Jan 18 2021 at 15:20, on Zulip):

This feels like overthinking, to be honest, but I want to have some artifact as an outcome of the meeting

Jonas Schievink [he/him] (Jan 18 2021 at 15:21, on Zulip):

yeah makes sense

matklad (Jan 18 2021 at 15:21, on Zulip):

@Jonas Schievink yeah, I want to unpin project.json changes )

Kirill Bulatov (Jan 18 2021 at 15:21, on Zulip):

And the transition issue is sort of a part of a roadmap anyway.

Jonas Schievink [he/him] (Jan 18 2021 at 15:21, on Zulip):

ah, just noticed that beta promotion happens on mondays, so if we wanna sync with the submodule update we should have the meeting a week before the release

matklad (Jan 18 2021 at 15:22, on Zulip):

@Jonas Schievink maybe it's better to not sync them though?

Jonas Schievink [he/him] (Jan 18 2021 at 15:22, on Zulip):

could be, yeah

matklad (Jan 18 2021 at 15:22, on Zulip):

I guss, it's a good point to check that we did't forget the update

Jonas Schievink [he/him] (Jan 18 2021 at 15:22, on Zulip):

but that could also act as an artifact

Jonas Schievink [he/him] (Jan 18 2021 at 15:23, on Zulip):

to deliver the results of the 6 weeks to upstream

matklad (Jan 18 2021 at 15:23, on Zulip):

Hm

oliver (Jan 18 2021 at 15:23, on Zulip):

why is it important to have two types of meetings?

matklad (Jan 18 2021 at 15:24, on Zulip):

we are nightly only anyways. so I guess beta promotion isn't strictly necessary

Jonas Schievink [he/him] (Jan 18 2021 at 15:24, on Zulip):

ah, right, then this is probably irrelevant

matklad (Jan 18 2021 at 15:24, on Zulip):

@oliver to have different mindsets: immediate problems vs med-term future

matklad (Jan 18 2021 at 15:25, on Zulip):

Ok, so meeting every 6 weeks + pinned issue + :tada: promotion sounds right!

matklad (Jan 18 2021 at 15:26, on Zulip):

Let's move one meta level down and think about next weeks then

matklad (Jan 18 2021 at 15:27, on Zulip):

I have three large areas in mind:

matklad (Jan 18 2021 at 15:28, on Zulip):

/poll priorities

Joshua Nelson (Jan 18 2021 at 15:29, on Zulip):

Screenshot_20210118-102908_Zulip.jpg

Joshua Nelson (Jan 18 2021 at 15:29, on Zulip):

FYI polls don't work on mobile

Laurențiu (Jan 18 2021 at 15:30, on Zulip):

Joshua Nelson said:

FYI polls don't work on mobile

They work in Firefox

matklad (Jan 18 2021 at 15:30, on Zulip):

I am curious which of the 3 you think we should focus next 6 weeks?

matklad (Jan 18 2021 at 15:31, on Zulip):

@Joshua Nelson do :thumbs_up: work? I might go with separate messages than

Joshua Nelson (Jan 18 2021 at 15:31, on Zulip):

Yes, reactions work. simulacrum wrote a triagebot command for it I think

matklad (Jan 18 2021 at 15:32, on Zulip):

@Laurențiu Nicola you have only one vote

matklad (Jan 18 2021 at 15:32, on Zulip):

doing two things is doing zero things )

bjorn3 (Jan 18 2021 at 15:32, on Zulip):

:wave: I didn't know that this meeting would be today.

matklad (Jan 18 2021 at 15:33, on Zulip):

@bjorn3 sorry about that -- itis the first one, hard to get routine going

matklad (Jan 18 2021 at 15:33, on Zulip):

theres' an event in the t-compiler calendar now

bjorn3 (Jan 18 2021 at 15:34, on Zulip):

No problem. I don't have access to the T-compiler calendar though as far as I know.

matklad (Jan 18 2021 at 15:35, on Zulip):

@bjorn3 https://calendar.google.com/calendar/u/0/embed?src=6u5rrtce6lrtv07pfi3damgjus@group.calendar.google.com ?

matklad (Jan 18 2021 at 15:35, on Zulip):

does it work?

Laurențiu (Jan 18 2021 at 15:35, on Zulip):

It works for me and I'm not a team member

bjorn3 (Jan 18 2021 at 15:35, on Zulip):

Yes, thanks for the link.

Joshua Nelson (Jan 18 2021 at 15:35, on Zulip):

As an outsider, I would like better integration with rustc, but for a different reason than you may expect: I've found RA has a much easier to understand codebase and I hope integrating it with rustc will rub off so to speak

oliver (Jan 18 2021 at 15:35, on Zulip):

is it possible to add notifications to all of the events?

matklad (Jan 18 2021 at 15:36, on Zulip):

@oliver I don't know -- not very fluent with org stuff (

Joshua Nelson (Jan 18 2021 at 15:37, on Zulip):

/me has been trying to understand the trait system for almost a month now

matklad (Jan 18 2021 at 15:37, on Zulip):

Ok, I think it does make sense to focus on shipping things next 6weeks -- it's the best way to try stearing meeting

matklad (Jan 18 2021 at 15:39, on Zulip):

And, to be clear, the goal here is not to try to define work, but form shared values: I am going go hack on rowan regardless, but @Kirill Bulatov post changed the way I see things a bit, and that is the reason why we are talking here

matklad (Jan 18 2021 at 15:40, on Zulip):

What are medium-term things we can do to make the users extatic?

matklad (Jan 18 2021 at 15:41, on Zulip):

One thing that comes to mind for me personally is enabling proc macros by default

Jonas Schievink [he/him] (Jan 18 2021 at 15:41, on Zulip):

If sorting issues by number of :+1: reactions is anything to go by, reducing memory usage and supporting inner items properly are high on the list

Laurențiu (Jan 18 2021 at 15:41, on Zulip):

My personal one is type inference and nameres accuracy (for autocompletion). Macros would be a second one, since they're needed for that anyway

Edwin Cheng (Jan 18 2021 at 15:41, on Zulip):

How many time @bjorn3 copy and paste that setting in issues ? :)

Jonas Schievink [he/him] (Jan 18 2021 at 15:42, on Zulip):

Support for attribute macros is huge for some users, but doesn't matter to others

bjorn3 (Jan 18 2021 at 15:42, on Zulip):

Edwin Cheng said:

How many time bjorn3 copy and paste that setting in issues ? :)

I added a saved reply, so not a lot :)

Kirill Bulatov (Jan 18 2021 at 15:42, on Zulip):

Not sure if feasible, but might be good to suport better our features in macros, similar to https://github.com/rust-analyzer/rust-analyzer/pull/7321

Joshua Nelson (Jan 18 2021 at 15:42, on Zulip):

Jonas Schievink said:

If sorting issues by number of :+1: reactions is anything to go by, reducing memory usage and supporting inner items properly are high on the list

big +1 to less memory usage, I don't even use RA on docs.rs because it crashes my laptop

Joshua Nelson (Jan 18 2021 at 15:43, on Zulip):

(most other codebases are fine though)

matklad (Jan 18 2021 at 15:43, on Zulip):

I also do think that Cargo.toml support would be huge, and @Kirill Bulatov is eyeing this

Edwin Cheng (Jan 18 2021 at 15:43, on Zulip):

+1 for Cargo.toml

Kirill Bulatov (Jan 18 2021 at 15:44, on Zulip):

(very slowly, with any actual work kicked off somewhere in the end of Feb by a single amateur dev, so it's not even a 6-week effort)

matklad (Jan 18 2021 at 15:45, on Zulip):

Inner items are tough -- it needs someone pretty dedicated...

Jonas Schievink [he/him] (Jan 18 2021 at 15:46, on Zulip):

I could probably implement that, since it's mostly tied to nameres. Not sure I'll find the time though.

bjorn3 (Jan 18 2021 at 15:46, on Zulip):

I proposed restricting inner items a bit in the 2021 edition: https://rust-lang.zulipchat.com/#narrow/stream/268952-edition/topic/forbid.20item.20definitions.20inside.20function.20bodies

Kirill Bulatov (Jan 18 2021 at 15:46, on Zulip):

Another metaidea for the usability would be to make a list of cool intellij-rust features and pick some.

I personally love their refactorings and diagnostics a lot (but the latter might irritate a lot of people rather then bring them joy in the beginning)

Florian Diebold (Jan 18 2021 at 15:46, on Zulip):

oh, another stream I didn't know about

matklad (Jan 18 2021 at 15:47, on Zulip):

No worries -- it is the first one!

Kirill Bulatov (Jan 18 2021 at 15:48, on Zulip):

Speaking of irritation, adding a generic assist(?) to suppress diagnostics and or/messages might be beneficial (at least you don't have to explain the users which magic string should be put into RA settings)

matklad (Jan 18 2021 at 15:48, on Zulip):

@Kirill Bulatov with intellij, some things are sadly client-side (

I really want "run cargo command" in vs code :sob:

Kirill Bulatov (Jan 18 2021 at 15:49, on Zulip):

I really want "run cargo command" in vs code

That sounds like a 6-week framable thing actually, I've had it in my tattered list of "cool things to have" for months.
IMO a very simple input field with some completion is enough and that's not that huge to do.

matklad (Jan 18 2021 at 15:51, on Zulip):

Ok, so the plan for the next Rust relase seems to be:

matklad (Jan 18 2021 at 15:52, on Zulip):

IMO a very simple input field with some completion is enough and that's not that huge to do.

The problem is, there's no API for that afaik

bjorn3 (Jan 18 2021 at 15:52, on Zulip):

Also not for vscode extensions?

matklad (Jan 18 2021 at 15:52, on Zulip):

OTOH, there's no API for inlay hints neither, and that didn't stop @Kirill Bulatov ...

matklad (Jan 18 2021 at 15:52, on Zulip):

@bjorn3 yup

Edwin Cheng (Jan 18 2021 at 15:53, on Zulip):

is anyone still working on that ra_fmt crate ??

matklad (Jan 18 2021 at 15:53, on Zulip):

@Edwin Cheng no

Kirill Bulatov (Jan 18 2021 at 15:53, on Zulip):

For the "run cargo command", IMO a fully homegrown VSCode solution is fine to start with, similar to the way we display gc stats or propose multiple imports to pick from (the latter is actually the way I imagine it, but it might involve plenty of client side code and suffering)

matklad (Jan 18 2021 at 15:55, on Zulip):

Ok, I guess it is time to wrap it up! I'll spawn a bunch of issues than, and link back into this thread!

matklad (Jan 18 2021 at 15:56, on Zulip):

Thanks folks for participating! We'll see in six weeks where we are at!

matklad (Jan 18 2021 at 17:32, on Zulip):

Our first steering issue: https://github.com/rust-analyzer/rust-analyzer/issues/7325#issue-788410886

matklad (Jan 18 2021 at 17:33, on Zulip):

Feel free to edit, obviously!

Jonas Schievink [he/him] (Jan 18 2021 at 19:26, on Zulip):

Wrote down a brief plan for handling local items: https://github.com/rust-analyzer/rust-analyzer/pull/7336

Laurențiu (Feb 23 2021 at 19:16, on Zulip):

Steering meeting next week, right?

matklad (Feb 23 2021 at 19:34, on Zulip):

Yup!

Laurențiu (Feb 23 2021 at 19:47, on Zulip):

Do we want a blog post or something?

matklad (Feb 23 2021 at 20:05, on Zulip):

My gut feeling is now: I’d rather keep steering and promotion separate

Laurențiu (Feb 23 2021 at 20:23, on Zulip):

I mean, we had this "sprint", we could write what happened. But I'm not sure it's worth it.

Jonas Schievink [he/him] (Feb 23 2021 at 20:23, on Zulip):

A retrospective would be good, but we can fold that into the next steering meeting

Jonas Schievink [he/him] (Feb 23 2021 at 20:24, on Zulip):

Since it's mostly useful for us, not the general user base

Jonas Schievink [he/him] (Feb 23 2021 at 20:24, on Zulip):

That said, this would probably make an excellent blog post too

matklad (Mar 01 2021 at 15:00, on Zulip):

Hey @WG-rls2.0 !

matklad (Mar 01 2021 at 15:00, on Zulip):

we have our second steering meeting now!

matklad (Mar 01 2021 at 15:01, on Zulip):

As a reminder, the tracking issue for the last one is https://github.com/rust-analyzer/rust-analyzer/issues/7325

matklad (Mar 01 2021 at 15:02, on Zulip):

The progress's been great: we did 0 out of 3 required items and 1 out of 1 optional items!

matklad (Mar 01 2021 at 15:02, on Zulip):

Although, we did advance the three issues quite a bit!

Jonas Schievink [he/him] (Mar 01 2021 at 15:03, on Zulip):

This happened because I work as per urgency-importance.png

Jonas Schievink [he/him] (Mar 01 2021 at 15:03, on Zulip):

and inner item support neither felt urgent nor important

matklad (Mar 01 2021 at 15:03, on Zulip):

@Jonas Schievink [he/him] you know, I am just about to publish my new library for parsing command line flags

Jonas Schievink [he/him] (Mar 01 2021 at 15:04, on Zulip):

more yaks to shave!

Jonas Schievink [he/him] (Mar 01 2021 at 15:06, on Zulip):

So, do we want to keep the 3 items for the next 6 week cycle or retarget?

matklad (Mar 01 2021 at 15:06, on Zulip):

I think we need to keep them

matklad (Mar 01 2021 at 15:06, on Zulip):

what we probably need to change is to try to more proactively follow through them

matklad (Mar 01 2021 at 15:07, on Zulip):

not sure what's the best porcess here... My tentative suggestion would be @matklad finishes up the rowan work, and then finished up all the other items

matklad (Mar 01 2021 at 15:08, on Zulip):

Althoug, I am wondering if we should drop memory usage

matklad (Mar 01 2021 at 15:08, on Zulip):

We make some improvemnt there, with @Jonas Schievink [he/him] interning and countme

matklad (Mar 01 2021 at 15:09, on Zulip):

And we've been secretly discussing picking up salsa parallelization work

matklad (Mar 01 2021 at 15:09, on Zulip):

|| and memory usage always go hand in hand

Laurențiu (Mar 01 2021 at 15:09, on Zulip):

There's still an actionable thing with the virtual macro-expansion files, right?

matklad (Mar 01 2021 at 15:10, on Zulip):

The investigation? right

Jonas Schievink [he/him] (Mar 01 2021 at 15:10, on Zulip):

global TypeRef/Path interning is actionable

matklad (Mar 01 2021 at 15:10, on Zulip):

Or you mean spilling to disk?

Laurențiu (Mar 01 2021 at 15:10, on Zulip):

No, there was something about item collection from recursive MBE expansions

Jonas Schievink [he/him] (Mar 01 2021 at 15:11, on Zulip):

ah, I prototyped that, didn't seem to improve memory usage though

Laurențiu (Mar 01 2021 at 15:12, on Zulip):

Ah, too bad. And we still can't run DHAT, I guess?

matklad (Mar 01 2021 at 15:12, on Zulip):

Do folks think that sinking focused hours into parallelizing salsa/rust-analyzer is the appropriate goal for the next sprint?

Laurențiu (Mar 01 2021 at 15:12, on Zulip):

Or maybe in making the salsa storage more cache-friendly?

Jonas Schievink [he/him] (Mar 01 2021 at 15:13, on Zulip):

Perhaps another thing to work towards at this point is not parsing item bodies?

Laurențiu (Mar 01 2021 at 15:13, on Zulip):

I think rustc ended up punting on the parallelization, maybe that one is too hard to crack

Jonas Schievink [he/him] (Mar 01 2021 at 15:13, on Zulip):

I have some ItemTree changes in mind that are useful anyways, and would help with that

matklad (Mar 01 2021 at 15:14, on Zulip):

btw, I've recently learned that we walk the whole syntax tree after parsing for validation

matklad (Mar 01 2021 at 15:14, on Zulip):

(but I didn't measure the impact of skiping validation)

matklad (Mar 01 2021 at 15:15, on Zulip):

@Jonas Schievink [he/him] maybe? It definitelly incersects with mutable trees.

Jonas Schievink [he/him] (Mar 01 2021 at 15:15, on Zulip):

Laurențiu Nicola said:

Ah, too bad. And we still can't run DHAT, I guess?

We can run valgrind DHAT, if you have heaps of RAM and a lot of time

Jonas Schievink [he/him] (Mar 01 2021 at 15:16, on Zulip):

It's what pointed me towards memory usage of TypeRef/Path

matklad (Mar 01 2021 at 15:16, on Zulip):

And there's a chance that we actually need something fancier still -- like building ItemTree out of green nodes or even straight forme the event stream, to not materialse syntax tree at all

Jonas Schievink [he/him] (Mar 01 2021 at 15:16, on Zulip):

yeah, that'd be neat

matklad (Mar 01 2021 at 15:17, on Zulip):

matklad said:

Do folks think that sinking focused hours into parallelizing salsa/rust-analyzer is the appropriate goal for the next sprint?

:point_up:

matklad (Mar 01 2021 at 15:17, on Zulip):

?

matklad (Mar 01 2021 at 15:18, on Zulip):

also, @Kirill Bulatov is there anything more to report regarding inlay hints impl?

Jonas Schievink [he/him] (Mar 01 2021 at 15:18, on Zulip):

matklad said:

Do folks think that sinking focused hours into parallelizing salsa/rust-analyzer is the appropriate goal for the next sprint?

Personally I'm more bothered by high memory usage than startup time, and would also like to finish off procedural attribute macro support

matklad (Mar 01 2021 at 15:19, on Zulip):

Yeah, that makes sense...

Laurențiu (Mar 01 2021 at 15:19, on Zulip):

matklad said:

Do folks think that sinking focused hours into parallelizing salsa/rust-analyzer is the appropriate goal for the next sprint?

It seems to me there might be larger wins in other areas (not parsing item bodies, salsa storage), and parallelization might make them less visible

matklad (Mar 01 2021 at 15:20, on Zulip):

I guess, now that I have 64 gigs and 12 cores, my personal priorities are skewed...

Jonas Schievink [he/him] (Mar 01 2021 at 15:20, on Zulip):

but figuring out the story for parallelization certainly seems good too, since we will need that eventually

Jonas Schievink [he/him] (Mar 01 2021 at 15:20, on Zulip):

I actually think persisting stuff to disk should be our last resort

matklad (Mar 01 2021 at 15:21, on Zulip):

yup, presitance is why I am eyeing ||

Laurențiu (Mar 01 2021 at 15:21, on Zulip):

Jonas Schievink [he/him] said:

I actually think persisting stuff to disk should be our last resort

I was thinking of using arenas for salsa. Which may be a path forward to persistence, but is still worth it even outside of that

matklad (Mar 01 2021 at 15:21, on Zulip):

I think that's better solution for slow startup then on-disk caches

matklad (Mar 01 2021 at 15:22, on Zulip):

Which may be a path forward to persistence,

Good point! Indixes are easire to mmap than pointers

matklad (Mar 01 2021 at 15:23, on Zulip):

So it seems like @Jonas Schievink [he/him] is tentatively volounteering to finish up the mem usage issue?

Kirill Bulatov (Mar 01 2021 at 15:24, on Zulip):

Do folks think that sinking focused hours into parallelizing salsa/rust-analyzer is the appropriate goal for the next sprint?

No idea, but looks like a reasonable step, considering the diagram brought by Jonas :smile:

is there anything more to report regarding inlay hints impl?

Nothing new, I rebase & force-push the branch and recheck it every week, but so far feels like nothing was done at all.
As I've mentioned already some time ago, I've sent the letter with the initial feedback and have gotten an abrupt reply, so nothing more actionable there for now, I guess.
I'll wait a couple more weeks and post a comment into the "upstream hints" issue, just to throw it away from my head and go on doing something else meanwhile.

Jonas Schievink [he/him] (Mar 01 2021 at 15:25, on Zulip):

matklad said:

So it seems like Jonas Schievink [he/him] is tentatively volounteering to finish up the mem usage issue?

I can look into that, yeah

Jonas Schievink [he/him] (Mar 01 2021 at 15:26, on Zulip):

but it seems there are still bugs around inner item handling that have to be fixed

matklad (Mar 01 2021 at 15:26, on Zulip):

uhu

Jonas Schievink [he/him] (Mar 01 2021 at 15:26, on Zulip):

I hope that won't take up all 6 weeks

matklad (Mar 01 2021 at 15:27, on Zulip):

I've also looked at the name res code again, when fixing that diagnostic issue, and it (at least the diagnistics part) was very hard to read

Edwin Cheng (Mar 01 2021 at 15:27, on Zulip):

How about proc-macro options ?? :)

matklad (Mar 01 2021 at 15:27, on Zulip):

So maybe some general cleanups are worth it as well in that area

Laurențiu (Mar 01 2021 at 15:28, on Zulip):

Edwin Cheng said:

How about proc-macro options ?? :)

Oof, we need to figure what to do about that rustc version PR

matklad (Mar 01 2021 at 15:28, on Zulip):

@Edwin Cheng you mean settings.json options? loadDirs, etc?

Edwin Cheng (Mar 01 2021 at 15:28, on Zulip):

yes

Edwin Cheng (Mar 01 2021 at 15:28, on Zulip):

I think I am not the best person to clean up settings and docs :)

matklad (Mar 01 2021 at 15:29, on Zulip):

:thumbs_up: I'll finish that up then!

matklad (Mar 01 2021 at 15:29, on Zulip):

After all, Edwin Cheng did the hardest part (lazy loading), so I might as well bring the stuff over the finish line :D

Edwin Cheng (Mar 01 2021 at 15:30, on Zulip):

Oof, we need to figure what to do about that rustc version PR

I could take it and finish it if the PR author want

matklad (Mar 01 2021 at 15:31, on Zulip):

@Edwin Cheng I guess you can ask on the issue? But also just doing doesn't seem bad to me, if you take care to preserve their commits and ensure proper attribution in general

Laurențiu (Mar 01 2021 at 15:31, on Zulip):

So do we

  1. want to check the rustc version in the proc macro metadata?
  2. support more than one proc macro ABI (maybe up to three for nightly/beta/stable)?
  3. try to figure out the rustc version range of the proc macro ABI? I did that for nightly in the PR, but blanked out when it came to the beta version; still, it should be doable, I guess.
matklad (Mar 01 2021 at 15:32, on Zulip):

It makes sense to start just with check I think

Edwin Cheng (Mar 01 2021 at 15:32, on Zulip):

Yes I would ask the author later on.

Laurențiu (Mar 01 2021 at 15:33, on Zulip):

Why not run rustc -V instead?

Edwin Cheng (Mar 01 2021 at 15:35, on Zulip):

Why not run rustc -V instead?

Oh, it should be the same ..... you r right.

Jonas Schievink [he/him] (Mar 01 2021 at 15:36, on Zulip):

that's not necessarily the compiler Cargo uses to build the proc macro

Jonas Schievink [he/him] (Mar 01 2021 at 15:37, on Zulip):

though I think non-cargo build systems would be the bigger issue here

Laurențiu (Mar 01 2021 at 15:42, on Zulip):

All right. So we try to finish the stuff in rust-analyzer#7325

matklad (Mar 01 2021 at 15:43, on Zulip):

Jup! With the difference being that @_matklad is now responsible to see to the stuff followed through

matklad (Mar 01 2021 at 15:43, on Zulip):

And we put || as an optional item, to not keep that bottom right quadrant empty?

Laurențiu (Mar 01 2021 at 15:44, on Zulip):

Re rowan, I suppose we want the better assists API, so I'd say we take the memory and parsing time hit?

matklad (Mar 01 2021 at 15:45, on Zulip):

Yeah, that's my feels as well, + vague ideas for more radical opts for read only case

matklad (Mar 01 2021 at 15:46, on Zulip):

rad = events, or storing tree in an array

Lukas Wirth (Mar 01 2021 at 15:49, on Zulip):

What I wanted to bring up was switching to chalks type representation, since I worked on that a bit the past day(s). Bring up as in whether this is something we would potentially want to target

Lukas Wirth (Mar 01 2021 at 15:49, on Zulip):

Bringing this up especially since I unfortunately brought in some regression as lnicola noted https://github.com/rust-analyzer/rust-analyzer/pull/7813#issuecomment-787936638

Jonas Schievink [he/him] (Mar 01 2021 at 15:49, on Zulip):

Is the upstream type IR library done already?

matklad (Mar 01 2021 at 15:54, on Zulip):

@Lukas Wirth I'd classify that as "refactor", and I'd always put refactoring over almost everything else

matklad (Mar 01 2021 at 15:54, on Zulip):

That is, you don't need this to be on the roadmap to deem it high prirority

Florian Diebold (Mar 01 2021 at 15:55, on Zulip):

Jonas Schievink [he/him]: Is the upstream type IR library done already?

that's a good question. my assumption was that chalk-ir would mostly stay the same, but that may be completely wrong. @Jack Huey @detrumi do you know?

matklad (Mar 01 2021 at 15:55, on Zulip):

but yeah, let's put this onto this cycle as well, to have that feeling of responsibility and anxiety! This is bit stuff, in the grand scheme of things

Jeremy Kolb (Mar 01 2021 at 16:01, on Zulip):

Kirill Bulatov said:

Do folks think that sinking focused hours into parallelizing salsa/rust-analyzer is the appropriate goal for the next sprint?

No idea, but looks like a reasonable step, considering the diagram brought by Jonas :smile:

is there anything more to report regarding inlay hints impl?

Nothing new, I rebase & force-push the branch and recheck it every week, but so far feels like nothing was done at all.
As I've mentioned already some time ago, I've sent the letter with the initial feedback and have gotten an abrupt reply, so nothing more actionable there for now, I guess.
I'll wait a couple more weeks and post a comment into the "upstream hints" issue, just to throw it away from my head and go on doing something else meanwhile.

They are not the most responsive. I think the big thing we'll need to watch out for is the timeline for stabilization of the API. We just want to make sure that by that point vscode supports what we need.

detrumi (Mar 01 2021 at 16:03, on Zulip):

Florian Diebold said:

Jonas Schievink [he/him]: Is the upstream type IR library done already?

that's a good question. my assumption was that chalk-ir would mostly stay the same, but that may be completely wrong. Jack Huey detrumi do you know?

There might be some small missing details, and the ongoing chalk integration into rustc might lead to some small changes in chalk-ir, but overall I would expect chalk-ir to stay mostly the same

detrumi (Mar 01 2021 at 16:10, on Zulip):

Lukas Wirth said:

Bringing this up especially since I unfortunately brought in some regression as lnicola noted https://github.com/rust-analyzer/rust-analyzer/pull/7813#issuecomment-787936638

Chalk hasn't really been optimized so far, so some temporary performance regressions are expected. But integration also makes it easier to identify where performance can be improved.

Lukas Wirth (Mar 01 2021 at 16:16, on Zulip):

I imagine swapping to chalks IR fully will help out here as well, or as you said at least aid in identifying performance things.

Florian Diebold (Mar 01 2021 at 16:30, on Zulip):

fully switching to Chalk's types may already help performance since we get rid of all the transformation code (maybe not though)

detrumi (Mar 01 2021 at 16:43, on Zulip):

Seems like there's a few upsides to switching to chalk-ir early, but at the same time there's the risk of additional churn in case chalk-ir has to change because of something that comes up in rustc integration. Integrating chalk-ir into both rustc and RA at the same time might guide the design faster but might also complicate things

Jack Huey (Mar 01 2021 at 17:22, on Zulip):

The biggest thing that comes to mind on things that could change with chalk-ir is adding Param to TyKind. I think we want to instead remove that in rustc, but it's a big ask and so we'll see.

Jack Huey (Mar 01 2021 at 17:22, on Zulip):

Most everything else should be "minor"

Jeremy Kolb (Mar 04 2021 at 18:47, on Zulip):

@Kirill Bulatov vscode 1.54 (just released) contains a blurb about the proposed inline values

Jeremy Kolb (Mar 04 2021 at 18:48, on Zulip):

though... just in the context of the debugger

Kirill Bulatov (Mar 04 2021 at 20:07, on Zulip):

Is it the thing you were referring to?
https://github.com/microsoft/vscode-docs/blob/vnext/release-notes/v1_54.md#inline-value-provider-api

Looks like they have two different proposals/APIs:

Looks like the debugger party is aware of the other api, but still keeps it separated, interesting.

But I've just rechecked and repushed the inline hints proposal and no changes are there yet:
image.png

I'll keep waiting, but thanks for your vigilance nonetheless.

Jeremy Kolb (Mar 04 2021 at 23:10, on Zulip):

Ahhh that makes sense.

matklad (Apr 12 2021 at 15:01, on Zulip):

Hey @WG-rls2.0 !

matklad (Apr 12 2021 at 15:01, on Zulip):

It's time for our third steering meeting!

matklad (Apr 12 2021 at 15:02, on Zulip):

Our tracking issuer looks much better than the last time: https://github.com/rust-analyzer/rust-analyzer/issues/7838

matklad (Apr 12 2021 at 15:03, on Zulip):
matklad (Apr 12 2021 at 15:04, on Zulip):

:medal: indeed, we all deserved it for this sprint!

matklad (Apr 12 2021 at 15:05, on Zulip):

Let's write what you think we can/should focus next in a "brainstorm" fashion? We should pick a couple objectives by the end of the meeting, but let's start with enumerating everything

Jonas Schievink [he/him] (Apr 12 2021 at 15:05, on Zulip):

I'm checking off memory usage and inner items, we did most of that

Jeremy Kolb (Apr 12 2021 at 15:06, on Zulip):

I have 0 time to devote to anything but I LOVE the progress made lately.

Jonas Schievink [he/him] (Apr 12 2021 at 15:06, on Zulip):

personally I have the goal of "finishing" hir_def, meaning reaching feature parity with rustc's name resolution and macro expansion implementation

matklad (Apr 12 2021 at 15:09, on Zulip):

Here's my list:

Features:

Debt:

Merging with Rustc:

matklad (Apr 12 2021 at 15:09, on Zulip):

@Lukas Wirth , @Florian Diebold ?

Lukas Wirth (Apr 12 2021 at 15:10, on Zulip):

Maybe consider trying to push RA to become more official? A lot of people still seem to fall for the RLS "trap"

matklad (Apr 12 2021 at 15:11, on Zulip):

Uhu, I guess I should start talking to foundation folks about that...

Edwin Cheng (Apr 12 2021 at 15:12, on Zulip):

I am working on ra_fmt

matklad (Apr 12 2021 at 15:12, on Zulip):

Yeah, that's long overdue...

Daniel Mcnab (Apr 12 2021 at 15:13, on Zulip):

I finally understand the reddit comment from @matklad a while back about rust-analyzer only being 30% of what it could be, just by thinking about other possible features and reading past issues.

matklad (Apr 12 2021 at 15:14, on Zulip):

Oh, I guess there's one more wish list item for me: reducing the number of broken windows.

Edwin Cheng (Apr 12 2021 at 15:14, on Zulip):

For attr macro, I would recommend we support proc-macro-hack as the first step, alike what we did for the macro 2.0 support (choose a smaller set to test the functionality first)

Jonas Schievink [he/him] (Apr 12 2021 at 15:15, on Zulip):

my current prototype for proc macro attrs will just support everything at once

matklad (Apr 12 2021 at 15:15, on Zulip):

It seems like before we had a breakneck dev speed to reach feature parity with rustc. Now that we did the first 90% of that, it seems to be wise to slow down to speed up: http://joeduffyblog.com/2013/04/12/software-leadership-4-slow-down-to-speed-up/

Edwin Cheng (Apr 12 2021 at 15:16, on Zulip):

And for macro, I will propose we should do some research on how to proper handle span and L_DOLLAR related problems

matklad (Apr 12 2021 at 15:16, on Zulip):

Edwin Cheng yeah, that intersects with "extract rust parser" thing

Kirill Bulatov (Apr 12 2021 at 15:17, on Zulip):

I'm still dreaming to carve the time for completion benches, but if you @matklad plan to work on that, I'd gladly step aside and hunt some small things to fix as I was usually doing.

(my dreams might come true very soon though, I've managed to offload all kids to the grannies at the very long last)

Edwin Cheng (Apr 12 2021 at 15:17, on Zulip):

I could imagine if we enable attr macro, it will break alot of completion features

Jonas Schievink [he/him] (Apr 12 2021 at 15:18, on Zulip):

yeah, attr macros still have a lot of questions around fallbacks and UX

Jonas Schievink [he/him] (Apr 12 2021 at 15:19, on Zulip):

I imagine we'll want to switch the symbol index to use DefMap to get better completions too?

Edwin Cheng (Apr 12 2021 at 15:19, on Zulip):

Thats why I recommand we hardcode the name of selected attr macro only to limit the bug report

Jonas Schievink [he/him] (Apr 12 2021 at 15:20, on Zulip):

yeah, I guess we could start with that

matklad (Apr 12 2021 at 15:21, on Zulip):

We discussed with vlad20012 of IntelliJ some way to mark "trivial" attr macros in Cargo.toml

matklad (Apr 12 2021 at 15:22, on Zulip):

Such that macros a-la tokio::main aren't actually expanded for the purposes of code completion.

Edwin Cheng (Apr 12 2021 at 15:22, on Zulip):

@Jonas Schievink [he/him] Do you have any idea about span and source file handling in proc macro? We currently don’t support it

Jonas Schievink [he/him] (Apr 12 2021 at 15:22, on Zulip):

hmm, since we throw out span info, we couldn't report accurate proc macro errors, right?

Jonas Schievink [he/him] (Apr 12 2021 at 15:22, on Zulip):

hah

Jonas Schievink [he/him] (Apr 12 2021 at 15:23, on Zulip):

that's a good question wrt. incrementality, I guess we'd somehow want a query that constructs span mappings, which is only invoked if the proc macro actually makes use of the span APIs?

Jonas Schievink [he/him] (Apr 12 2021 at 15:24, on Zulip):

but even without that, it would be nice to properly map spans in the macro output back to the input

matklad (Apr 12 2021 at 15:24, on Zulip):

Can we make proc-macros look only at the relative spans(/

Jonas Schievink [he/him] (Apr 12 2021 at 15:25, on Zulip):

for example I think syn will emit compile_error!("parse error") with a span pointing to the location of the syntax error

matklad (Apr 12 2021 at 15:25, on Zulip):

such that the query isn't invalidated when you type outside of the proc macro?

Jonas Schievink [he/him] (Apr 12 2021 at 15:25, on Zulip):

yeah, the query would only be used if some proc macro API is used that requires absolute positions, I think

Florian Diebold (Apr 12 2021 at 15:27, on Zulip):

sorry, got distracted

Florian Diebold (Apr 12 2021 at 15:27, on Zulip):

for me, probably starting to emit more diagnostics is the next step

Jonas Schievink [he/him] (Apr 12 2021 at 15:28, on Zulip):

I think we also need more tests for proc macros, I broke fn-like proc macros last week and no test failed

Jonas Schievink [he/him] (Apr 12 2021 at 15:29, on Zulip):

I'm not sure about more diagnostics, but improvements to them would be very nice

matklad (Apr 12 2021 at 15:29, on Zulip):

@Jonas Schievink [he/him] that's an interesting topic... I think we get a lot of leverage out of our "pure" test suite which doesn't do IO. I wonder what's the right testing strategy for proc macros, which gives us max coverage with minimilal deps on the stuff we don't controll.

Jonas Schievink [he/him] (Apr 12 2021 at 15:30, on Zulip):

I did add proc_macro_test as a dumping ground for proc macros that are used by the test suite

Jonas Schievink [he/him] (Apr 12 2021 at 15:30, on Zulip):

that crate should remain as small as possible, with 0 deps, so that cargo can build it quickly

matklad (Apr 12 2021 at 15:32, on Zulip):

Ok, we are past half of the meeting, so let's try to prioritize now!

Kirill Bulatov (Apr 12 2021 at 15:32, on Zulip):

I remember there was a discussion about utilizing VSCode IT tests and we turned them down.
Would that be a tolerable middleground here, with all macros and other features enabled on some project?

Kirill Bulatov (Apr 12 2021 at 15:33, on Zulip):

(uh, nvm then)

matklad (Apr 12 2021 at 15:33, on Zulip):

/poll

Laurențiu (Apr 12 2021 at 15:37, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/issues?q=is%3Aopen+is%3Aissue+label%3A%22Broken+Window%22 not sure we have enough of these, though

Lukas Wirth (Apr 12 2021 at 15:38, on Zulip):

I imagine there are some in there that aren't labeled yet

matklad (Apr 12 2021 at 15:38, on Zulip):

@Laurențiu I think that's more about attitudal change rather that fixing specific bugs.

matklad (Apr 12 2021 at 15:39, on Zulip):

Like, I kicked lazy fixes down the road for half a year already. I need a bit of targeted acceleration to actually see through that it is done.

matklad (Apr 12 2021 at 15:39, on Zulip):

And I fear that that salsa panic on cycle is a similar thing -- I'll be all to happy to pretend it doesn't exist :P

Edwin Cheng (Apr 12 2021 at 15:42, on Zulip):

Is any false positive diagnostics "broken windows"?

matklad (Apr 12 2021 at 15:43, on Zulip):

Good question: at this stage, I'd say no.

Laurențiu (Apr 12 2021 at 15:43, on Zulip):

Are non-technical debt issues "broken windows" when they're bad enough that someone running into them might think RA doesn't work at all?

Jonas Schievink [he/him] (Apr 12 2021 at 15:43, on Zulip):

the problem is that almost all nontrivial diagnostics will have false positives until hir_def/hir_ty reach parity with rustc

matklad (Apr 12 2021 at 15:44, on Zulip):

Though, once we do attr-like proc macros, that'd change to yes

Jonas Schievink [he/him] (Apr 12 2021 at 15:44, on Zulip):

today's release seem to have broken r-a for a few people

matklad (Apr 12 2021 at 15:46, on Zulip):

@Laurențiu I guess, I see broken window as a combination of the two:

matklad (Apr 12 2021 at 15:47, on Zulip):

today's release seem to have broken r-a for a few people

Mea culpa. That was a fix for a broken window by the way.

matklad (Apr 12 2021 at 15:48, on Zulip):

Ok, I think, in the last 10 minutes, we should hone our focus a bit!

oliver (Apr 12 2021 at 15:49, on Zulip):

focus on what?

matklad (Apr 12 2021 at 15:49, on Zulip):
matklad (Apr 12 2021 at 15:50, on Zulip):

@oliver on this specific subset of issues for the next sprint!

oliver (Apr 12 2021 at 15:50, on Zulip):

rust-analyzer isn't the official LS? false

Jonas Schievink [he/him] (Apr 12 2021 at 15:50, on Zulip):

what's "per feature crates" in the poll?

Jonas Schievink [he/him] (Apr 12 2021 at 15:50, on Zulip):

RLS is the official one

Edwin Cheng (Apr 12 2021 at 15:51, on Zulip):

Enable some set of features per crate for solving cycle deps bugs

Jonas Schievink [he/him] (Apr 12 2021 at 15:51, on Zulip):

ah

matklad (Apr 12 2021 at 15:51, on Zulip):

Yeah, "error: cycle detected" in the logs is def a broken window

oliver (Apr 12 2021 at 15:52, on Zulip):

who should use RLS over RA?

Edwin Cheng (Apr 12 2021 at 15:52, on Zulip):

IMO, we should impl it as soon as possible since it may affect the performance a lot.

matklad (Apr 12 2021 at 15:52, on Zulip):

:thinking: riight, crate forking for features might be the easiest way to fix our recent memory usage "regression" :laughing:

matklad (Apr 12 2021 at 15:53, on Zulip):

@Edwin Cheng strongly agree, added it to the suggested list!

Jonas Schievink [he/him] (Apr 12 2021 at 15:54, on Zulip):

crate forking would mean... adding non-cfg(test) duplicates of all crates in the workspace (but not from crates.io/sysroot), right?

matklad (Apr 12 2021 at 15:54, on Zulip):

@Jonas Schievink [he/him] right

Jonas Schievink [he/him] (Apr 12 2021 at 15:54, on Zulip):

definitely seems like a good thing to fix

matklad (Apr 12 2021 at 15:54, on Zulip):

@oliver I'd say, at this point, probably anybody should be using rust-analyzer. RLS, however, is still the official one, with the links from the website and such.

oliver (Apr 12 2021 at 15:55, on Zulip):

instead of saying 'making rust-analyzer the official LS ' maybe it should be 'notarize rust-analyzer the official LS' for clarity since RA already is built

matklad (Apr 12 2021 at 15:57, on Zulip):

Yeah, I'll try to phrase that more clearly.

oliver (Apr 12 2021 at 15:57, on Zulip):

or is that too focused?

oliver (Apr 12 2021 at 15:57, on Zulip):

like I'm not sure it even matters it's that focused

oliver (Apr 12 2021 at 15:58, on Zulip):

but it seems nice

matklad (Apr 12 2021 at 15:58, on Zulip):

Ok @WG-rls2.0 it seems that we went through the agenda!, any last minute things?

matklad (Apr 12 2021 at 15:59, on Zulip):

I want to re-iterate that this sprint was a blast! You all are awesome :heart: !

Edwin Cheng (Apr 12 2021 at 15:59, on Zulip):

Um.. I would like to know who is the official members or rust-analzyers workgroup ?

Edwin Cheng (Apr 12 2021 at 15:59, on Zulip):

and where can I find these information ?

matklad (Apr 12 2021 at 15:59, on Zulip):

Heh, good question! I don't think we have supper official membership

Kirill Bulatov (Apr 12 2021 at 16:00, on Zulip):

Maybe the contents of the WG-rls2.0 could be considered as the list?

Jonas Schievink [he/him] (Apr 12 2021 at 16:00, on Zulip):

only @matklad https://github.com/rust-lang/team/blob/master/teams/wg-rls-2.toml

matklad (Apr 12 2021 at 16:00, on Zulip):

Ther's a list of folks who get pinged on zulip, and it should be available in the groop settings

oliver (Apr 12 2021 at 16:00, on Zulip):

I don't have any links for this wg

matklad (Apr 12 2021 at 16:00, on Zulip):

yeah, there's wg toml, but it's not true, and not that useful

oliver (Apr 12 2021 at 16:01, on Zulip):

https://rust-lang.github.io/compiler-team/working-groups/rls-2.0/

oliver (Apr 12 2021 at 16:01, on Zulip):

soon someday

Jonas Schievink [he/him] (Apr 12 2021 at 16:01, on Zulip):

yeah, but it's the closest thing to "official" I could find :D

matklad (Apr 12 2021 at 16:01, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/tree/master/docs/dev#permissions

Florian Diebold (Apr 12 2021 at 16:01, on Zulip):

I got distracted again :grimacing:

matklad (Apr 12 2021 at 16:01, on Zulip):

I think that's the place which documents team membership.

matklad (Apr 12 2021 at 16:02, on Zulip):

@Florian Diebold no worries, here's your presonal todo list: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Steering.20meeting/near/234183320 :D

Florian Diebold (Apr 12 2021 at 16:02, on Zulip):

ok, I guess I should get to work then

detrumi (Apr 12 2021 at 16:03, on Zulip):

We just need to clone Florian a few times and we're set

matklad (Apr 12 2021 at 16:04, on Zulip):

@Edwin Cheng so, I guess https://github.com/orgs/rust-analyzer/teams/review is the closest approximation to "who is rls2.0 wg"

oliver (Apr 12 2021 at 16:04, on Zulip):

you need to login to follow that link :wrong_way:

Jonas Schievink [he/him] (Apr 12 2021 at 16:05, on Zulip):

does it make sense to sync that with the teams repo?

Kirill Bulatov (Apr 12 2021 at 16:05, on Zulip):

Weird, the link seem to contain a number of broken profile links (see the first one, for example) despite all avatars being in place.

Jeremy Kolb (Apr 12 2021 at 16:06, on Zulip):

It seems to work for me.

oliver (Apr 12 2021 at 16:07, on Zulip):

redirects directly to login page

Kirill Bulatov (Apr 12 2021 at 16:07, on Zulip):

Guess I'm missing some permissions then (or the order is different for you).

I get 404 for any profile url containing orgs/rust-analyzer/people

oliver (Apr 12 2021 at 16:07, on Zulip):

is this a protected repo?

Jonas Schievink [he/him] (Apr 12 2021 at 16:07, on Zulip):

you can only see team memberships if you're a member of the org

Jonas Schievink [he/him] (Apr 12 2021 at 16:08, on Zulip):

Kirill Bulatov should be able to see it though

Kirill Bulatov (Apr 12 2021 at 16:08, on Zulip):

image.png

Yes, I seem to be a member.

Not that important for me though, so no need to waste time on that just for me.

oliver (Apr 12 2021 at 16:09, on Zulip):

migrate the information off of gh?

Jonas Schievink [he/him] (Apr 12 2021 at 16:09, on Zulip):

if anything it should go into the official team repo

matklad (Apr 12 2021 at 17:10, on Zulip):

Steering issue: https://github.com/rust-analyzer/rust-analyzer/issues/8486

Florian Diebold (Apr 14 2021 at 12:28, on Zulip):

re: broken windows, it might also be a good idea to review completions in various places and make more of an effort that completions don't show up in places where they shouldn't? (e.g. snippets showing up in struct literal completions)

matklad (Apr 14 2021 at 12:58, on Zulip):

Maybe? To my mind, the quality of our completions is so low at the moment, that this is more of "there will be a building here one day", rather than a broken window :)

matklad (Apr 14 2021 at 12:59, on Zulip):

As in, I do think we should focus on this near/mid term, but it doesn't give the "brokenness of something which should just work" vibe.

matklad (Apr 14 2021 at 13:00, on Zulip):

(but, eg, bug about & being inserted in the wrong place in foo.&bar def was a broken window)

Jonas Schievink [he/him] (Apr 14 2021 at 13:02, on Zulip):

hmm, I might be misunderstanding the broken window metaphor. I thought that was mostly about tech debt that, if left unfixed, will result in more tech debt accumulating over time, rather than UX issues?

Laurențiu (Apr 14 2021 at 13:04, on Zulip):

They both can be -- completion is bad -> a regression shows up -> nobody fixes it because completion is bad anyway and maybe they don't even notice it.

Jonas Schievink [he/him] (Apr 14 2021 at 13:04, on Zulip):

aah, yeah I've done that :laughing:

Florian Diebold (Apr 14 2021 at 13:08, on Zulip):

yeah to me "wrong completions are showing up all over the place" feels kind of like a broken window, because it regularly annoys me but I kind of ignore it at this point

Florian Diebold (Apr 14 2021 at 13:08, on Zulip):

similarly with autoimport completions not showing up when I expect them, btw

Florian Diebold (Apr 14 2021 at 13:09, on Zulip):

I kind of disagree that the quality of our completions is so bad, _except_ for those points ;)

matklad (Apr 14 2021 at 13:13, on Zulip):

I see the point... I guess, if you could screen-shot an instance of bad completion and post an issue with "this, specifically, is wrong", then that can be a broken window

Florian Diebold (Apr 14 2021 at 13:20, on Zulip):

point taken ;)

matklad (Apr 14 2021 at 13:33, on Zulip):

Yeah. I'd say, 80% my personal motivation for "broken windows" thing is to disallow me wiggling out of filing bugs :)

Florian Diebold (Apr 14 2021 at 18:55, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/issues/8519 is surely a broken window though, isn't it

Florian Diebold (Apr 14 2021 at 18:56, on Zulip):

I thought that was fixed, by the way

matklad (Apr 14 2021 at 19:11, on Zulip):

Indeed that one is

matklad (May 24 2021 at 15:00, on Zulip):

Hey @WG-rls2.0, we have another steering meeting today!

matklad (May 24 2021 at 15:01, on Zulip):

cc @nikomatsakis, I believe you wanted to sync in as well

matklad (May 24 2021 at 15:01, on Zulip):

Here are results for our previous sprint: https://github.com/rust-analyzer/rust-analyzer/issues/8486#issuecomment-847100224

matklad (May 24 2021 at 15:02, on Zulip):

Seems like we did most of the things we wanted to!

matklad (May 24 2021 at 15:03, on Zulip):

Although (this might, or might not be the recency bias), we also shipped a couple of broken releases recently :(

Jonas Schievink [he/him] (May 24 2021 at 15:03, on Zulip):

we made some progress of duplicated crates: build scripts now have more correct dependencies, and we can display the crate graph for debugging

matklad (May 24 2021 at 15:04, on Zulip):

Ah, that's the backstory behind the crate graph featues, I somehow missed that :D

matklad (May 24 2021 at 15:06, on Zulip):

Let's spend the next 30 minutes or so brainstorming potential priorities for the next sprint

nikomatsakis (May 24 2021 at 15:07, on Zulip):

JFYI: I've been working on refactoring chalk + salsa

nikomatsakis (May 24 2021 at 15:07, on Zulip):

so that we can move the caching of chalk queries into salsa

nikomatsakis (May 24 2021 at 15:07, on Zulip):

and have them fully integrated with the incremental compilation system

nikomatsakis (May 24 2021 at 15:08, on Zulip):

I'm also thinking about next month's CTCFT and wondering whether there are rust-analyzer related agenda items :) I'm mostly thinking of things like "here is a proposal that affects >2 teams and is at a point where someone would like to present about it". This may not be relevant yet.

matklad (May 24 2021 at 15:08, on Zulip):

I believe Florian Diebold on our side did a lot of refactors removing code from rust-analyzer and switching to chalk!

nikomatsakis (May 24 2021 at 15:09, on Zulip):

Cool! the other thing that we've been doing is gearing up more and more for a rustc-ty library, but there's not enough progress to be worth thinking about during this 6 week period

matklad (May 24 2021 at 15:09, on Zulip):

I don't think we have anything that needs cross-team coordination at this point, and that itself is a problem.

matklad (May 24 2021 at 15:09, on Zulip):

@nikomatsakis could you give a quick update on the status of chalk in rustc?

Florian Diebold (May 24 2021 at 15:10, on Zulip):

We could target extracting something like match checking

matklad (May 24 2021 at 15:10, on Zulip):

As in, we are not very succesful with general library-ification, so I am wondering if we should stop worrying about that until chalk is "done"?

nikomatsakis (May 24 2021 at 15:10, on Zulip):

matklad said:

could you give a quick update on the status of chalk in rustc?

sure-- so @Jack Huey has been doing some pretty intense refactors, helping to move the rustc types in closer alignment with chalk, and we have some ongoing work e.g. by @Léo Lanteri Thauvin in a similar direction.

nikomatsakis (May 24 2021 at 15:11, on Zulip):

We've created a shared type library but it has only a few simple things in it

nikomatsakis (May 24 2021 at 15:11, on Zulip):

There is a stalled PR to take the next step and start moving some of the interner logic

nikomatsakis (May 24 2021 at 15:11, on Zulip):

There are a few questions that concern rust-analyzer too

nikomatsakis (May 24 2021 at 15:11, on Zulip):

Notably how to represent generic type parameters and how much context is required to interpret them

nikomatsakis (May 24 2021 at 15:12, on Zulip):

We're still working on firming up the roadmap there; there is a project board

nikomatsakis (May 24 2021 at 15:13, on Zulip):

ah yeah and @csmoe is looking at changing how rustc represents dyn types

nikomatsakis (May 24 2021 at 15:13, on Zulip):

I guess it would be helpful to have a sense for how closely aligned rust-analyzer's types are with chalk's

Jack Huey (May 24 2021 at 15:13, on Zulip):

So much action :hearts:

nikomatsakis (May 24 2021 at 15:13, on Zulip):

we should perhaps add items in there talking about work to help them get aligned as well

Florian Diebold (May 24 2021 at 15:14, on Zulip):

@nikomatsakis we exclusively use chalk types in inference now, we don't have our own Ty anymore

nikomatsakis (May 24 2021 at 15:14, on Zulip):

OK :)

Jack Huey (May 24 2021 at 15:14, on Zulip):

I'm curious: any changes to perf?

nikomatsakis (May 24 2021 at 15:15, on Zulip):

matklad said:

I don't think we have anything that needs cross-team coordination at this point, and that itself is a problem.

can you elaborate on what you meant by "and that itself is a problem", @matklad ?

Florian Diebold (May 24 2021 at 15:15, on Zulip):

We still implement type params in a hacky way though

Jack Huey (May 24 2021 at 15:15, on Zulip):

Florian Diebold said:

We still implement type params in a hacky way though

That seems relevant to the ParamTy vs BoundVar story

Florian Diebold (May 24 2021 at 15:16, on Zulip):

I think perf is hard to say, in total it's better because we also did some optimizations at the same time, some of which were enabled by it

matklad (May 24 2021 at 15:16, on Zulip):

@nikomatsakis the usual, it feels like rust-analyzer is a thing of its own, which doesn't integrate super well technically with the rest of rust-project.

nikomatsakis (May 24 2021 at 15:17, on Zulip):

got it

matklad (May 24 2021 at 15:17, on Zulip):

In particular, we don't have any ongoing stories about extracting more libraries out of compiler

nikomatsakis (May 24 2021 at 15:17, on Zulip):

What kind of focus areas were you thinking for this 6 week period?

nikomatsakis (May 24 2021 at 15:18, on Zulip):

I do feel like it would be reasonable not to worry about that until the type library is available

nikomatsakis (May 24 2021 at 15:18, on Zulip):

at the same time, @Florian Diebold's suggestion of the exhaustiveness checking code could be nice

nikomatsakis (May 24 2021 at 15:18, on Zulip):

I think that is based on thir... we'd have to extract that too

nikomatsakis (May 24 2021 at 15:18, on Zulip):

@Léo Lanteri Thauvin is also actively refactoring that :) (EDIT: thir, that is)

matklad (May 24 2021 at 15:18, on Zulip):

What I have in mind for the next sprint:

matklad (May 24 2021 at 15:19, on Zulip):

the last one might be related to salsa

nikomatsakis (May 24 2021 at 15:19, on Zulip):

oh yes

nikomatsakis (May 24 2021 at 15:19, on Zulip):

I really want to implement that side effects concept (also for rustc)

matklad (May 24 2021 at 15:19, on Zulip):

Basically, we now support more or less all the Rust (well, exccept for const-eval), so we could, in theory, do low FPR diagnostics.

nikomatsakis (May 24 2021 at 15:19, on Zulip):

"FPR"?

matklad (May 24 2021 at 15:20, on Zulip):

false positive rate

Kirill Bulatov (May 24 2021 at 15:20, on Zulip):

more or less all the Rust (well, exccept for const-eval)

Also except attribute proc macros?
https://github.com/rust-analyzer/rust-analyzer/issues/6029

nikomatsakis (May 24 2021 at 15:20, on Zulip):

(Random nit: I once read something suggesting the terminology "false error" or "false warning" instead, and I've found it's so much clearer, since "false positive" doesn't tell you what a "positive" is...)

matklad (May 24 2021 at 15:21, on Zulip):

in practice, our diagnostics infra is overenginered, so we need to clean it up before adding a ton of new error codes

matklad (May 24 2021 at 15:22, on Zulip):

That's interesting architecturally, because errors are emitted in the guts of the compiler, but are rendered by the IDE. So this is related to the general proglem of mapping back out of IR into surface-level syntax.

Florian Diebold (May 24 2021 at 15:22, on Zulip):

I'd like to get to 0 type mismatches on the RA repo

Florian Diebold (May 24 2021 at 15:22, on Zulip):

I'd like to get to 0 type mismatches on the RA repo

Florian Diebold (May 24 2021 at 15:22, on Zulip):

Then we can start emitting type check diagnostics

nikomatsakis (May 24 2021 at 15:22, on Zulip):

Florian Diebold said:

I'd like to get to 0 type mismatches on the RA repo

how far is that?

Jonas Schievink [he/him] (May 24 2021 at 15:23, on Zulip):

my wishlist for the next sprint:

nikomatsakis (May 24 2021 at 15:23, on Zulip):

ooh, I'd be interested to help push those salsa improvements along a bit

matklad (May 24 2021 at 15:24, on Zulip):

Another couple of things I sort of want to focus on (provided I have infinite focus):

nikomatsakis (May 24 2021 at 15:24, on Zulip):

(I'm already doing some parallelization related refactoring)

matklad (May 24 2021 at 15:26, on Zulip):

And yeah, salsa parallelization would be big! I think it should markedly improved rust-analyzer's UX.

nikomatsakis (May 24 2021 at 15:26, on Zulip):

I'm curious @Jonas Schievink [he/him] whether you would have time to hack on salsa par personally-- or have someone in mind

Jonas Schievink [he/him] (May 24 2021 at 15:27, on Zulip):

I might be able to do some work there, yes

nikomatsakis (May 24 2021 at 15:27, on Zulip):

I'm thinking about how much time I can realistically commit

matklad (May 24 2021 at 15:27, on Zulip):

@Kirill Bulatov, @Edwin Cheng , @Laurențiu , @Lukas Wirth, (sorry if I am forgetting someone) -- any wish list items for the next sprint?

nikomatsakis (May 24 2021 at 15:27, on Zulip):

I would definitely like to salsa reinvigorated, particularly if it will help rust-analyzer's UX

nikomatsakis (May 24 2021 at 15:28, on Zulip):

I've been working to carve out 1 or 2 days for coding per week

Jonas Schievink [he/him] (May 24 2021 at 15:28, on Zulip):

another item to maybe look into:

(the server process approach is not very efficient and has poor UX when it crashes)

Edwin Cheng (May 24 2021 at 15:29, on Zulip):

I am still slowing working on ra fmt

Jonas Schievink [he/him] (May 24 2021 at 15:30, on Zulip):

Realistically I probably can't spend that much time on coding, maybe 2-3 days a week? Depending on how much I do in my free time of course :/

Kirill Bulatov (May 24 2021 at 15:30, on Zulip):

I second the completions improvements idea: In my dreams, I'm soon starting with https://github.com/rust-analyzer/rust-analyzer/issues/8518 and then switch over some bullets from https://github.com/rust-analyzer/rust-analyzer/issues/7542 in the near future

I also like the standalone Rust files topic I've barely scratched: plenty of low hanging fruits.
I guess, I can touch the crate tree dependency improvements along the way, since very adjacent.

Laurențiu (May 24 2021 at 15:31, on Zulip):

I haven't been able to do much lately, but maybe I'll try to look through the older issues and see if there's any low hanging fruit. I think we're getting more bug reports than we used to.

Florian Diebold (May 24 2021 at 15:31, on Zulip):

I'd like to get to 0 type mismatches on the RA repo

Lukas Wirth (May 24 2021 at 15:31, on Zulip):

Maybe looking at refactoring completions a bit. As the CompletionContext has a huge number of specific fields currently and the code looks a bit odd in some places imo.

Florian Diebold (May 24 2021 at 15:31, on Zulip):

That requires working attribute macros though

Florian Diebold (May 24 2021 at 15:31, on Zulip):

Then we can start emitting type check diagnostics

Jonas Schievink [he/him] (May 24 2021 at 15:32, on Zulip):

improving completion quality and perf sounds like a good goal

matklad (May 24 2021 at 15:33, on Zulip):

Ok, so let's see what we got here...

matklad (May 24 2021 at 15:33, on Zulip):

/poll

nikomatsakis (May 24 2021 at 15:35, on Zulip):

(is this a preference or some form of volunteering :)

Edwin Cheng (May 24 2021 at 15:36, on Zulip):

A wish list i guess?

matklad (May 24 2021 at 15:36, on Zulip):

Preference -- the goal is to align the vision.

matklad (May 24 2021 at 15:36, on Zulip):

Everyone will end up working on the most nerd-sniping items anyway, but we can try to steer that just a little bit with figuring out priorities :)

nikomatsakis (May 24 2021 at 15:37, on Zulip):

I don't know enough about "tree-based HIR"-- but that sounds useful/imp't too to work out

Florian Diebold (May 24 2021 at 15:39, on Zulip):

I'd like to get to 0 type mismatches on the RA repo

Florian Diebold (May 24 2021 at 15:39, on Zulip):

That requires working attribute macros though

Florian Diebold (May 24 2021 at 15:39, on Zulip):

Then we can start emitting type check diagnostics

matklad (May 24 2021 at 15:39, on Zulip):

Yeah. The crux of the idea is to take the API we have for syntax trees (parent/children), and to "make it work" for sematic info as well.

The core idea is that we can make tree-based API work for macros. For something like format!("hello {}", name), the sem::MacroCall will have two children: .expansion() -> sem::Expr and .argument() -> sem::TokenTree.

Laurențiu (May 24 2021 at 15:40, on Zulip):

(@Florian Diebold are you on a spotty WiFi connection?)

Florian Diebold (May 24 2021 at 15:40, on Zulip):

Sorry :sweat_smile:

matklad (May 24 2021 at 15:40, on Zulip):

@Florian Diebold , is your zulip buggy, or are you just that dedicated to getting zero type saymismatches? I wholeheartedly support your efforts!

Florian Diebold (May 24 2021 at 15:41, on Zulip):

I had just entered a train without wifi

Florian Diebold (May 24 2021 at 15:41, on Zulip):

They have actually managed to fix it now

Florian Diebold (May 24 2021 at 15:41, on Zulip):

It was just my zulip client retrying though, I didn't resend the message

matklad (May 24 2021 at 15:42, on Zulip):

(all the hearts on all of the messages are genuine though!)

nikomatsakis (May 24 2021 at 15:42, on Zulip):

I'm still wondering how far the RA repo is from 0 :)

matklad (May 24 2021 at 15:43, on Zulip):

https://rust-analyzer.github.io/metrics/

nikomatsakis (May 24 2021 at 15:43, on Zulip):

looking at the poll above -- one thing I note is that it is a bit inconsistent on whether it desribes a mechanism or a user experience goal

Kirill Bulatov (May 24 2021 at 15:43, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/issues/8961

says

We've got about 1000 type mismatches remaining when running rust-analyzer analysis-stats . on the rust-analyzer repo

matklad (May 24 2021 at 15:43, on Zulip):

there are 1075 errors

nikomatsakis (May 24 2021 at 15:43, on Zulip):

salsa parallelization is clearly a mechanism, but I guess the UX goal is snappier

Laurențiu (May 24 2021 at 15:43, on Zulip):

(Oof, I should fix those diesel charts. Although they maybe don't look to bad)

nikomatsakis (May 24 2021 at 15:44, on Zulip):

I do think that, speaking as a user, completions don't really seem to work reliably enough

nikomatsakis (May 24 2021 at 15:44, on Zulip):

that is, sometimes they work, but I'm always a bit surprised, and I don't rely on them, and sometimes there's just a lot of stuff in there

Florian Diebold (May 24 2021 at 15:44, on Zulip):

@nikomatsakis we're at about 1000 errors, 700 of which come from salsa macros not working

matklad (May 24 2021 at 15:44, on Zulip):

There's a bigger tension even, between immediate UX and long-term maintanence.

nikomatsakis (May 24 2021 at 15:44, on Zulip):

Yes

Laurențiu (May 24 2021 at 15:44, on Zulip):

nikomatsakis said:

I do think that, speaking as a user, completions don't really seem to work reliably enough

That's usually either attribute proc macros or chalk

matklad (May 24 2021 at 15:45, on Zulip):

To me, salsa parallelization is more about getting the architecture right, than about UX benefits.

nikomatsakis (May 24 2021 at 15:45, on Zulip):

That makes sense to me

Edwin Cheng (May 24 2021 at 15:45, on Zulip):

IIRC, we are not enable proc-macro in perf yet

nikomatsakis (May 24 2021 at 15:45, on Zulip):

I think the goal of focusing on underlying architecture still feels right for where rust-analyer is in its lifecycle

Laurențiu (May 24 2021 at 15:45, on Zulip):

Edwin Cheng said:

IIRC, we are not enable proc-macro in pref yet

I think we do

Kirill Bulatov (May 24 2021 at 15:45, on Zulip):

Laurențiu said:

nikomatsakis said:

I do think that, speaking as a user, completions don't really seem to work reliably enough

That's usually either attribute proc macros or chalk

Or them being terribly slow, forcing the VSCode to fallback towards its own completion mechanisms.

matklad (May 24 2021 at 15:45, on Zulip):

but completions are indeed 100% UX. Well, except for that part where we need to do speculative things, which needs some first-class support in salsa

matklad (May 24 2021 at 15:46, on Zulip):

BTW, speaking of type-errors. Why are we not resolving salsa methods? Is it attribute proc macros, or dyn Trait support?

nikomatsakis (May 24 2021 at 15:47, on Zulip):

matklad said:

...except for that part where we need to do speculative things, which needs some first-class support in salsa

this is super useful to talk about too (not at this moment...)

Florian Diebold (May 24 2021 at 15:47, on Zulip):

Pretty sure we mostly are?

Florian Diebold (May 24 2021 at 15:47, on Zulip):

Just not stuff like interning methods because they're generated by the macros

Jonas Schievink [he/him] (May 24 2021 at 15:47, on Zulip):

salsa methods mostly work, just not on RootDatabase because of missing attribute macro support

Florian Diebold (May 24 2021 at 15:48, on Zulip):

Ah yeah

Jonas Schievink [he/him] (May 24 2021 at 15:48, on Zulip):

and yeah the interning lookup methods

matklad (May 24 2021 at 15:49, on Zulip):

@nikomatsakis could you expand on "a lot of stuff in there"?

matklad (May 24 2021 at 15:49, on Zulip):

is it that there are a lot of wrong suggestions, or is it some missing prioritization?

nikomatsakis (May 24 2021 at 15:49, on Zulip):

I'm not sure

nikomatsakis (May 24 2021 at 15:49, on Zulip):

I think it's more about just having generic suggestions

nikomatsakis (May 24 2021 at 15:50, on Zulip):

I'll try to pay more careful attention

nikomatsakis (May 24 2021 at 15:50, on Zulip):

well, ok, prioritization is part of it

nikomatsakis (May 24 2021 at 15:50, on Zulip):

e.g. I was just experimenting with . on a Vec<T>...

nikomatsakis (May 24 2021 at 15:50, on Zulip):

image.png

nikomatsakis (May 24 2021 at 15:50, on Zulip):

lots of random stuff in there :)

nikomatsakis (May 24 2021 at 15:51, on Zulip):

certainly those are applicable methods

nikomatsakis (May 24 2021 at 15:51, on Zulip):

just very few of them are methods I've ever called

Laurențiu (May 24 2021 at 15:51, on Zulip):

We totally need some AI-powered completion ordering (AKA sorting by frequency)

Florian Diebold (May 24 2021 at 15:51, on Zulip):

I think the tree-based hir would be nice for implementing diagnostics on

matklad (May 24 2021 at 15:53, on Zulip):

Hm, yeah.... I certainly feels like we should have some way to not show correct, but low probability suggestions...

Florian Diebold (May 24 2021 at 15:53, on Zulip):

I wonder how hard it would be to do some simple frequency ordering :thinking:

matklad (May 24 2021 at 15:53, on Zulip):

I guess the first step is to look into what IntelliJ is doing. I've never got to this part of completion engine myself....

Kirill Bulatov (May 24 2021 at 15:54, on Zulip):

IntelliJ is doing

Afaik, the latest thing for them is an actual ML(?) on datasets from EAP users.

Kirill Bulatov (May 24 2021 at 15:55, on Zulip):

https://github.com/intellij-rust/intellij-rust/issues/6411

matklad (May 24 2021 at 15:56, on Zulip):

Ok, so we have 5 minutes left, lets see what we have

matklad (May 24 2021 at 15:56, on Zulip):

These are the winners:

matklad (May 24 2021 at 15:57, on Zulip):

Clearly, we have a bias towards UX rather than architectural work

Florian Diebold (May 24 2021 at 15:57, on Zulip):

Well, I did advertise the mismatches a lot :sweat_smile:

matklad (May 24 2021 at 15:58, on Zulip):

And I'd love to through:

into the mix as well -- I think it'll massively importatn for both arch and UX actually

nikomatsakis (May 24 2021 at 15:58, on Zulip):

Yes, let's do that

nikomatsakis (May 24 2021 at 15:59, on Zulip):

We have a basic model, i'd love to prove it out and decide if it is working or what

nikomatsakis (May 24 2021 at 15:59, on Zulip):

Plus it fits with our opinionated cancellation model

nikomatsakis (May 24 2021 at 15:59, on Zulip):

I think I've overcome my resistsance to salsa managing threads

nikomatsakis (May 24 2021 at 15:59, on Zulip):

(this is also related to speculation, I suppose)

matklad (May 24 2021 at 16:05, on Zulip):

(sorry, got distracted before actually completing the meeting)

Ok, I think we have a plan for the next sprint, see you'all in a six weeks!

(and, @Edwin Cheng , I am intrigued by your formatter work -- this is also one of the core bits of tech that can unlock many intreseting cases. I wonder if we need to sync about that?)

Edwin Cheng (May 24 2021 at 16:11, on Zulip):

Sure, basically I am trying to mimics nix-fmt with intellj rust code rules

Edwin Cheng (May 24 2021 at 16:12, on Zulip):

But I am thinking it is possible do it as a general roman based formatter

Edwin Cheng (May 24 2021 at 16:13, on Zulip):

Seem like there are a lot of code which can be shared

matklad (May 24 2021 at 16:30, on Zulip):

Ow, I actually havent' thought of a formatting engine which is based directly on rowan and doesn't depend on rust-analyzer bits. That potentailly can be very cool!

matklad (May 24 2021 at 16:41, on Zulip):

Steering issue: https://github.com/rust-analyzer/rust-analyzer/issues/8972

matklad (Jul 05 2021 at 09:22, on Zulip):

Hey, we have a steering meeting today, but it unfortunately clashes with another meeting I have, and I am just back from vacation.

Let's maybe move the steering meeting to the Monday next week?

matklad (Jul 12 2021 at 15:00, on Zulip):

Hello @WG-rls2.0 and warm welcome to the today's steering meeting!

matklad (Jul 12 2021 at 15:01, on Zulip):

The current steering issue is: https://github.com/rust-analyzer/rust-analyzer/issues/8972

matklad (Jul 12 2021 at 15:02, on Zulip):

I suggest structuring the meeting roughly as follows:

matklad (Jul 12 2021 at 15:03, on Zulip):

Note that the absence of :check: on the steering issue is a bit misleading -- the subissues themselves have a whole lot of checkboxes, and most of them are actually checked!

matklad (Jul 12 2021 at 15:05, on Zulip):

My personal observation that this sprint was a lot about "filling-in the gaps", and that I think is a very good long-term strategy. I especially like that we improved our test suite (minicore, completion relevance tests, new typechecking tests)

matklad (Jul 12 2021 at 15:07, on Zulip):

At the same time, we sadly accumulated a bit too many of the broken windows at the moment: https://github.com/rust-analyzer/rust-analyzer/issues?q=is%3Aopen+is%3Aissue+label%3A%22Broken+Window%22 :(

matklad (Jul 12 2021 at 15:09, on Zulip):

Finally, I think the "hir 2.0" discussion was and is hightly important: https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Tree.20Based.20HIR/near/243560600

I still don't know where it goes, but I like the progress so far. I personally now have a much better understanding of the macro related issues

matklad (Jul 12 2021 at 15:09, on Zulip):

Any other summarising and reflecting thoughts?

Laurențiu (Jul 12 2021 at 15:09, on Zulip):

matklad said:

At the same time, we sadly accumulated a bit too many of the broken windows at the moment: https://github.com/rust-analyzer/rust-analyzer/issues?q=is%3Aopen+is%3Aissue+label%3A%22Broken+Window%22 :(

Just added one more :(

Laurențiu (Jul 12 2021 at 15:10, on Zulip):

I'm hyped up for the type checking and proc macro work.

Jonas Schievink [he/him] (Jul 12 2021 at 15:10, on Zulip):

(not able to attend this one, sorry)

matklad (Jul 12 2021 at 15:11, on Zulip):

No problems @Jonas Schievink [he/him] !

Lukas Wirth (Jul 12 2021 at 15:11, on Zulip):

same here unfortunately :sweat_smile:

matklad (Jul 12 2021 at 15:11, on Zulip):

Oh, one more thing from me -- no progress on "rust-anlyzer is a part of rust-lang/rust organizaion" , guess I'll do another round of pings

Florian Diebold (Jul 12 2021 at 15:11, on Zulip):

regarding type checking, we got to 175 type mismatches, 150 of which come from two issues: https://github.com/rust-analyzer/rust-analyzer/issues/9560 and https://github.com/rust-analyzer/rust-analyzer/issues/8984

Florian Diebold (Jul 12 2021 at 15:12, on Zulip):

the remaining 25 I haven't looked into in detail yet

matklad (Jul 12 2021 at 15:13, on Zulip):

Also, I've been thinking about overlall progress recently, and I want to give shoutouts to @Kirill Bulatov (and a steering meeting ping, while we are at it) for identifing the most improtant issues to work on. IIRC, the recently added single-file mode was warmly welcomed by the users :)

Florian Diebold (Jul 12 2021 at 15:14, on Zulip):

I'm also excited that we're recording coercion adjustments now, I think that'll come in useful for quite a few things

matklad (Jul 12 2021 at 15:15, on Zulip):

Uhu, I feel when & how coercions happen (or don't happen) is an important learnability aspect, woulr be cool to expose that better, in hover & such.

matklad (Jul 12 2021 at 15:15, on Zulip):

I guess, it's time for us to brainstorm the next 6 weeks?

matklad (Jul 12 2021 at 15:17, on Zulip):

Looking at the steering issue again, it seems that we accumulated a bunch of "almost done" things, so perhaps its time for another round of finishing the work up?

I personally would want to look into completion some more -- I know that @Lukas Wirth have been doing some pretty great refactors and improvemnts in that area!

Florian Diebold (Jul 12 2021 at 15:17, on Zulip):

yeah

matklad (Jul 12 2021 at 15:17, on Zulip):

I def do want to mend all of the broken windows though!

matklad (Jul 12 2021 at 15:17, on Zulip):

(also, to be fair, the O(N^2) findings fixes in hightlighting were epic this sprint)

matklad (Jul 12 2021 at 15:20, on Zulip):

I think what I also would want to look into is include! handling. Namely, making goto definition land into the actual file

Florian Diebold (Jul 12 2021 at 15:21, on Zulip):

that could be related to refactoring our span handling / token mapping more generally, right?

matklad (Jul 12 2021 at 15:21, on Zulip):

That's important in itself, and seems to be a good testing ground for the new approach to macro expansion location tracking, once we have it.

matklad (Jul 12 2021 at 15:22, on Zulip):

Oh wow. One thing I was thinking about is "could proc macro set a span to some random unrelated file, which is not part of the original input".

I guess, that's exactly what include! does, oh dear...z

matklad (Jul 12 2021 at 15:24, on Zulip):

And one more thing I was thinking about recently -- I've recored a video guide to rust-analyzer couple of years ago, I wonder if it makes sense to repeat that.

matklad (Jul 12 2021 at 15:25, on Zulip):

Specicically, I was thinking abou maybe recording short, 30-min long fragments about various areas of rust-analyzer, such that they are digestable in one go, and can be easily re-recorded when a specific area is refactored

matklad (Jul 12 2021 at 15:26, on Zulip):

oh noes, so many checkmarks, guess I gotta do it now :crying_cat:

matklad (Jul 12 2021 at 15:30, on Zulip):

Anyone else have ideas about what we might want to do for the next 6 weeks? I wonder if we should ask @Kirill Bulatov to just tell us what to work on? :)

Florian Diebold (Jul 12 2021 at 15:31, on Zulip):

depending on how far we get with the false positive type mismatches, I'm planning to add a proper diagnostic for them

Florian Diebold (Jul 12 2021 at 15:32, on Zulip):

resp. unify the existing ad-hoc ones ("wrap return expression in Ok", "remove semicolon" and "add reference") into one

matklad (Jul 12 2021 at 15:33, on Zulip):

hiiiight, i completely forgot that we did overhaul diagnostic infra as welll

matklad (Jul 12 2021 at 15:36, on Zulip):

Ok, so let's move to prunnig then! This seems to be a quite meeting, so not much to be done here

matklad (Jul 12 2021 at 15:38, on Zulip):

Seems like completion and type-missmatches issues are carried over, and we add two items:

Florian Diebold (Jul 12 2021 at 15:38, on Zulip):

seems good

matklad (Jul 12 2021 at 15:39, on Zulip):

I wonder if we should put hir2.0 there as well? I think I'd rather not -- seems something we should think about in the background, rather that something we should actively pursue

Florian Diebold (Jul 12 2021 at 15:41, on Zulip):

it might also be a bit much

matklad (Jul 12 2021 at 15:49, on Zulip):

New steering issues: https://github.com/rust-analyzer/rust-analyzer/issues/9580

matklad (Jul 12 2021 at 15:50, on Zulip):

I suggest not moving the time of the next steering meeting. that is, this sprint will be one week shorter. Sorry for moving this one in the first place!

Kirill Bulatov (Jul 12 2021 at 16:09, on Zulip):

Sorry, got out of the loop today too, but thanks for pointing out the development directions.
I will share some late thoughts in this message, for clarity.

I have the list of new features I imagine cool to have, but recently I've got influenced by the talks about getting "more mature" on the features that we have alreadys, so I try not to propose anything but rather fix bugs and do completion perf. improvements (or rather I imagine myself trying in the recent weeks).

I'd personally love to work further on standalone files-snippets with dynamic crate trees, but it feels better to make completions faster at this moment in time.

matklad (Jul 12 2021 at 18:33, on Zulip):

Publish a couple of test videos to https://www.youtube.com/playlist?list=PLhb66M_x9UmrqXhQuIpWC5VgTdrGxMx3y

Laurențiu (Jul 13 2021 at 16:45, on Zulip):

There's a fair bit of noise in there :-(. Oh, somebody already complained :grinning:.

Jonas Schievink [he/him] (Jul 13 2021 at 17:00, on Zulip):

OBS has a fairly good noise suppressor you can enable

Laurențiu (Jul 13 2021 at 17:02, on Zulip):

Oh dear. I was using noise cancelling filter, but I added it to my audio output (speakers) rather than to audio input (mic).

Solid UX there

Jonas Schievink [he/him] (Jul 13 2021 at 17:29, on Zulip):

heh, not sure why you'd want to do that but the flexibility is kinda neat I guess?

Laurențiu (Jul 13 2021 at 17:30, on Zulip):

Yeah, it got me down the rabbit hole where I installed NoiseTorch and I'm actually watching that video with the noise reduction enabled for the output

Jonas Schievink [he/him] (Jul 13 2021 at 17:31, on Zulip):

ah that looks neat, I've played with RNNoise before

Jonas Schievink [he/him] (Jul 13 2021 at 17:31, on Zulip):

so that might be easier to use

Laurențiu (Jul 13 2021 at 17:32, on Zulip):

It seems to work a bit better with PipeWire than pulseeffects

Last update: Jul 27 2021 at 20:45UTC