Stream: t-compiler

Topic: design meeting 2019-11-29


pnkfelix (Nov 29 2019 at 14:52, on Zulip):

Hey @T-compiler/meeting , we'll be starting this week's design meeting in about 8 minutes

pnkfelix (Nov 29 2019 at 14:52, on Zulip):

this week's topic is the REPL extensions, compiler-team#213

pnkfelix (Nov 29 2019 at 14:59, on Zulip):

by the way, is @matklad around?

pnkfelix (Nov 29 2019 at 15:00, on Zulip):

i ask because one of the items on the repl design hackmd is a Virtual File System (VFS), which is something that is also used in rust-analyzer. I would like to know if the two pieces of functionality can/should be merged, if only as part of eventually "librarification"

matklad (Nov 29 2019 at 15:01, on Zulip):

yeah, I guess I am around

pnkfelix (Nov 29 2019 at 15:02, on Zulip):

@matklad okay, just wanted to check. I can ping you again when we get around to talking about VFS stuffin that case, so that you don't have to be actively watching this topic?

pnkfelix (Nov 29 2019 at 15:02, on Zulip):

anyway, it is time to start the meeting, @T-compiler/meeting ! (add yourself to the :wave: to show you're here.)

pnkfelix (Nov 29 2019 at 15:02, on Zulip):

lets open with five minutes for

pnkfelix (Nov 29 2019 at 15:02, on Zulip):

Announcements

pnkfelix (Nov 29 2019 at 15:05, on Zulip):

someone privately pointed out I should cc @Alexander Regueiro to make sure they know this meeting has started

matklad (Nov 29 2019 at 15:07, on Zulip):

/me relies that they have an errand to attend to

pnkfelix (Nov 29 2019 at 15:07, on Zulip):

@matklad okay, that's alright; we can discuss VFS stuff async if need be

matklad (Nov 29 2019 at 15:07, on Zulip):

I'll catch up with VFS discussion later, but my main question is: "why existing FileLoader interface is not enough for repl?"

pnkfelix (Nov 29 2019 at 15:07, on Zulip):

so at this point I have skimmed over the design hackmd but I have not reviewed the comments from compiler-team#213

pnkfelix (Nov 29 2019 at 15:10, on Zulip):

I'm not sure if @Alexander Regueiro is absent; Zulip's UI claims they were active "just now"

bjorn3 (Nov 29 2019 at 15:10, on Zulip):

The FileLoader::read_file returns a string, while the incr cache is binary data.

bjorn3 (Nov 29 2019 at 15:10, on Zulip):

So at least the current FileLoader interface is not enough for this usage.

simulacrum (Nov 29 2019 at 15:11, on Zulip):

A decent summary I think is that it's not entirely clear that everything is warranted - but it's also not clear that we should try to design perfectly here, or just accept the changes in a series of PRs with the thought being that ultimately it may not matter that much

pnkfelix (Nov 29 2019 at 15:11, on Zulip):

lets maybe start by doing a big picture overview and some questions

pnkfelix (Nov 29 2019 at 15:11, on Zulip):

@bjorn3 do you think you can represent @Alexander Regueiro 's POV in their absence?

pnkfelix (Nov 29 2019 at 15:12, on Zulip):

(by represent POV, I really just mean "correct mistakes I make in my attempt to present things.")

bjorn3 (Nov 29 2019 at 15:13, on Zulip):

@pnkfelix All I know about the design come from the HackMD file.

pnkfelix (Nov 29 2019 at 15:14, on Zulip):

oh okay. Well, I guess I will just have to press on ahead and hope I don't get too many details wrong

simulacrum (Nov 29 2019 at 15:14, on Zulip):

I can maybe help correct mistakes

oli (Nov 29 2019 at 15:14, on Zulip):

we can start with an easy thing: the miri engine memory and machine changes

pnkfelix (Nov 29 2019 at 15:14, on Zulip):

So the design doc lays out the big level structure of a REPL

pnkfelix (Nov 29 2019 at 15:15, on Zulip):

Read (to an AST), Compile (AST to MIR), Eval (the MIR to a value), Print (the value). and Loop.

pnkfelix (Nov 29 2019 at 15:16, on Zulip):

before we get into too many low level details, I want to start with a really basic question: Is this going to be a tool analogous to Miri, where check-in's that break it may not break CI immediately, but rather will just file follow-up bugs?

bjorn3 (Nov 29 2019 at 15:17, on Zulip):

it has to be, as it depends on miri

pnkfelix (Nov 29 2019 at 15:17, on Zulip):

or do we not know if it will even file follow-up bugs

simulacrum (Nov 29 2019 at 15:17, on Zulip):

I think the initial intent is even less - it won't be a submodule at all

simulacrum (Nov 29 2019 at 15:18, on Zulip):

(note also that current architecture is not a dependency on miri, but rather a fork of miri)

pnkfelix (Nov 29 2019 at 15:18, on Zulip):

so that means that if we (rustc developers) make breaking changes to the compiler, we won't necessarily know, right? Unless REPL developers add appropriate unit tests to rustc's test suite ?

oli (Nov 29 2019 at 15:18, on Zulip):

as it says in the design doc:

but for now I shall take it upon myself to observe such breakages in a semi-automated (e.g., cronjob) or manual fashion, and update my REPL repository in accordance, thus offloading any significant maintenance burden from the compiler team.

simulacrum (Nov 29 2019 at 15:18, on Zulip):

Correct. But I believe this is considered acceptable for now.

pnkfelix (Nov 29 2019 at 15:18, on Zulip):

okay

oli (Nov 29 2019 at 15:19, on Zulip):

that's how miri and clippy started essentially. Now that we have a good tooling setup, we can move to a submodule faster though

pnkfelix (Nov 29 2019 at 15:21, on Zulip):

okay. I suppose I am willing to trust that the pieces added to the compiler will be sufficiently well-documented that we shouldn't be stressing too hard about trying to grep across github for how they are used.

oli (Nov 29 2019 at 15:22, on Zulip):

We could use // REPL: foo comments on all of them

pnkfelix (Nov 29 2019 at 15:22, on Zulip):

the design doc provides a specific list of proposed modifications. Some of them are labelled non-essential; the others are presumably essential for REPL support

oli (Nov 29 2019 at 15:22, on Zulip):

occasionally things have been made private or removed because ppl saw they were unsued in rustc, so adding annotations helps

pnkfelix (Nov 29 2019 at 15:23, on Zulip):

so one way we could run this meeting is to just walk through all of the proposed essential changes, and make sure we are comfortable with just that minimal list

pnkfelix (Nov 29 2019 at 15:23, on Zulip):

(because if someone vetos an essential piece of this, then we really do need to make sure we loop @Alexander Regueiro into the conversation)

pnkfelix (Nov 29 2019 at 15:24, on Zulip):

so lets see, lets follow the order given in the doc

pnkfelix (Nov 29 2019 at 15:24, on Zulip):

Added an “interpreter mode” to the compiler interface.

pnkfelix (Nov 29 2019 at 15:25, on Zulip):

At first I didn't understand why this needed to be used to "prevent dead user variables from being optimised away." -- but I'm inferring that the problem there is when you do let x = ... in the repl, you want x to be kept around for the future repl inputs, right?

oli (Nov 29 2019 at 15:25, on Zulip):

yes

oli (Nov 29 2019 at 15:25, on Zulip):

otherwise the memory of the locals will have the wrong indices

oli (Nov 29 2019 at 15:26, on Zulip):

since the previous function's locals' memory is restored, if the MIR changes (except for adding more code), that's bad

pnkfelix (Nov 29 2019 at 15:26, on Zulip):

okay. Out of curiosity, are there other contexts where one would want that optimization to be disabled?

oli (Nov 29 2019 at 15:26, on Zulip):

probably not, this is a very specific use case

pnkfelix (Nov 29 2019 at 15:26, on Zulip):

e.g. when you run under a debugger, for example? But I guess that's handled already for user-visible variables anyway?

oli (Nov 29 2019 at 15:26, on Zulip):

any REPL design will need this, but I don't know of anything else that would want that

pnkfelix (Nov 29 2019 at 15:27, on Zulip):

I guess its a question only for when you need to support introspection

simulacrum (Nov 29 2019 at 15:27, on Zulip):

Patching a running binary, perhaps

pnkfelix (Nov 29 2019 at 15:27, on Zulip):

The reason I ask the question is to try to figure out if, in that case, there is a more general feature waiting to be exposed here.

oli (Nov 29 2019 at 15:28, on Zulip):

Not sure if mir-opt-level=0 will leave in the variables

pnkfelix (Nov 29 2019 at 15:28, on Zulip):

but for now, I think its fine to have this functionality under an Interpreter boolean flag.

bjorn3 (Nov 29 2019 at 15:28, on Zulip):

If you want to reintroduce a variable in the next eval, you would need to know which are being defined previously. You can then as well add something to keep the variables alive, like "next_repl_round(&[&var1, &var2])"

oli (Nov 29 2019 at 15:28, on Zulip):

that.... would work, too

pnkfelix (Nov 29 2019 at 15:29, on Zulip):

I suppose I should have asked this question up above: the design being propsed

pnkfelix (Nov 29 2019 at 15:29, on Zulip):

says "We then prepend local variables from previous evaluation sessions"

pnkfelix (Nov 29 2019 at 15:29, on Zulip):

is that mean to be interpreted as "we prepend MIR of the form let FOO = EXPR, N times", where N is the number of previous repl invocations?

oli (Nov 29 2019 at 15:30, on Zulip):

I guess, but additionally some attributes are added

pnkfelix (Nov 29 2019 at 15:30, on Zulip):

I was personally wondering whether it would make more sense to have the generated closure take parameters

pnkfelix (Nov 29 2019 at 15:31, on Zulip):

and then you feed in the computed values

bjorn3 (Nov 29 2019 at 15:31, on Zulip):

I think it is more like for each live variable add "#[rustc_repl_alive] let var: type;"

pnkfelix (Nov 29 2019 at 15:31, on Zulip):

but this is just a design detail

bjorn3 (Nov 29 2019 at 15:31, on Zulip):

taking parameters would be problematic with stack pinning, i guess

oli (Nov 29 2019 at 15:31, on Zulip):

whether you have arguments or locals makes little difference, in MIR everything is a local

oli (Nov 29 2019 at 15:32, on Zulip):

yea, also references to other locals would be a bit messy

pnkfelix (Nov 29 2019 at 15:32, on Zulip):

anyway, the design doc points out other things that are guarded by the Intepreter flag: "a REPL-only intrinsic for casting a value to dyn Debug", and a guard to ensure things meant to be interpreter-only stay interpreter-only.

pnkfelix (Nov 29 2019 at 15:33, on Zulip):

whether you have arguments or locals makes little difference, in MIR everything is a local

well, the ancient REPL we had prior to Rust 1.0 did something pretty dumb where it really did prepend the entirety of all the previous REPL inputs to the curent input.

pnkfelix (Nov 29 2019 at 15:33, on Zulip):

so you did O(N) work on each repl invocation.

oli (Nov 29 2019 at 15:34, on Zulip):

I'm not quite sure why that intrinsic is needed. I believe we could generate a bit of MIR that does the downcasting directly, but I'm probably missing something

bjorn3 (Nov 29 2019 at 15:34, on Zulip):

https://github.com/murarth/rusti?

oli (Nov 29 2019 at 15:34, on Zulip):

so you did O(N) work on each repl invocation.

that doesn't happen, computation starts at the new commands

pnkfelix (Nov 29 2019 at 15:34, on Zulip):

https://github.com/murarth/rusti?

the one I'm thinking of ... used to be part of the project itself (I think).

oli (Nov 29 2019 at 15:34, on Zulip):

that's why the memory of the previous locals needs to be restored

pnkfelix (Nov 29 2019 at 15:34, on Zulip):

okay.

pnkfelix (Nov 29 2019 at 15:35, on Zulip):

so far, it seems like no one (including me) is saying that an Interpreter boolean flag is a terrible thing

pnkfelix (Nov 29 2019 at 15:35, on Zulip):

so I think we can safely move to the next essential addition.

pnkfelix (Nov 29 2019 at 15:36, on Zulip):

built-in attribute for marking the “user fn” and a TyCtxt query for locating and caching it’s DefId

Alexander Regueiro (Nov 29 2019 at 15:36, on Zulip):

Apologies, all. I've been very unwell today, and my whole sense of time and schedule seems to have gone out the window!

pnkfelix (Nov 29 2019 at 15:36, on Zulip):

although wait, both bullets under that are marked non-essential

Alexander Regueiro (Nov 29 2019 at 15:36, on Zulip):

I'm glad you've managed to proceed without me, it seems...

bjorn3 (Nov 29 2019 at 15:36, on Zulip):

I'm not quite sure why that intrinsic is needed. I believe we could generate a bit of MIR that does the downcasting directly, but I'm probably missing something

That is not possible at the syntax level when the closure is generated.

pnkfelix (Nov 29 2019 at 15:36, on Zulip):

@Alexander Regueiro we're currently walking through just the essential items

oli (Nov 29 2019 at 15:37, on Zulip):

oh right, we don't generate MIR

pnkfelix (Nov 29 2019 at 15:37, on Zulip):

am I right in inferring that the attribute for marking the user fn is actually non-essential ?

Alexander Regueiro (Nov 29 2019 at 15:37, on Zulip):

yeah, just looking through the backlog quickly now :-)

