Stream: t-compiler/wg-rls-2.0

Topic: chalk integration


Florian Diebold (Mar 05 2019 at 21:18, on Zulip):

This is kind of a minor point in the grand scheme of things, but chalk is currently nightly-only, while rust-analyzer builds on stable. Some of that is probably easy to fix and I'd be happy to do it (it would be an opportunity to get a bit more familiar with the chalk codebase), but chalk also seems to use specialization, which I assume won't be so easy to get around? @nikomatsakis

scalexm (Mar 05 2019 at 21:23, on Zulip):

@Florian Diebold mmh I don't think chalk is actually doing something useful with specialization

scalexm (Mar 05 2019 at 21:23, on Zulip):

(I didn't even know we had the feature flag activated)

Florian Diebold (Mar 05 2019 at 21:35, on Zulip):

Ah yeah, apparently it's only used for a Debug implementation

nikomatsakis (Mar 05 2019 at 22:27, on Zulip):

Moving to stable seems fine to me

Florian Diebold (Mar 06 2019 at 19:54, on Zulip):

I'll make a PR soon then, hopefully ;)

Meanwhile... I currently only have the vaguest idea how integrating chalk would actually look -- i.e. what data would rust-analyzer have to provide, and what forms of queries would it make. I've read the material in the rustc guide, but if I understand you correctly, e.g. the lowering logic would come from chalk. Is the rust_ir module in chalk basically the input for the lowering? And on the query side, would canonicalization happen in chalk?

This might be material for another meeting, but maybe you can give me some pointers already ;)

(btw, I wonder if we could integrate the chalk repl into RA, once the lowering works, so one could make trait queries about the whole program...)

detrumi (Mar 06 2019 at 20:04, on Zulip):

Integrating with the chalk repl would be really cool, especially if it could answer queries about the current context

scalexm (Mar 09 2019 at 20:11, on Zulip):

@Florian Diebold Ideally, yes the lowering logic etc would come from chalk. I believe the best thing would be to have the rust_ir module somehow shared between chalk and RLS 2.0 (as an independent crate), so that RLS 2.0 just has to feed chalk with all the Rust constructs in the crate being analyzed

scalexm (Mar 09 2019 at 20:12, on Zulip):

integration with the chalk repl is a good idea, and would be straightforward if we managed to share that rust_ir thing

matklad (Mar 09 2019 at 20:12, on Zulip):

I think just using a git dependency in Cargo.toml should work for sharing?

scalexm (Mar 09 2019 at 20:13, on Zulip):

@matklad yes it would work, but I was thinking more about refactoring and enhancing that module so that it is indeed easily shareable and covers most needs

nikomatsakis (Mar 11 2019 at 20:26, on Zulip):

So in the @WG-traits meeting today we discussed the idea of having a session to kind of brainstorm this out

nikomatsakis (Mar 11 2019 at 20:27, on Zulip):

we could do this tomorrow at at 15:00 UTC-04:00 (Boston time), if that works for everyone

nikomatsakis (Mar 11 2019 at 20:28, on Zulip):

I'd probably block out two hours just to give us more time to think things over ...

nikomatsakis (Mar 11 2019 at 20:28, on Zulip):

well, maybe I'll schedule that onto my calendar regardless -- not sure if it needs to be a compile-team calendar event, but I guess there's no harm

nikomatsakis (Mar 11 2019 at 20:30, on Zulip):

(I added it to my personal calendar, anyway)

scalexm (Mar 11 2019 at 20:35, on Zulip):

15:00 tomorrow Boston time works for me

Florian Diebold (Mar 11 2019 at 22:13, on Zulip):

Works for me!

matklad (Mar 12 2019 at 07:32, on Zulip):

works for me as well. Let's make a calendar event? It's easy to forget or misconvert the timezones :)

detrumi (Mar 12 2019 at 18:39, on Zulip):

I don't see it on the calendar, but that should be in 20 minutes

matklad (Mar 12 2019 at 19:04, on Zulip):

@nikomatsakis ping, is there a meeting?

nikomatsakis (Mar 12 2019 at 19:05, on Zulip):

Yeah, give me a few. Sorry, I didn't make it a "global calendar event"

nikomatsakis (Mar 12 2019 at 19:05, on Zulip):

I need ~5 minut :)

matklad (Mar 12 2019 at 19:06, on Zulip):

pinging @Florian Diebold & @scalexm in advance

nikomatsakis (Mar 12 2019 at 19:15, on Zulip):

OK, I'm back

nikomatsakis (Mar 12 2019 at 19:15, on Zulip):

I didn't really have a super concrete plan here

nikomatsakis (Mar 12 2019 at 19:15, on Zulip):

which is partly why I didn't schedule a firm meeting

nikomatsakis (Mar 12 2019 at 19:15, on Zulip):

sorry, today has of course been messier than anticipated

nikomatsakis (Mar 12 2019 at 19:16, on Zulip):

so my mind is a bit scattered

nikomatsakis (Mar 12 2019 at 19:16, on Zulip):

I guess I can imagine a few ways forward:

nikomatsakis (Mar 12 2019 at 19:16, on Zulip):
nikomatsakis (Mar 12 2019 at 19:16, on Zulip):
nikomatsakis (Mar 12 2019 at 19:16, on Zulip):

I'm sort of leaning towards the latter -- i.e., maybe we could sketch out first what we think a Chalk integration would look like

scalexm (Mar 12 2019 at 19:17, on Zulip):

I'm fine with option 2

nikomatsakis (Mar 12 2019 at 19:17, on Zulip):

then we can kind of try to map that to RLS?

nikomatsakis (Mar 12 2019 at 19:17, on Zulip):

Here is a dropbox paper document

nikomatsakis (Mar 12 2019 at 19:19, on Zulip):

whops

nikomatsakis (Mar 12 2019 at 19:19, on Zulip):

sorry, that wasn't meant to be posted here :)

detrumi (Mar 12 2019 at 19:20, on Zulip):

So this integration, is it changing Chalk to be usable for RLS, changing the RLS so it can use Chalk, or both?

nikomatsakis (Mar 12 2019 at 19:21, on Zulip):

I expect it'll be some of both

nikomatsakis (Mar 12 2019 at 19:21, on Zulip):

I was just thinking about where to start..

nikomatsakis (Mar 12 2019 at 19:21, on Zulip):

...I guess we know that (a) we want to share the lowering code

