consistently separate footnotes from text

diff --git a/ralf/_posts/2017-06-06-MIR-semantics.md b/ralf/_posts/2017-06-06-MIR-semantics.md
index 4221da5dac3cbe058c4b9043b98f7fa091b84912..c7fbbc93aa282aa85595b263ea89389f53d1170f 100644 (file)
--- a/ralf/_posts/2017-06-06-MIR-semantics.md
+++ b/ralf/_posts/2017-06-06-MIR-semantics.md
@@ -176,3 +176,5 @@ There will be a tension between the semantics being "conservative enough" such t
 There will be back and forth between various alternatives, and in the end, hopefully there will be a compromise that everybody can accept.
 
 Happy safe hacking!
 There will be back and forth between various alternatives, and in the end, hopefully there will be a compromise that everybody can accept.
 
 Happy safe hacking!

+
+#### Footnotes

diff --git a/ralf/_posts/2017-06-09-mutexguard-sync.md b/ralf/_posts/2017-06-09-mutexguard-sync.md
index 456d289e7e9d2dda31397d975c71f9c7f2975474..2fe628a5e9e2a07bfc01c9a9cfb6b3c908fd5aa8 100644 (file)
--- a/ralf/_posts/2017-06-09-mutexguard-sync.md
+++ b/ralf/_posts/2017-06-09-mutexguard-sync.md
@@ -129,3 +129,4 @@ However, I hope I convinced you that if we don't act, errors like the one descri
 That said, such decisions are of course going to go through the usual RFC process.
 It's certainly possible that someone comes up with a compromise that preserves some of the usefulness of auto traits, without putting safety at risk.
 
 That said, such decisions are of course going to go through the usual RFC process.
 It's certainly possible that someone comes up with a compromise that preserves some of the usefulness of auto traits, without putting safety at risk.
 

+#### Footnotes

diff --git a/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md b/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md
index b07a334fbab553de8be01d95ea5099d0a15c6911..e3bcce54c632194b84fef35b087a89904c09d723 100644 (file)
--- a/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md
+++ b/ralf/_posts/2018-01-31-sharing-for-a-lifetime.md
@@ -156,3 +156,5 @@ I honestly don't know, but I had to think of this a while back when I read [this
 
 If you have any comments or thoughts on this, please join the [discussion in the Rust forums](https://internals.rust-lang.org/t/sharing-for-a-lifetime/6675)!
 I'd also be interested in feedback on how understandable this post is; this is my first attempt at translating research results into a blog post.
 
 If you have any comments or thoughts on this, please join the [discussion in the Rust forums](https://internals.rust-lang.org/t/sharing-for-a-lifetime/6675)!
 I'd also be interested in feedback on how understandable this post is; this is my first attempt at translating research results into a blog post.

+
+#### Footnotes

diff --git a/ralf/_posts/2018-07-13-arc-synchronization.md b/ralf/_posts/2018-07-13-arc-synchronization.md
index 033d56e0f1049f56e020d21c9771cf0193de98b3..a91f8b26d1ea8f0dbcc3b1873c1b61935ad5edfe 100644 (file)
--- a/ralf/_posts/2018-07-13-arc-synchronization.md
+++ b/ralf/_posts/2018-07-13-arc-synchronization.md
@@ -190,3 +190,5 @@ We were realistic enough to find [another bug]({% post_url 2017-06-09-mutexguard
 Hai and Jacques-Henri are currently working on remedying this particular simplification by extending the first RustBelt paper to also cover weak memory, and that's when they ran into this problem.
 
 **Update:** Turns out Servo has a [copy of `Arc`](https://doc.servo.org/servo_arc/index.html) that [has the same problem](https://github.com/servo/servo/issues/21186). So we got two bugs for the price of one. :)  **/Update**
 Hai and Jacques-Henri are currently working on remedying this particular simplification by extending the first RustBelt paper to also cover weak memory, and that's when they ran into this problem.
 
 **Update:** Turns out Servo has a [copy of `Arc`](https://doc.servo.org/servo_arc/index.html) that [has the same problem](https://github.com/servo/servo/issues/21186). So we got two bugs for the price of one. :)  **/Update**

+
+#### Footnotes