simulacrum (Nov 29 2019 at 15:37, on Zulip):

that's my impression, though it's certainly helpful

oli (Nov 29 2019 at 15:37, on Zulip):

but at the syntax level you could just generate let x: &dyn Debug = &foo; right?

simulacrum (Nov 29 2019 at 15:37, on Zulip):

it's also a very minimal addition (i.e., basically just reserving the attribute or so)

pnkfelix (Nov 29 2019 at 15:38, on Zulip):

okay

oli (Nov 29 2019 at 15:38, on Zulip):

about the attribute, why can't we reuse the tcx.entry_fn(LOCAL_CRATE) ?

pnkfelix (Nov 29 2019 at 15:38, on Zulip):

still lets move along just to make sure we get through the list of essential things

oli (Nov 29 2019 at 15:38, on Zulip):

is the closure inside main necessary or could the code also just be inside main?

pnkfelix (Nov 29 2019 at 15:38, on Zulip):

(because we are at the 38 minute mark, and I'd ideally like for us to at least ensure that we finish the Essentials list and then double-check if we're happy with the list of changes.)

pnkfelix (Nov 29 2019 at 15:39, on Zulip):

so the next item is a set of Miri changes

pnkfelix (Nov 29 2019 at 15:39, on Zulip):

Slightly expanded miri API