nikomatsakis (Mar 12 2019 at 19:22, on Zulip):

so maybe we can elaborate a bit what it needs

nikomatsakis (Mar 12 2019 at 19:22, on Zulip):

this is code which basically takes the set of traits + impls and produces a set of rules

matklad (Mar 12 2019 at 19:22, on Zulip):

Presumably, this needs to speak about types as well?

nikomatsakis (Mar 12 2019 at 19:25, on Zulip):

Yes

nikomatsakis (Mar 12 2019 at 19:26, on Zulip):

so one other thing is that

nikomatsakis (Mar 12 2019 at 19:26, on Zulip):

we have to be able to do the lowering "piecemeal"

nikomatsakis (Mar 12 2019 at 19:26, on Zulip):

i.e., we have to be able to lower the impls for one specific trait

nikomatsakis (Mar 12 2019 at 19:27, on Zulip):

so I guess that means we have something like this:

nikomatsakis (Mar 12 2019 at 19:27, on Zulip):

I'm debating how chalk lowering should integrate here. One option is

nikomatsakis (Mar 12 2019 at 19:28, on Zulip):

it can export some salsa queries

nikomatsakis (Mar 12 2019 at 19:28, on Zulip):

but it needs a way to "call out" into the context

nikomatsakis (Mar 12 2019 at 19:28, on Zulip):

we were planning on porting chalk to use salsa more deeply internally anyway

nikomatsakis (Mar 12 2019 at 19:28, on Zulip):

this is an interesting design question :)

nikomatsakis (Mar 12 2019 at 19:29, on Zulip):

i.e., I could imagine that we have a chalk library that exports some salsa queries, one of which is for a "context object" that we can use to query the AST

nikomatsakis (Mar 12 2019 at 19:29, on Zulip):

then the RLS can implement this one

nikomatsakis (Mar 12 2019 at 19:29, on Zulip):

and so can some unit tester

nikomatsakis (Mar 12 2019 at 19:29, on Zulip):

(I wonder if we'll hit some obstacle trying do that)

matklad (Mar 12 2019 at 19:29, on Zulip):

context won't be a real query, right?

nikomatsakis (Mar 12 2019 at 19:29, on Zulip):

well it's more like a "constant"

matklad (Mar 12 2019 at 19:29, on Zulip):

Just an DB: AsRef<Context> or smth like that?

nikomatsakis (Mar 12 2019 at 19:30, on Zulip):

ah well I guess that's the trick we can use duh

nikomatsakis (Mar 12 2019 at 19:30, on Zulip):

that is, we can just add a trait of our own

nikomatsakis (Mar 12 2019 at 19:30, on Zulip):

something like this

trait ChalkCallbacks {
    fn ast_of_an_impl(&self) -> Ast;
}

#[salsa::query_database]
trait ChalkDatabase: ChalkCallbacks {
}
nikomatsakis (Mar 12 2019 at 19:30, on Zulip):

then RLS 2.0 can just implement those callbacks in terms of whatever queries it wants

matklad (Mar 12 2019 at 19:31, on Zulip):

SGMT

nikomatsakis (Mar 12 2019 at 19:32, on Zulip):

OK, that's good

nikomatsakis (Mar 12 2019 at 19:32, on Zulip):

so let's look a bit more closely at what the IR looks like I guess?

matklad (Mar 12 2019 at 19:33, on Zulip):

yeah, that is interesting

Florian Diebold (Mar 12 2019 at 19:33, on Zulip):

that would probably be pretty similar to what's currently in chalk's rust_ir, I guess?

nikomatsakis (Mar 12 2019 at 19:33, on Zulip):

yep I was just opening up that github repository

matklad (Mar 12 2019 at 19:33, on Zulip):

you mean chalk_ir?

Florian Diebold (Mar 12 2019 at 19:34, on Zulip):

@matklad no, https://github.com/rust-lang-nursery/chalk/blob/master/src/rust_ir.rs

nikomatsakis (Mar 12 2019 at 19:34, on Zulip):

so actually chalk lowering currently works in 2 phases

nikomatsakis (Mar 12 2019 at 19:34, on Zulip):

first, we have this parser

nikomatsakis (Mar 12 2019 at 19:34, on Zulip):

it produces an AST

nikomatsakis (Mar 12 2019 at 19:35, on Zulip):

we process this somewhat to produce something analogous to the HIR, that is (part of) what lives in chalk-ir

nikomatsakis (Mar 12 2019 at 19:35, on Zulip):

er, yes, maybe that's rust_ir, sorry

nikomatsakis (Mar 12 2019 at 19:35, on Zulip):

anyway I think we definitely don't want this AST

Florian Diebold (Mar 12 2019 at 19:35, on Zulip):

yeah

nikomatsakis (Mar 12 2019 at 19:36, on Zulip):

we probably want to refactor rust-ir to be more a set of queries

nikomatsakis (Mar 12 2019 at 19:36, on Zulip):

than a big data structure

Florian Diebold (Mar 12 2019 at 19:36, on Zulip):

yes

Florian Diebold (Mar 12 2019 at 19:36, on Zulip):

the stuff in rust-ir actually seems to me like it would be mostly pretty straightforward to provide from rust-analyzer

Florian Diebold (Mar 12 2019 at 19:37, on Zulip):

(there's a few details I'm not so sure about)

nikomatsakis (Mar 12 2019 at 19:38, on Zulip):

the stuff in rust-ir actually seems to me like it would be mostly pretty straightforward to provide from rust-analyzer

yeah I think overall should not be so hard

nikomatsakis (Mar 12 2019 at 19:39, on Zulip):

question: which of these things exist already?

nikomatsakis (Mar 12 2019 at 19:39, on Zulip):

i.e., is there a concept of (say) a TraitRef and so on?

Florian Diebold (Mar 12 2019 at 19:39, on Zulip):

although I have one general question... chalk is pretty focused on the perspective of one crate, right? I'm not sure how much difference it will really make, but whether an impl is local or external depends on what's the 'current' crate

nikomatsakis (Mar 12 2019 at 19:39, on Zulip):

I guess in the parser probably

nikomatsakis (Mar 12 2019 at 19:39, on Zulip):

although I have one general question... chalk is pretty focused on the perspective of one crate, right? I'm not sure how much difference it will really make, but whether an impl is local or external depends on what's the 'current' crate

well, this is presently true, but I think we could change that

nikomatsakis (Mar 12 2019 at 19:39, on Zulip):

almost nothing cares about that but coherence

Florian Diebold (Mar 12 2019 at 19:39, on Zulip):

yeah, there's not much of a HIR for traits and bounds so far in RA

nikomatsakis (Mar 12 2019 at 19:40, on Zulip):

I imagine what we will want is to have a "crate id" associated with things

nikomatsakis (Mar 12 2019 at 19:40, on Zulip):

and to define the coherence goals as relative to a crate

Florian Diebold (Mar 12 2019 at 19:40, on Zulip):

that seems good

nikomatsakis (Mar 12 2019 at 19:41, on Zulip):

so that when we ask "is X local" we can instead ask "same crate or not", I guess

nikomatsakis (Mar 12 2019 at 19:41, on Zulip):

definitely a good question, something to investigate

nikomatsakis (Mar 12 2019 at 19:41, on Zulip):

I'm going to rework this paper document to try and extract some of this :)

matklad (Mar 12 2019 at 19:44, on Zulip):

As I see, chalk's ir is heavily id-based (like, TraitRef is id)

nikomatsakis (Mar 12 2019 at 19:44, on Zulip):

yes

matklad (Mar 12 2019 at 19:44, on Zulip):

presumably, ids are currently assigned by chanlks parser

nikomatsakis (Mar 12 2019 at 19:44, on Zulip):

actually I don't think so

matklad (Mar 12 2019 at 19:44, on Zulip):

how this should work with RLS2, where we have our own ids?

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

I think they are assigned by the intermediate "lowering" step that creates rust-ir

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

well, I think RLS will be producing the rust-ir level information

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

directly

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

so it will just create its own ids

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

one question would be whether we should be generic over the id type

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

or whether we should try to extract the id into some shared crate

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

along with (say) the representation of types

nikomatsakis (Mar 12 2019 at 19:45, on Zulip):

that both RLS + chalk can depend upon

Florian Diebold (Mar 12 2019 at 19:46, on Zulip):

if the IDs are just numbers on both sides, we could also just convert between the types, right

matklad (Mar 12 2019 at 19:46, on Zulip):

chalk uses a single ItemId for different, right?

matklad (Mar 12 2019 at 19:46, on Zulip):

RLS2 uses different ids for different types

matklad (Mar 12 2019 at 19:47, on Zulip):

hm, otoh chalk uses usize for id, and we use u32, so we can use 32 bits for type tag :)

