Merge pull request #336 from Havvy/warning-css

Warning css

Author: QuietMisdreavus

src/expressions/method-call-expr.md

@@ -81,13 +81,17 @@ generic methods or traits are considered the same, then it is a compiler
 error. These cases require a [disambiguating function call syntax] for method
 and function invocation.
 
-> Warning: For [trait objects], if there is an inherent method of the same name
-> as a trait method, it will give a compiler error when trying to call the
-> method in a method call expression. Instead, you can call the method using
-> [disambiguating function call syntax], in which case it calls the trait
-> method, not the inherent method. There is no way to call the inherent method.
-> Just don't define inherent methods on trait objects with the same name a trait
-> method and you'll be fine.
+<div class="warning">
+
+***Warning:*** For [trait objects], if there is an inherent method of the same
+name as a trait method, it will give a compiler error when trying to call the
+method in a method call expression. Instead, you can call the method using
+[disambiguating function call syntax], in which case it calls the trait
+method, not the inherent method. There is no way to call the inherent method.
+Just don't define inherent methods on trait objects with the same name a trait
+method and you'll be fine.
+
+</div>
 
 [IDENTIFIER]: identifiers.html
 [visible]: visibility-and-privacy.html

src/theme/reference.css

@@ -77,3 +77,47 @@ the parenthetical. So for this example, you'd use
 .parenthetical {
     white-space: nowrap;
 }
+
+/*
+Warnings and notes:
+
+Write the <div>s on their own line. E.g.
+
+<div class="warning">
+
+Warning: This is bad!
+
+</div>
+*/
+main .warning p {
+    padding: 10px 20px;
+    margin: 20px 0;
+}
+
+main .warning p::before {
+    content: "⚠️ ";
+}
+
+.light main .warning p,
+.rust main .warning p {
+    border: 2px solid red;
+    background: #ffcece;
+}
+
+.rust main .warning p {
+    /* overrides previous declaration */
+    border-color: #961717;
+}
+
+.coal main .warning p,
+.navy main .warning p,
+.ayu main .warning p {
+    background: #542626
+}
+
+/* Make the links higher contrast on dark themes */
+.coal main .warning p a,
+.navy main .warning p a,
+.ayu main .warning p a {
+    color: #80d0d0
+}

src/trait-bounds.md

@@ -134,9 +134,6 @@ fn call_on_ref_zero<F>(f: F) where F: for<'a> Fn(&'a i32) {
 }
 ```
 
-> Warning: lifetime bounds are allowed on lifetimes in a `for` binder, but have
-> no effect: `for<'a, 'b: 'a>` is no different to `for<'a, 'b>`.
-
 [LIFETIME_OR_LABEL]: tokens.html#lifetimes-and-loop-labels
 [_TraitPath_]: paths.html
 [`Sized`]: special-types-and-traits.html#sized

src/type-layout.md

@@ -233,13 +233,17 @@ the default `enum` size and alignment for the target platform's C ABI.
 > really a "best guess". In particular, this may be incorrect when the C code
 > of interest is compiled with certain flags.
 
-> Warning: There are crucial differences between an `enum` in the C language and
-> Rust's C-like enumerations with this representation. An `enum` in  C is
-> mostly a `typedef` plus some named constants; in other words, an object of an
-> `enum` type can hold any integer value. For example, this is often used for
-> bitflags in `C`. In contrast, Rust’s C-like enumerations can only legally hold
-> the discriminant values, everything else is undefined behaviour. Therefore,
-> using a C-like enumeration in FFI to model a C `enum` is often wrong.
+<div class="warning">
+
+Warning: There are crucial differences between an `enum` in the C language and
+Rust's C-like enumerations with this representation. An `enum` in  C is
+mostly a `typedef` plus some named constants; in other words, an object of an
+`enum` type can hold any integer value. For example, this is often used for
+bitflags in `C`. In contrast, Rust’s C-like enumerations can only legally hold
+the discriminant values, everything else is undefined behaviour. Therefore,
+using a C-like enumeration in FFI to model a C `enum` is often wrong.
+
+</div>
 
 It is an error for [zero-variant enumerations] to have the `C` representation.
 
@@ -290,9 +294,13 @@ padding bytes and forcing the alignment of the type to `1`.
 The `align` and `packed` representations cannot be applied on the same type and
 a `packed` type cannot transitively contain another `align`ed type.
 
-> Warning: Dereferencing an unaligned pointer is [undefined behaviour] and it is
-> possible to [safely create unaligned pointers to `packed` fields][27060].
-> Like all ways to create undefined behavior in safe Rust, this is a bug.
+<div class="warning">
+
+***Warning:*** Dereferencing an unaligned pointer is [undefined behaviour] and
+it is possible to [safely create unaligned pointers to `packed` fields][27060].
+Like all ways to create undefined behavior in safe Rust, this is a bug.
+
+</div>
 
 [`align_of_val`]: ../std/mem/fn.align_of_val.html
 [`size_of_val`]: ../std/mem/fn.size_of_val.html

src/types.md

@@ -580,10 +580,13 @@ if the sets of auto traits are the same and the lifetime bounds are the same.
 For example, `dyn Trait + Send + UnwindSafe` is the same as
 `dyn Trait + Unwindsafe + Send`.
 
-> Warning: With two trait object types, even when the complete set of traits is
-> the same, if the base traits differ, the type is different. For example,
-> `dyn Send + Sync` is a different type from `dyn Sync + Send`. See
-> [issue 33140].
+<div class="warning">
+
+***Warning:*** With two trait object types, even when the complete set of traits
+is the same, if the base traits differ, the type is different. For example,
+`dyn Send + Sync` is a different type from `dyn Sync + Send`. See [issue 33140].
+
+</div>
 
 Due to the opaqueness of which concrete type the value is of, trait objects are
 [dynamically sized types]. Like all