|
| 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