nikomatsakis (Mar 12 2019 at 19:48, on Zulip):

if the IDs are just numbers on both sides, we could also just convert between the types, right

yes, that's an option too, just annoying

nikomatsakis (Mar 12 2019 at 19:48, on Zulip):

ok let's leave this as an "open question" for now, but we can certainly interconvert

nikomatsakis (Mar 12 2019 at 19:48, on Zulip):

RLS2 uses different ids for different types

we could probably adopt this too

Florian Diebold (Mar 12 2019 at 19:48, on Zulip):

I would expect that there'd be some converting between datastructures anyway, since chalk cares about different things

nikomatsakis (Mar 12 2019 at 19:48, on Zulip):

I don't think chalk has that many ids

nikomatsakis (Mar 12 2019 at 19:49, on Zulip):

yes, I agree there will be some, just not 100% sure which ones

nikomatsakis (Mar 12 2019 at 19:49, on Zulip):

I feel like it may be good to share notions where we can

Florian Diebold (Mar 12 2019 at 19:49, on Zulip):

relatedly -- rust_ir has something called "structs", but in the real world, that would be structs/enums/unions, right?

matklad (Mar 12 2019 at 19:49, on Zulip):

yeah, interconverting seems easiest to start with: a bit more code to write, a bit less mutual dependency

nikomatsakis (Mar 12 2019 at 19:49, on Zulip):

relatedly -- rust_ir has something called "structs", but in the real world, that would be structs/enums/unions, right?

yeah, it's just "nominal types"

nikomatsakis (Mar 12 2019 at 19:49, on Zulip):

I feel like it may be good to share notions where we can

so to elaborate a bit, I am specifically think about types, and the reason is that chalk has to do things like unifying types and so forth. And types embed IDs.

detrumi (Mar 12 2019 at 19:49, on Zulip):

if you start with converting, there's the danger that it'll get harder to share later

matklad (Mar 12 2019 at 19:50, on Zulip):

I feel like it may be good to share notions where we can

I actually not 100% sold on this one. If we are in separate repos, sharing "volatile" things could be a pain

nikomatsakis (Mar 12 2019 at 19:50, on Zulip):

I guess we can say this:

nikomatsakis (Mar 12 2019 at 19:51, on Zulip):
nikomatsakis (Mar 12 2019 at 19:51, on Zulip):

i.e., I'd prefer if we are not interconverting enums to flat integers at least

nikomatsakis (Mar 12 2019 at 19:51, on Zulip):

and anyway it might make chalk cleaner

nikomatsakis (Mar 12 2019 at 19:51, on Zulip):

I actually not 100% sold on this one. If we are in separate repos, sharing "volatile" things could be a pain

I agree. I just don't think that the notion of an id is volatile, but I agree it is not clear cut

nikomatsakis (Mar 12 2019 at 19:53, on Zulip):

so to elaborate a bit, I am specifically think about types, and the reason is that chalk has to do things like unifying types and so forth. And types embed IDs.

and yeah, this :point_up: I guess some of this comes back to whether we expect to share types etc. I think that, eventually, we really want the type checker and trait solver to be sharing the definition of types. And I think those types must embed IDs. But it's possible that all of this should be "external" to RLS and hence it's ok to interconvert IDs at the boundary.

Seems like we can figure it out a bit as we go.

nikomatsakis (Mar 12 2019 at 19:53, on Zulip):

To start we won't be sharing anyway

matklad (Mar 12 2019 at 19:54, on Zulip):

How "Ty" type is called in chalk?

matklad (Mar 12 2019 at 19:54, on Zulip):

I want to glance at what we want to share

nikomatsakis (Mar 12 2019 at 19:54, on Zulip):

this is probably the type you mean

nikomatsakis (Mar 12 2019 at 19:55, on Zulip):

that is sort of the equivalent of rustc's Ty<'tcx>

nikomatsakis (Mar 12 2019 at 19:55, on Zulip):

(I also don't think it's perfect :)

matklad (Mar 12 2019 at 19:59, on Zulip):

Sharing exactly same type representations seems good to me

