-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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 5 pull requests #64594
Rollup of 5 pull requests #64594
Conversation
there is a soft-error for older toolchains from https://reviews.llvm.org/D57264 in preparation for the hard error in https://reviews.llvm.org/D66188
…or Polonius as its output was changed by rust-lang@2ff337a#diff-bd3f80b956148a5d1567aa8698b8a507
This can be removed once dataflow-based const validation is merged.
This commit changes our CI to use two separate IAM users to authenticate with AWS: * ci--rust-lang--rust--sccache: has access to the rust-lang-ci-sccache2 S3 bucket and its credentials are available during the whole build. * ci--rust-lang--rust--upload: has access to the rust-lang-ci2 S3 bucket and its credentials are available just during the upload step. The new tokens are available in the `prod-credentials` library.
Update installed compiler dependencies As llvm have updated the minimum toolchain https://reviews.llvm.org/D66188
Polonius: more `ui` test suite fixes Since rust-lang#62736, new tests have been added, and the `run-pass` suite was merged into the `ui` suite. This PR adds the missing tests expectations for Polonius, and updates the existing ones where the NLL output has changed in some manner (e.g. ordering of notes) Those are the trivial cases, but a more-detailed explanation is available [in this write-up](https://hackmd.io/CjYB0fs4Q9CweyeTdKWyEg?both#26-async-awaitasync-borrowck-escaping-closure-errorrs-outputs-from-NLL-Polonius-diff) starting at test case 26: they are only differing in diagnostics and instances of other existing test cases differences. Only 3 of the 9020 tests are still "failing" at the moment (1 failure, 2 OOMs). r? @nikomatsakis
…oli-obk A more generic interface for dataflow analysis rust-lang#64470 requires a transfer function that is slightly more complex than the typical `gen`/`kill` one. Namely, it must copy state bits between locals when assignments occur (see rust-lang#62547 for an attempt to make this fit into the existing framework). This PR contains a dataflow interface that allows for arbitrary transfer functions. The trade-off is efficiency: we can no longer coalesce transfer functions for blocks and must visit each statement individually while iterating to fixpoint. Another issue is that poorly behaved transfer functions can result in an analysis that fails to converge. `gen`/`kill` sets do not have this problem. I believe that, in order to guarantee convergence, flipping a bit from `false` to `true` in the entry set cannot cause an output bit to go from `true` to `false` (negate all preceding booleans when `true` is the bottom value). Perhaps someone with a more formal background can confirm and we can add a section to the docs? This approach is not maximally generic: it still requires that the lattice used for analysis is the powerset of values of `Analysis::Idx` for the `mir::Body` of interest. This can be done at a later date. Also, this is the bare minimum to get rust-lang#64470 working. I've not adapted the existing debug framework to work with the new analysis, so there are no `rustc_peek` tests either. I'm planning to do this after rust-lang#64470 is merged. Finally, my ultimate plan is to make the existing, `gen`/`kill`-based `BitDenotation` a special case of `generic::Analysis`. Currently they share a ton of code. I should be able to do this without changing any implementers of `BitDenotation`. Something like: ```rust struct GenKillAnalysis<A: BitDenotation> { trans_for_block: IndexVec<BasicBlock, GenKillSet<A::Idx>>, analysis: A, } impl<A> generic::Analysis for GenKillAnalysis<A> { // specializations of `apply_{partial,whole}_block_effect`... } ``` r? @pnkfelix
…excrichton ci: split aws credentials in two separate users with scoped perms This commit changes our CI to use two separate IAM users to authenticate with AWS: * `ci--rust-lang--rust--sccache`: has access to the `rust-lang-ci-sccache2` S3 bucket and its credentials are available during the whole build. * `ci--rust-lang--rust--upload`: has access to the `rust-lang-ci2` S3 bucket and its credentials are available just during the upload step. The new tokens are available in the `prod-credentials` library. r? @alexcrichton
…ievink Fix a minor grammar nit, update UI tests Minor fix, but I noticed it while debugging some code
@bors r+ p=5 rollup=never |
📌 Commit 7aa65bf has been approved by |
⌛ Testing commit 7aa65bf with merge 26918565d4693ae244e39972cdf6e533567e6821... |
The job Click to expand the log.
I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
💔 Test failed - checks-azure |
Successful merges:
ui
test suite fixes #64554 (Polonius: moreui
test suite fixes)Failed merges:
r? @ghost