-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 11 pull requests #114637
Rollup of 11 pull requests #114637
Conversation
Even where actually running processes is not supported. Needed for the next commit. The manual trait implementations now belong on ExitStatusError, which still can't exist.
Signed-off-by: 袁浩 <yuanhao34@huawei.com>
Fix rust-lang#90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
Includes of `include/llvm/Support/Host.h` now emit a deprecated warning: `warning: This header is deprecated, please use llvm/TargetParser/Host.h`.
Make module inner and function run_analysis_to_runtime_passes in rustc_mir_transform public to allow re-implementing the query from the rust compiler interface.
The code fails to parse with `nightly-2021-02-05`: $ cargo +nightly-2021-02-05 build error: generic associated types in trait paths are currently not implemented --> src/main.rs:9:42 | 9 | fn _bar<T: for<'a> StreamingIterator<Item<'a> = &'a [i32]>>(_iter: T) { /* ... */ | ^^^^ but parses with `nightly-2021-02-06`: $ cargo +nightly-2021-02-06 build warning: the feature `generic_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes warning: 1 warning emitted because it was (with high probability) fixed by PR 79554 which was merged within that nightly range.
…olnay Make ExitStatus implement Default And, necessarily, make it inhabited even on platforms without processes. I noticed while preparing rust-lang/rfcs#3362 that there was no way for anyone to construct an `ExitStatus`. This would be insta-stable so needs an FCP.
add aarch64-unknown-teeos target TEEOS is a mini os run in TrustZone, for trusted/security apps. The libc of TEEOS is a part of musl. The kernel of TEEOS is micro kernel. This MR is to add a target for teeos. MRs for libc and rust-std are in progress. Compiler team MCP: [MCP](rust-lang/compiler-team#652)
Mention style for new syntax in tracking issue template `@rust-lang/style` would like the specification of new syntax in the style guide to be part of the feature stabilization process, in order to avoid situations where new syntax is stabilized and it never has style specified or formatting implemented for it. This most recently occurred with [let-else](https://blog.rust-lang.org/2023/07/01/rustfmt-supports-let-else-statements.html). We've made a lot of progress with the [nightly style procedure](https://github.com/rust-lang/style-team/blob/master/nightly-style-procedure.md) to unblock rustfmt from experimenting with formatting for new syntax, and T-style's existence means we actually have people who are willing and qualified to make decisions about formatting specification. This check-box should also perhaps include "formatting support implemented in rustfmt", but that's really up to `@rust-lang/rustfmt,` so I'm not volunteering them for any new responsibilities in this PR just yet. Putting this up mostly to discuss with T-lang, though feedback welcome from anyone. --- As more of an implementation detail: alternatively, instead of a this could be just added to the existing rustc-dev-guide chapter(s) on stabilization. r? `@ghost`
…eywiser CFI: Fix error compiling core with LLVM CFI enabled Fix rust-lang#90546 by filtering out global value function pointer types from the type tests, and adding the LowerTypeTests pass to the rustc LTO optimization pipelines.
update llvm-wrapper include to silence deprecation warning Includes of `include/llvm/Support/Host.h` now emit a deprecated warning: `warning: This header is deprecated, please use llvm/TargetParser/Host.h`. I don't believe we are using this include. I don't believe we need to bump the `download-ci-llvm` stamp since these warnings are emitted while building the `llvm-wrapper`. r? ```@nikic```
Prevent constant rebuilds of `rustc-main` (and thus everything else) PR rust-lang#114305 changed bootstrap to run `strip -g` on `librustc_driver.so` and `libllvm.so` on Linux when no debuginfo was requested. Unfortunately, that PR resulted in bootstrap always rebuilding everything starting from stage 1 `rustc-main` (including stage 1 libraries and tests) when invoking bootstrap multiple times. We noticed this because Ferrocene's CI times increased to between 2x and 3x total execution time, but the regression can also be reproduced locally by running `./x build library/sysroot --stage 1` twice. The explanation of the problem is in the code comments. r? ```@lqd``` cc ```@ozkanonur```
…r=lcnr interpret: remove incomplete protection against invalid where clauses Cc rust-lang#97477, rust-lang/project-const-generics#37 r? ``@lcnr``
Allowing re-implementation of mir_drops_elaborated query For our use case of the rust compiler interface (a rust verifier called [Prusti](https://github.com/viperproject/prusti-dev/)), it would be extremely useful if we were able to "copy" the implementation of the `mir_drops_elaborated_and_const_checked` query to override it. This would mean that the following items would need to be made public: >https://github.com/rust-lang/rust/blob/6d55184d05c9bd3c46b294dcad3bfb1d0907e871/compiler/rustc_mir_transform/src/lib.rs#L434 >https://github.com/rust-lang/rust/blob/6d55184d05c9bd3c46b294dcad3bfb1d0907e871/compiler/rustc_mir_transform/src/inline.rs#L32 (for the latter its module needs to be public or it needs to be re-exported) To explain why (we think) this is necessary: I am currently working on a new feature, where we try to modify the generated executables by inserting certain additional checks, and potentially perform some optimizations based on verification results. We are using the rust compiler interface and most of our goals can be achieved by overriding queries, in our case this is currently `mir_drops_elaborated_and_const_checked`. However, at the moment this approach is somewhat limited. When overriding queries, we can call and steal the base-query and then modify the results before allocating and returning those. The problem is that the verification works with a copy of `mir_promoted`. For the modifications we want to make to the mir, we would often want to rely on results of the verifier that refer to Locations in the `mir_promoted`. We can not modify the `mir_promoted` query using these results, because to run the verification we also need the results of `mir_borrowck()`, which means `mir_promoted` will already be constructed and cached. The Locations we get from the verifier are also no longer usable to modify `mir_drops_elaborated_and_const_checked`, because the MIR obviously changes between those 2 phases. Tracking all Locations between the two seems to be pretty much unfeasible, and would also be extremely unstable. By being able to override the query with its original implementation, we could modify the MIR before drop elaboration and the various other passes are performed. I have spent quite a bit of time investigating other solutions, and didn't find any other way solving this problem. If I still missed something I would of course be happy to hear any suggestions that do not require exposing more internal compiler functionality. However, I think being able to re-implement certain queries could also benefit other use cases in the future, for example in PR rust-lang#108328 one of the approaches discussed involved doing the same thing for `mir_promoted`.
…iler-errors tests: Uncomment now valid GAT code behind FIXME The code fails to parse with `nightly-2021-02-05`: $ cargo +nightly-2021-02-05 build error: generic associated types in trait paths are currently not implemented --> src/main.rs:9:42 | 9 | fn _bar<T: for<'a> StreamingIterator<Item<'a> = &'a [i32]>>(_iter: T) { /* ... */ | ^^^^ but parses with `nightly-2021-02-06`: $ cargo +nightly-2021-02-06 build warning: the feature `generic_associated_types` is incomplete and may not be safe to use and/or cause compiler crashes warning: 1 warning emitted because it was (with high probability) fixed by rust-lang#79554 which was merged within that nightly range. This PR is part of rust-lang#44366 which is E-help-wanted.
…lor-30, r=notriddle Migrate GUI colors test to original CSS color format Follow-up of rust-lang#111459. r? `@notriddle`
…errors add provisional cache test for new solver wrote it for chalk in rust-lang/chalk#788 and never added it to the new solver. r? ``@compiler-errors``
@bors r+ rollup=never p=11 |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: f88a8b71ce In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (e3590fc): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 632.905s -> 631.766s (-0.18%) |
Successful merges:
rustc-main
(and thus everything else) #114613 (Prevent constant rebuilds ofrustc-main
(and thus everything else))r? @ghost
@rustbot modify labels: rollup
Create a similar rollup