nikomatsakis (Mar 12 2019 at 19:59, on Zulip):

I was just reading over the rust-ir definition

nikomatsakis (Mar 12 2019 at 19:59, on Zulip):

I guess that, right now, it also uses that same version of Ty to e.g. represent the types in an impl header

nikomatsakis (Mar 12 2019 at 19:59, on Zulip):

(I was trying to remember if we had another variant somewhere)

nikomatsakis (Mar 12 2019 at 20:00, on Zulip):

@matklad or @Florian Diebold -- where in rust-analyzer is the representation of an impl?

nikomatsakis (Mar 12 2019 at 20:00, on Zulip):

(ps, I'm feeling pretty good about this, it seems like we're starting to have a concrete-ish set of action items)

Florian Diebold (Mar 12 2019 at 20:00, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/ra_hir/src/impl_block.rs#L118

Florian Diebold (Mar 12 2019 at 20:01, on Zulip):

(that's unresolved, as all the 'HIR' structures in RA)

nikomatsakis (Mar 12 2019 at 20:03, on Zulip):

where is TypeRef to be found?

Florian Diebold (Mar 12 2019 at 20:03, on Zulip):

https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/ra_hir/src/type_ref.rs#L40 ;)

nikomatsakis (Mar 12 2019 at 20:03, on Zulip):

yep, I just found it, thanks

nikomatsakis (Mar 12 2019 at 20:03, on Zulip):

these file names are totally unpredictable ;)

Florian Diebold (Mar 12 2019 at 20:04, on Zulip):

so that's still very close to the AST

nikomatsakis (Mar 12 2019 at 20:04, on Zulip):

Yes.

nikomatsakis (Mar 12 2019 at 20:04, on Zulip):

I was interpreting this as basically the AST

nikomatsakis (Mar 12 2019 at 20:04, on Zulip):

I mean I know it's not literally

nikomatsakis (Mar 12 2019 at 20:04, on Zulip):

but it's "syntactic" in nature

matklad (Mar 12 2019 at 20:05, on Zulip):

Yeah, this is position-independent AST

nikomatsakis (Mar 12 2019 at 20:05, on Zulip):

it seems fine, we would translate that (combined with name resolution information) into what chalk wants

matklad (Mar 12 2019 at 20:05, on Zulip):

It's not just ids to make name-resolution lazy

nikomatsakis (Mar 12 2019 at 20:05, on Zulip):

How would we integrate with name resolution?

Florian Diebold (Mar 12 2019 at 20:06, on Zulip):

e.g. for the target type of an impl there's a method that returns the actual (name-resolved) Ty: https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/ra_hir/src/impl_block.rs#L83

Florian Diebold (Mar 12 2019 at 20:07, on Zulip):

I'd expect there to be a similar name-resolved TraitRef (maybe it needs a different name) in RA that the target trait would be lowered to

detrumi (Mar 12 2019 at 20:08, on Zulip):

So the Chalk inputs would always be fully resolved?

matklad (Mar 12 2019 at 20:08, on Zulip):

Good question!

matklad (Mar 12 2019 at 20:09, on Zulip):

I imagine that we might save some computation if not eagarly resolving

matklad (Mar 12 2019 at 20:09, on Zulip):

like, imagine impl Foo for (Bar, Baz)

matklad (Mar 12 2019 at 20:09, on Zulip):

I guess there are cases when it's enough to know that target is a tuple, without understanding what Bar and Baz mean exactly

Florian Diebold (Mar 12 2019 at 20:09, on Zulip):

that seems like a lot of complication though

nikomatsakis (Mar 12 2019 at 20:09, on Zulip):

well, it's plausible

detrumi (Mar 12 2019 at 20:09, on Zulip):

can Chalk handle missing information?

nikomatsakis (Mar 12 2019 at 20:09, on Zulip):

sort of

nikomatsakis (Mar 12 2019 at 20:10, on Zulip):

I imagine in the beginning we might not need to worry about this but

nikomatsakis (Mar 12 2019 at 20:10, on Zulip):

when you ask Chalk to prove some predicate (e.g., is Trait implemented for Ty),

nikomatsakis (Mar 12 2019 at 20:10, on Zulip):

one of the first thing it does is to callback into the context and ask for a superset of the rules that might be used to prove that

nikomatsakis (Mar 12 2019 at 20:10, on Zulip):

this is probably the hook we would use to trigger lowering

nikomatsakis (Mar 12 2019 at 20:11, on Zulip):

so it is plausible that we could say (for example) "lower the impls of trait Foo that are for tuples"

nikomatsakis (Mar 12 2019 at 20:11, on Zulip):

(or which might be)

nikomatsakis (Mar 12 2019 at 20:11, on Zulip):

rustc uses a similar sort of trick, categorizing impls into some big bins

nikomatsakis (Mar 12 2019 at 20:11, on Zulip):

basically a hashing trick

nikomatsakis (Mar 12 2019 at 20:12, on Zulip):

so yeah it's plausible that, while Chalk does want name resolution for the impls it requests info about, it may not require access to all the impls

matklad (Mar 12 2019 at 20:12, on Zulip):

yeah, we have something called TyFingerprint for this

matklad (Mar 12 2019 at 20:13, on Zulip):

fully resolved types for subset of impls look good

Florian Diebold (Mar 12 2019 at 20:13, on Zulip):

seems to me like that would be done on the level of queries, right? e.g. chalk would ask for 'impls of trait Foo with target type fingerprint Tuple'

nikomatsakis (Mar 12 2019 at 20:13, on Zulip):

this is roughly what I had in mind, yeah

matklad (Mar 12 2019 at 20:13, on Zulip):

Do we need some kind of type-interning infrastructure?

matklad (Mar 12 2019 at 20:14, on Zulip):

Or are types just basically PODs with derived Eq and possible duplicates?

nikomatsakis (Mar 12 2019 at 20:14, on Zulip):

well, we don't at first, as I think that neither chalk nor RLS currently uses type interning

nikomatsakis (Mar 12 2019 at 20:15, on Zulip):

I suspect eventually we'll want something but it can wait

nikomatsakis (Mar 12 2019 at 20:15, on Zulip):

maybe based on https://github.com/salsa-rs/salsa/pull/150 :)

Florian Diebold (Mar 12 2019 at 20:17, on Zulip):

so the question above about missing information reminded me, what about dealing with incomplete types? e.g. we might have an Option<{unknown}> because there was a syntax error in there somehow, in the ideal case we'd still know it implements certain traits

nikomatsakis (Mar 12 2019 at 20:17, on Zulip):

hmm that's a good point

detrumi (Mar 12 2019 at 20:17, on Zulip):

Maybe both could work the same way

nikomatsakis (Mar 12 2019 at 20:17, on Zulip):

it seems like we should add some form of "error" variant to chalk's notion of a type

Florian Diebold (Mar 12 2019 at 20:17, on Zulip):

in RA we have Ty::Unknown, but I don't know if that makes sense in chalk

nikomatsakis (Mar 12 2019 at 20:17, on Zulip):

I don't see why not

matklad (Mar 12 2019 at 20:18, on Zulip):

this probably could be just a fresh inference variant though?

nikomatsakis (Mar 12 2019 at 20:18, on Zulip):

yeah so I'm debating a bit

matklad (Mar 12 2019 at 20:18, on Zulip):

like, ErrorType is more or less unimplemented!

nikomatsakis (Mar 12 2019 at 20:18, on Zulip):

at some level you'll have to represent errors

nikomatsakis (Mar 12 2019 at 20:18, on Zulip):

it might be that you can 'lower' them into uses of inference variables etc but

nikomatsakis (Mar 12 2019 at 20:18, on Zulip):

I am wary

Florian Diebold (Mar 12 2019 at 20:19, on Zulip):

because of spurious errors?

nikomatsakis (Mar 12 2019 at 20:19, on Zulip):

I've found that trying to "model" errors as "normal things" leads to complications later and confusing error messages

nikomatsakis (Mar 12 2019 at 20:19, on Zulip):

yeah, it's rare that it's a perfect fit

nikomatsakis (Mar 12 2019 at 20:19, on Zulip):

I think e.g. it'd be pretty straight-forward to add an error variant to the "type"

Florian Diebold (Mar 12 2019 at 20:19, on Zulip):

we could represent it as inference variables, but with a special tag so we don't report any diagnostics from it?

nikomatsakis (Mar 12 2019 at 20:20, on Zulip):

I feel like at that point it'd be better to just have an error variant

nikomatsakis (Mar 12 2019 at 20:20, on Zulip):

but a more interesting question, perhaps, is how it propagates to the results

nikomatsakis (Mar 12 2019 at 20:20, on Zulip):

chalk also has a notion of being "unable to prove" things

nikomatsakis (Mar 12 2019 at 20:20, on Zulip):

(i.e., neither true nor false)

Florian Diebold (Mar 12 2019 at 20:20, on Zulip):

I think with the error variant you'd just have to be careful not to treat two errors as the same type, but I have no idea if that's actually a problem in chalk ;)

