An update to patterns documentation
As it is written the current pattern page creates a lot of confusion, even for someone with previous rust experience. It's so hard because it introduces an entirely new language feature without explaining. Someone could update it within the span of a few minutes by just explaining the newly introduced feature.
```rust
match c {
x => println!("x: {} c: {}", x, c),
}
```
No where in the book up to this point has it explained that identifiers match patterns with just a name create an irrefutable pattern. The page uses this feature without explanation, it just assumes that readers would immediately understand it. To confuse the issue even further the topic uses this feature to explain shadowing, placing two x's from different scopes and different meanings without ever explaining why there is shadowing.
What follows comes across as utterly nonsensical given everything the reader would know about Rust about this point:
```rust
the result:
x: c c: c
x: x
```
x is c? What? Yes even if you understand that x here is not the x in the previous scope why would x equal 'c' here? What previous chapter explained this? The previous chapter on 'matching' only mentions the catch all '_' and never in any shape or form mentioned that a name here creates an irrefutable pattern and binds a value.
There are numerous examples of people not understanding this section, not finding answers and looking for them online about `x: c c: c`:
https://github.com/rust-lang/book/issues/316https://stackoverflow.com/questions/35563141/match-shadowing-example-in-the-patterns-section-of-the-rust-book-is-very-perplexhttps://users.rust-lang.org/t/confusion-about-match-and-patterns/3937https://www.bountysource.com/issues/38852461-question-on-patterns-section-shadowing-example-existing-book
And a [google search for `rust x: c c: c`](https://www.google.com/search?q=rust+%22x:+c+c:+c%22) finds many more people being tripped up, including people who speak a language other than English. I am confident that this page has resulted in questions on the irc channel more than once. Given rust already has a pretty big learning curve I recommend this be fixed.
I was asked to create PR from where I made this same case in the [rust book repository issue](https://github.com/rust-lang/book/issues/316) (I didn't realize this was a separate project).
Minor improvements to docs in std::env structures/functions.
* Call functions "functions" instead of "methods".
* Link structures to their constructor functions
* Add other misc. documentation links
(Shot at) Fix endian bugs in i128 intrinsic impls
Attempt to fix the endianness issues on big-endian machines such as power pc. Could not test if it actually makes stuff work on the powerpc, because setting up cross-compiler for ppc seems to be nigh-impossible on arch.
travis: Mirror some NetBSD artifacts
This mirrors a few artifacts that have been flaky to download recently
on our own S3 bucket, which has historically been more reliable.
Closes#39097
Mark safe_suggestion and pushpop_unsafe as removed in feature_gate.rs
This removes two features from feature_gate.rs: `safe_suggestion` and `pushpop_unsafe`. Both had been removed in other places already, but were forgotten to be removed from feature_gate.rs.
* `safe_suggestion` was added in commit 164f0105bb and then removed again in commit c11fe553df both in the same PR #38099.
* `pushpop_unsafe` was added in commit 1829fa5199 and removed again in commit d399098fd8
Removes two elements from the whitelist of non gate tested unstable lang features (issue #39059).
Fix lint attributes on non-item nodes.
Currently, late lint checking uses two HIR visitors: LateContext and
IdVisitor. IdVisitor only overrides visit_id, and for each node searches
for builtin lints previously added to the session; LateContext overrides
a number of methods, and runs late lints. When LateContext encounters an
item, it first has IdVisitor walk everything in it except nested items
(OnlyBodies), then recurses into it itself - i.e. there are two separate
walks.
Aside from apparently being unnecessary, this separation prevents lint
attributes (allow/deny/warn) on non-item HIR nodes from working
properly. Test case:
```rust
// generates warning without this change
fn main() { #[allow(unreachable_code)] loop { break; break; } }
```
LateContext contains logic to merge attributes seen into the current lint
settings while walking (with_lint_attrs), but IdVisitor does not. So
such attributes will affect late lints (because they are called from
LateContext), and if the node contains any items within it, they will
affect builtin lints within those items (because that IdVisitor is run
while LateContext is within the attributed node), but otherwise the
attributes will be ignored for builtin lints.
This change simply removes IdVisitor and moves its visit_id into
LateContext itself. Hopefully this doesn't break anything...
Also added walk calls to visit_lifetime and visit_lifetime_def
respectively, so visit_lifetime_def will recurse into the lifetime and
visit_lifetime will recurse into the name. In principle this could
confuse lint plugins. This is "necessary" because walk_lifetime calls
visit_id on the lifetime; of course, an alternative would be directly
calling visit_id (which would require manually iterating over the
lifetimes in visit_lifetime_def), but that seems less clean.
travis: Expand dist builder coverage
This commit adds six new travis matrix entires for doing cross-compiled
distribution builds of the compiler. The support added in #38731 allows us to
quickly compile a complete suite of distribution artifacts for cross-compiled
platforms, and currently each matrix entry (when fully cached) clocks in around
an hour to finish. Note that a full test run typically takes about two hours
right now.
With further optimizations coming down the pike in #39026 this commit also
starts doubling up cross-compiled distribution builders on each matrix entry. We
initially planned to do one build per entry, but it's looking like we may be
able to get by with more than one in each entry. Depending on how long these
builds take we may even be able to up it to three, but we'll start with two
first.
This commit then completes the suite of cross-compiled compilers that we're
going to compile, adding it for a whole litany of platforms detailed in the
changes to the docker files here. The existing `cross` image is also trimmed
down quite a bit to avoid duplicate work, and we'll eventually provision it for
far more cross compilation as well.
Note that the gcc toolchains installed to compile most of these compilers are
inappropriate for actualy distribution. The glibc they pull in is much newer
than we'd like, so before we turn nightlies off we'll need to tweak these docker
files to custom build toolchains like the current `linux-cross` docker image
does.
This commit adds six new travis matrix entires for doing cross-compiled
distribution builds of the compiler. The support added in #38731 allows us to
quickly compile a complete suite of distribution artifacts for cross-compiled
platforms, and currently each matrix entry (when fully cached) clocks in around
an hour to finish. Note that a full test run typically takes about two hours
right now.
With further optimizations coming down the pike in #39026 this commit also
starts doubling up cross-compiled distribution builders on each matrix entry. We
initially planned to do one build per entry, but it's looking like we may be
able to get by with more than one in each entry. Depending on how long these
builds take we may even be able to up it to three, but we'll start with two
first.
This commit then completes the suite of cross-compiled compilers that we're
going to compile, adding it for a whole litany of platforms detailed in the
changes to the docker files here. The existing `cross` image is also trimmed
down quite a bit to avoid duplicate work, and we'll eventually provision it for
far more cross compilation as well.
Note that the gcc toolchains installed to compile most of these compilers are
inappropriate for actualy distribution. The glibc they pull in is much newer
than we'd like, so before we turn nightlies off we'll need to tweak these docker
files to custom build toolchains like the current `linux-cross` docker image
does.
Fix covered-switch-default warnings in RustWrapper
These switch statements cover all possible values, so the default case is dead code (it contains an `llvm_unreachable anyway`), triggering a `-Wcovered-switch-default` warning that pollutes the build output. Moving the unreachable after the switch resolves these warnings.
r? @rkruppe
If submodule init fails, try from scratch
See #39051
I wonder if the cause could be some strange not-quite-checked-out state in a submodule. Try and fix this by force deinitialising everything before initialising (this will not throw away downloaded objects, git will skip them on the next attempt at cloning).
r? @alexcrichton
rustbuild: Skip the build_helper crate in tests
I've been noticing some spurious recompiles of the final stage on Travis lately
and in debugging them I found a case where we were a little to eager to update
a stamp file due to the build_helper library being introduced during the testing
phase.
Part of the rustbuild system detects when libstd is recompiled and automatically
cleans out future directories to ensure that dirtyness propagation works. To do
this rustbuild doesn't know the artifact name of the standard library so it just
probes everything in the target directory, looking to see if anything changed.
The problem here happened where:
* First, rustbuild would compile everything (a normal build)
* Next, rustbuild would run all tests
* During testing, the libbuild_helper library was introduced into the target
directory, making it look like a change happened because a file is newer
than the newest was before
* Detecting a change, the next compilation would then cause rustbuild to clean
out old artifacts and recompile everything again.
This commit fixes this problem by correcting rustbuild to just not test the
build_helper crate at all. This crate doesn't have any unit tests, nor is it
intended to. That way the target directories should stay the same throughout
testing after a previous build.
Use multiline Diagnostic for "relevant impl" list
Provide the following output:
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
<Bar as Foo<i8>>
<Bar as Foo<i16>>
<Bar as Foo<i32>>
<Bar as Foo<u8>>
and 2 others
error: aborting due to previous error
```
instead of
```
error[E0277]: the trait bound `Bar: Foo<usize>` is not satisfied
--> $DIR/issue-21659-show-relevant-trait-impls-2.rs:38:8
|
38 | f1.foo(1usize);
| ^^^ the trait `Foo<usize>` is not implemented for `Bar`
|
= help: the following implementations were found:
= help: <Bar as Foo<i8>>
= help: <Bar as Foo<i16>>
= help: <Bar as Foo<i32>>
= help: <Bar as Foo<u8>>
= help: and 2 others
error: aborting due to previous error
```
This marks the pushpop_unsafe feature as removed inside the feature_gate.
It was added in commit 1829fa5199 and then
removed again in commit d399098fd8 .
Seems that the second commit forgot to mark it as removed in feature_gate.rs.
This enables us to remove another element from the whitelist of non gate
tested unstable lang features (issue #39059).
This removes the safe_suggestion feature from feature_gate.rs.
It was added in commit 164f0105bb
and then removed again in commit c11fe553df .
As the removal was in the same PR #38099 as the addition, we don't move it to
the "removed" section.
Removes an element from the whitelist of non gate tested unstable lang features (issue #39059).
rustbuild: Actually don't build stage0 target rustc
This was attempted in #38853 but erroneously forgot one more case of where the
compiler was compiled. This commit fixes that up and adds a test to ensure this
doesn't sneak back in.
incr.comp.: Add some caching to Predecessors construction.
This speeds up the "serialize dep graph" pass for libsyntax from 45 secs to 15 secs on my machine. Still far from ideal, but things will get better when we change the metadata hashing strategy.
The `CACHING_THRESHOLD` value of 60 has been arrived at experimentally. It seemed to give the best speedup.
r? @nikomatsakis
Fix two const-eval issues related to i128 negation
First issue here was the fact that we’d only allow negating integers in i64 range in case the
integer was not infered yes. While this is not the direct cause of the issue, its still good to fix
it.
The real issue here is the code handling specifically the `min_value` literals. While I128_OVERFLOW
has the expected value (0x8000_..._0000), match using this value as a pattern is handled
incorrectly by the stage1 compiler (it seems to be handled correctly, by the stage2 compiler). So
what we do here is extract this pattern into an explicit `==` until the next snapshot.
Fixes#38987
expect_err for Result.
This adds an `expect_err` method to `Result`. Considering how `unwrap_err` already exists, this seems to make sense. Inconsistency noted in Manishearth/rust-clippy#1435.
