Rollup of 11 pull requests - #162632
Closed
Zalathar wants to merge 40 commits into
Closed
Conversation
…llow for more correct ABI handling in cg_gcc
Co-authored-by: Jubilee <workingjubilee@gmail.com>
* Refactor `HygieneEncodeContext` * Review: remove comment outdated part * Review: return `raw_encode_syntax_context` as a free function * Review: small cleanups * Review: add comment about expansions data `Option` * Review: don't set explicit capacity * Review: return `queued` -> `latest` * Remove not needed changes * Fix `Rc` cloning * Return comment
As a Tier 1 (without host tools) target. - Fix an outdated claim that all T1 targets have host tools, since `i686-pc-windows-msvc` no longer does. - Remove a duplicate Tier 1 section. - Put `i686-pc-windows-msvc` under its own Tier 1 without host tools section.
We no longer ship host tools for this target.
…nkov Refactor `HygieneEncodeContext` Some refactorings around `HygieneEncodeContext` with minor perf improvements, the most notable thing is that `Lock`s were removed. First part for rust-lang#161450. r? @petrochenkov
…d-braces-temp-scope-lite, r=oli-obk Skip linting unused braces for FunctionArg and MethodArg context for 2024 later Fixes rust-lang#154247 `unused_braces` is a AST level lint, but in Rust 2024 braces around function and method arguments can affect temporary drop scope. I tried to find a more complete fix for it, but seems all too heavy, which involve AST visitor or need `hir` related stuff. Instead of teaching this lint to reason about semantics, so it's better to stop linting those argument-position braces in 2024 later edition.
…ingjubilee Refactor the way cg_ssa handles indirect returns (returns via `sret`) — Take 2 This continues the work that @FractalFir done in rust-lang#144976. **I managed to make this work, so this confirms the original approach works and is ready to merge.** r? workingjubilee (assigning the same reviewer as the original PR) # The problem The current way `cg_ssa` handles `PassMode::Indirect` is fundamentally incompatible with the requirements of the GCC backend. This is currently worked around in a very brittle way, that breaks on ARM. In order to function correctly, `cg_gcc` requires the `sret`(indirect return) pointer to be treated in a special way. # The solution This PR separates the `sret` pointer from all the other arguments, allowing each backend to decide how it wants to handle that pointer. This will allow GCC to do it's own thing, while changing nothing on the LLVM side. Currently, the PR just makes both backends preappend the sret arg, mimicking the previous behaviour. The PR is based on this [zulip suggestion](https://rust-lang.zulipchat.com/#narrow/channel/421156-gsoc/topic/Project.3A.20Bootstrap.20of.20rustc.20with.20rustc_codegen_gcc/near/526487725). # Assumptions I made. The PR makes certain assumptions about the ABI handling. 1. No LLVM intrinsic returns via sret. [According to my sources](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Can.20LLVM.20intrinsics.20return.20via.20PassMode.3A.3AIndirect.3F), this is always true. 2. Tail calls don't currently return via `sret`. From [asking about](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Can.20tail.20calls.20return.20indirectly.28via.20a.20pointer.29.3F/near/532984507), it seems like the tail call handling does not currently support indirect returns. So, I did not add support for that. 3. TLS shims don't perform indirect returns, and asserts and drops also don't perform indirect returns(since they return nothing) - those assumptions seemed reasonable. 4. Inline assembly calls don't use indirect returns. I *assumed* functions like `inline_asm_call` will not need the `sret` handling code. I am not 100% sure about this, tough.
Implement arbitrary casts in custom mir [See zulip](https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/extending.20custom.20MIR/with/613727602) Implement custom casts using an enum in `intrinsics::mir` that closely matches the `CastKind` enum in the compiler. We have 5 different ways to cast in custom MIR, 3 with functions (which hard code a cast kind), 1 implicit coerce (which only does subtyping i think), 1 with `as` (which does a few more). They are all different and the error messages don't tell you what to do. Some are (i think) not possible at all. This came up [while testing miri](https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Valdity.20checks.20for.20references/near/613662285). We currently have to guess the casting syntax until we find the one that generates the MIR we want. This PR changes that by adding a custom mir operation that allows picking an arbitrary cast. r? RalfJung
…thanBrouwer Use attribute parser for `#[non_exhaustive]` attribute check Updates rust-lang#153101 r? @JonathanBrouwer
…n, r=adwinwhite deeper `rustc_builtin_macros` cleanups As a followup to rust-lang#161464, this contains a few more surface cleanups and begins simplifying the mess that `SubstructureFields` currently is by removing the `StaticFields` type in favor of just using the `VariantData` directly.
small refactor of doc attribute arguments warnings
split `macroless_generic_const_args` in two Two's a crowd! But One's a lonely. Having `macroless_generic_const_args` apply to const items was quite annoying for users especially as we moved away from `type const` to just regular const items. We would quite commonly be "guessing wrong" with no easy way for users to opt out of `const ASSOC: usize = ...` being represented directly instead of an opaque body I just swapped any failing tests over to using macroless_const_item_generic_const_args, didnt look through the whole set :> We should probably bikeshed the feature name rn because it's currently inconsistent with what we wanted to rename all of the other gca features too :> Maybe this should be `gca_macroless_const_items` cc rust-lang#162540 r? khyperia
The fuchsia team maintains `riscv64gc-unknown-fuchsia` The fuchsia team maintains `riscv64gc-unknown-fuchsia` target (cc rust-lang#113739).
…r=khyperia Fix `i686-pc-windows-msvc` platform support docs and target spec metadata ## Summary Follow-up fixes to rust-lang#162288. - Fix an outdated claim that all T1 targets have host tools, since `i686-pc-windows-msvc` no longer does. - Remove a duplicate Tier 1 section. - Put `i686-pc-windows-msvc` under its own Tier 1 without host tools ## Context * `i686-pc-windows-msvc` Tier 1 (with host tools) => Tier 1 (without host tools) RFC: rust-lang/rfcs#3999 * cc rust-lang#158378
…ion-closure-capture, r=beetrees regression test for opaque field projection in closure capture Closes rust-lang#156837
Member
Author
|
Rollup of everything. @bors r+ rollup=never p=5 |
Contributor
Member
Author
|
Closing as identical to #162631. |
Contributor
|
This pull request was unapproved due to being closed. |
This file contains hidden or 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
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:
HygieneEncodeContext#162520 (RefactorHygieneEncodeContext)sret) — Take 2 #160023 (Refactor the way cg_ssa handles indirect returns (returns viasret) — Take 2)#[non_exhaustive]attribute check #161482 (Use attribute parser for#[non_exhaustive]attribute check)rustc_builtin_macroscleanups #161867 (deeperrustc_builtin_macroscleanups)macroless_generic_const_argsin two #162541 (splitmacroless_generic_const_argsin two)riscv64gc-unknown-fuchsia#162549 (The fuchsia team maintainsriscv64gc-unknown-fuchsia)i686-pc-windows-msvcplatform support docs and target spec metadata #162577 (Fixi686-pc-windows-msvcplatform support docs and target spec metadata)r? @ghost
Create a similar rollup