nikomatsakis (Mar 12 2019 at 20:21, on Zulip):

so it might be that this is a useful thing here -- i.e., if you are asked whether <error> = u32, the answer is ¯\_(ツ)_/¯ (which was actually our Debug impl for this "can't prove" concept, at least for a time)

nikomatsakis (Mar 12 2019 at 20:22, on Zulip):

this also comes up with overflow, as it happens

nikomatsakis (Mar 12 2019 at 20:22, on Zulip):

e.g., if types get too big, we will introduce approximation

nikomatsakis (Mar 12 2019 at 20:22, on Zulip):

winding up with CannotProve results

nikomatsakis (Mar 12 2019 at 20:22, on Zulip):

anyway it's a good question and we should experiment with it

nikomatsakis (Mar 12 2019 at 20:23, on Zulip):

OK, i'm looking over the notes i've been collecting in this paper

detrumi (Mar 12 2019 at 20:24, on Zulip):

Maybe have an enum with error and "unable to prove" variants, or something

Florian Diebold (Mar 12 2019 at 20:24, on Zulip):

I've added a few lines, hope you don't mind ;)

nikomatsakis (Mar 12 2019 at 20:24, on Zulip):

we've got a number of "refactorings and questions", some pointers into the RLS source, and a few notes on the overall flow

nikomatsakis (Mar 12 2019 at 20:24, on Zulip):

I've added a few lines, hope you don't mind ;)

oh please add away :)

nikomatsakis (Mar 12 2019 at 20:25, on Zulip):

@Florian Diebold one question about those lines though:

do we want to add those things into the RLS? Or will we just be creating them when chalk asks for them and hence we should use chalk's data structures?

detrumi (Mar 12 2019 at 20:25, on Zulip):

yeah I wouldn't expect bounds as part of RLS

Florian Diebold (Mar 12 2019 at 20:25, on Zulip):

I think we need to have a 'HIR' for them in RA

Florian Diebold (Mar 12 2019 at 20:26, on Zulip):

because we don't want to go back to the AST when chalk asks for them

matklad (Mar 12 2019 at 20:26, on Zulip):

Not sure we need a separate HIR, it could be just a method on ImplBlock

Florian Diebold (Mar 12 2019 at 20:27, on Zulip):

yes, and a few enums to represent them

nikomatsakis (Mar 12 2019 at 20:27, on Zulip):

I think we need to have a 'HIR' for them in RA

I see, ok.

nikomatsakis (Mar 12 2019 at 20:27, on Zulip):

I'm basically trying to figure out what is a good set of "next steps" here. I feel like this is starting to take shape. It

Florian Diebold (Mar 12 2019 at 20:27, on Zulip):

I've got one thing remaining that's not very clear yet

Florian Diebold (Mar 12 2019 at 20:27, on Zulip):

to me ;)

Florian Diebold (Mar 12 2019 at 20:28, on Zulip):

which is how queries from RLS to chalk will look

matklad (Mar 12 2019 at 20:29, on Zulip):

I guess the most important one, which we want for completion, is "impl_ty_trait(Ty, TraitRef) -> bool"?

detrumi (Mar 12 2019 at 20:30, on Zulip):

Wouldn't you want a list of traits that a type implements instead?

nikomatsakis (Mar 12 2019 at 20:30, on Zulip):

trait-ref, in my usage, usually includes the self type

nikomatsakis (Mar 12 2019 at 20:30, on Zulip):

jfyi

nikomatsakis (Mar 12 2019 at 20:31, on Zulip):

but yeah I doubt that's the most important one

nikomatsakis (Mar 12 2019 at 20:31, on Zulip):

for one thing, in the general case, the queries can involve variables, and so the answer you get back is not a bool

nikomatsakis (Mar 12 2019 at 20:31, on Zulip):

