[beta] Beta rollup #89527
Merged
[beta] Beta rollup #89527
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
Fix WinUWP std compilation errors due to I/O safety I/O safety for Windows has landed in rust-lang#87329. However, it does not cover UWP specific parts and prevents all UWP targets from building. See YtFlow/Maple#18. This PR fixes these compile errors when building std for UWP targets.
… r=oli-obk Disable RemoveZsts in generators to avoid query cycles Querying layout of a generator requires its optimized MIR. Thus computing layout during MIR optimization of a generator might create a query cycle. Disable RemoveZsts in generators to avoid the issue (similar approach is used in ConstProp transform already). Fixes rust-lang#88972.
Disable the evaluation cache when in intercrate mode It's possible to use the same `InferCtxt` with both an intercrate and non-intercrate `SelectionContext`. However, the local (inferctxt) evaluation cache is not aware of this distinction, so this kind of `InferCtxt` re-use will pollute the cache wth bad results. This commit avoids the issue by disabling the evaluation cache entirely during intercrate mode.
…trochenkov
Fix linting when trailing macro expands to a trailing semi
When a macro is used in the trailing expression position of a block
(e.g. `fn foo() { my_macro!() }`), we currently parse it as an
expression, rather than a statement. As a result, we ended up
using the `NodeId` of the containing statement as our `lint_node_id`,
even though we don't normally do this for macro calls.
If such a macro expands to an expression with a `#[cfg]` attribute,
then the trailing statement can get removed entirely. This lead to
an ICE, since we were usng the `NodeId` of the expression to emit
a lint.
Ths commit makes us skip updating `lint_node_id` when handling
a macro in trailing expression position. This will cause us to
lint at the closest parent of the macro call.
…jackh726 Don't use projection cache or candidate cache in intercrate mode Fixes rust-lang#88969 It appears that *just* disabling the evaluation cache (in rust-lang#88994) leads to other issues involving intercrate mode caching. I suspect that since we now always end up performing the full evaluation in intercrate mode, we end up 'polluting' the candidate and projection caches with results that depend on being in intercrate mode in some way. Previously, we might have hit a cached evaluation (stored during non-intercrate mode), and skipped doing this extra work in intercrate mode. The whole situation with intercrate mode caching is turning into a mess. Ideally, we would remove intercrate mode entirely - however, this might require waiting on Chalk.
2229: Mark insignificant dtor in stdlib I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop. Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501 One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion. r? `@Mark-Simulacrum` cc `@nikomatsakis`
Temporarily rename int_roundings functions to avoid conflicts These functions are unstable, but because they're inherent they still introduce conflicts with stable trait functions in crates. Temporarily rename them to fix these conflicts, until we can resolve those conflicts in a better way.
…ikomatsakis [rfc 2229] Drop fully captured upvars in the same order as the regular drop code Currently, with the new 2021 edition, if a closure captures all of the fields of an upvar, we'll drop those fields in the order they are used within the closure instead of the normal drop order (the definition order of the fields in the type). This changes that so we sort the captured fields by the definition order which causes them to drop in that same order as well. Fixes rust-lang/project-rfc-2229#42 r? `@nikomatsakis`
…Gomez Use the correct edition for syntax highlighting doctests Previously it would unconditionally use edition 2015, which was incorrect. Helps with rust-lang#89135 in that you can now override the doctest to be 2018 edition instead of being forced to fix the error. This doesn't resolve any of the deeper problems that rustdoc disagrees with most rust users on what a code block is. cc `@Mark-Simulacrum`
Don't normalize opaque types with escaping late-bound regions Fixes rust-lang#88862 Turns out, this has some really bad perf implications in large types (issue rust-lang#88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf. Needs a perf run once rust-lang/rustc-perf#1033 is merged r? `@nikomatsakis`
…ate, r=Mark-Simulacrum Update Let's Encrypt ROOT CA certificate in dist-(i686|x86_64)-linux docker images The DST Root CA X3 used by Let's Encrypt has expired ([Let's Encrypt announcement](https://letsencrypt.org/docs/dst-root-ca-x3-expiration-september-2021/)). This patch installs the new root certificate (ISRG Root X1) and disables the old one. Disabling the old one is necessary because otherwise curl still fails to download from servers with Let's Encrypt certs even though they are cross-signed. Fixes rust-lang#89484.
|
rust-highfive
added
the
S-waiting-on-review
The backport of rust-lang#89277 needed adjustment due to another PR (rust-lang#87915 - Use smaller spans for some structured suggestions) causing the test to have a slightly different span.
|
@bors r+ p=1 rollup=never |
|
📌 Commit cfa1cd0 has been approved by |
|
🌲 The tree is currently closed for pull requests below priority 4. This pull request will be tested once the tree is reopened. |
bors
added
S-waiting-on-bors
|
@bors p=4 |
|
⌛ Testing commit cfa1cd0 with merge 18788b98c6f21567effa67b2393e46a9411809ca... |
This comment has been minimized.
This comment has been minimized.
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
…crum Fix Windows LLVM issue. GitHub image 20210928.2 added LLVM 12.0.1 to the stock image. However, the `lldb` executable doesn't work, it fails with: > C:/Program Files/LLVM/bin/lldb.exe: error while loading shared libraries: ?: cannot open shared object file: No such file or directory We probably don't want to start testing LLDB on windows anyways (at least not without intent). The hacky solution for now is to just delete the system LLVM.
|
@bors r+ |
|
📌 Commit 06b37f1 has been approved by |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
@ehuss I think you forgot to update milestones to 1.56, but I've now done that so no worries :) |
|
Oh, apologies! I didn't realize that was part of the process. I'll send an update to the forge in a bit to clarify that. |
This was referenced Oct 14, 2021
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.
Cargo update: