From 84c9044ceeee1030c0bae6ab43f69de4b024ebd7 Mon Sep 17 00:00:00 2001
From: Sean Griffin <sean@seantheprogrammer.com>
Date: Mon, 1 Aug 2016 10:15:43 -0400
Subject: [PATCH 1/2] Add a `compile_error!` macro to libstd

---
 text/0000-add-error-macro.md | 73 ++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)
 create mode 100644 text/0000-add-error-macro.md

diff --git a/text/0000-add-error-macro.md b/text/0000-add-error-macro.md
new file mode 100644
index 00000000000..833c7a54577
--- /dev/null
+++ b/text/0000-add-error-macro.md
@@ -0,0 +1,73 @@
+- Feature Name: compile\_error\_macro
+- Start Date: 2016-08-01
+- RFC PR: (leave this empty)
+- Rust Issue: (leave this empty)
+
+# Summary
+[summary]: #summary
+
+This RFC proposes adding a new macro to `libstd`, `compile_error!` which will
+unconditionally cause compilation to fail with the given error message when
+encountered.
+
+# Motivation
+[motivation]: #motivation
+
+Crates which work with macros or annotations such as `cfg` have no tools to
+communicate error cases in a meaningful way on stable. For example, given the
+following macro:
+
+```rust
+macro_rules! give_me_foo_or_bar {
+    (foo) => {};
+    (bar) => {};
+}
+```
+
+when invoked with `baz`, the error message will be `error: no rules expected the
+token baz`. In a real world scenario, this error may actually occur deep in a
+stack of macro calls, with an even more confusing error message. With this RFC,
+the macro author could provide the following:
+
+```rust
+macro_rules! give_me_foo_or_bar {
+    (foo) => {};
+    (bar) => {};
+    ($x:ident) => {
+        compile_error!("This macro only accepts `foo` or `bar`");
+    }
+}
+```
+
+When combined with attributes, this also provides a way for authors to validate
+combinations of features.
+
+```rust
+#[cfg(not(any(feature = "postgresql", feature = "sqlite")))]
+compile_error!("At least one backend must be used with this crate. \
+    Please specify `features = ["postgresql"]` or `features = ["sqlite"]`")
+```
+
+# Detailed design
+[design]: #detailed-design
+
+The span given for the failure should be the invocation of the `compile_error!`
+macro. The macro must take exactly one argument, which is a string literal. The
+macro will then call `span_err` with the provided message on the expansion
+context, and will not expand to any further code.
+
+# Drawbacks
+[drawbacks]: #drawbacks
+
+None
+
+# Alternatives
+[alternatives]: #alternatives
+
+Wait for the stabilization of procedural macros, at which point a crate could
+provide this functionality.
+
+# Unresolved questions
+[unresolved]: #unresolved-questions
+
+None

From a4418bc60e5d158390a165e65ef3b840e19f0ac2 Mon Sep 17 00:00:00 2001
From: Sean Griffin <sean@seantheprogrammer.com>
Date: Sun, 26 Feb 2017 15:51:38 -0500
Subject: [PATCH 2/2] Mention libcore instead of libstd

---
 text/0000-add-error-macro.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/text/0000-add-error-macro.md b/text/0000-add-error-macro.md
index 833c7a54577..f81af095b17 100644
--- a/text/0000-add-error-macro.md
+++ b/text/0000-add-error-macro.md
@@ -6,7 +6,7 @@
 # Summary
 [summary]: #summary
 
-This RFC proposes adding a new macro to `libstd`, `compile_error!` which will
+This RFC proposes adding a new macro to `libcore`, `compile_error!` which will
 unconditionally cause compilation to fail with the given error message when
 encountered.