bors [Fri, 19 Mar 2021 18:23:44 +0000 (18:23 +0000)]
Auto merge of #82951 - sexxi-goose:wr-mir-replace-methods2, r=nikomatsakis
Replace closures_captures and upvar_capture with closure_min_captures
Removed all uses of closures_captures and upvar_capture and refactored code to work with closure_min_captures. This also involved removing functions that were no longer needed like the bridge.
Dylan DPC [Fri, 19 Mar 2021 14:03:29 +0000 (15:03 +0100)]
Rollup merge of #83270 - steffahn:missing_word_in_skip_while_doc, r=joshtriplett
Fix typo/inaccuracy in the documentation of Iterator::skip_while
One of the examples used to say “this leads to a possibly confusing situation, where the type of the closure is a double reference” while _actually_ referring to the type of the closure _argument_.
This PR just changes a single word in documentation.
Dylan DPC [Fri, 19 Mar 2021 14:03:26 +0000 (15:03 +0100)]
Rollup merge of #83215 - bstrie:dephaikuraw, r=joshtriplett
Deprecate std::os::haiku::raw, which accidentally wasn't deprecated
In early 2016, all `std::os::*::raw` modules [were deprecated](https://github.com/rust-lang/rust/commit/aa23c98450063992473d40d707273903f8a3937d) in accordance with [RFC 1415](https://github.com/rust-lang/rfcs/blob/master/text/1415-trim-std-os.md). However, at this same time support for Haiku was being added to libstd, landing shortly after the aforementioned commit, and due to some crossed wires a `std::os::haiku::raw` module was added and was not marked as deprecated.
I have been in correspondence with the author of the Haiku patch, ````@nielx,```` who has confirmed that this was simply an oversight and that the definitions from the libc crate should be preferred instead.
Dylan DPC [Fri, 19 Mar 2021 14:03:23 +0000 (15:03 +0100)]
Rollup merge of #83179 - Aaron1011:actix-web-lint, r=petrochenkov
Extend `proc_macro_back_compat` lint to `actix-web`
Unlike the other cases of this lint, there's no simple way to detect if
an old version of the relevant crate (`syn`) is in use. The `actix-web`
crate only depends on `pin-project` v1.0.0, so checking the version of
`actix-web` does not guarantee that a new enough version of
`pin-project` (and therefore `syn`) is in use.
Instead, we rely on the fact that virtually all of the regressed crates
are pinned to a pre-1.0 version of `pin-project`. When this is the case,
bumping the `actix-web` dependency will pull in the *latest* version of
`pin-project`, which has an explicit dependency on a newer v dependency
on a newer version of `syn`.
The lint message tells users to update `actix-web`, since that's what
they're most likely to have control over. We could potentially tell them
to run `cargo update -p syn`, but I think it's more straightforward to
suggest an explicit change to the `Cargo.toml`
The `actori-web` fork had its last commit over a year ago, and appears
to just be a renamed fork of `actix-web`. Therefore, I've removed the
`actori-web` check entirely - any crates that actually get broken can
simply update `syn` themselves.
Dylan DPC [Fri, 19 Mar 2021 14:03:22 +0000 (15:03 +0100)]
Rollup merge of #82892 - jix:clarify-read-read, r=joshtriplett
Clarify docs for Read::read's return value
Right now the docs for `Read::read`'s return value are phrased in a way that makes it easy for the reader to assume that the return value is never larger than the passed buffer. This PR clarifies that this is a requirement for implementations of the trait, but that callers have to expect a buggy yet safe implementation failing to do so, especially if unchecked accesses to the buffer are done afterwards.
I fell into this trap recently, and when I noticed, I looked at the docs again and had the feeling that I might not have been the first one to miss this.
The same issue of trusting the return value of `read` was also present in std itself for about 2.5 years and only fixed recently, see #80895.
I hope that clarifying the docs might help others to avoid this issue.
Dylan DPC [Fri, 19 Mar 2021 14:03:20 +0000 (15:03 +0100)]
Rollup merge of #82759 - m-ou-se:remove-unwrap-none, r=petrochenkov
Remove unwrap_none/expect_none from compiler/.
We're not going to stabilize `Option::{unwrap_none, expect_none}`. (See https://github.com/rust-lang/rust/issues/62633.) This removes the usage of those unstable methods from `compiler/`.
Dylan DPC [Fri, 19 Mar 2021 14:03:14 +0000 (15:03 +0100)]
Rollup merge of #82500 - CDirkx:hermit-pipe, r=joshtriplett
Reuse `std::sys::unsupported::pipe` on `hermit`
Pipes are not supported on `hermit` and `hermit/pipe.rs` is identical to `unsupported/pipe.rs`. This PR reduces duplication between the two by doing the following on `hermit`:
```rust
#[path = "../unsupported/pipe.rs"]
pub mod pipe;
```
bors [Fri, 19 Mar 2021 12:44:33 +0000 (12:44 +0000)]
Auto merge of #82754 - rylev:rusage-windows, r=pnkfelix
Attempt to gather similar stats as rusage on Windows
A follow up to #82532. This is a bit hacked in because I think we need to discuss this before merging, but this is an attempt to gather similar metrics as `libc::rusage` on Windows.
Some comments on differences:
* Currently, we're passing `RUSAGE_CHILDREN` to `rusage` which collects statistics on all children that have been waited on and terminated. I believe this is currently just the invocation of the real `rustc` that the shim is wrapping. Does `rustc` itself spawn children processes? The windows version gets the child processes handle when spawning it, and uses that to collect the statistics. For maxrss, `rusage` will return "the resident set size of the largest child, not the maximum resident set size of the process tree.", the Windows version will only collect statistics on the wrapped `rustc` child process directly even if some theoretical sub process has a larger memory footprint.
* There might be subtle differences between `rusage`'s "resident set" and Window's "working set". The "working set" and "resident set" should both be the number of pages that are in memory and which would not cause a page fault when accessed.
* I'm not yet sure how best to get the same information that `ru_minflt`, `ru_inblock`, `ru_oublock`, `ru_nivcsw ` and `ru_nvcsw` provide.
bors [Fri, 19 Mar 2021 00:47:37 +0000 (00:47 +0000)]
Auto merge of #71780 - jcotton42:string_remove_matches, r=joshtriplett
Implement String::remove_matches
Closes #50206.
I lifted the function help from `@frewsxcv's` original PR (#50015), hope they don't mind.
I'm also wondering whether it would be useful for `remove_matches` to collect up the removed substrings into a `Vec` and return them, right now they're just overwritten by the copy and lost.
Frank Steffahn [Thu, 18 Mar 2021 17:58:22 +0000 (18:58 +0100)]
Fix typo/inaccuracy in the documentation of Iterator::skip_while
One of the examples used to say “this leads to a possibly confusing situation,
where the type of the closure is a double reference” while _actually_ referring to
the type of the closure _argument_.
Aaron Hill [Tue, 16 Mar 2021 02:59:21 +0000 (22:59 -0400)]
Extend `proc_macro_back_compat` lint to `actix-web`
Unlike the other cases of this lint, there's no simple way to detect if
an old version of the relevant crate (`syn`) is in use. The `actix-web`
crate only depends on `pin-project` v1.0.0, so checking the version of
`actix-web` does not guarantee that a new enough version of
`pin-project` (and therefore `syn`) is in use.
Instead, we rely on the fact that virtually all of the regressed crates
are pinned to a pre-1.0 version of `pin-project`. When this is the case,
bumping the `actix-web` dependency will pull in the *latest* version of
`pin-project`, which has an explicit dependency on a newer v dependency
on a newer version of `syn`.
The lint message tells users to update `actix-web`, since that's what
they're most likely to have control over. We could potentially tell them
to run `cargo update -p syn`, but I think it's more straightforward to
suggest an explicit change to the `Cargo.toml`
The `actori-web` fork had its last commit over a year ago, and appears
to just be a renamed fork of `actix-web`. Therefore, I've removed the
`actori-web` check entirely - any crates that actually get broken can
simply update `syn` themselves.
bors [Thu, 18 Mar 2021 11:03:49 +0000 (11:03 +0000)]
Auto merge of #77566 - Marwes:smaller_hashmap, r=Amanieu
feat: Update hashbrown to instantiate less llvm IR
Includes https://github.com/rust-lang/hashbrown/pull/204 and https://github.com/rust-lang/hashbrown/pull/205 (not yet merged) which both serve to reduce the amount of IR generated for hashmaps.
Inspired by the llvm-lines data gathered in https://github.com/rust-lang/rust/pull/76680 (cc `@Julian-Wollersberger)`
bors [Thu, 18 Mar 2021 08:18:06 +0000 (08:18 +0000)]
Auto merge of #81312 - dylni:clarify-btree-range-search-comments, r=m-ou-se
Clarify BTree `range_search` comments
These comments were added by #81169. However, the soundness issue [might not be exploitable here](https://github.com/rust-lang/rust/pull/81169#issuecomment-765271717), so the comments should be updated.
bors [Wed, 17 Mar 2021 23:39:51 +0000 (23:39 +0000)]
Auto merge of #83247 - Dylan-DPC:rollup-bdwmvjg, r=Dylan-DPC
Rollup of 11 pull requests
Successful merges:
- #82191 (Vec::dedup_by optimization)
- #82270 (Emit error when trying to use assembler syntax directives in `asm!`)
- #82434 (Add more links between hash and btree collections)
- #83080 (Make source-based code coverage compatible with MIR inlining)
- #83168 (Extend `proc_macro_back_compat` lint to `procedural-masquerade`)
- #83192 (ci/docker: Add SDK/NDK level 21 to android docker for 32bit platforms)
- #83204 (Simplify C compilation for Fortanix-SGX target)
- #83216 (Allow registering tool lints with `register_tool`)
- #83223 (Display error details when a `mmap` call fails)
- #83228 (Don't show HTML diff if tidy isn't installed for rustdoc tests)
- #83231 (Switch riscvgc-unknown-none-elf use lp64d ABI)
Dylan DPC [Wed, 17 Mar 2021 23:28:17 +0000 (00:28 +0100)]
Rollup merge of #83231 - DieracDelta:lp64d-abi-for-riscvgc-unknown-none-elf, r=estebank
Switch riscvgc-unknown-none-elf use lp64d ABI
Corrects #83229 by directly specifying the target abi in the spec in the same way as is done for the `riscv64gc-unknown-linux-gnu` target [here](https://github.com/rust-lang/rust/blob/master/compiler/rustc_target/src/spec/riscv64gc_unknown_linux_gnu.rs).
Dylan DPC [Wed, 17 Mar 2021 23:28:11 +0000 (00:28 +0100)]
Rollup merge of #83192 - kinnison:add-android-21, r=Mark-Simulacrum
ci/docker: Add SDK/NDK level 21 to android docker for 32bit platforms
Certain features of Linux (getauxval() and epoll_create1()) are only
available in android SDK/NDK levels 18 and 21 respectively. The 32bit
platform is currently on level 14 for compatibility with Android 4.0.
This patch adds SDK/NDK level 21 to the docker for 32 bit platforms,
while leaving the default setup at level 14.
With this done, projects such as `rustup` which rely on these dockers
can build with modern ecosystem crates such as tokio 1.0, by using
the level 21 toolchain, but those which do not need to switch will
be unaffected, since the level 14 toolchain remains available.
Dylan DPC [Wed, 17 Mar 2021 23:28:10 +0000 (00:28 +0100)]
Rollup merge of #83168 - Aaron1011:lint-procedural-masquerade, r=petrochenkov
Extend `proc_macro_back_compat` lint to `procedural-masquerade`
We now lint on *any* use of `procedural-masquerade` crate. While this
crate still exists, its main reverse dependency (`cssparser`) no longer
depends on it. Any crates still depending off should stop doing so, as
it only exists to support very old Rust versions.
If a crate actually needs to support old versions of rustc via
`procedural-masquerade`, then they'll just need to accept the warning
until we remove it entirely (at the same time as the back-compat hack).
The latest version of `procedural-masquerade` does work with the
latest rustc, but trying to check for the version seems like more
trouble than it's worth.
While working on this, I realized that the `proc-macro-hack` check was
never actually doing anything. The corresponding enum variant in
`proc-macro-hack` is named `Value` or `Nested` - it has never been
called `Input`. Due to a strange Crater issue, the Crater run that
tested adding this did *not* end up testing it - some of the crates that
would have failed did not actually have their tests checked, making it
seem as though the `proc-macro-hack` check was working.
The Crater issue is being discussed at
https://rust-lang.zulipchat.com/#narrow/stream/242791-t-infra/topic/Nearly.20identical.20Crater.20runs.20processed.20a.20crate.20differently/near/230406661
Despite the `proc-macro-hack` check not actually doing anything, we
haven't gotten any reports from users about their build being broken.
I went ahead and removed it entirely, since it's clear that no one is
being affected by the `proc-macro-hack` regression in practice.
Dylan DPC [Wed, 17 Mar 2021 23:28:09 +0000 (00:28 +0100)]
Rollup merge of #83080 - tmiasko:inline-coverage, r=wesleywiser
Make source-based code coverage compatible with MIR inlining
When codegenning code coverage use the instance that coverage data was
originally generated for, to ensure basic level of compatibility with
MIR inlining.
Dylan DPC [Wed, 17 Mar 2021 23:28:07 +0000 (00:28 +0100)]
Rollup merge of #82434 - jyn514:hash, r=JohnTitor
Add more links between hash and btree collections
- Link from `core::hash` to `HashMap` and `HashSet`
- Link from HashMap and HashSet to the module-level documentation on
when to use the collection
- Link from several collections to Wikipedia articles on the general
concept
See also https://github.com/rust-lang/rust/pull/81989#issuecomment-783920840.
Dylan DPC [Wed, 17 Mar 2021 23:28:06 +0000 (00:28 +0100)]
Rollup merge of #82270 - asquared31415:asm-syntax-directive-errors, r=nagisa
Emit error when trying to use assembler syntax directives in `asm!`
The `.intel_syntax` and `.att_syntax` assembler directives should not be used, in favor of not specifying a syntax for intel, and in favor of the explicit `att_syntax` option using the inline assembly options.
Dylan DPC [Wed, 17 Mar 2021 23:28:04 +0000 (00:28 +0100)]
Rollup merge of #82191 - Soveu:dedup, r=nagisa
Vec::dedup_by optimization
Now `Vec::dedup_by` drops items in-place as it goes through them.
From my benchmarks, it is around 10% faster when T is small, with no major regression when otherwise.
I used `ptr::copy` instead of conditional `ptr::copy_nonoverlapping`, because the latter had some weird performance issues on my ryzen laptop (it was 50% slower on it than on intel/sandybridge laptop)
It would be good if someone was able to reproduce these results.
bors [Wed, 17 Mar 2021 19:39:03 +0000 (19:39 +0000)]
Auto merge of #82122 - bstrie:dep4real, r=dtolnay
Deprecate `intrinsics::drop_in_place` and `collections::Bound`, which accidentally weren't deprecated
Fixes #82080.
I've taken the liberty of updating the `since` values to 1.52, since an unobservable deprecation isn't much of a deprecation (even the detailed release notes never bothered to mention these deprecations).
As mentioned in the issue I'm *pretty* sure that using a type alias for `Bound` is semantically equivalent to the re-export; [the reference implies](https://doc.rust-lang.org/reference/items/type-aliases.html) that type aliases only observably differ from types when used on unit structs or tuple structs, whereas `Bound` is an enum.
bors [Wed, 17 Mar 2021 16:49:46 +0000 (16:49 +0000)]
Auto merge of #83188 - petrochenkov:field, r=lcnr
ast/hir: Rename field-related structures
I always forget what `ast::Field` and `ast::StructField` mean despite working with AST for long time, so this PR changes the naming to less confusing and more consistent.
Various visiting and other methods working with the fields are renamed correspondingly too.
The second commit reduces the size of `ExprKind` by boxing fields of `ExprKind::Struct` in preparation for https://github.com/rust-lang/rust/pull/80080.
bors [Wed, 17 Mar 2021 08:27:16 +0000 (08:27 +0000)]
Auto merge of #83225 - JohnTitor:rollup-4hnuhb8, r=JohnTitor
Rollup of 8 pull requests
Successful merges:
- #82774 (Fix bad diagnostics for anon params with ref and/or qualified paths)
- #82826 ((std::net::parser): Fix capitalization of IP version names)
- #83092 (More precise spans for HIR paths)
- #83124 (Do not insert impl_trait_in_bindings opaque definitions twice.)
- #83202 (Show details in cfg version unstable book)
- #83203 (Don't warn about old rustdoc lint names (temporarily))
- #83206 (Update books)
- #83219 (Update cargo)
3 commits in 3b6fe80c205d2a2b5dc8a276192bbce9eeb9e9cf..e32a2f928f8b78d534bca2b9e7736413314dc556
2021-02-22 22:09:17 -0800 to 2021-03-08 23:24:30 -0800
- Clarify that ::foo paths are not necessarily based off of the "crate root" (rust-lang-nursery/reference#974)
- Comment typo (rust-lang-nursery/reference#977)
- Fix misspelled word discrimnant (rust-lang-nursery/reference#976)
15 commits in c431f8c29a41413dddcb3bfa0d71c9cabe366317..67ebd4b55dba44edfc351621cef6e5e758169c55
2021-02-28 16:35:20 -0500 to 2021-03-11 13:36:25 -0800
- Remove extra the (rust-lang/rustc-dev-guide#1088)
- Fix double-word typos (rust-lang/rustc-dev-guide#1084)
- I-nominated are nominated for discussion (rust-lang/rustc-dev-guide#1080)
- Complete unfinished statement
- Check `BASE_SHA` only if it's a PR (rust-lang/rustc-dev-guide#1083)
- Update lins
- Apply suggestions from code review
- Add stub about the THIR
- Switch from Travis to GHA (rust-lang/rustc-dev-guide#1073)
- Adjust a bit better P- label text
- Fix typos (rust-lang/rustc-dev-guide#1079)
- Update cmake version in prerequisites.md (rust-lang/rustc-dev-guide#1077)
- Fix typo: suceed -> succeed
- Add article on using WPA to profile rustc memory usage on Windows (rust-lang/rustc-dev-guide#1074)
- Use more accurate estimate of generated LLVM IR with llvm-lines
Yuki Okushi [Wed, 17 Mar 2021 06:20:58 +0000 (15:20 +0900)]
Rollup merge of #83203 - jyn514:rustdoc-warnings, r=Manishearth
Don't warn about old rustdoc lint names (temporarily)
Since https://github.com/rust-lang/rust/pull/80527, rustdoc users have an unpleasant situation: they can either use the new tool lint names (`rustdoc::non_autolinks`) or they can use the old names (`non_autolinks`). If they use the tool lints, they get a hard error on stable compilers, because rustc rejects all tool names it doesn't recognize (https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193). If they use the old name, they get a warning to rename the lint to the new name. The only way to compile without warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint, this avoids warning about the old name, while still allowing you to use the new name. Once the new `rustdoc` tool name makes it to the stable channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored` - I didn't see an existing way to do this.
Yuki Okushi [Wed, 17 Mar 2021 06:20:54 +0000 (15:20 +0900)]
Rollup merge of #83092 - petrochenkov:qspan, r=estebank
More precise spans for HIR paths
`Ty::assoc_item` is lowered to `<Ty>::assoc_item` in HIR, but `Ty` got span from the whole path.
This PR fixes that, and adjusts some diagnostic code that relied on `Ty` having the whole path span.
This is a pre-requisite for https://github.com/rust-lang/rust/pull/82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans).
r? ````@estebank````
bors [Wed, 17 Mar 2021 05:46:08 +0000 (05:46 +0000)]
Auto merge of #83084 - nagisa:nagisa/features-native, r=petrochenkov
Adjust `-Ctarget-cpu=native` handling in cg_llvm
When cg_llvm encounters the `-Ctarget-cpu=native` it computes an
explciit set of features that applies to the target in order to
correctly compile code for the host CPU (because e.g. `skylake` alone is
not sufficient to tell if some of the instructions are available or
not).
However there were a couple of issues with how we did this. Firstly, the
order in which features were overriden wasn't quite right – conceptually
you'd expect `-Ctarget-cpu=native` option to override the features that
are implicitly set by the target definition. However due to how other
`-Ctarget-cpu` values are handled we must adopt the following order
of priority:
* Features from -Ctarget-cpu=*; are overriden by
* Features implied by --target; are overriden by
* Features from -Ctarget-feature; are overriden by
* function specific features.
Another problem was in that the function level `target-features`
attribute would overwrite the entire set of the globally enabled
features, rather than just the features the
`#[target_feature(enable/disable)]` specified. With something like
`-Ctarget-cpu=native` we'd end up in a situation wherein a function
without `#[target_feature(enable)]` annotation would have a broader
set of features compared to a function with one such attribute. This
turned out to be a cause of heavy run-time regressions in some code
using these function-level attributes in conjunction with
`-Ctarget-cpu=native`, for example.
With this PR rustc is more careful about specifying the entire set of
features for functions that use `#[target_feature(enable/disable)]` or
`#[instruction_set]` attributes.
Sadly testing the original reproducer for this behaviour is quite
impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in
particular on developer or CI machines.
cc https://github.com/rust-lang/rust/issues/83027 `@BurntSushi`
bors [Tue, 16 Mar 2021 22:42:56 +0000 (22:42 +0000)]
Auto merge of #82936 - oli-obk:valtree, r=RalfJung,lcnr,matthewjasper
Implement (but don't use) valtree and refactor in preparation of use
This PR does not cause any functional change. It refactors various things that are needed to make valtrees possible. This refactoring got big enough that I decided I'd want it reviewed as a PR instead of trying to make one huge PR with all the changes.
cc `@rust-lang/wg-const-eval` on the following commits:
cc `@rust-lang/wg-mir-opt` for cf1700c (`mir::Constant` can now represent either a `ConstValue` or a `ty::Const`, and it is totally possible to have two different representations for the same value)
When cg_llvm encounters the `-Ctarget-cpu=native` it computes an
explciit set of features that applies to the target in order to
correctly compile code for the host CPU (because e.g. `skylake` alone is
not sufficient to tell if some of the instructions are available or
not).
However there were a couple of issues with how we did this. Firstly, the
order in which features were overriden wasn't quite right – conceptually
you'd expect `-Ctarget-cpu=native` option to override the features that
are implicitly set by the target definition. However due to how other
`-Ctarget-cpu` values are handled we must adopt the following order
of priority:
* Features from -Ctarget-cpu=*; are overriden by
* Features implied by --target; are overriden by
* Features from -Ctarget-feature; are overriden by
* function specific features.
Another problem was in that the function level `target-features`
attribute would overwrite the entire set of the globally enabled
features, rather than just the features the
`#[target_feature(enable/disable)]` specified. With something like
`-Ctarget-cpu=native` we'd end up in a situation wherein a function
without `#[target_feature(enable)]` annotation would have a broader
set of features compared to a function with one such attribute. This
turned out to be a cause of heavy run-time regressions in some code
using these function-level attributes in conjunction with
`-Ctarget-cpu=native`, for example.
With this PR rustc is more careful about specifying the entire set of
features for functions that use `#[target_feature(enable/disable)]` or
`#[instruction_set]` attributes.
Sadly testing the original reproducer for this behaviour is quite
impossible – we cannot rely on `-Ctarget-cpu=native` to be anything in
particular on developer or CI machines.
bors [Tue, 16 Mar 2021 19:19:06 +0000 (19:19 +0000)]
Auto merge of #82536 - sexxi-goose:handle-patterns-take-2, r=nikomatsakis
2229: Handle patterns within closures correctly when `capture_disjoint_fields` is enabled
This PR fixes several issues related to handling patterns within closures when `capture_disjoint_fields` is enabled.
1. Matching is always considered a use of the place, even with `_` patterns
2. Compiler ICE when capturing fields in closures through `let` assignments
To do so, we
- Introduced new Fake Reads
- Delayed use of `Place` in favor of `PlaceBuilder`
- Ensured that `PlaceBuilder` can be resolved before attempting to extract `Place` in any of the pattern matching code
Joshua Nelson [Tue, 16 Mar 2021 15:59:05 +0000 (11:59 -0400)]
Don't warn about old rustdoc lint names (temporarily)
Right now, rustdoc users have an unpleasant situation: they can either
use the new tool lint names (`rustdoc::non_autolinks`) or they can use
the old names (`non_autolinks`). If they use the tool lints, they get a
hard error on stable compilers, because rustc rejects all tool names it
doesn't recognize. If they use the old name, they get a warning to
rename the lint to the new name. The only way to compile without
warnings is to add `#[allow(renamed_removed_lints)]`, which defeats the
whole point of the change: we *want* people to switch to the new name.
To avoid people silencing the lint and never migrating to the tool lint,
this avoids warning about the old name, while still allowing you to use
the new name. Once the new `rustdoc` tool name makes it to the stable
channel, we can change these lints to warn again.
This adds the new lint functions `register_alias` and `register_ignored`
- I didn't see an existing way to do this.
bors [Tue, 16 Mar 2021 16:37:43 +0000 (16:37 +0000)]
Auto merge of #83199 - JohnTitor:rollup-zrfk94a, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #81822 (Added `try_exists()` method to `std::path::Path`)
- #83072 (Update `Vec` docs)
- #83077 (rustdoc: reduce GC work during search)
- #83091 (Constify `copy` related functions)
- #83156 (Fall-back to sans-serif if Arial is not available)
- #83157 (No background for code in portability snippets)
- #83160 (Deprecate RustcEncodable and RustcDecodable.)
- #83162 (Specify *.woff2 files as binary)
- #83172 (More informative diagnotic from `x.py test` attempt atop beta checkout)
- #83196 (Use delay_span_bug instead of panic in layout_scalar_valid_range)
Yuki Okushi [Tue, 16 Mar 2021 14:54:03 +0000 (23:54 +0900)]
Rollup merge of #83196 - tmiasko:valid-range-delay-span-bug, r=oli-obk
Use delay_span_bug instead of panic in layout_scalar_valid_range
#83054 introduced validation of scalar range attributes, but panicking
code that uses the attribute remained reachable. Use `delay_span_bug`
instead to avoid the ICE.
Yuki Okushi [Tue, 16 Mar 2021 14:54:02 +0000 (23:54 +0900)]
Rollup merge of #83172 - pnkfelix:bootstrap-tell-me-what-to-do-about-tidy-on-beta, r=Mark-Simulacrum
More informative diagnotic from `x.py test` attempt atop beta checkout
Make bootstrap be more informative when one does `x.py test` on a beta checkout without other mods.
To be clear, by default running `x.py test` on a checkout of the beta branch
currently fails, and with this change will continue to fail, because `x.py
tests` runs `x.py test src/tools/tidy` which tries to run `rustfmt` and that
will fail because the `rustfmt` binary is pinned to the current nighlty and we
do not attempt to distribute one for the beta builds.
This change gives a better error message than the current message, which is just
"./x.py fmt is not supported on this channel" without providing any hint about
what one might do about that problem.