Rollup of 10 pull requests #133894
Closed
Rollup of 10 pull requests #133894
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
this implements checks necessary to guarantee that we can actually perform a tail call. while extremely restrictive, this is what is documented in the RFC, and all these checks are needed for one reason or another.
first steps of codegen for `#[naked]` functions using `global_asm!` configure external linkage if no linkage is explicitly set create a `FunctionCx` and properly evaluate consts inline attribute is no longer relevant for naked functions the naked attribute no longer needs to be set by llvm/... we're generating global asm now, so this attribute is meaningless for the codegen backend
correctly emit `.hidden` this test was added in rust-lang#105193 but actually NO_COVERAGE is no longer a thing in the compiler. Sadly, the link to the issue is broken, so I don't know what the problem was originally, but I don't think this is relevant any more with the global asm approach rename test file because it now specifically checks for directives only used by non-macos, non-windows x86_64 add codegen tests for 4 interesting platforms add codegen test for the `#[instruction_set]` attribute add test for `#[link_section]` use `tcx.codegen_fn_attrs` to get attribute info Fix rust-lang#124375 inline const monomorphization/evaluation getting rid of FunctionCx mark naked functions as `InstantiatedMode::GloballyShared` this makes sure that the function prototype is defined correctly, and we don't see LLVM complaining about a global value with invalid linkage monomorphize type given to `SymFn` remove hack that always emits `.globl` monomorphize type given to `Const` remove `linkage_directive` make naked functions always have external linkage mark naked functions as `#[inline(never)]` add test file for functional generics/const/impl/trait usage of naked functions
… it earlier, then some other logic causes invalid visibility for the item (exporting when it shouldn't).
- codegen tests: change `windows` to `win`
- cleanup
- fix review comments
- better way of checking for thumb
- get the mangled name from the codegen backend
- propagate function alignment
- fix gcc backend
- fix asan test
- check that assembler mode restored
…kage" This reverts commit 9142cae.
we get these declarations ``` ; opt level 0 declare x86_intrcc void @page_fault_handler(ptr byval([8 x i8]) align 8, i64) unnamed_addr #1 ; opt level > 0 declare x86_intrcc void @page_fault_handler(ptr noalias nocapture noundef byval([8 x i8]) align 8 dereferenceable(8), i64 noundef) unnamed_addr #1 ``` The space after `i64` in the original regex made the regex not match for opt level 0. Removing the space fixes the issue. ``` declare x86_intrcc void @page_fault_handler(ptr {{.*}}, i64 {{.*}}){{.*}}#[[ATTRS:[0-9]+]] ```
…vaarg for xtensa. LLVM does not include an implementation of the va_arg instruction for Xtensa. From what I understand, this is a conscious decision and instead language frontends are encouraged to implement it themselves. The rationale seems to be that loading values correctly requires language and ABI-specific knowledge that LLVM lacks. This is true of most architectures, and rustc already provides implementation for a number of them. This commit extends the support to include Xtensa. See https://lists.llvm.org/pipermail/llvm-dev/2017-August/116337.html for some discussion on the topic. Unfortunately there does not seem to be a reference document for the semantics of the va_list and va_arg on Xtensa. The most reliable source is the GCC implementation, which this commit tries to follow. Clang also provides its own compatible implementation. This was tested for all the types that rustc allows in variadics. Co-authored-by: Brian Tarricone <brian@tarricone.org> Co-authored-by: Jonathan Bastien-Filiatrault <joe@x2a.org> Co-authored-by: Paul Lietar <paul@lietar.net>
Linux v6.13-rc1 contains commit 28e848386b92 ("rust: block: fix formatting
of `kernel::block::mq::request` module"), which in turn contains commit
c95bbb59a9b2 ("rust: enable arbitrary_self_types and remove `Receiver`"),
which is why we had a hash rather than a tag.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
…e actual output for lines which didn't match
example output:
```
failures:
---- [ui] tests/ui/layout/enum.rs stdout ----
diff of stderr:
- error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: $PREF_ALIGN }
+ error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: $PREF_ALIN }
2 --> $DIR/enum.rs:9:1
3 |
4 LL | enum UninhabitedVariantAlign {
Note: some mismatched output was normalized before being compared
- error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: Align(8 bytes) }
- --> /home/jyn/src/rust2/tests/ui/layout/enum.rs:9:1
+ error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: $PREF_ALIN }
```
Nested job objects aren't supported on Windows 7 but we've long since moved on from that.
…ilee Teach rustc about the Xtensa VaListImpl Following on from the target Xtensa target PRs (rust-lang#125141, rust-lang#126380), this PR teaches rustc about the structure of the VA list on the Xtensa arch, as well as adding the required lowering to be able to actually use it.
codegen `#[naked]` functions using global asm tracking issue: rust-lang#90957 Fixes rust-lang#124375 This implements the approach suggested in the tracking issue: use the existing global assembly infrastructure to emit the body of `#[naked]` functions. The main advantage is that we now have full control over what gets generated, and are no longer dependent on LLVM not sneakily messing with our output (inlining, adding extra instructions, etc). I discussed this approach with ``@Amanieu`` and while I think the general direction is correct, there is probably a bunch of stuff that needs to change or move around here. I'll leave some inline comments on things that I'm not sure about. Combined with rust-lang#127853, if both accepted, I think that resolves all steps from the tracking issue. r? ``@Amanieu``
…r=Kobzol CI: use free runners for i686-gnu jobs try-job: i686-gnu-1 try-job: i686-gnu-2 try-job: i686-gnu-nopt-1 try-job: i686-gnu-nopt-2
…ompiler-errors implement checks for tail calls Quoting the [RFC draft](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md): > The argument to become is a function (or method) call, that exactly matches the function signature and calling convention of the callee. The intent is to ensure a matching ABI. Note that lifetimes may differ as long as they pass borrow checking, see [below](https://github.com/phi-go/rfcs/blob/guaranteed-tco/text/0000-explicit-tail-calls.md#return-type-coercion) for specifics on the return type. > Tail calling closures and tail calling from closures is not allowed. This is due to the high implementation effort, see below, this restriction can be lifted by a future RFC. > Invocations of operators were considered as valid targets but were rejected on grounds of being too error-prone. In any case, these can still be called as methods. > Tail calling [variadic functions](https://doc.rust-lang.org/beta/unstable-book/language-features/c-variadic.html) and tail calling from variadic functions is not allowed. As support for variadic function is stabilized on a per target level, support for tail-calls regarding variadic functions would need to follow a similar approach. To avoid this complexity and to minimize implementation effort for backends, this interaction is currently not allowed but support can be added with a future RFC. ----- The checks are implemented as a query, similarly to `check_unsafety`. The code is cherry-picked straight out of rust-lang#112657 which was written more than a year ago, so I expect we might need to change some things ^^"
CI: split x86_64-msvc job try-job: x86_64-msvc-1 try-job: x86_64-msvc-2
compiletest: show the difference between the normalized output and the actual output for lines which didn't match
example output:
```
failures:
---- [ui] tests/ui/layout/enum.rs stdout ----
diff of stderr:
- error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: $PREF_ALIGN }
+ error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: $PREF_ALIN }
2 --> $DIR/enum.rs:9:1
3 |
4 LL | enum UninhabitedVariantAlign {
Note: some mismatched output was normalized before being compared
- error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: Align(8 bytes) }
- --> /home/jyn/src/rust2/tests/ui/layout/enum.rs:9:1
+ error: align: AbiAndPrefAlign { abi: Align(2 bytes), pref: $PREF_ALIN }
```
CI: rfl: move job forward to Linux v6.13-rc1
Linux v6.13-rc1 contains commit 28e848386b92 ("rust: block: fix formatting of `kernel::block::mq::request` module"), which in turn contains commit c95bbb59a9b2 ("rust: enable arbitrary_self_types and remove `Receiver`"), which is why we had a hash rather than a tag.
r? ``@Kobzol`` ``@lqd``
try-job: x86_64-rust-for-linux
``@rustbot`` label A-rust-for-linux
``@bors`` try
…r=workingjubilee clarify simd_relaxed_fma non-determinism This is the safer spec in the sense that it is more likely to be satisfied by the backend -- and if people are okay with a non-deterministic result, I assume they don't care whether it's the same choice across all lanes or not? Cc `@calebzulawski` `@workingjubilee`
Fix "std" support status of some tier 3 targets rust-lang#127265 marked targets with empty "std" support status as no-std targets in target-spec metadata: > * Where a targets 'std' or 'host tools' support is listed as '?' in the rust docs, these are left as 'None' with this PR. The corresponding changes in cargo will only reject an attempt to build std if the 'std' field is 'Some(false)'. In the case it is 'None', cargo will continue trying to build However, this is not accurate because "std" support status has a marker indicating that it is a no-std target. (empty status is just invalid.) https://doc.rust-lang.org/nightly/rustc/platform-support.html#tier-3 > The `std` column in the table below has the following meanings: > > * ✓ indicates the full standard library is available. > * \* indicates the target only supports [`no_std`] development. > * ? indicates the standard library support is unknown or a work-in-progress. > > [`no_std`]: https://rust-embedded.github.io/book/intro/no-std.html This PR fixes the status of targets whose "std" support status is currently set to empty and update target-spec metadata. The new status is set based on the following criteria: - Set to ✓ for targets that I regularly check in [rust-cross-toolchain](https://github.com/taiki-e/rust-cross-toolchain) that the `cargo test` works. (riscv32-unknown-linux-gnu,{riscv64,s390x}-unknown-linux-musl) - Targets where `cargo run` works but `cargo test` does not work tend to have incomplete std support (e.g., riscv32 musl taiki-e/rust-cross-toolchain@f3068b6), so I included them in the group below that means “work in progress” rather than in this group. - Set powerpc64le FreeBSD to ✓ on both std and host_tools, because the [Rust package](https://www.freshports.org/lang/rust/) is available. - Set to ? (which means "unknown" or “work in progress”) for all other affected targets because these are Linux, Android, FreeBSD, or Fuchsia, all of which are operating systems that support std if properly supported. r? Noratrieb cc `@harmou01`
Improve bootstrap job objects This attempts to fix a few comments on bootstrap job objects. I also fixed an issue where if duplicating the job object handle into the python process failed, it would close the job object. This would then result in the job object closing all attached processes, which at that point includes the current process. The fix is to simply never close the job object handle at any point after the current process is assigned to it.
rustbot
added
A-compiletest
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
|
🔒 Merge conflict This pull request and the master branch diverged in a way that cannot be automatically merged. Please rebase on top of the latest master branch, and let the reviewer approve again. How do I rebase?Assuming
You may also read Git Rebasing to Resolve Conflicts by Drew Blessing for a short tutorial. Please avoid the "Resolve conflicts" button on GitHub. It uses Sometimes step 4 will complete without asking for resolution. This is usually due to difference between how Error message |
bors
added
S-waiting-on-author
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:
#[naked]functions using global asm #128004 (codegen#[naked]functions using global asm)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup