Merge pull request #3883 from ehuss/mdbook-0.5

Update to mdbook 0.5

Author: Urgau

.github/workflows/deploy.yml

@@ -6,7 +6,7 @@ on:
 
 env:
   # renovate: datasource=crate depName=mdbook versioning=semver
-  MDBOOK_VERSION: 0.4.52
+  MDBOOK_VERSION: 0.5.1
 
 jobs:
   build:

0000-template.md

@@ -3,12 +3,12 @@
 - RFC PR: [rust-lang/rfcs#0000](https://github.com/rust-lang/rfcs/pull/0000)
 - Rust Issue: [rust-lang/rust#0000](https://github.com/rust-lang/rust/issues/0000)
 
-# Summary
+## Summary
 [summary]: #summary
 
 One paragraph explanation of the feature.
 
-# Motivation
+## Motivation
 [motivation]: #motivation
 
 Any changes to Rust should focus on solving a problem that users of Rust are having.
@@ -19,7 +19,7 @@ This can then be used to guide the design of the feature.
 
 This section is one of the most important sections of any RFC, and can be lengthy.
 
-# Guide-level explanation
+## Guide-level explanation
 [guide-level-explanation]: #guide-level-explanation
 
 Explain the proposal as if it was already included in the language and you were teaching it to another Rust programmer. That generally means:
@@ -33,7 +33,7 @@ Explain the proposal as if it was already included in the language and you were
 
 For implementation-oriented RFCs (e.g. for compiler internals), this section should focus on how compiler contributors should think about the change, and give examples of its concrete impact. For policy RFCs, this section should provide an example-driven introduction to the policy, and explain its impact in concrete terms.
 
-# Reference-level explanation
+## Reference-level explanation
 [reference-level-explanation]: #reference-level-explanation
 
 This is the technical portion of the RFC. Explain the design in sufficient detail that:
@@ -44,20 +44,20 @@ This is the technical portion of the RFC. Explain the design in sufficient detai
 
 The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
 
-# Drawbacks
+## Drawbacks
 [drawbacks]: #drawbacks
 
 Why should we *not* do this?
 
-# Rationale and alternatives
+## Rationale and alternatives
 [rationale-and-alternatives]: #rationale-and-alternatives
 
 - Why is this design the best in the space of possible designs?
 - What other designs have been considered and what is the rationale for not choosing them?
 - What is the impact of not doing this?
 - If this is a language proposal, could this be done in a library or macro instead? Does the proposed change make Rust code easier or harder to read, understand, and maintain?
 
-# Prior art
+## Prior art
 [prior-art]: #prior-art
 
 Discuss prior art, both the good and the bad, in relation to this proposal.
@@ -74,14 +74,14 @@ If there is no prior art, that is fine - your ideas are interesting to us whethe
 Note that while precedent set by other languages is some motivation, it does not on its own motivate an RFC.
 Please also take into consideration that rust sometimes intentionally diverges from common language features.
 
-# Unresolved questions
+## Unresolved questions
 [unresolved-questions]: #unresolved-questions
 
 - What parts of the design do you expect to resolve through the RFC process before this gets merged?
 - What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
 - What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
 
-# Future possibilities
+## Future possibilities
 [future-possibilities]: #future-possibilities
 
 Think about what the natural extension and evolution of your proposal would

libs_changes.md

@@ -1,6 +1,6 @@
 # RFC guidelines - libraries sub-team
 
-# Motivation
+## Motivation
 
 * RFCs are heavyweight:
     * RFCs generally take at minimum 2 weeks from posting to land. In
@@ -42,7 +42,7 @@ the RFC process, it is important that we be maximally friendly towards their
 needs.
 
 
-# Is an RFC required?
+## Is an RFC required?
 
 The overarching philosophy is: *do whatever is easiest*. If an RFC
 would be less work than an implementation, that's a good sign that an RFC is
@@ -66,7 +66,7 @@ as `std` has become more conservative in favour of the much more agile cargovers
 * **Do the easier thing** if uncertain. (choosing a path is not final)
 
 
-# Non-RFC process
+## Non-RFC process
 
 * A (non-RFC) PR is likely to be **closed** if clearly not acceptable:
     * Disproportionate breaking change (small inference breakage may be acceptable)

text/0001-private-fields.md

@@ -2,12 +2,12 @@
 - RFC PR: [rust-lang/rfcs#1](https://github.com/rust-lang/rfcs/pull/1)
 - Rust Issue: [rust-lang/rust#8122](https://github.com/rust-lang/rust/issues/8122)
 
-# Summary
+## Summary
 
 This is an RFC to make all struct fields private by default. This includes both
 tuple structs and structural structs.
 
-# Motivation
+## Motivation
 
 Reasons for default private visibility
 
@@ -38,7 +38,7 @@ Reasons for inherited visibility (today's design)
 * Private definitions certainly want private fields (to hide implementation
   details).
 
-# Detailed design
+## Detailed design
 
 Currently, rustc has two policies for dealing with the privacy of struct fields:
 
@@ -146,13 +146,13 @@ This RFC does not impact enum variants in any way. All enum variants will
 continue to inherit privacy from the outer enum type. This includes both the
 fields of tuple variants as well as fields of struct variants in enums.
 
-# Alternatives
+## Alternatives
 
 The main alternative to this design is what is currently implemented today,
 where fields inherit the privacy of the outer structure. The pros and cons of
 this strategy are discussed above.
 
-# Unresolved questions
+## Unresolved questions
 
 As the above statistics show, almost all structures are either all public or all
 private. This RFC provides an easy method to make struct fields all private, but

text/0002-rfc-process.md

@@ -2,14 +2,14 @@
 - RFC PR: [rust-lang/rfcs#2](https://github.com/rust-lang/rfcs/pull/2), [rust-lang/rfcs#6](https://github.com/rust-lang/rfcs/pull/6)
 - Rust Issue: N/A
 
-# Summary
+## Summary
 
 The "RFC" (request for comments) process is intended to provide a
 consistent and controlled path for new features to enter the language
 and standard libraries, so that all stakeholders can be confident about
 the direction the language is evolving in.
 
-# Motivation
+## Motivation
 
 The freewheeling way that we add new features to Rust has been good for
 early development, but for Rust to become a mature platform we need to
@@ -18,7 +18,7 @@ This is a proposal for a more principled RFC process to make it
 a more integral part of the overall development process, and one that is
 followed consistently to introduce features to Rust.
 
-# Detailed design
+## Detailed design
 
 Many changes, including bug fixes and documentation improvements can be
 implemented and reviewed via the normal GitHub pull request workflow.
@@ -27,7 +27,7 @@ Some changes though are "substantial", and we ask that these be put
 through a bit of a design process and produce a consensus among the Rust
 community and the [core team].
 
-## When you need to follow this process
+### When you need to follow this process
 
 You need to follow this process if you intend to make "substantial"
 changes to the Rust distribution. What constitutes a "substantial"
@@ -53,7 +53,7 @@ If you submit a pull request to implement a new feature without going
 through the RFC process, it may be closed with a polite request to
 submit an RFC first.
 
-## What the process is
+### What the process is
 
 In short, to get a major feature added to Rust, one must first get the
 RFC merged into the RFC repo as a markdown file. At that point the RFC
@@ -99,7 +99,7 @@ after becoming active is 'inactive' and moves to the 'inactive' folder.
 
 [Active RFC List]: ../README.md#active-rfc-list
 
-# Alternatives
+## Alternatives
 
 Retain the current informal RFC process. The newly proposed RFC process is
 designed to improve over the informal process in the following ways:
@@ -111,7 +111,7 @@ understand why new features are being merged
 
 As an alternative, we could adopt an even stricter RFC process than the one proposed here. If desired, we should likely look to Python's [PEP] process for inspiration.
 
-# Unresolved questions
+## Unresolved questions
 
 1. Does this RFC strike a favorable balance between formality and agility?
 2. Does this RFC successfully address the aforementioned issues with the current

text/0003-attribute-usage.md

@@ -2,13 +2,13 @@
 - RFC PR: [rust-lang/rfcs#3](https://github.com/rust-lang/rfcs/pull/3)
 - Rust Issue: [rust-lang/rust#14373](https://github.com/rust-lang/rust/issues/14373)
 
-# Summary
+## Summary
 
 Rust currently has an attribute usage lint but it does not work particularly
 well. This RFC proposes a new implementation strategy that should make it
 significantly more useful.
 
-# Motivation
+## Motivation
 
 The current implementation has two major issues:
 
@@ -39,7 +39,7 @@ pub struct Foo {
 }
 ```
 
-# Detailed design
+## Detailed design
 
 The current implementation is implemented as a simple fold over the AST,
 comparing attributes against a whitelist. Crate-level attributes use a separate
@@ -82,15 +82,15 @@ Attributes in code that has been eliminated with `#[cfg()]` will not be linted,
 but I feel that this is consistent with the way `#[cfg()]` works in general
 (e.g. the code won't be type-checked either).
 
-# Alternatives
+## Alternatives
 
 An alternative would be to rewrite `rustc::middle::lint` to robustly check
 that attributes are used where they're supposed to be. This will be fairly
 complex and be prone to failure if/when more nodes are added to the AST. This
 also doesn't solve motivation #2, which would require externally loaded lint
 support.
 
-# Unresolved questions
+## Unresolved questions
 
 + This implementation doesn't allow for a distinction between "unused" and
 "unknown" attributes. The `#[phase(syntax)]` crate loading infrastructure could

text/0008-new-intrinsics.md

@@ -6,7 +6,7 @@
 design may still be useful in the future, but before implementing we
 would prefer to revisit it so as to be sure it is up to date.**
 
-# Summary
+## Summary
 
 The way our intrinsics work forces them to be wrapped in order to
 behave like normal functions. As a result, rustc is forced to inline a
@@ -17,7 +17,7 @@ in the language so that they behave the same as normal Rust functions
 by removing the "rust-intrinsic" foreign ABI and reusing the "Rust"
 ABI.
 
-# Motivation
+## Motivation
 
 A number of commonly-used intrinsics, including `transmute`, `forget`,
 `init`, `uninit`, and `move_val_init`, are accessed through wrappers
@@ -39,7 +39,7 @@ let transmute: fn(int) -> uint = intrinsics::transmute;
 This incongruity means that we can't just expose the intrinsics
 directly as part of the public API.
 
-# Detailed design
+## Detailed design
 
 `extern "Rust" fn` is already equivalent to `fn`, so if intrinsics
 have the "Rust" ABI then the problem is solved.
@@ -66,7 +66,7 @@ abstractions.
 Currently, "Rust" foreign functions may not be generic; this change
 will require a special case that allows intrinsics to be generic.
 
-# Alternatives
+## Alternatives
 
 1. Instead of making intrinsics lang items we could create a slightly
 different mechanism, like an `#[intrinsic]` attribute, that would
@@ -78,6 +78,6 @@ continue letting intrinsics to be redeclared.
 3. We could also make "rust-intrinsic" coerce or otherwise be the same
 as "Rust" externs and normal Rust functions.
 
-# Unresolved questions
+## Unresolved questions
 
 None.

text/0016-more-attributes.md

@@ -2,12 +2,12 @@
 - RFC PR: [rust-lang/rfcs#16](https://github.com/rust-lang/rfcs/pull/16)
 - Rust Issue: [rust-lang/rust#15701](https://github.com/rust-lang/rust/issues/15701)
 
-# Summary
+## Summary
 
 Allow attributes on more places inside functions, such as statements,
 blocks and expressions.
 
-# Motivation
+## Motivation
 
 One sometimes wishes to annotate things inside functions with, for
 example, lint `#[allow]`s, conditional compilation `#[cfg]`s, and even
@@ -43,7 +43,7 @@ The minimum useful functionality would be supporting attributes on
 blocks and `let` statements, since these are flexible enough to allow
 for relatively precise attribute handling.
 
-# Detailed design
+## Detailed design
 
 Normal attribute syntax on `let` statements, blocks and expressions.
 
@@ -74,7 +74,7 @@ fn foo() {
 Attributes bind tighter than any operator, that is `#[attr] x op y` is
 always parsed as `(#[attr] x) op y`.
 
-## `cfg`
+### `cfg`
 
 It is definitely an error to place a `#[cfg]` attribute on a
 non-statement expressions, that is, `attr1`--`attr4` can possibly be
@@ -87,7 +87,7 @@ the ability for attributes to be placed in specific places, it is not
 mandating that `#[cfg]` actually be stripped in those places (although
 it should be an error if it is ignored).
 
-## Inner attributes
+### Inner attributes
 
 Inner attributes can be placed at the top of blocks (and other
 structure incorporating a block) and apply to that block.
@@ -118,7 +118,7 @@ match bar {
 }
 ```
 
-## `if`
+### `if`
 
 Attributes would be disallowed on `if` for now, because the
 interaction with `if`/`else` chains are funky, and can be simulated in
@@ -174,7 +174,7 @@ match cond {
 }
 ```
 
-# Drawbacks
+## Drawbacks
 
 This starts mixing attributes with nearly arbitrary code, possibly
 dramatically restricting syntactic changes related to them, for
@@ -189,7 +189,7 @@ reason about, but (also stated), this RFC is not for making such
 `#[cfg]`s be obeyed, it just opens the language syntax to possibly
 allow it.
 
-# Alternatives
+## Alternatives
 
 These instances could possibly be approximated with macros and helper
 functions, but to a low degree degree (e.g. how would one annotate a
@@ -209,7 +209,7 @@ difference between interior and exterior for an `else {` branch, and
 so `else #[attr] {` is sufficient.
 
 
-# Unresolved questions
+## Unresolved questions
 
 Are the complications of allowing attributes on arbitrary
 expressions worth the benefits?