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_.
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.
Don't show HTML diff if tidy isn't installed for rustdoc tests
The output without the `tidy` tool is just way too big to be of any use. It makes reading the error much more complicated.
r? ``@jyn514``
Allow registering tool lints with `register_tool`
Previously, there was no way to add a custom tool prefix, even if the tool
itself had registered a lint:
```rust
#![feature(register_tool)]
#![register_tool(xyz)]
#![warn(xyz::my_lint)]
```
```
$ rustc unknown-lint.rs --crate-type lib
error[E0710]: an unknown tool name found in scoped lint: `xyz::my_lint`
--> unknown-lint.rs:3:9
|
3 | #![warn(xyz::my_lint)]
| ^^^
```
This allows opting-in to lints from other tools using `register_tool`.
cc https://github.com/rust-lang/rust/issues/66079#issuecomment-788589193, ``@chorman0773``
r? ``@petrochenkov``
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.
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.
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.
Fixes#83061
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.
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.
Closes#79869
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.
`Vec` can hold up to `usize::MAX` ZST items, but `VecDeque` has a lower
limit to keep its raw capacity as a power of two, so we should check
that in `From<Vec<T>> for VecDeque<T>`. We can also simplify the
capacity check for the remaining non-ZST case.
Before this fix, the new test would fail on the length:
```
thread 'collections::vec_deque::tests::test_from_vec_zst_overflow' panicked at 'assertion failed: `(left == right)`
left: `0`,
right: `9223372036854775808`', library/alloc/src/collections/vec_deque/tests.rs:474:5
note: panic did not contain expected string
panic message: `"assertion failed: `(left == right)`\n left: `0`,\n right: `9223372036854775808`"`,
expected substring: `"capacity overflow"`
```
That was a result of `len()` using a mask `& (size - 1)` with the
improper length. Now we do get a "capacity overflow" panic as soon as
that `VecDeque::from(vec)` is attempted.
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.
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.
- `StructField` -> `FieldDef` ("field definition")
- `Field` -> `ExprField` ("expression field", not "field expression")
- `FieldPat` -> `PatField` ("pattern field", not "field pattern")
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.
Add a check for ASCII characters in to_upper and to_lower
This extra check has better performance. See discussion here:
https://internals.rust-lang.org/t/to-upper-speed/13896
Thanks to `@gilescope` for helping discover and test this.
Update books
## nomicon
1 commits in adca786547d08fe676b2fc7a6f08c2ed5280ca38..6fe476943afd53a9a6e91f38a6ea7bb48811d8ff
2021-02-16 16:34:20 +0900 to 2021-03-10 07:28:57 +0900
- Merge pull request rust-lang-nursery/nomicon#257 from skade/opaque-types-fix
## reference
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)
## book
2 commits in 0f87daf683ae3de3cb725faecb11b7e7e89f0e5a..fc2f690fc16592abbead2360cfc0a42f5df78052
2021-03-01 08:54:04 -0500 to 2021-03-05 14:03:22 -0500
- Fix wrapping
- fix: redundant double introduction of shadowing (rust-lang/book#2633)
## rust-by-example
1 commits in 3e0d98790c9126517fa1c604dc3678f396e92a27..eead22c6c030fa4f3a167d1798658c341199e2ae
2021-02-25 08:23:10 -0300 to 2021-03-04 16:26:43 -0300
- Fix grammar "terminates" -> "terminate" (rust-lang/rust-by-example#1423)
## rustc-dev-guide
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
## embedded-book
1 commits in a96d096cffe5fa2c84af1b4b61e1492f839bb2e1..f61685755fad7d3b88b4645adfbf461d500563a2
2021-02-17 08:08:52 +0000 to 2021-03-08 01:06:44 +0000
- Swap to GHA (rust-embedded/book#285)
