-
Notifications
You must be signed in to change notification settings - Fork 13.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rollup of 7 pull requests #83222
Closed
Closed
Rollup of 7 pull requests #83222
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
Resolves rust-lang#78911 The target's linker was used but rustc wasn't told to build for that target (instead defaulting to the host). This led to the host instead of the target getting tested and to the linker getting inappropriate arguments.
The test assumes it can run target binaries on the host. This not true for riscv64 CI (or for other platforms using remote-test-server).
When we cross compile, some things (and their documentation) are built for the host (e.g. rustc), while others (and their documentation) are built for the target. This generated documentation will have broken links between documentation for different platforms e.g. between rustc and cargo.
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.
The tests issue-36710 and incr-prev-body-beyond-eof were changed in a previous commit so that the correct target was passed to rustc (previously rustc was building for the host not for the specific target). Since that change it turns out that these platforms never worked (they only appeared to work because rustc was actually building for the host architecture). The wasm architectures fall over trying to build the C++ file in issue-36710. They look for clang (which isn't installed in the test-various docker container). If clang is installed, they can't find a wasm c++ standard library to link to. nvtptx64-nvidia-cuda fails in rustc saying it can't find std. The rust platforms support page says that std is supported on cuda so this is surprising.
Riscv64linux Test fixes Get tests passing again using the riscv64gc-unknown-linux-gnu docker image. Test with ``` src/ci/docker/run.sh riscv64gc-linux ``` ## linkcheck Linkcheck tests that interdocument links in the documentation are correct. Some interdocument links go between rustc and tools (such as rustdoc and cargo). When cross compiling, rustc is built for the host while some tools are built for the target. This goes for the documentation too. Because of this, links in the rustc documentation reffering to cargo or rustdoc documentation look broken. This issue is worked around by disabling linkcheck for cross compilation builds. ## run-make tests rust-lang#78911 seems to happen because `--target` was not passed to `rustc`, but the target linker was specified, causing the target linker to be called with options intended for the host. Resolves rust-lang#78911 In a separate issue, `issue-36710` was trying to run a binary built for the target on the host system. This will not work for any platform using `remote-test-server`/`client` (such as riscv64). I don't know of a way of skipping those platforms specifically, so I set this test to skip only on riscv64 for now.
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.
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 rust-lang#82868 (we cannot report suggestions like `Tr::assoc` -> `<dyn Tr>::assoc` with the current imprecise spans). r? ```@estebank```
Do not insert impl_trait_in_bindings opaque definitions twice. The reference to the item already appears inside the `OpaqueDef`. It does not need to be repeated as a statement.
…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 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.
Show details in cfg version unstable book
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/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/reference#974) - Comment typo (rust-lang/reference#977) - Fix misspelled word discrimnant (rust-lang/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 c431f8c..67ebd4b 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)
@bors rollup=never p=5 r+ |
📌 Commit f494c01 has been approved by |
⌛ Testing commit f494c01 with merge 0e8b83692f2af9b3d515a833537e8ecb06e91829... |
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
Could you exclude #80839 from your rollups next time? It's iffy and likely causes a failure. |
might as well mark it as rollup=never then 🤷 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
rollup
A PR which is a rollup
S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
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:
proc_macro_back_compat
lint toprocedural-masquerade
#83168 (Extendproc_macro_back_compat
lint toprocedural-masquerade
)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup