When unnecessarily using a fat arrow after an if condition, suggest the
removal of it.
When finding an if statement with no block, point at the `if` keyword to
provide more context.
When finding:
```rust
match &Some(3) {
&None => 1
&Some(2) => { 3 }
_ => 2
}
```
provide the following diagnostic:
```
error: expected one of `,`, `.`, `?`, `}`, or an operator, found `=>`
--> $DIR/missing-comma-in-match.rs:15:18
|
X | &None => 1
| -- - help: missing comma
| |
| while parsing the match arm starting here
X | &Some(2) => { 3 }
| ^^ expected one of `,`, `.`, `?`, `}`, or an operator here
```
Since compiling the bootstrap command doesn't require any submodules,
we can skip updating submodules when a --help command is passed in.
On my machine, this saves 1 minute if the submodules are already
downloaded, and 10 minutes if run on a clean repo.
This commit also adds a message before compiling/downloading anything
when a --help command is passed in, to tell the user WHY --help
takes so long to complete. It also points the user to the bootstrap
README.md for faster help.
Finally, this fixes one warning message that still referenced using
make instead of x.py, even though x.py is now the standard way of
building rust.
Anonymize some line numbers in UI test output
New unstable flag `-Z ui-testing` is introduced. This flag changes diagnostic output of the compiler *in some way* making it more suitable for UI testing (this is intentionally vague).
At the moment this flag anonymizes line numbers at line starts thus solving the largest issue with UI test diffs. If diffs continue to be too noisy, some other tweaks could be applied (e.g. anonymizing lines/columns in `--> $DIR/file.rs:line:column`), but this needs some time and experience (we shouldn't diverge too much from the actual output in general).
If comment `// disable-ui-testing-normalization` is added to an UI test, then `-Z ui-testing` is not passed.
Closes https://github.com/rust-lang/rust/issues/46643
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 is named for the issue as it's testing the specific details of that
bug. It's a bit tricky as the ICE requires multiple files and debug info
enabled to trigger.
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.
Make ".e0" not parse as 0.0
This forces floats to have either a digit before the separating point, or after. Thus `".e0"` is invalid like `"."`, when using `parse()`. Fixes#40654. As mentioned in the issue, this is technically a breaking change... but clearly incorrect behaviour at present.
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.
rustbuild: Restore Config.libdir_relative
This re-introduces a `Config.libdir_relative` field, now derived from
`libdir` and made relative to `prefix` if necessary.
This fixes a regression from #46592 when `--libdir` is given an absolute
path. `Builder::sysroot_libdir` should always use a relative path so
its callers don't clobber system locations, and `librustc` also asserts
that `CFG_LIBDIR_RELATIVE` is really relative.