pnkfelix (Nov 29 2019 at 15:39, on Zulip):

"Added insert_alloc method to machine, used by REPL for restoring memory when deserialising previous evaluation session."

oli (Nov 29 2019 at 15:39, on Zulip):

makes total sense, let's add it and leave a comment that it's for the REPL

pnkfelix (Nov 29 2019 at 15:39, on Zulip):

I take it this is what you were talking about above, @oli ?

oli (Nov 29 2019 at 15:40, on Zulip):

I believe it's needed to restore a static's memory?

Alexander Regueiro (Nov 29 2019 at 15:40, on Zulip):

Sure

pnkfelix (Nov 29 2019 at 15:40, on Zulip):

or is it for the incremental support, where the REPL wants its memory restored across distinct sessions of the REPL itself?

oli (Nov 29 2019 at 15:41, on Zulip):

well, the regular locals must be in InterpCx memory, otherwise you can't modify it

bjorn3 (Nov 29 2019 at 15:41, on Zulip):

Can machine.alloc_map.insert be used instead? Or is this about preserving the AllocId?

Alexander Regueiro (Nov 29 2019 at 15:41, on Zulip):

well, the insert_alloc is needed to restore Miri's dynamic memory, AFAIR

oli (Nov 29 2019 at 15:41, on Zulip):

