The move gathering code is sensitive to type-equality - that is rather
un-robust and I plan to fix it eventually, but that's a more invasive
change. And we want to fix the visitor anyway.
Fixes#42903.
Reword OsStr docs to clarify that utf8 may contain nulls
The use of the word "but" in the OsStr docs implies (at least to me) that valid UTF-8 does not contain null bytes.
Using "which" instead makes it clear that valid UTF-8 may contain null bytes.
only set "overruled by outer forbid" once for lint groups, by group name
Previously, conflicting forbid/allow attributes for a lint group would
result in a separate "allow(L) overruled by outer forbid(L)" error for
every lint L in the group. This was needlessly and annoyingly verbose;
we prefer to just have one error pointing out the conflicting
attributes.
(Also, while we're touching context.rs, clean up some unused arguments.)
Resolves#42873.
change binding name of for loop lowering to appease clippy
With the latest change to for loop lowering (#42634), a `_next` binding was introduced.
Unfortunately, this [disturbs](https://github.com/Manishearth/rust-clippy/issues/1846) clippy's `used_underscore_binding` lint. This commit just renames the binding to `__next` so clippy will be happy. It should have no other effect.
rustdoc: Fix a few issues with associated consts
* Make sure private consts are stripped.
* Don't show a code block for the value if there is none.
* Make sure default values are shown in impls.
* Make sure docs from the trait are used if the impl has no docs.
Make wasm32 buildbot test LLVM backend
This adds the experimental targets option to configure so it can be used
by the builders and changes the wasm32 Dockerfile accordingly. Instead
of using LLVM from the emsdk, the builder's emscripten tools now uses
the Rust in-tree LLVM, since this is the one built with wasm support.
assert_eq failure message easier to read
By having the left and right strings aligned with one another it helps spot the difference between the two far quicker than if they are on the same line.
E.g.
Before:
```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)` left: `"-aandb--S123.html"` right: `"-aandb-S123.html"`',
```
After:
```
thread 'tests::test_safe_filename' panicked at 'assertion failed: `(left == right)`
left: `"-aandb--S123.html"`
right: `"-aandb-S123.html"`',
```
When the strings are both on the same line it take a lot longer to spot the difference. It is a small change but the small time savings add up with repetition. This would help Rust be an excellent language to write tests in out of the box.
Closes https://github.com/rust-lang/rust/issues/41615
Relaxed Debug constraints on {HashMap,BTreeMap}::{Keys,Values}.
I has hit by this yesterday too. 😄
And I've realised that Debug for BTreeMap::{Keys,Values} wasn't formatting just keys and values respectively, but the whole map. 🤔Fixed#41924
r? @jonhoo
Previously, conflicting forbid/allow attributes for a lint group would
result in a separate "allow(L) overruled by outer forbid(L)" error for
every lint L in the group. This was needlessly and annoyingly verbose;
we prefer to just have one error pointing out the conflicting
attributes.
Resolves#42873.
rustc: Enable #[thread_local] for Windows
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
Long ago, in the before-time, the find_lint method was created with the
unused_variables ("unused_variable" in the singular, as it was called at
the time) attribute in anticipation of using the session and span in the
handling of renamed lints (31b7d64fd), and indeed, the session and span
came to be used in this method, while the unused_variables attribute
remained (1ad1e2e29). In modern times, the session and span are again no
longer used (ca81d3dd); it seems we can safely prune them from the
method signature, for justice, and mercy.
I think LLVM has had support for quite some time now for this, we just never got
around to testing it out and binding it. We've had some trouble landing this in
the past I believe, but it's time to try again!
This commit flags the `#[thread_local]` attribute as being available for Windows
targets and adds an implementation of `register_dtor` in the `thread::local`
module to ensure we can destroy these keys. The same functionality is
implemented in clang via a function called `__tlregdtor` (presumably provided in
some Windows runtime somewhere), but this function unfortunately does not take a
data pointer (just a thunk) which means we can't easily call it. For now
destructors are just run in the same way the Linux fallback is implemented,
which is just keeping track via a single OS-based TLS key.
* Make sure private consts are stripped.
* Don't show a code block for the value if there is none.
* Make sure default values are shown in impls.
* Make sure docs from the trait are used if the impl has no docs.
With the latest change to for loop lowering, a `_next` binding was introduced.
Unfortunately, this disturbs clippy's `used_underscore_binding` lint. This
commit just renames the binding to `__next` so clippy will be happy. It should
have no other effect.
Set CXX_<target> in bootstrap
I came across this trying to cross-compile rustc for Redox. It was also mentioned in a comment on https://github.com/rust-lang/rust/pull/42206, but doesn't seem to have been corrected.
Print -Zincremental-info to stderr instead of stdout.
Fixes#42583.
The [cargo-incremental](https://github.com/nikomatsakis/cargo-incremental) tool probably does not need to be updated. It already merges stdout and stderr before parsing the compiler's output.
r? @alexcrichton
Remove most "```ignore" doc tests.
Unconditional ` ```ignore ` doc tests lead to outdated examples (e.g. https://github.com/rust-lang/rust/issues/42729#issuecomment-309346572). This PR tries to change all existing ` ```ignore ` tests into one of the following:
* Add import and declarations to ensure the code is run-pass
* If the code is not Rust, change to ` ```text `/` ```sh `/` ```json `/` ```dot `
* If the code is expected compile-fail, change to ` ```compile_fail `
* If the code is expected run-fail, change to ` ```should_panic `
* If the code can type-check but cannot link/run, change to ` ```no_run `
* Otherwise, add an explanation after the ` ```ignore `
The `--explain` handling is changed to cope with hidden lines from the error index.
Tidy is changed to reject any unexplained ` ```ignore ` and ` ```rust,ignore `.
Replaced by adding extra imports, adding hidden code (`# ...`), modifying
examples to be runnable (sorry Homura), specifying non-Rust code, and
converting to should_panic, no_run, or compile_fail.
Remaining "```ignore"s received an explanation why they are being ignored.
