Fix inconsistent heading depth

This fixes several pages that did not start with a level one heading.

The unsafe page also had a weird use of level five headings. It's not
entirely clear to me why. The page originally used a list, so I have
switched it back to that. If in the future we decide to add more content
to one of these items, it can be broken out into a separate section like
integer overflow did.

Author: ehuss

src/behavior-considered-undefined.md

@@ -1,5 +1,5 @@
 r[undefined]
-## Behavior considered undefined
+# Behavior considered undefined
 
 r[undefined.general]
 Rust code is incorrect if it exhibits any of the behaviors in the following
@@ -92,12 +92,12 @@ r[undefined.runtime]
 > Undefined behavior affects the entire program. For example, calling a function in C that exhibits undefined behavior of C means your entire program contains undefined behaviour that can also affect the Rust code. And vice versa, undefined behavior in Rust can cause adverse affects on code executed by any FFI calls to other languages.
 
 r[undefined.pointed-to]
-### Pointed-to bytes
+## Pointed-to bytes
 
 The span of bytes a pointer or reference "points to" is determined by the pointer value and the size of the pointee type (using `size_of_val`).
 
 r[undefined.misaligned]
-### Places based on misaligned pointers
+## Places based on misaligned pointers
 [based on a misaligned pointer]: #places-based-on-misaligned-pointers
 
 r[undefined.misaligned.general]
@@ -137,7 +137,7 @@ that being based on an aligned pointer is always sufficient to ensure that the
 new reference is aligned, but it is not always necessary.
 
 r[undefined.dangling]
-### Dangling pointers
+## Dangling pointers
 [dangling]: #dangling-pointers
 
 r[undefined.dangling.general]
@@ -159,7 +159,7 @@ must never exceed `isize::MAX`, since it is impossible for a single allocation
 to be larger than `isize::MAX`.
 
 r[undefined.validity]
-### Invalid values
+## Invalid values
 [invalid-values]: #invalid-values
 
 r[undefined.validity.general]

src/behavior-not-considered-unsafe.md

@@ -1,14 +1,15 @@
-## Behavior not considered `unsafe`
+# Behavior not considered `unsafe`
 
 The Rust compiler does not consider the following behaviors _unsafe_,
 though a programmer may (should) find them undesirable, unexpected,
 or erroneous.
 
-##### Deadlocks
-##### Leaks of memory and other resources
-##### Exiting without calling destructors
-##### Exposing randomized base addresses through pointer leaks
-##### Integer overflow
+- Deadlocks
+- Leaks of memory and other resources
+- Exiting without calling destructors
+- Exposing randomized base addresses through pointer leaks
+
+## Integer overflow
 
 If a program contains arithmetic overflow, the programmer has made an
 error. In the following discussion, we maintain a distinction between
@@ -36,7 +37,7 @@ semantics.
 See [RFC 560] for error conditions, rationale, and more details about
 integer overflow.
 
-##### Logic errors
+## Logic errors
 
 Safe code may impose extra logical constraints that can be checked
 at neither compile-time nor runtime. If a program breaks such

src/procedural-macros.md

@@ -1,5 +1,5 @@
 r[macro.proc]
-## Procedural Macros
+# Procedural Macros
 
 r[macro.proc.intro]
 *Procedural macros* allow creating syntax extensions as execution of a function.
@@ -43,7 +43,7 @@ Procedural macros have two ways of reporting errors. The first is to panic. The
 second is to emit a [`compile_error`] macro invocation.
 
 r[macro.proc.proc_macro]
-### The `proc_macro` crate
+## The `proc_macro` crate
 
 r[macro.proc.proc_macro.intro]
 Procedural macro crates almost always will link to the compiler-provided
@@ -67,7 +67,7 @@ cannot modify a `Span` itself, you can always change the `Span` *associated*
 with any token, such as through getting a `Span` from another token.
 
 r[macro.proc.hygiene]
-### Procedural macro hygiene
+## Procedural macro hygiene
 
 Procedural macros are *unhygienic*. This means they behave as if the output
 token stream was simply written inline to the code it's next to. This means that
@@ -80,7 +80,7 @@ by ensuring that generated functions have names that are unlikely to clash with
 other functions (like `__internal_foo` instead of `foo`).
 
 r[macro.proc.function]
-### Function-like procedural macros
+## Function-like procedural macros
 
 r[macro.proc.function.intro]
 *Function-like procedural macros* are procedural macros that are invoked using
@@ -131,7 +131,7 @@ expressions], [item] positions, including items in [`extern` blocks], inherent
 and trait [implementations], and [trait definitions].
 
 r[macro.proc.derive]
-### Derive macros
+## Derive macros
 
 r[macro.proc.derive.intro]
 *Derive macros* define new inputs for the [`derive` attribute]. These macros
@@ -182,7 +182,7 @@ fn main() {
 ```
 
 r[macro.proc.derive.attributes]
-#### Derive macro helper attributes
+### Derive macro helper attributes
 
 r[macro.proc.derive.attributes.intro]
 Derive macros can add additional [attributes] into the scope of the [item]
@@ -221,7 +221,7 @@ struct Struct {
 ```
 
 r[macro.proc.attribute]
-### Attribute macros
+## Attribute macros
 
 r[macro.proc.attribute.intro]
 *Attribute macros* define new [outer attributes][attributes] which can be
@@ -307,7 +307,7 @@ fn invoke4() {}
 ```
 
 r[macro.proc.token]
-### Declarative macro tokens and procedural macro tokens
+## Declarative macro tokens and procedural macro tokens
 
 r[macro.proc.token.intro]
 Declarative `macro_rules` macros and procedural macros use similar, but