huh?

oli (Nov 29 2019 at 15:41, on Zulip):

you can't mutate that memory

oli (Nov 29 2019 at 15:42, on Zulip):

everything inside alloc_map is forever frozen

oli (Nov 29 2019 at 15:42, on Zulip):

so in order to keep AllocIds to constants and statics working, this needs to be somewhere

oli (Nov 29 2019 at 15:43, on Zulip):

while it could be in InterpCx memory, that would just unnecessarily complicate things

bjorn3 (Nov 29 2019 at 15:43, on Zulip):

That's only the tcx.alloc_map, right? I meant the alloc_map of the machine.

Alexander Regueiro (Nov 29 2019 at 15:43, on Zulip):

yes, I'm talking of that too

oli (Nov 29 2019 at 15:44, on Zulip):

ah, so it's being pushed into the Memory

Alexander Regueiro (Nov 29 2019 at 15:44, on Zulip):

this

Alexander Regueiro (Nov 29 2019 at 15:44, on Zulip):

pub type MiriMemory<'mir, 'tcx> = Memory<'mir, 'tcx, Evaluator<'tcx>>;

oli (Nov 29 2019 at 15:44, on Zulip):

can't you access the Memory directly?

Alexander Regueiro (Nov 29 2019 at 15:44, on Zulip):

