Rollup of 11 pull requests #83247
Merged
Rollup of 11 pull requests #83247
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
- 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
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 not 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.
When codegenning code coverage use the instance that coverage data was originally generated for, to ensure basic level of compatibility with MIR inlining.
Consider functions to be reachable for code coverage purposes, either when they reach the code generation directly, or indirectly as inlined part of another function.
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. Signed-off-by: Daniel Silverstone <[email protected]>
Previously, there was no way to add a custom tool prefix, even if the tool itself had registered a lint: ``` #![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`.
Co-authored-by: Yuki Okushi <[email protected]>
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.
…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. Closes rust-lang#79869
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 rust-lang#81989 (comment).
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 rust-lang#83061
…e, 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.
…ulacrum 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.
…lett,raoulstrackx Simplify C compilation for Fortanix-SGX target cc ``@raoulstrackx``
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 rust-lang#66079 (comment), ``@chorman0773`` r? ``@petrochenkov``
…joshtriplett Display error details when a `mmap` call fails Fixes rust-lang#82388
…r=jyn514 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``
…nknown-none-elf, r=estebank Switch riscvgc-unknown-none-elf use lp64d ABI Corrects rust-lang#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).
|
@bors r+ rollup=never p=5 |
|
📌 Commit 1839d1d has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
asm!#82270 (Emit error when trying to use assembler syntax directives inasm!)proc_macro_back_compatlint toprocedural-masquerade#83168 (Extendproc_macro_back_compatlint toprocedural-masquerade)register_tool#83216 (Allow registering tool lints withregister_tool)mmapcall fails #83223 (Display error details when ammapcall fails)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup