From 651049d7e1f040db5e8d85f9f3fb11cfd512a9fa Mon Sep 17 00:00:00 2001
From: "Felix S. Klock II" <pnkfelix@pnkfx.org>
Date: Wed, 4 Dec 2019 20:25:40 +0100
Subject: [PATCH 1/2] REPL meeting minutes.
---
.../design-meeting/2019-11-29-repl-meeting.md | 80 +++++++++++++++++++
1 file changed, 80 insertions(+)
create mode 100644 content/minutes/design-meeting/2019-11-29-repl-meeting.md
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..0dcd8fd1
--- /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 swubmodule 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
From e00f8ad078206a4e5c150821a4a51ea91150628d Mon Sep 17 00:00:00 2001
From: Felix S Klock II <pnkfelix@pnkfx.org>
Date: Wed, 4 Dec 2019 20:42:44 +0100
Subject: [PATCH 2/2] Update
content/minutes/design-meeting/2019-11-29-repl-meeting.md
Co-Authored-By: Oliver Scherer <github35764891676564198441@oli-obk.de>
---
content/minutes/design-meeting/2019-11-29-repl-meeting.md | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/content/minutes/design-meeting/2019-11-29-repl-meeting.md b/content/minutes/design-meeting/2019-11-29-repl-meeting.md
index 0dcd8fd1..7f32e555 100644
--- a/content/minutes/design-meeting/2019-11-29-repl-meeting.md
+++ b/content/minutes/design-meeting/2019-11-29-repl-meeting.md
@@ -24,7 +24,7 @@ type: docs
- 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 swubmodule later.
+ 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