but includes values for the variables etc

nikomatsakis (Mar 12 2019 at 20:31, on Zulip):

it's more like "Is that trait implemented for these types and -- if so -- what is an exact substitution"

nikomatsakis (Mar 12 2019 at 20:32, on Zulip):

so e.g. you can ask Vec<?T>: Foo and maybe you get back Yes, if ?T = Bar

nikomatsakis (Mar 12 2019 at 20:32, on Zulip):

or No (meaning -- not for any values of ?T)

nikomatsakis (Mar 12 2019 at 20:32, on Zulip):

or Maybe (meaning -- for some values of ?T, but we couldn't find an unambig answer)

nikomatsakis (Mar 12 2019 at 20:32, on Zulip):

anyway it's probably a good idea to step back and ask what the RLS would like to ask

nikomatsakis (Mar 12 2019 at 20:32, on Zulip):

irrespective of how chalk works

matklad (Mar 12 2019 at 20:33, on Zulip):

Can it answer Vec<u32>: Foo<?T>

matklad (Mar 12 2019 at 20:33, on Zulip):

(i am thinking about code compltion)

nikomatsakis (Mar 12 2019 at 20:33, on Zulip):

certainly in rustc's method resolution code, we do ask questions kind of like the one @matklad posed, where the bool represents kind of "could this be true, for some types"? so maybe that is a useful one for the RLS

Florian Diebold (Mar 12 2019 at 20:33, on Zulip):

Wouldn't you want a list of traits that a type implements instead?

my thinking on that is currently that we'd go through all the traits that are in scope and ask whether they're implemented by the type, separately

matklad (Mar 12 2019 at 20:33, on Zulip):

we will know the type precisely, so there shouldn't be ? on the left hand side

nikomatsakis (Mar 12 2019 at 20:33, on Zulip):

Can it answer Vec<u32>: Foo<?T>

I'm not sure I follow :)

nikomatsakis (Mar 12 2019 at 20:34, on Zulip):

we will know the type precisely, so there shouldn't be ? on the left hand side

why would you know the type precisely?

nikomatsakis (Mar 12 2019 at 20:34, on Zulip):

I mean a lot of times you won't

Florian Diebold (Mar 12 2019 at 20:34, on Zulip):

yeah

nikomatsakis (Mar 12 2019 at 20:34, on Zulip):

because there will be inference variables whose result is not known

matklad (Mar 12 2019 at 20:34, on Zulip):

code completion runs on fully type-checked code

nikomatsakis (Mar 12 2019 at 20:34, on Zulip):

e.g., let mut x = None; x.foo( then x has type Option<?T>

Florian Diebold (Mar 12 2019 at 20:35, on Zulip):

we need the implements query to get that fully type-checked code though ;)

matklad (Mar 12 2019 at 20:35, on Zulip):

yeah

matklad (Mar 12 2019 at 20:35, on Zulip):

so, what I am trying to say that there are two modes for questions

matklad (Mar 12 2019 at 20:35, on Zulip):

questions during type inference (presumably the same as in rustc)

matklad (Mar 12 2019 at 20:35, on Zulip):

questions during completion (might be different)

nikomatsakis (Mar 12 2019 at 20:35, on Zulip):

anyway so yeah maybe we take the "method resolution" to be the main goal, makes sense, and I think in that case the main interface rustc uses is the "evaluate" one, which basically asks whether an impl might exist. I suppose we also have to implement searches around the Deref trait (which is a similar query, ultimately)

detrumi (Mar 12 2019 at 20:36, on Zulip):

So Chalk has a choice when it finds inconclusive results: it can ask for more type info, or it can just return what it has

nikomatsakis (Mar 12 2019 at 20:36, on Zulip):

(as an aside, moving the method resolution algorithm into shared code is another (long-term) goal of mine)

nikomatsakis (Mar 12 2019 at 20:37, on Zulip):

So Chalk has a choice when it finds inconclusive results: it can ask for more type info, or it can just return what it has

presently, no. It always gives back a result. If you want to add more type info, you can formulate another query.

nikomatsakis (Mar 12 2019 at 20:37, on Zulip):

so it's more that you, as the one posing the queries, have a choice :)

detrumi (Mar 12 2019 at 20:37, on Zulip):

Ah right, that's effectively the same

nikomatsakis (Mar 12 2019 at 20:38, on Zulip):

(actually, at the lowest level interface, which probably isn't the one RLS wants but it may be, chalk yields back an iterator of answers, and you can choose whether to keep asking for more)

nikomatsakis (Mar 12 2019 at 20:38, on Zulip):

we then have a wrapper that tries to decide how long it makes sense to keep pulling

matklad (Mar 12 2019 at 20:39, on Zulip):

(as an aside, moving the method resolution algorithm into shared code is another (long-term) goal of mine)

BTW, do we expect to keep type inference inside RLS2, or is it a good occasion to start moving it out?

nikomatsakis (Mar 12 2019 at 20:40, on Zulip):

My expectation is that the type checker that is "invoking" chalk will always have its own "type inference context", basically. Whether that type checker lives in RLS2 or some shared library is another question.

nikomatsakis (Mar 12 2019 at 20:40, on Zulip):

So I guess the question is -- how do we get more precise about the queries we need

nikomatsakis (Mar 12 2019 at 20:40, on Zulip):

maybe we should make our first goal

nikomatsakis (Mar 12 2019 at 20:40, on Zulip):

be integrating with the existing type checker

nikomatsakis (Mar 12 2019 at 20:40, on Zulip):

vs completions -- not sure how different that is

nikomatsakis (Mar 12 2019 at 20:40, on Zulip):

my main point is that the existing type checker, well, exists

nikomatsakis (Mar 12 2019 at 20:41, on Zulip):

so we can see the goal as primarily being one of helping it assign types better

nikomatsakis (Mar 12 2019 at 20:41, on Zulip):

for the time being

matklad (Mar 12 2019 at 20:41, on Zulip):

yeah. I'd game to integrate something, and than see what we need as we go

nikomatsakis (Mar 12 2019 at 20:41, on Zulip):

so that means that a good starting point is to kind of enumerate where in the type-checker trait resolution would fit in. The obvious place is method resolution, but there are other spots-- e.g., proving where clauses

nikomatsakis (Mar 12 2019 at 20:42, on Zulip):

I guess that the current type-checker doesn't probably make much effort at doing that since that is mostly useful for finding errors (but not entirely, it can inform inference too)

nikomatsakis (Mar 12 2019 at 20:42, on Zulip):

e.g., fn foo<A, B>(x: A) -> B where A: Deref<Target = B>

Florian Diebold (Mar 12 2019 at 20:42, on Zulip):

yeah, proving where-clauses is actually pretty interesting e.g. for chains of iterator methods

nikomatsakis (Mar 12 2019 at 20:42, on Zulip):

yep, another great example

nikomatsakis (Mar 12 2019 at 20:43, on Zulip):

that might be a mildly easier starting point

nikomatsakis (Mar 12 2019 at 20:43, on Zulip):

where-clauses I mean

nikomatsakis (Mar 12 2019 at 20:43, on Zulip):

though really once we have anything working I think integrating more won't be super hard

nikomatsakis (Mar 12 2019 at 20:43, on Zulip):

so the way I had envisioned this working in rustc, and I think it would work the same in RLS

matklad (Mar 12 2019 at 20:44, on Zulip):

As an "end goal", completion & goto def working for iterator chains would be pretty great

Florian Diebold (Mar 12 2019 at 20:44, on Zulip):

method resolution feels to me like the more useful starting point though (for iterator chains, we need both anyway)

nikomatsakis (Mar 12 2019 at 20:44, on Zulip):

is that we'd have a few queries, sort of like

nikomatsakis (Mar 12 2019 at 20:45, on Zulip):

a "canonical" goal is one where the unresolved inference variables have been rewritten

nikomatsakis (Mar 12 2019 at 20:46, on Zulip):

this rustc-guide chapter gives more details on that

Florian Diebold (Mar 12 2019 at 20:46, on Zulip):

yeah, the canonicalization is actually another thing I was wondering about -- will RLS need to do that, or can chalk help? I'm not sure if it's even actually complicated to implement

nikomatsakis (Mar 12 2019 at 20:46, on Zulip):

anyway, the idea is that prove will -- internally -- access the chalk-engine and pull out enough answers to come up with a conclusion.

nikomatsakis (Mar 12 2019 at 20:46, on Zulip):

yeah, the canonicalization is actually another thing I was wondering about -- will RLS need to do that, or can chalk help? I'm not sure if it's even actually complicated to implement

this is why I keep talking about sharing the repr of types

nikomatsakis (Mar 12 2019 at 20:46, on Zulip):

if we are doing that, then we should be able to share the code chalk uses to do it

nikomatsakis (Mar 12 2019 at 20:46, on Zulip):

not that it's super hard

nikomatsakis (Mar 12 2019 at 20:46, on Zulip):

but it'd be good to share

nikomatsakis (Mar 12 2019 at 20:47, on Zulip):

anyway, the idea is that prove will -- internally -- access the chalk-engine and pull out enough answers to come up with a conclusion.

anyway, the type checker's main job then is basically to keep a list of 'unproven things'. It keeps trying to prove. If the attempt succeeds, the item can be removed from the list. We also get back some "substitutions" we can apply as a result that can help inference along (even an ambiguous result might be able to tell us some things)

nikomatsakis (Mar 12 2019 at 20:48, on Zulip):

I think this is roughly what we did in rustc ;) @scalexm would remember better

detrumi (Mar 12 2019 at 20:48, on Zulip):

And those substitutions would work on the shared AST?

nikomatsakis (Mar 12 2019 at 20:48, on Zulip):

I could imagine trying to "mock this up" in RLS 2.0 to start

nikomatsakis (Mar 12 2019 at 20:49, on Zulip):

perhaps with some hand-coded rules, like .. idk .. Vec<T>: Clone if T: Clone

nikomatsakis (Mar 12 2019 at 20:49, on Zulip):

not sure if that's worth the trouble :)

nikomatsakis (Mar 12 2019 at 20:50, on Zulip):

And those substitutions would work on the shared AST?

they would apply to the types from the goal -- i.e., if we asked vec::IntoIter<Vec<u32>>: Iterator<Item=?X>, the result might include the substitution ?X = u32

matklad (Mar 12 2019 at 20:50, on Zulip):

Do we want to discuss technical details about sharing? Like what code lives where, what do we use instead git-submodules, etc? :)

