diff --git a/content/minutes/design-meeting/2019-11-29-repl-meeting.md b/content/minutes/design-meeting/2019-11-29-repl-meeting.md new file mode 100644 index 00000000..7f32e555 --- /dev/null +++ b/content/minutes/design-meeting/2019-11-29-repl-meeting.md @@ -0,0 +1,80 @@ +--- +title: Read-Eval-Print-Loop (REPL) Extensions +type: docs +--- + +* [Zulip stream][] or read on the [Zulip archive][]. + +[Zulip stream]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-11-29/near/182183477 +[Zulip archive]: https://zulip-archive.rust-lang.org/131828tcompiler/72407designmeeting20191129.html + +# Agenda + +- Design doc: https://hackmd.io/GJokfI0wQ0i4SIgRbFTmfw + +- Big picture overview and questions + +- Essential changes to support REPL extensions + +# Big picture overview of design, and on-the-fly questions about it + +- Read (to an AST), Compile (AST to MIR), Eval (the MIR to a value), Print (the value). and Loop. +- 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? + - Answer 1: it has to be a tool; it depends on miri (or a fork of miri) + - Answer 2: it will be even less than a submodule (where a CI automatically files follow-up bugs): There + won't be any automatic filing of follow-up bugs (alexreg has said + they will handle maintenance manually); this is how miri and + clippy had initially started. It could become a submodule later. + +- Question: Does this mean if we (rustc developers) make breaking + changes to the compiler, we won't necessarily know, right? (Unless + explicit tests are added to rustc test suite.) +- Answer 1: Yes, but this is considered acceptable +- Answer 2: We can annotate relevant points in `rustc` with `// REPL` comments, + (e.g. to avoid them being made private or removed due to lack of use in rustc). + +- Design doc is split into (interleaved) essential and non-essential changes + +- For remainder of meeting, we reviewed each essential change at a high level, + and asked participatnts about their thoughts on that change. + +# Add an “interpreter mode” to the compiler interface + +- E.g. conditionally prevents dead user variable elimination. +- for example, when you do `let x = ...` in the repl, you want `x` to be kept around for the future repl inputs. +- Question: Are there other contexts where one would the dead-user-variable-elim optimization disable? +- Answer 1: Probably not +- Answer 2: Patching a running binary, perhaps + +- Question: What deos it mean to prepend local variables from previous evaluation sessions? +- Answer: For each live variable add `#[rustc_repl_alive] let var: type;` + +- Conclusion: No one objects to the addition of the "interpreter mode" flag + +# Slightly expanded miri API + + +- "Added insert_alloc method to machine, used by REPL for restoring memory when deserialising previous evaluation session." + - There was some debate about exactly where this would need to go, but + everyone agreed that the functionality was necessary. + +- "Added hooks before_statement, after_statement, before_stack_push (renamed existing method), after_stack_push, before_stack_pop, after_stack_pop (renamed existing method)." + - no objections to these additions + +- "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”." + - Question: What are the stack pop changes? + - Answer: 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). + - Question: Is the cleanup the running of destructors? + - Answer: more like clearing the local's memory + - no objections to this addition + +# Any remainning conerns from stake holders? + +We reviewed some vague misgivings with certain design decisions, but +no one had strong objections. + +Its not typical to accept changes like this for supporting other projects, +but it is also not unheard of (e.g. miri, priroda, clippy). + +Conclusion: people are generally okay with moving forward with what +alexreg laid out, at least the Essential portion