Rollup of 12 pull requests #79030
Closed
Rollup of 12 pull requests #79030
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
x86_64-fortanix-unknown-sgx and wasm32-unknown-unknown still have os == "unknown" because both have libstd
Majority of targets use "unknown" vendor and changing it from "unknown" to omitted doesn't make sense. From the LLVM docs (https://clang.llvm.org/docs/CrossCompilation.html#target-triple): >Most of the time it can be omitted (and Unknown) will be assumed, which sets the defaults for the specified architecture. >When a parameter is not important, it can be omitted, or you can choose unknown and the defaults will be used. If you choose a parameter that Clang doesn’t know, like blerg, it’ll ignore and assume unknown
…s and vendor values
As discussed in PR rust-lang#78267, for example: * rust-lang#78267 (comment) * rust-lang#78267 (comment)
Co-authored-by: Joshua Nelson <joshua@yottadb.com>
Including llvm-as adds the ability to include assembly language fragments that can be inlined using LTO.
Per Mark's recommendation at: rust-lang#78963 (comment)
Note, in the coverage-reports test, the comment about MacOS was wrong. The setting is based on config.toml llvm `optimize` setting. There doesn't appear to be any environment variable I can check, and I don't think we should add one. Testing the binary itself is a more reliable way to check anyway. For the coverage-spanview test, I removed the dependency on sed altogether, which is much less ugly than trying to work around the MacOS sed differences. I tested these changes on Linux, Windows, and Mac.
Document what `is_like_windows` and `is_like_msvc` mean in more detail.
The inliner looks if a sanitizer is enabled before considering `no_sanitize` attribute as possible source of incompatibility. The MIR inlining could happen in a crate with sanitizer disabled, but code generation in a crate with sanitizer enabled, thus the attribute would be incorrectly ignored. To avoid the issue never inline functions with different `no_sanitize` attributes.
The information about cold attribute is lost during inlining, Avoid the issue by never inlining cold functions.
The callee body is already transformed; the condition is always false.
…ens` The optimization conflates empty token streams with unknown token stream, which is at least suspicious, and doesn't affect performance because 0-length token streams are very rare.
During inlining, the callee body is normalized and has types revealed, but some of locals corresponding to the arguments might come from the caller body which is not. As a result the caller body does not pass validation without additional normalization.
Restructured the code a little, to allow getting both the mir::Body and coverage graph.
Do not call `unwrap` with `signatures` option enabled Fixes rust-lang#75229 Didn't add a test since I couldn't set `RUST_SAVE_ANALYSIS_CONFIG` even with `rustc-env`.
rustc_parse: Remove optimization for 0-length streams in `collect_tokens` The optimization conflates empty token streams with unknown token stream, which is at least suspicious, and doesn't affect performance because 0-length token streams are very rare. r? ``@Aaron1011``
…andry Fix and re-enable two coverage tests on MacOS Note, in the coverage-reports test, the comment about MacOS was wrong. The setting is based on config.toml llvm `optimize` setting. There doesn't appear to be any environment variable I can check, and I don't think we should add one. Testing the binary itself is a more reliable way to check anyway. For the coverage-spanview test, I removed the dependency on sed altogether, which is much less ugly than trying to work around the MacOS sed differences. I tested these changes on Linux, Windows, and Mac. r? ``@tmandry`` FYI ``@wesleywiser``
rustc_target: Change os and vendor values to "none" and "unknown" for some targets Closes rust-lang#77730 r? ``@ehuss``
rustc_target: Mark UEFI targets as `is_like_windows`/`is_like_msvc` And document what `is_like_windows` and `is_like_msvc` actually mean in more detail. Addresses FIXMEs left from rust-lang#71030. r? ``@nagisa``
…, r=jyn514 Add a test for r# identifiers I'm not entirely sure I properly ran the test locally (I think so though), waiting for CI to confirm. :) ``@rustbot`` modify labels: T-rustdoc r? ``@jyn514``
…0.4, r=tmandry Added some unit tests as requested As discussed in PR rust-lang#78267, for example: * rust-lang#78267 (comment) * rust-lang#78267 (comment) r? ``@tmandry`` FYI: ``@wesleywiser`` This is pretty much self contained, but depending on feedback and timing, I may have a chance to add a few more unit tests requested against `counters.rs`. I'm looking at those now.
Never inline C variadics, cold functions, functions with incompatible attributes ... ... and fix generator inlining. Closes rust-lang#67863. Closes rust-lang#78859.
Include llvm-as in llvm-tools-preview component Including `llvm-as` adds the ability to include assembly language fragments that can be inlined using LTO while making sure the correct version of LLVM is always used.
Normalize function type during validation During inlining, the callee body is normalized and has types revealed, but some of locals corresponding to the arguments might come from the caller body which is not. As a result the caller body does not pass validation without additional normalization. Closes rust-lang#78442.
Fix rustc_ast_pretty print_qpath resulting in invalid macro input related rust-lang#76874 (third case) ### Issue: The input for a procedural macro is incorrect, for the rust code: ```rust mod m { pub trait Tr { type Ts: super::Tu; } } trait Tu { fn dummy() { } } #[may_proc_macro] fn foo() { <T as m::Tr>::Ts::dummy(); } ``` the macro will get the input: ```rust fn foo() { <T as m::Tr>::dummy(); } ``` Thus `Ts` has disappeared. ### Fix: This is due to invalid pretty print of qpath. This PR fix it.
Implement BTreeMap::retain and BTreeSet::retain Adds new methods `BTreeMap::retain` and `BTreeSet::retain`. These are implemented on top of `drain_filter` (rust-lang#70530). The API of these methods is identical to `HashMap::retain` and `HashSet::retain`, which were implemented in rust-lang#39560 and stabilized in rust-lang#36648. The docs and tests are also copied from HashMap/HashSet. The new methods are unstable, behind the `btree_retain` feature gate, with tracking issue rust-lang#79025. See also rust-lang/rfcs#1338.
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:
unwrapwithsignaturesoption enabled #78352 (Do not callunwrapwithsignaturesoption enabled)collect_tokens#78736 (rustc_parse: Remove optimization for 0-length streams incollect_tokens)is_like_windows/is_like_msvc#78959 (rustc_target: Mark UEFI targets asis_like_windows/is_like_msvc)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup