add missing title

Author: tshepang

src/conventions.md

@@ -1,11 +1,13 @@
+# Coding conventions
+
 This file offers some tips on the coding conventions for rustc. This
 chapter covers [formatting](#formatting), [coding for correctness](#cc),
 [using crates from crates.io](#cio), and some tips on
 [structuring your PR for easy review](#er).
 
 <a id="formatting"></a>
 
-# Formatting and the tidy script
+## Formatting and the tidy script
 
 rustc is moving towards the [Rust standard coding style][fmt].
 
@@ -28,7 +30,7 @@ pass the <!-- date-check: nov 2022 --> `--edition=2021` argument yourself when c
 
 [`rustfmt`]:https://github.com/rust-lang/rustfmt
 
-## Formatting C++ code
+### Formatting C++ code
 
 The compiler contains some C++ code for interfacing with parts of LLVM that
 don't have a stable C API.
@@ -41,7 +43,7 @@ When modifying that code, use this command to format it:
 This uses a pinned version of `clang-format`, to avoid relying on the local
 environment.
 
-## Formatting and linting Python code
+### Formatting and linting Python code
 
 The Rust repository contains quite a lot of Python code. We try to keep
 it both linted and formatted by the [ruff][ruff] tool.
@@ -65,7 +67,7 @@ environment.
 
 <!-- REUSE-IgnoreStart -->
 <!-- Prevent REUSE from interpreting the heading as a copyright notice -->
-## Copyright notice
+### Copyright notice
 <!-- REUSE-IgnoreEnd -->
 
 In the past, files began with a copyright and license notice. Please **omit**
@@ -75,7 +77,7 @@ MIT/Apache-2.0).
 All of the copyright notices should be gone by now, but if you come across one
 in the rust-lang/rust repo, feel free to open a PR to remove it.
 
-## Line length
+### Line length
 
 Lines should be at most 100 characters. It's even better if you can
 keep things to 80.
@@ -88,18 +90,18 @@ that case, you can add a comment towards the top of the file like so:
 // ignore-tidy-linelength
 ```
 
-## Tabs vs spaces
+### Tabs vs spaces
 
 Prefer 4-space indent.
 
 <a id="cc"></a>
 
-# Coding for correctness
+## Coding for correctness
 
 Beyond formatting, there are a few other tips that are worth
 following.
 
-## Prefer exhaustive matches
+### Prefer exhaustive matches
 
 Using `_` in a match is convenient, but it means that when new
 variants are added to the enum, they may not get handled correctly.
@@ -109,7 +111,7 @@ other treatment? Unless the answer is "low", then prefer an
 exhaustive match. (The same advice applies to `if let` and `while
 let`, which are effectively tests for a single variant.)
 
-## Use "TODO" comments for things you don't want to forget
+### Use "TODO" comments for things you don't want to forget
 
 As a useful tool to yourself, you can insert a `// TODO` comment
 for something that you want to get back to before you land your PR:
@@ -136,13 +138,13 @@ if foo {
 
 <a id="cio"></a>
 
-# Using crates from crates.io
+## Using crates from crates.io
 
 See the [crates.io dependencies][crates] section.
 
 <a id="er"></a>
 
-# How to structure your PR
+## How to structure your PR
 
 How you prepare the commits in your PR can make a big difference for the
 reviewer. Here are some tips.
@@ -172,7 +174,7 @@ require that every intermediate commit successfully builds – we only
 expect to be able to bisect at a PR level. However, if you *can* make
 individual commits build, that is always helpful.
 
-# Naming conventions
+## Naming conventions
 
 Apart from normal Rust style/naming conventions, there are also some specific
 to the compiler.