(in my fork of miri)

oli (Nov 29 2019 at 15:44, on Zulip):

why does it need a machine function?

oli (Nov 29 2019 at 15:45, on Zulip):

(also why is this restoring done per alloc instead of "just" implementing RustcSerialize and RustcDeserialize on Memory?

oli (Nov 29 2019 at 15:46, on Zulip):

btw everyone here's the Memory type we're talking about: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir/interpret/struct.Memory.html

Alexander Regueiro (Nov 29 2019 at 15:46, on Zulip):

the alloc_map field is pub(super)

Alexander Regueiro (Nov 29 2019 at 15:46, on Zulip):

so basically, yes

Alexander Regueiro (Nov 29 2019 at 15:47, on Zulip):

so, re having Memory itself serialisable... there was a reason, let me recall

oli (Nov 29 2019 at 15:47, on Zulip):

ok, so it would need a public function on Memory to insert entries with specific ids

oli (Nov 29 2019 at 15:47, on Zulip):

makes sense

Alexander Regueiro (Nov 29 2019 at 15:47, on Zulip):

right

pnkfelix (Nov 29 2019 at 15:47, on Zulip):

so we don't need to finalize the details here now

Alexander Regueiro (Nov 29 2019 at 15:47, on Zulip):

possibly with some behaviour like insert_same. I wasn't sure.

Alexander Regueiro (Nov 29 2019 at 15:47, on Zulip):

yes, good point @pnkfelix. let's not get bogged down in details..

oli (Nov 29 2019 at 15:47, on Zulip):

right

pnkfelix (Nov 29 2019 at 15:48, on Zulip):

the broader point is, it sounds like @oli agrees that some change is needed here to accomplish this

oli (Nov 29 2019 at 15:48, on Zulip):

yes

pnkfelix (Nov 29 2019 at 15:48, on Zulip):

but it sounds like an appropriate change can be worked out between you all

oli (Nov 29 2019 at 15:48, on Zulip):

we can do the serialize vs manual discussion elsewhere

pnkfelix (Nov 29 2019 at 15:48, on Zulip):

likewise, there is a family of API changes described as

Alexander Regueiro (Nov 29 2019 at 15:48, on Zulip):

BTW, the closure in main is needed to have an type-inferred return value :-)

pnkfelix (Nov 29 2019 at 15:48, on Zulip):

Added hooks before_statement, after_statement, before_stack_push (renamed existing method), after_stack_push, before_stack_pop, after_stack_pop (renamed existing method).

