Stream: t-compiler

Topic: design meeting 2020-03-06


nikomatsakis (Mar 03 2020 at 22:12, on Zulip):

Hey @T-compiler/meeting -- the next design meeting (2020-03-06) will be discussing compiler-team#234, a proposal for a design for a shared library that defines types and can be used by rustc/chalk/rust-analyzer. There is now a write-up available sketching the ideas and also trying to outline what the meeting should discuss and what is out of scope. Thoughts and feedback welcome!

simulacrum (Mar 03 2020 at 23:06, on Zulip):

fyi, I will mostly not be here this week but will try to leave some thoughts before then

pnkfelix (Mar 04 2020 at 02:13, on Zulip):

(I also will not be able to attend; I hope to provide feedback on the hackmd write-up before the meeting itself.)

simulacrum (Mar 04 2020 at 23:18, on Zulip):

The proposal looks good to me. I would like to note that the complexity feels pretty small, in particular the changes to rustc seem loosely good even if they don't end up going anywhere :)

I agree with the approach to start out with the in rust-lang/rust crate, too.

pnkfelix (Mar 06 2020 at 11:50, on Zulip):

One (hopefully quick) agenda item to add: We have two independent fixes for beta-regression #69191. The first PR is #69753. The second is #69768. The question is: What to do with each PR w.r.t nightly and beta branches, given that beta is imminently going to be promoted to stable.

pnkfelix (Mar 06 2020 at 11:50, on Zulip):

