Fix null exclusions in grammar docs
The grammar documentation incorrectly says that comments, character literals,
and string literals may not include null.
Fix grammar documentation wrt Unicode identifiers
The grammar defines identifiers in terms of XID_start and XID_continue,
but this is referring to the unstable non_ascii_idents feature.
The documentation implies that non_ascii_idents is forthcoming, but this
is left over from pre-1.0 documentation; in reality, non_ascii_idents
has been without even an RFC for several years now, and will not be
stabilized anytime soon. Furthermore, according to the tracking issue at
https://github.com/rust-lang/rust/issues/28979 , it's highly
questionable whether or not this feature will use XID_start or
XID_continue even when or if non_ascii_idents is stabilized.
This commit fixes this by respecifying identifiers as the usual
[a-zA-Z_][a-zA-Z0-9_]*
Tweak `nearest_common_ancestor()`.
- Remove the "no nearest common ancestor found" case, because it's never
hit in practise. (This means `closure_is_enclosed_by` can also be
removed.)
- Add a comment about why `SmallVec` is used for the "seen" structures.
- Use `&Scope` instead of `Scope` to avoid some `map()` calls.
- Use `any(p)` instead of `position(p).is_some()`.
r? @nikomatsakis
Improve format string errors
Point at format string position inside the formatting string:
```
error: invalid format string: unmatched `}` found
--> $DIR/format-string-error.rs:21:22
|
LL | let _ = format!("}");
| ^ unmatched `}` in format string
```
Explain that argument names can't start with an underscore:
```
error: invalid format string: invalid argument name `_foo`
--> $DIR/format-string-error.rs:15:23
|
LL | let _ = format!("{_foo}", _foo = 6usize);
| ^^^^ invalid argument name in format string
|
= note: argument names cannot start with an underscore
```
Fix#23476.
The more accurate spans will only be seen when using `format!` directly, when using `println!` the diagnostics machinery makes the span be the entire statement.
Switch to bootstrapping from 1.27
It's possible the Float trait could be removed from core, but I couldn't tell whether it was intended to be removed or not. @SimonSapin may be able to comment more here; we can presumably also do that in a follow up PR as this one is already quite large.
In #49289, rustc was changed to emit metadata for binaries, which made
it so that the librustc.rmeta file created when compiling librustc was
overwritten by the rustc-main compilation. This commit renames the
rustc-main binary to avoid this problem.
https://github.com/rust-lang/cargo/issues/5524 has also been filed to
see if Cargo can learn to warn on this situation instead of leaving it
for the user to debug.
compiletest: Run revisions as independent tests.
Fixes#47604.
- The output of each test is now in its own directory.
- "auxiliary" output is now under the respective test directory.
- `stage_id` removed from filenames, and instead placed in the stamp file as a hash. This helps keep path lengths down for Windows.
In brief, the new layout looks like this:
```
<build_base>/<relative_dir>/<testname>.<revision>.<mode>/
stamp
<testname>.err
<testname>.out
a (binary)
auxiliary/lib<auxname>.dylib
auxiliary/<auxname>/<auxname>.err
auxiliary/<auxname>/<auxname>.out
```
(revision and mode are optional)
- The output of each test is now in its own directory.
- "auxiliary" output is now under the respective test directory.
- `stage_id` removed from filenames, and instead placed in the stamp file as a hash. This helps keep path lengths down for Windows.
In brief, the new layout looks like this:
```
<build_base>/<relative_dir>/<testname>.<revision>.<mode>/
stamp
<testname>.err
<testname>.out
a (binary)
auxiliary/lib<auxname>.dylib
auxiliary/<auxname>/<auxname>.err
auxiliary/<auxname>/<auxname>.out
```
(revision and mode are optional)
rustc: Fix `crate` lint for single-item paths
This commit fixes recommending the `crate` prefix when migrating to 2018 for
paths that look like `use foo;` or `use {bar, baz}`
Closes#50660
Rollup of 17 pull requests
Successful merges:
- #50170 (Implement From for more types on Cow)
- #50638 (Don't unconditionally set CLOEXEC twice on every fd we open on Linux)
- #50656 (Fix `fn main() -> impl Trait` for non-`Termination` trait)
- #50669 (rustdoc: deprecate `#![doc(passes, plugins, no_default_passes)]`)
- #50726 (read2: Use inner function instead of closure)
- #50728 (Fix rustdoc panic with `impl Trait` in type parameters)
- #50736 (env: remove unwrap in examples in favor of try op)
- #50740 (Remove LazyBTreeMap.)
- #50752 (Add missing error codes in libsyntax-ext asm)
- #50779 (Make mutable_noalias and arg_align_attributes be tracked)
- #50787 (Fix run-make wasm tests)
- #50788 (Fix an ICE when casting a nonexistent const)
- #50789 (Ensure libraries built in stage0 have unique metadata)
- #50793 (tidy: Add a check for empty UI test files)
- #50797 (fix a typo in signed-integer::from_str_radix())
- #50808 (Stabilize num::NonZeroU*)
- #50809 (GitHub: Stop treating Cargo.lock as a generated file.)
Failed merges:
Implement From for more types on Cow
This is basically https://github.com/rust-lang/rust/pull/48191, except that it should be implemented in a way that doesn't break third party crates.
tidy: Add a check for empty UI test files
Check for empty `.stderr` and `.stdout` files in UI test directories.
Empty files could still pass testing for `compile-pass` tests with no output
so they can get into the repo accidentally, but they are not necessary and can
be removed.
This is very much an in progress pull request. I'm having an issue with rustfmt. It wanted to reformat the entire file for almost every file by default. And when I run tidy it just errors out because it catches the empty files that are already in the repo.
My next step is goin got be to remove those empty file and see if running tidy again will actually reformat things outside of the context of `cargo fmt`
Fixes https://github.com/rust-lang/rust/issues/50785
Ensure libraries built in stage0 have unique metadata
Issue #50786 shows a case with local rebuild where the libraries built
by stage0 had the same suffix as stage0's own, and were accidentally
loaded by that stage0 rustc when compiling `librustc_trans`.
Now we set `__CARGO_DEFAULT_LIB_METADATA` to "bootstrap" during stage0,
rather than the release channel like usual, so the library suffix will
always be completely distinct from the stage0 compiler.
Remove LazyBTreeMap.
It was introduced in #50240 to avoid an allocation when creating a new
BTreeMap, which gave some speed-ups. But then #50352 made that the
default behaviour for BTreeMap, so LazyBTreeMap is no longer necessary.
Fix rustdoc panic with `impl Trait` in type parameters
Fixes#50702.
I'm not sure `impl Trait`s neither in arguments nor in return types are supposed to work, though.
read2: Use inner function instead of closure
Very minor thing, but there doesn't appear to be a reason to use a closure here.
Generated code is identical in my tests, but I believe it's clearer that nothing from the environment is being used.
Check for empty `.stderr` and `.stdout` files in UI test directories.
Empty files could still pass testing for `compile-pass` tests with no output
so they can get into the repo accidentally, but they are not necessary and can
be removed.
Reenable the MergeFunctions pass
The crash that happened in #23566 doesn't happen anymore with the LLVM mergefunc
pass enabled and it hugely reduces code size (for example it shaves off 10% of the
final Servo executable). This patch reenables it.
For those wondering, [here are the docs from LLVM about this pass](http://llvm.org/docs/MergeFunctions.html).
rustdoc: deprecate `#![doc(passes, plugins, no_default_passes)]`
Closes https://github.com/rust-lang/rust/issues/48164
Blocked on https://github.com/rust-lang/rust/pull/50541 - this includes those changes, which were necessary to create the UI test
cc https://github.com/rust-lang/rust/issues/44136
Turns out, there were special attributes to mess with rustdoc passes and plugins! Who knew! Since we deprecated the CLI flags for this functionality, it makes sense that we do the same for the attributes.
This PR also introduces a `#![doc(document_private_items)]` attribute, to match the `--document-private-items` flag introduced in https://github.com/rust-lang/rust/pull/44138 when the passes/plugins flags were deprecated.
I haven't done a search to see whether these attributes are being used at all, but if the flags were any indication, i don't expect to see any users of these.
Fix `fn main() -> impl Trait` for non-`Termination` trait
Fixes#50595.
This bug currently affects stable. Why I think we can go for hard error:
- It will in stable for at most one cycle and there is no legitimate reason to abuse it, nor any known uses in the wild.
- It only affects `bin` crates (which have a `main`), so there is little practical difference between a hard error or a deny lint, both are a one line fix.
The fix was to just unshadow a variable. Thanks @nikomatsakis for the mentoring!
r? @nikomatsakis
Don't unconditionally set CLOEXEC twice on every fd we open on Linux
Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`,
because some old Linux version would ignore the `O_CLOEXEC` flag we pass
to the `open64` function.
Now, we check whether the `CLOEXEC` flag is set on the first file we
open – if it is, we won't do extra syscalls for every opened file. If it
is not set, we fall back to the old behavior of unconditionally calling
`ioctl(…, FIOCLEX)` on newly opened files.
On old Linuxes, this amounts to one extra syscall per process, namely
the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag.
On new Linuxes, this reduces the number of syscalls per opened file by
one, except for the first file, where it does the same number of
syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of
`ioctl(…, FIOCLEX)` to set it).