Alexander Regueiro (Nov 29 2019 at 15:49, on Zulip):

which for obvious reasons is desirable in a REPL

oli (Nov 29 2019 at 15:49, on Zulip):

yea these can just happen,

pnkfelix (Nov 29 2019 at 15:49, on Zulip):

I assume these hooks are fine

pnkfelix (Nov 29 2019 at 15:49, on Zulip):

and then there's this:

Alexander Regueiro (Nov 29 2019 at 15:49, on Zulip):

they seem... consistent?

pnkfelix (Nov 29 2019 at 15:49, on Zulip):

Made stack pop behaviour more flexible, so as to allow the cleanup flag to be independent of wherever the action is null or a “goto”.

Alexander Regueiro (Nov 29 2019 at 15:49, on Zulip):

hopefully @oli is okay with them

oli (Nov 29 2019 at 15:49, on Zulip):

I think there were recent changes about the cleanup that may make that obsolete

Alexander Regueiro (Nov 29 2019 at 15:49, on Zulip):

the latter is "even more" necessary, yes

pnkfelix (Nov 29 2019 at 15:49, on Zulip):

Can you describe the stack pop changes, @Alexander Regueiro ?

Alexander Regueiro (Nov 29 2019 at 15:49, on Zulip):

oh right

oli (Nov 29 2019 at 15:49, on Zulip):

the the Machine changes are good

oli (Nov 29 2019 at 15:50, on Zulip):

BTW, the closure in main is needed to have an type-inferred return value :-)

couldn't you also generate let value = expr; where the expr is the last statement by the user?

Alexander Regueiro (Nov 29 2019 at 15:51, on Zulip):

@pnkfelix basically, it's important that we can exit a block / pop off the stack but still not perform cleanup (so as to be able to serialise the values of the locals when execution is done).

pnkfelix (Nov 29 2019 at 15:51, on Zulip):

/me idly wonders if let value = expr; gets into problems with r-value lifetime rules

Alexander Regueiro (Nov 29 2019 at 15:51, on Zulip):

that wasn't possible before.

Alexander Regueiro (Nov 29 2019 at 15:51, on Zulip):

but perhaps it is now, even without my changes, if miri has been modified since.

Alexander Regueiro (Nov 29 2019 at 15:51, on Zulip):

either way, something of that ilk is needed.

pnkfelix (Nov 29 2019 at 15:51, on Zulip):

ah I see, the cleanup here is the running of destructors and what not?

oli (Nov 29 2019 at 15:52, on Zulip):

probably not running destructors, but clearing the locals's memory

oli (Nov 29 2019 at 15:52, on Zulip):

makes sense that we need to do something there

pnkfelix (Nov 29 2019 at 15:52, on Zulip):

okay then. So it sounds like @oli is cool with that too

pnkfelix (Nov 29 2019 at 15:52, on Zulip):

the remaining bullet in the design doc is marked Non-Essential

oli (Nov 29 2019 at 15:53, on Zulip):

modulo details but we'll figure sth out that works

Alexander Regueiro (Nov 29 2019 at 15:53, on Zulip):

@oli yes, that would be acceptable, I think, but would involve some more manipulation of the AST which seemed unnecessary. (that is, this seemed the simpler solution, at no noteworthy performance hit.)

pnkfelix (Nov 29 2019 at 15:53, on Zulip):

so maybe, given that we are at the 53 minute mark, it is a good time to take stock with what we've discussed so far

pnkfelix (Nov 29 2019 at 15:53, on Zulip):

it seems like these changes are indeed relatively non-invasive

Alexander Regueiro (Nov 29 2019 at 15:53, on Zulip):

cool

pnkfelix (Nov 29 2019 at 15:53, on Zulip):

and the main active stake-holder present (@oli ) is agreeable to them

bjorn3 (Nov 29 2019 at 15:54, on Zulip):

pnkfelix basically, it's important that we can exit a block / pop off the stack but still not perform cleanup (so as to be able to serialise the values of the locals when execution is done).

Quoting myself