(My personal suggestion is to land both PR's on nightly, and then backport solely PR #69753.)

pnkfelix (Mar 06 2020 at 11:52, on Zulip):

((related discussion over on the zulip topic for the beta regression itself)

oli (Mar 06 2020 at 12:07, on Zulip):

well, we can just land #69753 on beta and #69768 on nightly, as #69768 would revert #69753 if it were already merged

eddyb (Mar 06 2020 at 12:08, on Zulip):

funnily enough I don't think they would conflict

pnkfelix (Mar 06 2020 at 12:08, on Zulip):

the only conflict would be the regression test, I Think.

pnkfelix (Mar 06 2020 at 12:08, on Zulip):

(which I ... slightly revised :wink: )

oli (Mar 06 2020 at 12:08, on Zulip):

not even that, different filenames

eddyb (Mar 06 2020 at 12:09, on Zulip):

what @oli just said :P (I noticed it because I compared the PRs)

oli (Mar 06 2020 at 12:09, on Zulip):

but the point is that #69753 creates some logic in const eval that we don't want in there

pnkfelix (Mar 06 2020 at 12:09, on Zulip):

yes we definitely want to revert it eventually

pnkfelix (Mar 06 2020 at 12:12, on Zulip):

(Solely on principle I prefer to first land on nightly nonetheless, rather than going direct to beta. But I won't veto a merge direct to beta of my PR #69753 )

pnkfelix (Mar 06 2020 at 12:13, on Zulip):

(I re-r+'ed the latter, BTW ....)

eddyb (Mar 06 2020 at 12:17, on Zulip):

btw you might want to raise the priorities or at least rollup- my rollup=never

nikomatsakis (Mar 06 2020 at 14:54, on Zulip):

Hello @T-compiler/meeting! Design meeting starts in ~6 minutes. As I wrote at the start of this topic:

The next design meeting (2020-03-06) will be discussing compiler-team#234, a proposal for a design for a shared library that defines types and can be used by rustc/chalk/rust-analyzer. There is now a write-up available sketching the ideas and also trying to outline what the meeting should discuss and what is out of scope. Thoughts and feedback welcome!

nikomatsakis (Mar 06 2020 at 15:00, on Zulip):

Hello @T-compiler/meeting -- meeting starting now! Please add :wave: emoji to show you're here. We'll kick off with 5 minutes of...

Announcements

nikomatsakis (Mar 06 2020 at 15:03, on Zulip):

pnkfelix said:

:exclamation: One (hopefully quick) agenda item to add: We have two independent fixes for beta-regression #69191. The first PR is #69753. The second is #69768. The question is: What to do with each PR w.r.t nightly and beta branches, given that beta is imminently going to be promoted to stable.

nikomatsakis (Mar 06 2020 at 15:03, on Zulip):

pnkfelix said:

(My personal suggestion is to land both PR's on nightly, and then backport solely PR #69753.)

nikomatsakis (Mar 06 2020 at 15:05, on Zulip):

I am just seeing this now, but I see that @pnkfelix is making the suggestion because #69753 is a very narrow fix and whatever we backport will become insta-stable. Seems reasonable to me. Does anyone object to just backporting #69753?

oli (Mar 06 2020 at 15:05, on Zulip):

no objection, actually very much in favour of doing it this way

centril (Mar 06 2020 at 15:07, on Zulip):
    _Variant(Void),
    _Warriont(Void),
    _Worrynot(Void),

Btw... Something about this makes me smile :slight_smile:

nikomatsakis (Mar 06 2020 at 15:08, on Zulip):

OK, any final announcements?

nikomatsakis (Mar 06 2020 at 15:10, on Zulip):

OK, let's kick it off then

nikomatsakis (Mar 06 2020 at 15:10, on Zulip):

So I laid out two goals for the meeting:

nikomatsakis (Mar 06 2020 at 15:11, on Zulip):

Let's start in on the first item? I'm going to just give periodic timing reminders, I'd like to leave at least 20 minutes for the final item, so I guess that means ~20 minutes for first, ~20 minutes for second, and 10 minutes to talk about random things :)

nikomatsakis (Mar 06 2020 at 15:11, on Zulip):

but let's see

nikomatsakis (Mar 06 2020 at 15:12, on Zulip):

So yeah the big picture here is the idea of extracting out some kind of "shared library" that will represent Rust's types. The goal is for this library to be usable directly by rustc, rust-analyzer, and chalk, so that everyone can share a representation of Rust's types.

nikomatsakis (Mar 06 2020 at 15:13, on Zulip):

One of the tricky bits is that the different consumers have somewhat different requirements -- rustc uses interning, rust-analyzer doesn't (and probably shouldn't), and chalk wants to work with both (though it doesn't use interning in its tests)

nikomatsakis (Mar 06 2020 at 15:13, on Zulip):

This leads to the proposed pattern for representing types, where the actual representation of a type is made generic, and we just define methods for getting at a TyData enum that contains the variants (and some flags)

nikomatsakis (Mar 06 2020 at 15:14, on Zulip):

(Side note: @Jack Huey , we should add "add flags" to the list of chalk adaptation steps)

nikomatsakis (Mar 06 2020 at 15:15, on Zulip):

I won't copy and paste the whole doc here, I'm presuming most folks looked it over or are doing a bit of that now

nikomatsakis (Mar 06 2020 at 15:15, on Zulip):

oh and cc @WG-rls2.0 in case those folks aren't on the meeting group

nikomatsakis (Mar 06 2020 at 15:15, on Zulip):

anway basically the way to represent types is just

pub struct Ty<I: Interner> {
    interned: I::InternedType
}
nikomatsakis (Mar 06 2020 at 15:16, on Zulip):

but you can use ty.data(interner) to get access to the type data:

enum TyData<I: Interner> {
    Apply(ApplicationTy<I>),
    Placeholder(PlaceholderIndex),
    Dyn(DynTy<I>),
    Alias(AliasTy<I>),
    Function(Fn<I>),
    BoundVar(usize),
    InferenceVar(InferenceVar),
}
nikomatsakis (Mar 06 2020 at 15:16, on Zulip):

(In Chalk today, it's ty.data(), but we're adding an interner argument to support different kinds of interning; e.g., rust-analyzer presently uses a form of interning where types are represented as an integer, and that is integrated into the incremental system to allow recycling integers when things change etc)

centril (Mar 06 2020 at 15:16, on Zulip):

Pros with the proposed design:

Cons with the proposed design:

eddyb (Mar 06 2020 at 15:17, on Zulip):

bikeshed: interner[ty].data() might flow a bit better, but also interner could be cx which would make it cx[ty] vs ty.data(cx)

eddyb (Mar 06 2020 at 15:17, on Zulip):

also I assume kind vs data is another bikeshed

nikomatsakis (Mar 06 2020 at 15:18, on Zulip):

yes, I'd like to avoid the bikesheds for now, but let's note them down

centril (Mar 06 2020 at 15:18, on Zulip):

(ty.kind(cx) feels more obvious)

eddyb (Mar 06 2020 at 15:18, on Zulip):

yeah if you want a method there I kind of agree

nikomatsakis (Mar 06 2020 at 15:18, on Zulip):

kind of course overlaps with other jargon, but don't claim a strong opinion

nikomatsakis (Mar 06 2020 at 15:18, on Zulip):

I'm interested more in two other things @centril noted

centril (Mar 06 2020 at 15:18, on Zulip):

kind of course overlaps with other jargon, but don't claim a strong opinion

(As in higher kinded types?)

nikomatsakis (Mar 06 2020 at 15:19, on Zulip):

or "parameter kinds", etc

nikomatsakis (Mar 06 2020 at 15:19, on Zulip):

e.g., lifetime, type, const

eddyb (Mar 06 2020 at 15:19, on Zulip):

that's the same notion of "kind" I'm pretty sure :P

nikomatsakis (Mar 06 2020 at 15:19, on Zulip):

(yes, just saying that it's relevant even if we never add HKT)

eddyb (Mar 06 2020 at 15:19, on Zulip):

but maybe I should leave before I get out-theorized

Zoxc (Mar 06 2020 at 15:19, on Zulip):

I like abstracting more over the concrete representation of types so alternative representations could be more easily tried for performance reasons.

centril (Mar 06 2020 at 15:20, on Zulip):

Anyhow, let's cut the bikeshed short :slight_smile:

nikomatsakis (Mar 06 2020 at 15:20, on Zulip):

one of the things I wanted to point out is that you can use the generic here in interesting ways to make code a bit more generic, or enforce separations

matklad (Mar 06 2020 at 15:20, on Zulip):

More monomorphization needed

Yeah, this is what I am worried about a lot. We hit repeated re-monomophizations a lot in rust-analyzer. Somehow forcing -Z share_generics for a specific crate would be great

nikomatsakis (Mar 06 2020 at 15:20, on Zulip):

well, ok, let's turn to that :)

nikomatsakis (Mar 06 2020 at 15:21, on Zulip):

so, it's certainly true that in rustc you will only ever use one value for the Interner type

centril (Mar 06 2020 at 15:21, on Zulip):

I'm somewhat unhappy about the loss of pattern matching personally, given that I very recently took advantage of it to make code read nicer

nikomatsakis (Mar 06 2020 at 15:21, on Zulip):

nikomatsakis said:

so, it's certainly true that in rustc you will only ever use one value for the Interner type

and to the extent that we mostly extract definitions, there isn't much code to monomorphize, but I do expect to also extract things like the folder,

nikomatsakis (Mar 06 2020 at 15:22, on Zulip):

but then that code is generic anyway

centril (Mar 06 2020 at 15:22, on Zulip):

...but I'm sure I can learn to live with it :slight_smile:

nikomatsakis (Mar 06 2020 at 15:22, on Zulip):

in short, I'm not really sure what the effect on compilation times will be, but I see no fundamental reason for them to be worse,

eddyb (Mar 06 2020 at 15:22, on Zulip):

okay so this might seem offtopic, but, does Chalk do anything for interning slices? i.e. like ty::List<T> in rustc

nikomatsakis (Mar 06 2020 at 15:22, on Zulip):

(it may be something we want to look at and improve)

nikomatsakis (Mar 06 2020 at 15:22, on Zulip):

there are also some potential advantages though

nikomatsakis (Mar 06 2020 at 15:22, on Zulip):

in that we you can write libraries that work with types but which don't depend on the details of rustc

nikomatsakis (Mar 06 2020 at 15:22, on Zulip):

which is of course part of the whole goal here

nikomatsakis (Mar 06 2020 at 15:23, on Zulip):

i.e., we can get the point where modifying parts of rustc doesn't mean rebuilding the type checker, etc

nikomatsakis (Mar 06 2020 at 15:23, on Zulip):

eddyb said:

okay so this might seem offtopic, but, does Chalk do anything for interning slices? i.e. like ty::List<T> in rustc

yes

nikomatsakis (Mar 06 2020 at 15:23, on Zulip):

I simplified things but

eddyb (Mar 06 2020 at 15:23, on Zulip):

because I realized recently that ty::List<T>'s design could easily accomodate tracking flags even forTs that might not have use for them (or I guess the flags could be an associated type of T)

nikomatsakis (Mar 06 2020 at 15:23, on Zulip):

there are associated types for things like "list of parameters"

nikomatsakis (Mar 06 2020 at 15:23, on Zulip):

precisely for this reason

centril (Mar 06 2020 at 15:23, on Zulip):

@nikomatsakis hmm... without access to tcx or fcx specifically, what sort of logic can you write without access to the methods on that?

nikomatsakis (Mar 06 2020 at 15:23, on Zulip):

@centril you take access to an &I where I: Interner

nikomatsakis (Mar 06 2020 at 15:24, on Zulip):

this is how all of chalk is written, for example

centril (Mar 06 2020 at 15:24, on Zulip):

Yes, but I: Interner says very little

nikomatsakis (Mar 06 2020 at 15:24, on Zulip):

it says everything you need to access type data

nikomatsakis (Mar 06 2020 at 15:24, on Zulip):

but in chalk there is an add'l trait, RustIrDatabase, that gives access to select queries etc

centril (Mar 06 2020 at 15:24, on Zulip):

Right; that's what I was after

nikomatsakis (Mar 06 2020 at 15:25, on Zulip):

(and which gives access to an interner)

nikomatsakis (Mar 06 2020 at 15:25, on Zulip):

yeah, so you basically declare your interface to the outside world

nikomatsakis (Mar 06 2020 at 15:25, on Zulip):

and then there is some crate that "knits" things together

centril (Mar 06 2020 at 15:25, on Zulip):

So basically more tagless final, makes sense

nikomatsakis (Mar 06 2020 at 15:25, on Zulip):

I don't know what "tagless final" refers to =)

nikomatsakis (Mar 06 2020 at 15:26, on Zulip):

but it's a pretty standard pattern in many contexts

Zoxc (Mar 06 2020 at 15:26, on Zulip):

Is there something that requires interning in this design, or is it just named that since rustc uses interners?

nikomatsakis (Mar 06 2020 at 15:26, on Zulip):

the latter

nikomatsakis (Mar 06 2020 at 15:26, on Zulip):

we tried various names

nikomatsakis (Mar 06 2020 at 15:26, on Zulip):

but interner felt like the one that gave the most immediate intution

nikomatsakis (Mar 06 2020 at 15:26, on Zulip):

even if sometimes you aren't really interning

centril (Mar 06 2020 at 15:26, on Zulip):

nikomatsakis said:

I don't know what "tagless final" refers to =)

See e.g. http://okmij.org/ftp/tagless-final/index.html and http://okmij.org/ftp/tagless-final/course/lecture.pdf

eddyb (Mar 06 2020 at 15:27, on Zulip):

eddyb said:

because I realized recently that ty::List<T>'s design could easily accomodate tracking flags even forTs that might not have use for them (or I guess the flags could be an associated type of T)

I hope this is a significant improvement for certain kinds of workloads, that currently have to do a linear search across Substs, or worse, across all Substs embedded in [Predicate] (e.g. .has_...() methods on ParamEnv)

but I don't know how soon I'll get to it or how long it would take to implement

nikomatsakis (Mar 06 2020 at 15:27, on Zulip):

one side note that is interesting

nikomatsakis (Mar 06 2020 at 15:28, on Zulip):

and relevant maybe to that

nikomatsakis (Mar 06 2020 at 15:28, on Zulip):

in chalk today, at least, the fold trait takes two interners -- source and target.

nikomatsakis (Mar 06 2020 at 15:28, on Zulip):

in practice, they are typically the same

nikomatsakis (Mar 06 2020 at 15:28, on Zulip):

but it lets you write code that separates out "before" and "after" types

nikomatsakis (Mar 06 2020 at 15:28, on Zulip):

one downside though is that it sometimes requires more re-interning than rustc would

nikomatsakis (Mar 06 2020 at 15:28, on Zulip):

i.e., we could shortcircuit a search

eddyb (Mar 06 2020 at 15:29, on Zulip):

regarding interners: I wonder how many "parametric polymorphism"-like benefits you get from using associated types instead of having a single "interned Ty" type that's always an integer or reference

nikomatsakis (Mar 06 2020 at 15:29, on Zulip):

I sort of expect to resolve this eventually -- I'd prefer to keep the ability to write code generic over multiple interners to express logical separations, without requiring them to be represented by actually different types, and to add specializations or other tricks to make it efficient

nikomatsakis (Mar 06 2020 at 15:30, on Zulip):

but I figured that we'd start by just extracting "single Interner fold" (like rustc has today)

nikomatsakis (Mar 06 2020 at 15:30, on Zulip):

and figure out after that if we can generalize it, I'm not sure yet how much value the "two interner fold" has anyway

nikomatsakis (Mar 06 2020 at 15:30, on Zulip):

eddyb said:

regarding interners: I wonder how many "parametric polymorphism"-like benefits you get from using associated types instead of having a single "interned Ty" type that's always an integer or reference

what do you mean by PP-like benefits?

eddyb (Mar 06 2020 at 15:30, on Zulip):

for example, you can't even attempt to implement fmt::Debug on the generic structs by relying on TLS, without either Interner methods that let you do that, or the associated types themselves implementing fmt::Debug

nikomatsakis (Mar 06 2020 at 15:30, on Zulip):

I'm not sure if that's the same thing I was just talking about or different

centril (Mar 06 2020 at 15:30, on Zulip):

eddyb said:

regarding interners: I wonder how many "parametric polymorphism"-like benefits you get from using associated types instead of having a single "interned Ty" type that's always an integer or reference

Like theorems for free benefits?

nikomatsakis (Mar 06 2020 at 15:31, on Zulip):

eddyb said:

for example, you can't even attempt to implement fmt::Debug on the generic structs by relying on TLS, without either Interner methods that let you do that, or the associated types themselves implementing fmt::Debug

yeah, we have some methods for customizing debug representation right now

eddyb (Mar 06 2020 at 15:31, on Zulip):

like "you can't accidentally rely too much on knowing specifics about the types involved"

nikomatsakis (Mar 06 2020 at 15:31, on Zulip):

yes, ok

eddyb (Mar 06 2020 at 15:31, on Zulip):

even if in practice there might only be one implementation in the entire crate graph

nikomatsakis (Mar 06 2020 at 15:31, on Zulip):

this is similar to what I was saying, I do think there's benefits there

centril (Mar 06 2020 at 15:31, on Zulip):

Well... except for specialization destroying your parametricity...

nikomatsakis (Mar 06 2020 at 15:31, on Zulip):

or at least I think there might be

eddyb (Mar 06 2020 at 15:32, on Zulip):

it's not like we use specialization in rustc please ignore rustc_metadata

nikomatsakis (Mar 06 2020 at 15:32, on Zulip):

specialization is not relevant here, we're talking more about informal benefits

eddyb (Mar 06 2020 at 15:32, on Zulip):

right, not proof assistant benefits (you would presumably not worry about interners there :P)

nikomatsakis (Mar 06 2020 at 15:32, on Zulip):

but yeah if you want a theorem, add a "given no specialization" and call it a day :)

centril (Mar 06 2020 at 15:32, on Zulip):

Sure; "theorems for free"-ish by not actually using specialization; anyways... it's probably not a big deal either way

nikomatsakis (Mar 06 2020 at 15:33, on Zulip):

ok, so, we're 13 minutes in, it seems like people are not too upset about the basic idea :)

centril (Mar 06 2020 at 15:33, on Zulip):

Basic idea seems good

centril (Mar 06 2020 at 15:33, on Zulip):

Details TBD, etc.

nikomatsakis (Mar 06 2020 at 15:34, on Zulip):

right, so let's talk a bit about the "transition plan" because I think it's relevant then

eddyb (Mar 06 2020 at 15:34, on Zulip):

anyway, that was a hunch, and it does seem interesting enough that I might try this pattern in one my side projects (if I ever get back to it), and play around with the names and APIs to see how nice I can get it (for myself)

nikomatsakis (Mar 06 2020 at 15:34, on Zulip):

I think the most practical thing is to try and gradually extract this library out from rustc

nikomatsakis (Mar 06 2020 at 15:34, on Zulip):

one of the benefits of this is we can track performance

nikomatsakis (Mar 06 2020 at 15:34, on Zulip):

so e.g. if we try to make things generic and we wind up losing out on some benefits we got from flags or whatever, we'll notice

centril (Mar 06 2020 at 15:35, on Zulip):

Seems tricky though to do this as a series of small PRs

matklad (Mar 06 2020 at 15:35, on Zulip):

Do you think it might make sense to extract it from chalk-ra first? Presumably, this can be done fast enough, and could inform rustc extraction

centril (Mar 06 2020 at 15:36, on Zulip):

Cause it seems fairly invasive... but maybe we can do e.g. ty.kind -> ty.kind() -> ty.kind(tcx) as a 2-PR step thing

matklad (Mar 06 2020 at 15:36, on Zulip):

Ie, we first do exploration with ra/chalk, and then procede with rustc plan

eddyb (Mar 06 2020 at 15:36, on Zulip):

problem is rustc has all of the necessary complexity, so it will ultimately impose itself onto the design

nikomatsakis (Mar 06 2020 at 15:36, on Zulip):

centril said:

Seems tricky though to do this as a series of small PRs

well, I'm not sure how smal said PRs will be, but I think we have to do it step by step, presumably by trying first to "align" the "API" of Ty<'tcx>,

nikomatsakis (Mar 06 2020 at 15:37, on Zulip):

centril said:

Cause it seems fairly invasive... but maybe we can do e.g. ty.kind -> ty.kind() -> ty.kind(tcx) as a 2-PR step thing

right, I think there are basically a set of mechanical (if not small) Prs of this nature

eddyb (Mar 06 2020 at 15:37, on Zulip):

so there's two main parts from this I'm seeing:

nikomatsakis (Mar 06 2020 at 15:37, on Zulip):

as I wrote, I hope that we get to the point where Ty<'tcx> is basically an alias for rustc_ty::Ty<TyCtxt<'tcx>>

eddyb (Mar 06 2020 at 15:37, on Zulip):

and we can probably do them relatively independently (except for the fact that they would likely conflict, diff-wise)

nikomatsakis (Mar 06 2020 at 15:37, on Zulip):

eddyb said:

so there's two main parts from this I'm seeing:

yeah, and the two are fairly independent

nikomatsakis (Mar 06 2020 at 15:38, on Zulip):

@matklad to circle back to your question, on the chalk + rust-analyzer side, I think those too will have to migrate some. I do think it makes sense to start merging chalk + rust-analyzer's type representation

eddyb (Mar 06 2020 at 15:38, on Zulip):

if it helps, we already do something like that with rustc_target, even if the abstraction looks nothing like Interner-generic types

nikomatsakis (Mar 06 2020 at 15:38, on Zulip):

my proposed end-point for now was that we had a library (let's call it rustc-ty) that is in-tree but also published periodically to crates.io with meaningful semver

nikomatsakis (Mar 06 2020 at 15:39, on Zulip):

so that chalk + rust-analyzer can rely on it without using sysroot

nikomatsakis (Mar 06 2020 at 15:39, on Zulip):

(and without using unstable attributes)

nikomatsakis (Mar 06 2020 at 15:39, on Zulip):

we were doing something similar with libsyntax, except that the semver was "every change is a breaking change", and I'd prefer to do better with this library

nikomatsakis (Mar 06 2020 at 15:39, on Zulip):

(I don't know if we still are)

eddyb (Mar 06 2020 at 15:39, on Zulip):

that is, rustc::ty::layout reexports rustc_layout::abi::* but shadows generic-over-typesystem parts of it like TyLayout with a type alias limited to rustc::ty::Ty

nikomatsakis (Mar 06 2020 at 15:40, on Zulip):

ah, interesting

nikomatsakis (Mar 06 2020 at 15:40, on Zulip):

I hadn't seen that pattern

nikomatsakis (Mar 06 2020 at 15:40, on Zulip):

or maybe I did and forgot :)

nikomatsakis (Mar 06 2020 at 15:40, on Zulip):

/me waits for someone to tell him that he reviewed it

centril (Mar 06 2020 at 15:40, on Zulip):

nikomatsakis said:

my proposed end-point for now was that we had a library (let's call it rustc-ty) that is in-tree but also published periodically to crates.io with meaningful semver

The name rustc_ty is already taken btw

nikomatsakis (Mar 06 2020 at 15:40, on Zulip):

that's fine :) I'm not wedded to the name.

eddyb (Mar 06 2020 at 15:40, on Zulip):

it would make even more sense if the module was rustc::ty::abi but that's a rename that has been pending for years, welp

nikomatsakis (Mar 06 2020 at 15:40, on Zulip):

it will contain more than types anyway

nikomatsakis (Mar 06 2020 at 15:41, on Zulip):

rustc-term...rustc-ir...?

eddyb (Mar 06 2020 at 15:41, on Zulip):

rustc-typesystem

nikomatsakis (Mar 06 2020 at 15:41, on Zulip):

"term" is PL jargon but kind of what we want...

centril (Mar 06 2020 at 15:41, on Zulip):

let's just rename the existing rustc_ty to something else :slight_smile:

nikomatsakis (Mar 06 2020 at 15:41, on Zulip):

also ok:)

eddyb (Mar 06 2020 at 15:41, on Zulip):

the term crate is a terminal library, that might get confusing :P

centril (Mar 06 2020 at 15:41, on Zulip):

"term" would be fine if you want to move MIR into it too

eddyb (Mar 06 2020 at 15:42, on Zulip):

I was actually hoping we could consider the typesystem a part of MIR

nikomatsakis (Mar 06 2020 at 15:42, on Zulip):

ok, time-check: 40 minutes

centril (Mar 06 2020 at 15:42, on Zulip):

nikomatsakis said:

(and without using unstable attributes)

Why this? I think we should be able to take advantage of unstable features and dogfood them

eddyb (Mar 06 2020 at 15:42, on Zulip):

but that's a different pie in the sky

nikomatsakis (Mar 06 2020 at 15:42, on Zulip):

centril said:

"term" would be fine if you want to move MIR into it too

so, this is actually a good point

nikomatsakis (Mar 06 2020 at 15:42, on Zulip):

I did not expet to move MIR into this, but

nikomatsakis (Mar 06 2020 at 15:42, on Zulip):

I expected MIr to depend on it

nikomatsakis (Mar 06 2020 at 15:42, on Zulip):

and perhaps use the same I: Interner scheme to be made independent

nikomatsakis (Mar 06 2020 at 15:42, on Zulip):

(this is more a "down the line" sort of thing)

eddyb (Mar 06 2020 at 15:42, on Zulip):

make it rustc-mir and then rename all internal crates to rustc_mir_something

matklad (Mar 06 2020 at 15:43, on Zulip):

with meaningful semver

But we should be explicit that the library is not considered perma-stable. Ie, we might abondon it in Rust 1.2019.0 and pursue something else.

nikomatsakis (Mar 06 2020 at 15:43, on Zulip):

Yes, I think we would be saying this:

nikomatsakis (Mar 06 2020 at 15:43, on Zulip):
centril (Mar 06 2020 at 15:43, on Zulip):

https://doc.rust-lang.org/nightly/nightly-rustc/rustc/ty/struct.Const.html is somewhat tied to MIR

nikomatsakis (Mar 06 2020 at 15:44, on Zulip):

Yeah, I am not sure the best way to sever the "const and MIR" connection,

nikomatsakis (Mar 06 2020 at 15:44, on Zulip):

chalk doesn't have consts yet :P but

oli (Mar 06 2020 at 15:44, on Zulip):

why are constants tied to MIR?

eddyb (Mar 06 2020 at 15:44, on Zulip):

eh, all the MIR is referred to by DefIds

nikomatsakis (Mar 06 2020 at 15:44, on Zulip):

right, this is what I hope

oli (Mar 06 2020 at 15:44, on Zulip):

ah

nikomatsakis (Mar 06 2020 at 15:45, on Zulip):

I was just reviewing ConstKind

nikomatsakis (Mar 06 2020 at 15:45, on Zulip):

so that seems fine

nikomatsakis (Mar 06 2020 at 15:45, on Zulip):

the chalk Interner trait, as it ahppens, also has a I::DefId associated type :)

centril (Mar 06 2020 at 15:45, on Zulip):

does seem fine

nikomatsakis (Mar 06 2020 at 15:45, on Zulip):

though we've been debating about whether to make more of them (e.g., StructDefId and the lke)

nikomatsakis (Mar 06 2020 at 15:45, on Zulip):

but that's a separate thing

oli (Mar 06 2020 at 15:45, on Zulip):

we do have the Promoted index, but I think that's surmountable

centril (Mar 06 2020 at 15:46, on Zulip):

but we will let you know when that happens and not bump major version gratuitously

I'm not a fan of providing any sort of stability / conservatism wrt. rustc internals; we should be able to change things as needed, although I don't expect that we will frequently break Ty internals (the query database we absolutely do however)

nikomatsakis (Mar 06 2020 at 15:46, on Zulip):

right either it becomes an associated type, or we just include the indices, I think that's the kind of thing we can tinker with to try and find the right place to draw the lines

centril (Mar 06 2020 at 15:47, on Zulip):

Similarly I think we should be able to use unstable features in this new library, and e.g. rustc_typeck if/when we start migrating that

nikomatsakis (Mar 06 2020 at 15:47, on Zulip):

centril said:

but we will let you know when that happens and not bump major version gratuitously

I'm not a fan of providing any sort of stability / conservatism wrt. rustc internals; we should be able to change things as needed, although I don't expect that we will frequently break Ty internals (the query database we absolutely do however)

This is probably worth talking about a bit more. I want rustc to be able to be divided up into more independent libraries that people can focus on. Having meaningful boundaries is an important part of that. It doesn't mean we can't change things, but at least knowing when we did so will be helpful.

eddyb (Mar 06 2020 at 15:47, on Zulip):

I think we can have an abstract type/trait system and even MIR bodies that hide a lot of the gnarly details behind associated types / methods

nikomatsakis (Mar 06 2020 at 15:48, on Zulip):

I would actually go further and say that if we are able to find meaningful and correct boundaries,

nikomatsakis (Mar 06 2020 at 15:48, on Zulip):

it won't be much work to maintain them

centril (Mar 06 2020 at 15:48, on Zulip):

nikomatsakis said:

centril said:

but we will let you know when that happens and not bump major version gratuitously

I'm not a fan of providing any sort of stability / conservatism wrt. rustc internals; we should be able to change things as needed, although I don't expect that we will frequently break Ty internals (the query database we absolutely do however)

This is probably worth talking about a bit more. I want rustc to be able to be divided up into more independent libraries that people can focus on. Having meaningful boundaries is an important part of that. It doesn't mean we can't change things, but at least knowing when we did so will be helpful.

Sure, but typically we know via PRs that we changed things?

nikomatsakis (Mar 06 2020 at 15:49, on Zulip):

Longer term, I'd like to be able to support people building more complex tooling for analyzing rust (think Libra's MIRAI) as well, eventually, and have them be able to use our libraries (think Roslyn)

matklad (Mar 06 2020 at 15:49, on Zulip):

Existence of such meaningful boundaries is an open question though :D But it makes sense to at least try

centril (Mar 06 2020 at 15:49, on Zulip):

Starting to maintain CHANGELOG.md and stuff feels like a hassle

eddyb (Mar 06 2020 at 15:49, on Zulip):

like MIR is relatively simple if you hide all of the builtins as pure-ish operations of various arities

nikomatsakis (Mar 06 2020 at 15:50, on Zulip):

I would want to put a line of "no unstable features"

nikomatsakis (Mar 06 2020 at 15:50, on Zulip):

in rustc-ty

nikomatsakis (Mar 06 2020 at 15:50, on Zulip):

basically, I think there's still some ongoing debate about the best "shape"

nikomatsakis (Mar 06 2020 at 15:50, on Zulip):

and I want this library to not take a side :)

nikomatsakis (Mar 06 2020 at 15:51, on Zulip):

i.e., should rustc dev be something where people can drop in with a stable compiler and participate in much the same way as any other project?

centril (Mar 06 2020 at 15:51, on Zulip):

I disagree with such a line; It's not something we do in the compiler, and if we start here it will definitely spread to other crates that depend on rustc_ty

nikomatsakis (Mar 06 2020 at 15:51, on Zulip):

It will spread to any crate that is going to be consumed by rust-analyzer and chalk :)

nikomatsakis (Mar 06 2020 at 15:52, on Zulip):

Until we decide firmly one way or the other, which I (personally) feel is too soon to do

centril (Mar 06 2020 at 15:52, on Zulip):

And presumably that number will increase, as rust-analyzer shares more and more code, disallowing us from testing unstable features in the compiler

eddyb (Mar 06 2020 at 15:52, on Zulip):

we could do some auditing and see which unstable features we care about (e.g. extern type is useful in making ty::List work) and which not so much

nikomatsakis (Mar 06 2020 at 15:52, on Zulip):

Unless we decide to require nightly, that's true.

nikomatsakis (Mar 06 2020 at 15:52, on Zulip):

But we can revisit this topic once we have more experience.

nikomatsakis (Mar 06 2020 at 15:52, on Zulip):

Personally I think that's a good trade, but I have felt differently in the past

nikomatsakis (Mar 06 2020 at 15:53, on Zulip):

(i.e., I think that dogfooding unstable features on rustc was super useful to rust during its development -- I'm less sure now, but I see the point)

nikomatsakis (Mar 06 2020 at 15:53, on Zulip):

but yeah what I hoped for in this meeting was that we could just not decide yet :)

centril (Mar 06 2020 at 15:54, on Zulip):

I'm fine with sticking with the status quo of not changing things in terms of unstable features

nikomatsakis (Mar 06 2020 at 15:54, on Zulip):

eddyb said:

we could do some auditing and see which unstable features we care about (e.g. extern type is useful in making ty::List work) and which not so much

yes, I'd be interested if there are unstable features we really need, though right now that stuff is abstracted through the Interner trait

eddyb (Mar 06 2020 at 15:54, on Zulip):

anyway before I lose this from my clipboard:

this typesystem vs/besides MIR reminds me I thought of abusing reusing the new mangling scheme as a def-path/type serialization system (e.g. between two users of rustc-ty/rustc-mir/whatever we're calling it), because it's already compact, has builtin compression, and it can handle some typesystem corner cases better than plain Rust syntax

centril (Mar 06 2020 at 15:54, on Zulip):

and discussing a change later

nikomatsakis (Mar 06 2020 at 15:54, on Zulip):

(time-check: 54 minutes, so we're basically done)

nikomatsakis (Mar 06 2020 at 15:55, on Zulip):

eddyb said:

anyway before I lose this from my clipboard:

I'm intrigued but not sure I'm fully following :)

centril (Mar 06 2020 at 15:55, on Zulip):

As for dogfooding, I think it's still very useful, both because it lets us real-world-test the benefits of a feature, but more importantly, it allows us to find bugs in a feature, since fewer people tend to use nightly these days

eddyb (Mar 06 2020 at 15:55, on Zulip):

it came up while I was discussing Ferrous Systems' "sealed Rust" with @James Munns

centril (Mar 06 2020 at 15:56, on Zulip):

("really need" is highly subjective; e.g. a bunch of ergonomics features would presumably answer that with "no", but it's still important to test those out, and they make development nicer.)

eddyb (Mar 06 2020 at 15:56, on Zulip):

long-term they would like if the frontend and backend could be split with a (presumably human-inspectable) IR in the middle

nikomatsakis (Mar 06 2020 at 15:56, on Zulip):

It is my impression that

nikomatsakis (Mar 06 2020 at 15:57, on Zulip):

does that sound correct?

eddyb (Mar 06 2020 at 15:57, on Zulip):

so it overlaps with "MIR abstracted out of rustc" ideas that adjacent to what we're talking about here

eddyb (Mar 06 2020 at 15:57, on Zulip):

@nikomatsakis I might want to bikeshed the name but other than that yeah :P

centril (Mar 06 2020 at 15:57, on Zulip):

Yep; @nikomatsakis you might perhaps want to include this:

So, a sketch for a plan in rustc (each step is a PR):
1. ty.kind -> ty.kind()
2. ty.kind()-> ty.kind(tcx)
3. Add a type alias and make kind work on I: Interner
4. Start using Ty<I> more (This is a lot of PRs)

eddyb (Mar 06 2020 at 15:57, on Zulip):

rustc-sema :D

oli (Mar 06 2020 at 15:57, on Zulip):

rust-sea

nikomatsakis (Mar 06 2020 at 15:58, on Zulip):

"sea"?

eddyb (Mar 06 2020 at 15:58, on Zulip):

seamantic?

nikomatsakis (Mar 06 2020 at 15:58, on Zulip):

oh dear

nikomatsakis (Mar 06 2020 at 15:58, on Zulip):

is that meant to be a pun? :)

oli (Mar 06 2020 at 15:58, on Zulip):

idk, just sounds like rustc, we can think about the backronym later

nikomatsakis (Mar 06 2020 at 15:58, on Zulip):

I kind of love it

centril (Mar 06 2020 at 15:58, on Zulip):

Now I get it...

centril (Mar 06 2020 at 15:58, on Zulip):

Let's... not :slight_smile:

eddyb (Mar 06 2020 at 15:58, on Zulip):

this is like grammer where I can't type "grammar" correctly now (without triple-checking myself)

nikomatsakis (Mar 06 2020 at 15:59, on Zulip):

ok, great, thanks everyone for attending :)

matklad (Mar 06 2020 at 15:59, on Zulip):

not forward compatible with sea of nodes

centril (Mar 06 2020 at 15:59, on Zulip):

Boring is better: rustc_ty it is? ;)

nikomatsakis (Mar 06 2020 at 15:59, on Zulip):

matklad said:

not forward compatible with sea of nodes

or very forwards compatible

eddyb (Mar 06 2020 at 16:00, on Zulip):

we'll be drowning in MIR

Wesley Wiser (Mar 06 2020 at 16:01, on Zulip):

Don't forget that when MIR was de-orbited, it was dropped into the sea ;) https://en.wikipedia.org/wiki/Deorbit_of_Mir

oli (Mar 06 2020 at 16:01, on Zulip):

the MIR dump library could be called pacific, because that's where the MIR was dumped

oli (Mar 06 2020 at 16:01, on Zulip):

damn! too slow

eddyb (Mar 06 2020 at 16:02, on Zulip):

@Wesley Wiser /me faints

Wesley Wiser (Mar 06 2020 at 16:02, on Zulip):

@oli Great minds think alike lol

centril (Mar 06 2020 at 16:02, on Zulip):

lol, I was also researching the deorbit of MIR :D

centril (Mar 06 2020 at 16:02, on Zulip):

I'm way too slow

eddyb (Mar 06 2020 at 16:03, on Zulip):

definitely nowhere near orbital velocity,

oli (Mar 06 2020 at 16:04, on Zulip):

groan

nikomatsakis (Mar 12 2020 at 11:35, on Zulip):

posted minutes from this meeting in compiler-team#255

Last update: Jun 04 2020 at 18:45UTC