Support parentheses in patterns under feature gate
This is a prerequisite for any other extensions to pattern syntax - `|` with multiple patterns, type ascription, `..PAT` in slice patterns.
Closes https://github.com/rust-lang/rfcs/issues/554
[Underspecified semantics] Type check defaults at declaration.
Fixes #46669. See the test for code that compiles on stable but will no longer compile. This falls under a "Underspecified language semantics" fix. **Needs crater**.
On type and trait declarations, we currently allow anything that name checks as a type parameter default. That allows the user to write a default that can never be applied, or even a default that may conditionally be applied depending on the type of another parameter. Mostly this just defers the error to use sites, but also allows clever hacks such as `Foo<T, U = <T as Iterator>::Item>` where `U` will be able to apply it's default only when `T: Iterator`. Maybe that means this bug is a feature, but it's a fiddly behaviour that seems undesirable.
This PR validates defaults at declaration sites by ensuring all predicates on the parameter are valid for the default. With the exception of `Self: Sized` which we don't want to check to allow things like `trait Add<RHS = Self>`.
Given a trait predicate, if all params appearing in the LHS have
defaults then it should be a backwards compatible predicate. We verify
that by checking the WF of predicate with all defaults substituted
simultaneously.
Ensure main() always has external linkage
This ensures that the entry function is never elided due to inlining, even with `inline(always)`. Fixes#47783.
There were a couple of possible ways of addressing this issue; I simply picked the one that seemed most direct. A warning could be appropriate, but considering using inlining hints in other places it doesn't apply also throws no warnings, and it seems like an edge case anyway, I haven't added one for now.
Restrict the Termination impls to simplify stabilization
Make a minimal commitment in preparation for stabilization. More impls, or broader ones, are likely in future, but are not necessary at this time and are more controversial.
cc https://github.com/rust-lang/rust/issues/48453#issuecomment-368155082
r? @nikomatsakis
Add support for powerpc-unknown-linux-gnuspe
This PR adds support for the embedded PowerPC variant "e500". On Linux, this architecture is usually called "powerpcspe", it is a 32-bit PowerPC architecture. The main difference between normal 32-bit PowerPC and PowerPCSPE is the lack of Altivec instructions and the additional SPE instruction set.
This architecture is supported in Debian through an unofficial port.
Comprehensively support trailing commas in std/core macros
I carefully organized the changes into four commits:
* Test cases
* Fixes for `macro_rules!` macros
* Fixes for builtin macros
* Docs for builtins
**I can easily scale this back to just the first two commits for now if such is desired.**
### Breaking (?) changes
* This fixes#48042, which is a breaking change that I hope people can agree is just a bugfix for an extremely dark corner case.
* To fix five of the builtins, this changes `syntax::ext::base::get_single_str_from_tts` to accept a trailing comma, and revises the documentation so that this aspect is not surprising. **I made this change under the (hopefully correct) understanding that `libsyntax` is private rustc implementation detail.** After reviewing all call sites (which were, you guessed it, *precisely those five macros*), I believe the revised semantics are closer to the intended spirit of the function.
### Changes which may require concensus
Up until now, it could be argued that some or all the following macros did not conceptually take a comma-separated list, because they only took one argument:
* **`cfg(unix,)`** (most notable since cfg! is unique in taking a meta tag)
* **`include{,_bytes,_str}("file.rs",)`** (in item form this might be written as "`include!{"file.rs",}`" which is even slightly more odd)
* **`compile_error("message",);`**
* **`option_env!("PATH",)`**
* **`try!(Ok(()),)`**
So I think these particular changes may require some sort of consensus. **All of the fixes for builtins are included this list, so if we want to defer these decisions to later then I can scale this PR back to just the first two commits.**
### Other notes/general requests for comment
* Do we have a big checklist somewhere of "things to do when adding macros?" My hope is for `run-pass/macro-comma-support.rs` to remain comprehensive.
* Originally I wanted the tests to also comprehensively forbid double trailing commas. However, this didn't work out too well: [see this gist and the giant FIXME in it](https://gist.github.com/ExpHP/6fc40e82f3d73267c4e590a9a94966f1#file-compile-fail_macro-comma-support-rs-L33-L50)
* I did not touch `select!`. It appears to me to be a complete mess, and its trailing comma mishaps are only the tip of the iceberg.
* There are [some compile-fail test cases](5fa97c35da/src/test/compile-fail/macro-comma-behavior.rs (L49-L52)) that didn't seem to work (rustc emits errors, but compile-fail doesn't acknowledge them), so they are disabled. Any clues? (Possibly related: These happen to be precisely the set of errors which are tagged by rustc as "this error originates in a macro outside of the current crate".)
---
Fixes#48042Closes#46241
Rustc explain
Fixes#48041.
To make the review easier, I separated tests update to code update. Also, I used this script to generate new ui tests stderr:
```python
from os import listdir
from os.path import isdir, isfile, join
PATH = "src/test/ui"
def do_something(path):
files = [join(path, f) for f in listdir(path)]
for f in files:
if isdir(f):
do_something(f)
continue
if not isfile(f) or not f.endswith(".stderr"):
continue
x = open(f, "r")
content = x.read().strip()
if "error[E" not in content:
continue
errors = dict()
for y in content.splitlines():
if y.startswith("error[E"):
errors[y[6:11]] = True
errors = sorted(errors.keys())
if len(errors) < 1:
print("weird... {}".format(f))
continue
if len(errors) > 1:
content += "\n\nYou've got a few errors: {}".format(", ".join(errors))
content += "\nIf you want more information on an error, try using \"rustc --explain {}\"".format(errors[0])
else:
content += "\n\nIf you want more information on this error, try using \"rustc --explain {}\"".format(errors[0])
content += "\n"
x = open(f, "w")
x.write(content)
do_something(PATH)
```
This ensures that the entry function is never elided due to inlining, even with `inline(always)`. Fixes#47783.
There were a couple of possible ways of addressing this issue; I simply picked the one that seemed most direct. A warning could be appropriate, but considering using inlining hints in other places it doesn't apply also throws no warnings, and it seems like an edge case anyway, I haven't added one for now.
test: Fix s390x-unknown-linux-gnu atomic-lock-free test not run for systemz
The s390-unknown-linux-gnu atomic-lock-free test is currently run for ```LLVM_COMPONENTS == powerpc```. I assume it was meant to be run for ```LLVM_COMPONENTS == systemz```, so let's fix this.
rustdoc: don't crash when an external trait's docs needs to import another trait
Fixes https://github.com/rust-lang/rust/issues/48414
When resolving intra-paths for an item, rustdoc needs to have information about their items on hand, for proper bookkeeping. When loading a path for an external item, it needs to load these items from their host crate, since their information isn't otherwise available. This includes resolving paths for those docs. which can cause this process to recurse. Rustdoc keeps a map of external traits in a `RefCell<HashMap<DefId, Trait>>`, and it keeps a borrow of this active when importing an external trait. In the linked crash, this led to a RefCell borrow error, panic, and ICE.
This PR manually releases the borrow while importing the trait, and also keeps a list of traits being imported at the given moment. The latter keeps rustdoc from infinitely recursing as it tries to import the same trait repeatedly.