If you want to reintroduce a variable in the next eval, you would need to know which are being defined previously. You can then as well add something to keep the variables alive, like "next_repl_round(&[&var1, &var2])"

next_repl_round could just abort execution, so that the values can get saved without running the destructors.

Alexander Regueiro (Nov 29 2019 at 15:54, on Zulip):

@bjorn3 that's a bit awkward, because they can get destructed as soon as the block ends (not even the fn) which is before the "user fn" ends even

pnkfelix (Nov 29 2019 at 15:55, on Zulip):

but I also know from the comment thread that @simulacrum had some concerns, largely about wanting to be sure, before we commit, that this design was the one we want to commit to/

oli (Nov 29 2019 at 15:55, on Zulip):

well some of the design points are universal

oli (Nov 29 2019 at 15:56, on Zulip):

any REPL would need them

bjorn3 (Nov 29 2019 at 15:56, on Zulip):

@Alexander Regueiro When taking a reference to them as arguments, the variables must be kept alive.

Alexander Regueiro (Nov 29 2019 at 15:56, on Zulip):

yes. we ha a number of discussions before this meeting (a few weeks ago) and I even shared my prototype REPL repo with him. he basically said "I understand why you took these design decisions, I'm not 100% convinced I agree with all of them, but equally I don't have major objections at this point in time". that was a couple of weeks ago at least. I hope I'm not misrepresenting his view, and it hasn't changed much since then, but yeah...

pnkfelix (Nov 29 2019 at 15:56, on Zulip):

I think the main point was from this comment:

it's a bit unusual for us to be accepting changes to make other projects viable into the tree proper

Alexander Regueiro (Nov 29 2019 at 15:56, on Zulip):

did Niko end up leaving notes on his thoughts about the design doc? I know he told me he would... but no worries if not.

Alexander Regueiro (Nov 29 2019 at 15:57, on Zulip):

yes

Alexander Regueiro (Nov 29 2019 at 15:57, on Zulip):

and we all agreed it's far from typical, but (I think) not unheard of, e.g. miri in its earlier days, priroda, clippy..

pnkfelix (Nov 29 2019 at 15:57, on Zulip):

right

pnkfelix (Nov 29 2019 at 15:57, on Zulip):

and I think its fair to say that the changes, as described here, all sounds reasonable to the people present here

Alexander Regueiro (Nov 29 2019 at 15:58, on Zulip):

@bjorn3 oh right, I see now. well yes, that could work. I am personally of the opinion this is a cleaner solution though.

pnkfelix (Nov 29 2019 at 15:58, on Zulip):

did Niko end up leaving notes on his thoughts about the design doc? I know he told me he would... but no worries if not.

I don't know if they had time, to be honest

Alexander Regueiro (Nov 29 2019 at 15:58, on Zulip):

yep, understandable @pnkfelix

Alexander Regueiro (Nov 29 2019 at 15:58, on Zulip):

he can always leave post-hoc comments, no problem.

pnkfelix (Nov 29 2019 at 15:59, on Zulip):

Anyway, all of my comments at the end here are generally just to say that it seems like people are generally okay with moving forward with what you've laid out, at least the Essential portion

Alexander Regueiro (Nov 29 2019 at 15:59, on Zulip):

