clarify boundary
[web.git] / ralf / _posts / 2017-06-06-MIR-semantics.md
index 6ddc745f6e76b186fc0d6a2a65dce33a7865926a..4221da5dac3cbe058c4b9043b98f7fa091b84912 100644 (file)
@@ -7,7 +7,7 @@ reddit: /rust/comments/6fqzub/exploring_mir_semantics_through_miri/
 It's now been two weeks since my internship started (two weeks already, can you believe it?).
 In other words, if I want to post "weekly or bi-weekly" updates, I better write one today ;) .
 
-As [already mentioned]({{ site.baseurl }}{% post_url
+As [already mentioned]({% post_url
 2017-05-23-internship-starting %}), the goal for this internship is to
 experiment with
 [unsafe code guidelines](https://internals.rust-lang.org/t/next-steps-for-unsafe-code-guidelines/3864)
@@ -140,7 +140,7 @@ So, did we find a bug?
 
 Well, maybe.
 Or maybe the rules we picked were just too conservative.
-At this point, I ended up in a lengthy discussion with @eddyb and @arielb1, who both know approximately infinitely more about LLVM and rustc than I do, and this is how the third option in the list arose:
+At this point, I ended up in a lengthy discussion with @eddyb and @arielb1 and some folks in #rustc, who know approximately infinitely more about LLVM and rustc than I do, and this is how the third option in the list arose:
 When performing `StorageLive` on a variable that already is live, forget the value that is currently in the local variable, but otherwise keep it live.
 This is consistent with what we have caught LLVM doing.
 It is hard to get any more definite than this.
@@ -151,7 +151,7 @@ This is not very satisfying, but lacking a more precise description of the LLVM
 The good news is that with this choice of MIR semantics, miri's test suite passes.
 We can thus be sure (well, insofar as the test suite is representative -- this will hopefully get better over time) that rustc produces code that follows our new rules.
 
-## And the moral of this story
+## And the Moral of This Story
 
 So, what did we learn?