Skip to content

Commit 8a5c99b

Browse files
authored
Merge pull request #226 from pnkfelix/2019-11-29-repl-meeting
REPL meeting minutes.
2 parents 0cb5f28 + e00f8ad commit 8a5c99b

File tree

1 file changed

+80
-0
lines changed

1 file changed

+80
-0
lines changed
Lines changed: 80 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,80 @@
1+
---
2+
title: Read-Eval-Print-Loop (REPL) Extensions
3+
type: docs
4+
---
5+
6+
* [Zulip stream][] or read on the [Zulip archive][].
7+
8+
[Zulip stream]: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/design.20meeting.202019-11-29/near/182183477
9+
[Zulip archive]: https://zulip-archive.rust-lang.org/131828tcompiler/72407designmeeting20191129.html
10+
11+
# Agenda
12+
13+
- Design doc: https://hackmd.io/GJokfI0wQ0i4SIgRbFTmfw
14+
15+
- Big picture overview and questions
16+
17+
- Essential changes to support REPL extensions
18+
19+
# Big picture overview of design, and on-the-fly questions about it
20+
21+
- Read (to an AST), Compile (AST to MIR), Eval (the MIR to a value), Print (the value). and Loop.
22+
- 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?
23+
- Answer 1: it has to be a tool; it depends on miri (or a fork of miri)
24+
- Answer 2: it will be even less than a submodule (where a CI automatically files follow-up bugs): There
25+
won't be any automatic filing of follow-up bugs (alexreg has said
26+
they will handle maintenance manually); this is how miri and
27+
clippy had initially started. It could become a submodule later.
28+
29+
- Question: Does this mean if we (rustc developers) make breaking
30+
changes to the compiler, we won't necessarily know, right? (Unless
31+
explicit tests are added to rustc test suite.)
32+
- Answer 1: Yes, but this is considered acceptable
33+
- Answer 2: We can annotate relevant points in `rustc` with `// REPL` comments,
34+
(e.g. to avoid them being made private or removed due to lack of use in rustc).
35+
36+
- Design doc is split into (interleaved) essential and non-essential changes
37+
38+
- For remainder of meeting, we reviewed each essential change at a high level,
39+
and asked participatnts about their thoughts on that change.
40+
41+
# Add an “interpreter mode” to the compiler interface
42+
43+
- E.g. conditionally prevents dead user variable elimination.
44+
- for example, when you do `let x = ...` in the repl, you want `x` to be kept around for the future repl inputs.
45+
- Question: Are there other contexts where one would the dead-user-variable-elim optimization disable?
46+
- Answer 1: Probably not
47+
- Answer 2: Patching a running binary, perhaps
48+
49+
- Question: What deos it mean to prepend local variables from previous evaluation sessions?
50+
- Answer: For each live variable add `#[rustc_repl_alive] let var: type;`
51+
52+
- Conclusion: No one objects to the addition of the "interpreter mode" flag
53+
54+
# Slightly expanded miri API
55+
56+
57+
- "Added insert_alloc method to machine, used by REPL for restoring memory when deserialising previous evaluation session."
58+
- There was some debate about exactly where this would need to go, but
59+
everyone agreed that the functionality was necessary.
60+
61+
- "Added hooks before_statement, after_statement, before_stack_push (renamed existing method), after_stack_push, before_stack_pop, after_stack_pop (renamed existing method)."
62+
- no objections to these additions
63+
64+
- "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”."
65+
- Question: What are the stack pop changes?
66+
- 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).
67+
- Question: Is the cleanup the running of destructors?
68+
- Answer: more like clearing the local's memory
69+
- no objections to this addition
70+
71+
# Any remainning conerns from stake holders?
72+
73+
We reviewed some vague misgivings with certain design decisions, but
74+
no one had strong objections.
75+
76+
Its not typical to accept changes like this for supporting other projects,
77+
but it is also not unheard of (e.g. miri, priroda, clippy).
78+
79+
Conclusion: people are generally okay with moving forward with what
80+
alexreg laid out, at least the Essential portion

0 commit comments

Comments
 (0)