nikomatsakis (Mar 12 2019 at 20:51, on Zulip):

Hmm. I was expecting to publish stuff through crates.io, I guess

nikomatsakis (Mar 12 2019 at 20:51, on Zulip):

but maybe we don't want to do that to start

matklad (Mar 12 2019 at 20:52, on Zulip):

A plausible first step would be:

matklad (Mar 12 2019 at 20:52, on Zulip):

I'd start with RLS2 using git-deps to depend on (stable) crates of chalk repo

matklad (Mar 12 2019 at 20:52, on Zulip):

crates.io seems to be an overhead

nikomatsakis (Mar 12 2019 at 20:53, on Zulip):

seems fine

nikomatsakis (Mar 12 2019 at 20:53, on Zulip):

I'm debating about the idea of starting out by sharing types. I .. kind of like it maybe.

Florian Diebold (Mar 12 2019 at 20:53, on Zulip):

I don't know about switching RA to using chalk's type representation immediately

nikomatsakis (Mar 12 2019 at 20:53, on Zulip):

It's certainly a goal to work towards

detrumi (Mar 12 2019 at 20:54, on Zulip):

I don't know about switching RA to using chalk's type representation immediately

Because that representation could change based on how the RLS is going to use it?

detrumi (Mar 12 2019 at 20:55, on Zulip):

Or because RA's representation is too different?

Florian Diebold (Mar 12 2019 at 20:56, on Zulip):

because it will be a huge change if we try to do it all at once, yes

Florian Diebold (Mar 12 2019 at 20:56, on Zulip):

(I actually tried it a bit)

nikomatsakis (Mar 12 2019 at 20:56, on Zulip):

yeah, it's probably a good idea to try and dig into that task separately

nikomatsakis (Mar 12 2019 at 20:56, on Zulip):

I'm going to have to go soon

nikomatsakis (Mar 12 2019 at 20:56, on Zulip):

but try to break it into some steps

nikomatsakis (Mar 12 2019 at 20:57, on Zulip):

On the chalk side, I think a good first step is work on refactoring the lowering code

nikomatsakis (Mar 12 2019 at 20:57, on Zulip):

with an eye towards integration into RLS

nikomatsakis (Mar 12 2019 at 20:57, on Zulip):

