Improve documentation for slice strip_* functions
Prompted by the stabilisation tracking issue #73413 I looked at the docs for `strip_prefix` and `strip_suffix` for both `str` and `slice`, and I felt they could be slightly improved.
Thanks for your attention.
ci: update x86_64-gnu and x86_64-gnu-debug to ubuntu:20.04
The former `ubuntu:19.10` reached EOL in July, 2020, whereas
`ubuntu:20.04` is an LTS release supported until 2025.
These are non-dist CI images, so the impact should be low.
Include non-rustup artifacts in the manifest
This PR fixes https://github.com/rust-lang/promote-release/issues/22 by including all the files we ship in the generated manifests, even the ones that are not installable through rustup. In practice this adds the following "artifacts":
* `source-code`: the tarball containing the full source code used to build the release (`rustc-{channel}-src.tar.xz`)
* `installer-msi`: the MSI installer for Windows systems (`rust-{channel}-{target}.msi`)
* `installer-pkg`: the PKG installer for macOS systems (`rust-{channel}-{target}.pkg`)
These files are included in a new `artifacts` table of the manifest, like so:
```toml
[[artifacts.installer-msi.target.aarch64-pc-windows-msvc]]
url = "https://example.com/2020-10-28/rust-nightly-aarch64-pc-windows-msvc.msi"
hash-sha256 = "6b41d5b829d20834c5d93628d008ec618f8914ee79303363bd13a86fd5f305dd"
[[artifacts.installer-msi.target.i686-pc-windows-gnu]]
url = "https://example.com/2020-10-28/rust-nightly-i686-pc-windows-gnu.msi"
hash-sha256 = "83f020de6e180c155add9fce1cea2ac6e5f744edbd6dc1581e24de8f56b2ca7a"
[[artifacts.installer-msi.target.i686-pc-windows-msvc]]
url = "https://example.com/2020-10-28/rust-nightly-i686-pc-windows-msvc.msi"
hash-sha256 = "dbc80c24e9d5df01616c6f216114b4351f51a94218e2368b5cebe4165b270702"
[[artifacts.installer-msi.target.x86_64-pc-windows-gnu]]
url = "https://example.com/2020-10-28/rust-nightly-x86_64-pc-windows-gnu.msi"
hash-sha256 = "8196eca3f02d72d4c8776ad4fcc72897125e2cf6404ae933e31c07e197e3c9fa"
[[artifacts.installer-msi.target.x86_64-pc-windows-msvc]]
url = "https://example.com/2020-10-28/rust-nightly-x86_64-pc-windows-msvc.msi"
hash-sha256 = "b2e7fd6463790732fcf9c726b9448068712341943199cb40fc11d1138b8a207b"
[[artifacts.installer-pkg.target.aarch64-apple-darwin]]
url = "https://example.com/2020-10-28/rust-nightly-aarch64-apple-darwin.pkg"
hash-sha256 = "70421c191752fb33886f8033b029e634bcc993b72308cef52a38405840e91f5c"
[[artifacts.installer-pkg.target.x86_64-apple-darwin]]
url = "https://example.com/2020-10-28/rust-nightly-x86_64-apple-darwin.pkg"
hash-sha256 = "ebd7a5acb61e82d85e855146cc9bd856f32228ee7f40dd94c659b00614ed4f1f"
[[artifacts.source-code.target."*"]]
url = "https://example.com/2020-10-28/rustc-nightly-src.tar.gz"
hash-sha256 = "5fcc487ee4c15c689de8ddf7daac7ff6a65c80498197b9aea58622dc2b3bca10"
[[artifacts.source-code.target."*"]]
url = "https://example.com/2020-10-28/rustc-nightly-src.tar.xz"
hash-sha256 = "0c618ef0ec5f64da1801e9d0df6c755f6ed1a8780ec5c8ee75e55614be51d42c"
```
Each artifact can be available for multiple targets, and each target can have multiple versions of the same file (for example, a `gz`-compressed one and a `xz`-compressed one). In the future rustup might add functionality to let users retrieve the artifacts, but that's not needed to land this PR, and whether to do the implementation is up to the rustup maintainers.
r? `@kinnison`
cc `@Mark-Simulacrum`
In particular, this allows us to write more explicit matches that
avoid the pitfalls of using a fully general fall-through case, yet
remain fairly ergonomic. Less logic is in guard cases, more is in
the actual exhaustive case analysis.
No functional changes.
Update books
## nomicon
7 commits in 6e57e64501f61873ab80cb78a07180a22751a5d6..69333eddb1de92fd17e272ce4677cc983d3bd71d
2020-09-14 11:40:23 -0400 to 2020-10-17 15:44:12 -0700
- Tweak GHA config (rust-lang-nursery/nomicon#240)
- Fix link for `[T]` (rust-lang-nursery/nomicon#239)
- Update casts.md (rust-lang-nursery/nomicon#232)
- [WIP] Add more links (rust-lang-nursery/nomicon#180)
- Data Race definition should be more precise (rust-lang-nursery/nomicon#219)
- Update the diagnostic of `error[E0597]` in dropck.md (rust-lang-nursery/nomicon#157)
- fix typo in Lifetimes mutable reference aliasing section (rust-lang-nursery/nomicon#225)
## reference
3 commits in 1b78182e71709169dc0f1c3acdc4541b6860e1c4..10c16caebe475d0d11bec0531b95d7697856c13c
2020-10-11 13:53:47 -0700 to 2020-10-25 20:51:26 -0700
- Add `unsafe` for `mod` and `extern`. (rust-lang-nursery/reference#898)
- mention how unions interact with dropping (rust-lang-nursery/reference#897)
- Add `move_ref_pattern` docs (rust-lang-nursery/reference#881)
## book
2 commits in 451a1e30f2dd137aa04e142414eafb8d05f87f84..13e1c05420bca86ecc79e4ba5b6d02de9bd53c62
2020-10-05 09:11:18 -0500 to 2020-10-20 14:57:32 -0500
- Referencing to Appendix B (rust-lang/book#2481)
- Use GITHUB_PATH instead of add-path (rust-lang/book#2477)
## rust-by-example
2 commits in 152475937a8d8a1f508d8eeb57db79139bc803d9..99eafee0cb14e6ec641bf02a69d7b30f6058349a
2020-10-09 09:29:50 -0300 to 2020-10-21 14:21:55 -0300
- Formatting footer items. (rust-lang/rust-by-example#1385)
- Add partial moves example for `move_ref_pattern` stabilization (rust-lang/rust-by-example#1377)
## edition-guide
3 commits in 81f16863014de60b53de401d71ff904d163ee030..7bc9b7a5e800f79df62947cb7d566fd2fbaf19fe
2020-08-27 13:56:31 -0700 to 2020-10-23 18:31:23 -0500
- A few small updates. (rust-lang/edition-guide#221)
- Clarify the limitation of ? in main and tests (rust-lang/edition-guide#219)
- Update deprecated GitHub Actions commands. (rust-lang/edition-guide#220)
Adjust turbofish help message for const generics
Types are no longer special. (This message arguably only makes sense with `min_const_generics` or more, but we'll be there soon.)
r? @lcnr
MinConstGenerics UI test for invalid values for bool & char
This adds a test for `feature(min_const_generics)` with some invalid values for bools and chars and ensures that they do not ICE and error with understandable messages.
r? @lcnr
min_const_generics: allow ty param in repeat expr
implements https://rust-lang.zulipchat.com/#narrow/stream/260443-project-const-generics/topic/repeat.20expressions
Even with `min_const_generics` active, now keeps resulting in future compat warnings instead of hard errors.
Const parameters, for example `[0; N + 1]`, still result in hard errors during resolve.
```rust
#![allow(dead_code)]
fn foo<T>() {
[0; std::mem::size_of::<*mut T>()];
}
struct Foo<T>(T);
impl<T> Foo<T> {
const ASSOC: usize = 4;
fn test() {
[0; Self::ASSOC];
}
}
```
r? @varkor cc @petrochenkov
rustdoc options to set default theme (and other settings)
Hi. This is the MR I promised in #77024
It is a little more general than I envisaged there. Once I had found the settings-handling machinery it seemed foolish to add this feature just for the theme.
Closes#77024
Clarify main code paths in exhaustiveness checking
This PR massively clarifies the main code paths of exhaustiveness checking, by using the `Constructor` enum to a fuller extent. I've been itching to write it for more than a year, but the complexity of matching consts had prevented me. Behold a massive simplification :D.
This in particular removes a fair amount of duplication between various parts, localizes code into methods of relevant types when applicable, makes some implicit assumptions explicit, and overall improves legibility a lot (or so I hope). Additionally, after my changes undoing #76918 turned out to be a noticeable perf gain.
As usual I tried my best to make the commits self-contained and easy to follow. I've also tried to keep the code well-commented, but I tend to forget how complex this file is; I'm happy to clarify things as needed.
My measurements show good perf improvements on the two match-heavy benchmarks (-18.0% on `unicode_normalization-check`! :D); I'd like a perf run to check the overall impact.
r? `@varkor`
`@rustbot` modify labels: +A-exhaustiveness-checking
The former `ubuntu:19.10` reached EOL in July, 2020, whereas
`ubuntu:20.04` is an LTS release supported until 2025.
These are non-dist CI images, so the impact should be low.
$ touch empty.rs
$ env RUSTC_LOG=debug rustc +stage1 --crate-type=lib empty.rs
Fails with a `BorrowMutError` because source map files are already
borrowed while `features_query` attempts to format a log message
containing a span.
Release the borrow before the query to avoid the issue.
* Remove a needless comma in the Rust code
* Replace double spaces after full stops with single spaces
Requested-by: @GuillaumeGomez
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
This is a fairly simple special case of --default-eetting. We must
set both "theme" and "use-system-theme".
Providing it separately enables us to document a way to set the theme
without expoosing the individual settings keywords, which are quite
complex.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
We just plumb through what the user tells us.
This is flagged as unstable, mostly because I don't understand the
compatibility rules that rustdoc obeys for local storage data, and how
error handling of invalid data works.
We collect() the needed HashMap from Vec of Vecs of (key, value)
pairs, so that there is a nice place to add new more-specific options.
It would have been possible to use Extend::extend but doing it this
way ensures that all the used inputs are (and will stay) right next to
each other.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
rustdoc has various user-configurable preferences. These are recorded
in web Local Storage (where available). But we want to provide a way
to configure the default default, including for when web storage is
not available.
getSettingValue is the function responsible for looking up these
settings. Here we make it fall back some in-DOM data, which
ultimately comes from RenderOptions.default_settings.
Using HTML data atrtributes is fairly convenient here, dsspite the
need to transform between snake and kebab case to avoid the DOM
converting kebab case to camel case (!)
We cache the element and dataset lookup in a global variable, to
ensure that getSettingValue remains fast.
The DOM representation has to be in an element which precedes the
inclusion of storage.js. That means it has to be in the <head> and we
should not use an empty <div> as the container (although most browsers
will accept that). An empty <script> element provides a convenient
and harmless container object. <meta> would be another possibility
but runs a greater risk of having unwanted behaviours on weird
browsers.
We trust the RenderOptions not to contain unhelpful setting names,
which don't fit nicely into an HTML attribute. It's awkward to quote
dataset keys.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