(he'd done an initial review of the design doc some weeks ago, he told me, and we only discussed some very minor points. but obviously we can discuss any comments/concerns of his after he returns, if he has them.)

pnkfelix (Nov 29 2019 at 15:59, on Zulip):

I didn't allocate time to discuss the Non-Essentials.

Alexander Regueiro (Nov 29 2019 at 16:00, on Zulip):

okay. there was some discussion of the intrinsic fn though... briefly?

oli (Nov 29 2019 at 16:00, on Zulip):

I opened https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/REPL.3A.20dyn.20Debug.20intrinsic for that

Alexander Regueiro (Nov 29 2019 at 16:00, on Zulip):

I replied to oli-obk's note on that on the design doc too.

oli (Nov 29 2019 at 16:00, on Zulip):

we can continue there

Alexander Regueiro (Nov 29 2019 at 16:00, on Zulip):

I hope there's agreement that something of that sort is needed, roughly speaking

oli (Nov 29 2019 at 16:00, on Zulip):

Mostly it's me not getting it ^^

Alexander Regueiro (Nov 29 2019 at 16:00, on Zulip):

ah okay

Alexander Regueiro (Nov 29 2019 at 16:00, on Zulip):

that's fine

Alexander Regueiro (Nov 29 2019 at 16:01, on Zulip):

the VFS thing can be discussed later. basically, it's an optimisation. something initially suggested by @Zoxc, whom it might be good to get involved at some level.

pnkfelix (Nov 29 2019 at 16:01, on Zulip):

My main concern is one I alluded to at the beginning: Whether people trying to hack the compiler will encounter some piece of Interpreter-support functionality, and then get frustrated if they cannot find where it is used.

Alexander Regueiro (Nov 29 2019 at 16:01, on Zulip):

but the idea is of course to do PRs for the "essential" bits first.

pnkfelix (Nov 29 2019 at 16:01, on Zulip):

But we've already outlined ways to mitigate that

Alexander Regueiro (Nov 29 2019 at 16:01, on Zulip):

and then more discussion on the non-essential parts can either be discussed in those PRs, special issues, or another design meeting.

pnkfelix (Nov 29 2019 at 16:02, on Zulip):

Sounds great

Alexander Regueiro (Nov 29 2019 at 16:02, on Zulip):

okay, glad to hear @pnkfelix

pnkfelix (Nov 29 2019 at 16:02, on Zulip):

Does anyone have any questions?

pnkfelix (Nov 29 2019 at 16:02, on Zulip):

Doesn't look like it. I'm going to declare this meeting to be over, then.

Alexander Regueiro (Nov 29 2019 at 16:03, on Zulip):

@bjorn3 I have some time free now after the meeting (if I can keep my focus!), so if you want to stay and discuss alternative Cranelift backend stuff, for a bit, that's cool with me.

pnkfelix (Nov 29 2019 at 16:03, on Zulip):

Thanks to @T-compiler/meeting for attending. And thanks to @Alexander Regueiro for all the work you've put into this

Alexander Regueiro (Nov 29 2019 at 16:03, on Zulip):

Thanks for your time, everyone.

pnkfelix (Nov 29 2019 at 16:03, on Zulip):

(both in source code and in explanatory docs)

Alexander Regueiro (Nov 29 2019 at 16:03, on Zulip):

Great we could sort this out. :-)

Alexander Regueiro (Nov 29 2019 at 16:03, on Zulip):

No problem @pnkfelix

bjorn3 (Nov 29 2019 at 16:04, on Zulip):

@Alexander Regueiro Can we talk in about an hour? It's time for diner.

Alexander Regueiro (Nov 29 2019 at 16:04, on Zulip):

Cheerio.

Alexander Regueiro (Nov 29 2019 at 16:05, on Zulip):

@bjorn3 that should work, I think. I'll create a separate topic for it. see you at 5:00 GMT?

oli (Nov 29 2019 at 16:05, on Zulip):

I also opened https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/REPL.3A.20closure.20vs.20locals for the closure user_fn discussion

Alexander Regueiro (Nov 29 2019 at 16:06, on Zulip):

okay, sounds fair

Alexander Regueiro (Nov 29 2019 at 17:34, on Zulip):

@pnkfelix BTW, would you mind leaving a brief comment on my design doc issue at some point, just so people can see that we've approved the non-essential points? Just as a sort of indication we're moving forward with PRs, and that non-essential points are also being discussed now, but won't have PRs in the immediate future. :-)

pnkfelix (Nov 29 2019 at 20:10, on Zulip):

@Alexander Regueiro even better: someone (maybe me) will be posting a summary of today's meeting on the compiler-team site.

Alexander Regueiro (Nov 29 2019 at 20:13, on Zulip):

@pnkfelix ah, super. cheers.

Last update: Dec 12 2019 at 00:45UTC