if someone were interested, i'd be interested in trying to collaborate with someone

matklad (Mar 12 2019 at 20:57, on Zulip):

@Florian Diebold what would be the better first-step? Explicit mapping beween all RA types and all chalks types?

nikomatsakis (Mar 12 2019 at 20:58, on Zulip):

i.e., I'd like to schedule some pair prog time to start playing with that, then I can go get real busy and not have any time, and that person (or people) can carry on ;)

Florian Diebold (Mar 12 2019 at 20:58, on Zulip):

I think we need to at least solve the ItemId question before we can share the representation, and to do that it would probably be helpful to first implement it as a conversion, yes

nikomatsakis (Mar 12 2019 at 20:58, on Zulip):

my guess would be that the way to do the transition would be

nikomatsakis (Mar 12 2019 at 20:58, on Zulip):

to first try and refactor the RLS definition to be closer to the chalk definition

nikomatsakis (Mar 12 2019 at 20:59, on Zulip):

bit by bit

nikomatsakis (Mar 12 2019 at 20:59, on Zulip):

we may encounter challenges along the way

nikomatsakis (Mar 12 2019 at 20:59, on Zulip):

eventually, if we can get it to be the same, then we can take the dependency

Florian Diebold (Mar 12 2019 at 20:59, on Zulip):

yeah, that seems good to me

nikomatsakis (Mar 12 2019 at 20:59, on Zulip):

one very simple first step there

nikomatsakis (Mar 12 2019 at 21:00, on Zulip):

the rust-analyzer Ty has a ton of variants for things like bool etc (like rustc itself)

nikomatsakis (Mar 12 2019 at 21:00, on Zulip):

but chalk basically lumps all of those together into "applied" to an id

nikomatsakis (Mar 12 2019 at 21:00, on Zulip):

(so e.g. there is an id for bool, which in chalk terms if a "struct" :P)

nikomatsakis (Mar 12 2019 at 21:00, on Zulip):

(that terminology should obviously change)

matklad (Mar 12 2019 at 21:01, on Zulip):

and that person (or people) can carry on ;)

I personally am stuck with macros for some time, but I definitely will be watching for this :)

nikomatsakis (Mar 12 2019 at 21:01, on Zulip):

anyway, but yeah trying to consolidate those variants and make things more uniform

nikomatsakis (Mar 12 2019 at 21:01, on Zulip):

so, on a meta point

nikomatsakis (Mar 12 2019 at 21:01, on Zulip):

one thing we've been thinking about in the Traits Working Group

nikomatsakis (Mar 12 2019 at 21:01, on Zulip):

is that we are going to wind up with kind of "subworking groups" that are operating somewhat independently

nikomatsakis (Mar 12 2019 at 21:01, on Zulip):

this feels like an obvious one

nikomatsakis (Mar 12 2019 at 21:01, on Zulip):

I'm not saying we actually go "form a working group"

nikomatsakis (Mar 12 2019 at 21:02, on Zulip):

but just thinking that we might want a kind of regular meeting time

nikomatsakis (Mar 12 2019 at 21:02, on Zulip):

we're getting towards work items here

nikomatsakis (Mar 12 2019 at 21:05, on Zulip):

I'm compiling some immediate work items and steps from the rest of the doc

nikomatsakis (Mar 12 2019 at 21:06, on Zulip):

but maybe that's not useful

nikomatsakis (Mar 12 2019 at 21:06, on Zulip):

maybe a better way is to put the [ ] work items into the top two sections :)

scalexm (Mar 12 2019 at 21:08, on Zulip):

(Sorry, I’ve been semi-following the conv since it’s dinner time here) I’d probably be game to do some refactoring on chalk

scalexm (Mar 12 2019 at 21:08, on Zulip):

It would probably be easier than writing code in rustc since I have little time currently, at least I don’t have to deal with rebasing and bors etc

nikomatsakis (Mar 12 2019 at 21:09, on Zulip):

@scalexm would you be available around (say) 14:00 UTC-04:00 tomorrow? (probably 19:00 your time?)

scalexm (Mar 12 2019 at 21:09, on Zulip):

19:00 might be hard, 20:00 is better

nikomatsakis (Mar 12 2019 at 21:10, on Zulip):

ok, how about this -- I'll do some experimentation starting earlier, and we'll sync up at 20:00?

scalexm (Mar 12 2019 at 21:10, on Zulip):

Sounds good!

matklad (Mar 12 2019 at 21:11, on Zulip):

:wave: by everyone!

Thanks for organizing convo @nikomatsakis , its very helpful!

nikomatsakis (Mar 12 2019 at 21:12, on Zulip):

Yes, this was great. :tada: Thanks all.

nikomatsakis (Mar 12 2019 at 21:14, on Zulip):

is that we are going to wind up with kind of "subworking groups" that are operating somewhat independently

to continue along this vein -- maybe we should make a Zulip steam like t-compiler/wg-rls-2.0/chalk?

nikomatsakis (Mar 12 2019 at 21:15, on Zulip):

I wanted to call it "rls 2.0 :heart: chalk", but I'm not sure if stream names can have emojis

nikomatsakis (Mar 12 2019 at 21:15, on Zulip):

I guess I could test it :)

detrumi (Mar 12 2019 at 21:26, on Zulip):

I'd like to contribute, but I'm not sure what to work on since I'm not too familiar with RA/Chalk yet. Maybe the Ids?

detrumi (Mar 12 2019 at 21:27, on Zulip):

The "refactor to match" would probably change Chalk's single Id type to separate Ids like RA, right?

nikomatsakis (Mar 12 2019 at 21:29, on Zulip):

@detrumi actually I wanted to ping you

nikomatsakis (Mar 12 2019 at 21:29, on Zulip):

I think the ids would be a great choice, yes

nikomatsakis (Mar 12 2019 at 21:30, on Zulip):

I guess I could test it :)

tested..emojis don't work

detrumi (Mar 12 2019 at 21:33, on Zulip):

Please don't add that to the Zulip feature wishlist, I fear they won't take us seriously any more :big_smile:

nikomatsakis (Mar 12 2019 at 22:36, on Zulip):

to continue along this vein -- maybe we should make a Zulip steam like t-compiler/wg-rls-2.0/chalk?

I'm going to make it -- if for no other reason than that it will make it easier for me to respond to people who are talking about the chalk integration plan :)

Last update: Nov 19 2019 at 19:00UTC