Merge ObjectSum and PolyTraitRef in AST/HIR + some other refactoring
`ObjectSum` and `PolyTraitRef` are the same thing (list of bounds), they exist separately only due to parser quirks. The second commit merges them.
The first commit replaces `Path` with `Ty` in (not yet supported) equality predicates. They are parsed as types anyway and arbitrary types can always be disguised as paths using aliases, so this doesn't add any new functionality.
The third commit uses `Vec` instead of `P<[T]>` in AST. AST is not immutable like HIR and `Vec`s are more convenient for it, unnecessary conversions are also avoided.
The last commit renames `parse_ty_sum` (which is used for parsing types in general) into `parse_ty`, and renames `parse_ty` (which is used restricted contexts where `+` is not permitted due to operator priorities or other reasons) into `parse_ty_no_plus`.
This is the first part of https://github.com/rust-lang/rust/issues/39085#issuecomment-272743755 and https://github.com/rust-lang/rust/issues/39080 focused on data changes and mechanical renaming, I'll submit a PR with parser changes a bit later.
r? @eddyb
travis: Pass --release-channel=nightly on deploy
This commit passes the `--release-channel=nightly` flag to all images which have
the `DEPLOY` flag set. This means that we'll name artifacts and the compiler
appropriately.
This reworks a bit how arguments are passed, but for now doesn't change what's
already being passed. Eventually we'll want to avoid enabling debug assertions
and llvm assertions for *all* releases, but I figure we can tackle that a little
bit more down the road.
* Add support for `#[proc_macro]`
* Reactivate `proc_macro` feature and gate `#[proc_macro_attribute]` under it
* Have `#![feature(proc_macro)]` imply `#![feature(use_extern_macros)]`,
error on legacy import of proc macros via `#[macro_use]`
This commit passes the `--release-channel=nightly` flag to all images which have
the `DEPLOY` flag set. This means that we'll name artifacts and the compiler
appropriately.
This reworks a bit how arguments are passed, but for now doesn't change what's
already being passed. Eventually we'll want to avoid enabling debug assertions
and llvm assertions for *all* releases, but I figure we can tackle that a little
bit more down the road.
This expands the `cross` travis matrix entry with a few more targets that our
nightlies are building:
* x86_64-rumprun-netbsd
* arm-unknown-linux-musleabi
* arm-unknown-linux-musleabihf
* armv7-unknown-linux-musleabihf
* mips-unknown-linux-musl
* mipsel-unknown-linux-musl
This commit doesn't compile custom toolchains like our current cross-image does,
but instead compiles musl manually and then compiles libunwind manually (like
x86_64) for use for the ARM targets and just uses openwrt toolchains for the
mips targets.
This is a target that we're shipping today, so this commit adds this matrix
entry to AppVeyor. This reuses the existing i686 MSVC matrix entry as it's
currently finishing about a half hour under two hours, which should hopefully
give it enough extra time to run this test suite.
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).
