Skip to content
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 8 pull requests #100799

Closed
wants to merge 38 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

pnkfelix and others added 30 commits July 6, 2022 10:53
…being to confirm that the

entries actually correspond to what is specified in each of the respective ABIs...

updated to incorporate feedback: fix x86_64/i686 tests to use correct name for the corresponding llvm component.
incorporated review feedback, with comment explaining why this is calling CC
instead of COMPILE_OBJ or NATIVE_STATICLIB. As drive-by, removed some other
unnecessary commands from the recipe.
parameterized on target details to decide value-extension policy on calls, in order to address how Apple's aarch64 ABI differs from that on Linux and Windows.

Updated to incorporate review feedback: adjust comment on new enum specifying
param extension policy.

Updated to incorporate review feedback: shorten enum names and those of its
variants to make it less unwieldy.

placate tidy.
…t_test_helpers. This instance is almost certainly insufficient because we need to force optimization flags for both the C and Rust sides of the code. but lets find out for sure.
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
This commit adds the following functions all of which have a signature
`pointer, usize -> pointer`:
- `<*mut T>::mask`
- `<*const T>::mask`
- `intrinsics::ptr_mask`

These functions are equivalent to `.map_addr(|a| a & mask)` but they
utilize `llvm.ptrmask` llvm intrinsic.

*masks your pointers*
Co-authored-by: bjorn3 <bjorn3@users.noreply.github.com>
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
This reverts commit 16e10bf.

# Conflicts:
#	compiler/rustc_target/src/spec/apple_sdk_base.rs
I couldn't find where exactly it's documented, but apperantly pointers to void
type are invalid in llvm - void is only allowed as a return type of functions.
… the

extension operation depending on target architecture.
remove unnecessary string searchings for checking if function arguments have `&` and `&mut`
Add pointer masking convenience functions

This PR adds the following public API:
```rust
impl<T: ?Sized> *const T {
    fn mask(self, mask: usize) -> *const T;
}

impl<T: ?Sized> *mut T {
    fn mask(self, mask: usize) -> *const T;
}

// mod intrinsics
fn mask<T>(ptr: *const T, mask: usize) -> *const T
```
This is equivalent to `ptr.map_addr(|a| a & mask)` but also uses a cool llvm intrinsic.

Proposed in rust-lang#95643 (comment)

cc ``@Gankra`` ``@scottmcm`` ``@RalfJung``

r? rust-lang/libs-api
…ll-abi-does-not-zeroext, r=wesleywiser

Aarch64 call abi does not zeroext (and one cannot assume it does so)

Fix rust-lang#97463
…ochenkov

Reenable disabled early syntax gates as future-incompatibility lints

- MCP: rust-lang/compiler-team#535

The approach taken by this PR is

- Introduce a new lint, `unstable_syntax_pre_expansion`, and reenable the early syntax gates to emit it
- Use the diagnostic stashing mechanism to stash warnings the early warnings
- When the hard error occurs post expansion, steal and cancel the early warning
- Don't display any stashed warnings if errors are present to avoid the same noise problem that hiding type ascription errors is avoiding

Commits are working commits, but in a coherent steps-to-implement manner. Can be squashed if desired.

The preexisting `soft_unstable` lint seems like it would've been a good fit, but it is deny-by-default (appropriate for `#[bench]`) and these gates should be introduced as warn-by-default.

It may be desirable to change the stash mechanism's behavior to not flush lint errors in the presence of other errors either (like is done for warnings here), but upgrading a stash-using lint from warn to error perhaps is enough of a request to see the lint that they shouldn't be hidden; additionally, fixing the last error to get new errors thrown at you always feels bad, so if we know the lint errors are present, we should show them.

Using a new flag/mechanism for a "weak diagnostic" which is suppressed by other errors may also be desirable over assuming any stashed warnings are "weak," but this is the first user of stashing warnings and seems an appropriate use of stashing (it follows the "know more later to refine the diagnostic" pattern; here we learn that it's in a compiled position) so we get to define what it means to stash a non-hard-error diagnostic.

cc ```@petrochenkov``` (seconded MCP)
add miri-test-libstd support to libstd

- The first commit mirrors what we already have in liballoc.
- The second commit adds some regression tests that only really make sense to be run in Miri, since they rely on Miri's extra checks to detect anything.
- The third commit makes the MPSC tests work in reasonable time in Miri by reducing iteration counts.
- The fourth commit silences some warnings due to code being disabled with `cfg(miri)`
…lcnr

Ban references to `Self` in trait object substs for projection predicates too.

Fixes rust-lang#100484
Fixes rust-lang#100485

r? ``@lcnr``
Revert "Revert "Allow dynamic linking for iOS/tvOS targets.""

This reverts commit 16e10bf (PR rust-lang#77716).

The original original PR enabled `cdylib` builds for iOS. However this caused problems because:

> This new feature in Rust 1.46 added a lot of headache for iOS builds with cdylib targets. cdylib target is near impossible to build if you are using any crate with native dependencies (ex. openssl, libsodium, zmq). You can't just find .so files for all architectures to perform correct linking. Usual workflow is the following:
>
> 1. You build staticlib and rely that native dependencies will be linked as frameworks later
> 2. You setup right cocoapods in ObjectiveC/Swift wrapper.
>
> As cargo doesn't support platform-dependent crate types rust-lang#4881 as a result a lot of projects now broken on Rust 1.46

However, this will be soon a thing of the past since 1.64 brings us the long awaited much anticipated `--crate-type` flag.

> I see that this got merged recently: rust-lang/cargo#10083. The --crate-type flag will get stabilized in 1.64. In 1.64, you could still get a successful iOS staticlib with cargo build --crate-type=statclib even if the crate has cdylib targets too. If I'm not mistaken, this solves the problem too so this PR could be reverted in 1.64 with relatively little headache.

So summing up, I think this PR can be reverted in 1.64. 🤞
…me, r=TaKO8Ki

elaborate how revisions work with FileCheck stuff in src/test/codegen

elaborate how revisions work with FileCheck stuff in src/test/codegen
…searching, r=compiler-errors

Refactor: remove unnecessary string searchings

This patch removes unnecessary string searchings for checking if function arguments have `&` and `&mut`.
@rustbot rustbot added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. rollup A PR which is a rollup labels Aug 20, 2022
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Aug 20, 2022

📌 Commit d403a96 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Aug 20, 2022
@bors
Copy link
Contributor

bors commented Aug 20, 2022

⌛ Testing commit d403a96 with merge 309789aebbc24731febcc95bfc396a9a2c619d0f...

@bors
Copy link
Contributor

bors commented Aug 20, 2022

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 20, 2022
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
test [ui] src/test/ui/abi/lib-defaults.rs ... ok
test [ui] src/test/ui/abi/issues/issue-62350-sysv-neg-reg-counts.rs ... ok
test [ui] src/test/ui/abi/mir/mir_codegen_calls_variadic.rs ... ok
test [ui] src/test/ui/abi/foreign/invoke-external-foreign.rs ... ok
test [ui] src/test/ui/abi/issues/issue-97463-broken-abi-leaked-uninit-data.rs ... ok
test [ui] src/test/ui/abi/foreign/foreign-dupe.rs ... ok
test [ui] src/test/ui/abi/numbers-arithmetic/i128-ffi.rs ... ok
test [ui] src/test/ui/abi/extern/extern-call-deep2.rs ... ok
test [ui] src/test/ui/abi/unsupported.rs#aarch64 ... ok
---
test [ui] src/test/ui/feature-gates/issue-43106-gating-of-unstable.rs ... ok
test [ui] src/test/ui/feature-gates/issue-49983-see-issue-0.rs ... ok
test [ui] src/test/ui/feature-gates/rustc-private.rs ... ok
test [ui] src/test/ui/feature-gates/stability-attribute-consistency.rs ... ok
test [ui] src/test/ui/feature-gates/soft-syntax-gates-without-errors.rs ... ok
test [ui] src/test/ui/feature-gates/soft-syntax-gates-with-errors.rs ... ok
test [ui] src/test/ui/feature-gates/stable-features.rs ... ok
test [ui] src/test/ui/ffi_const.rs ... ok
test [ui] src/test/ui/feature-gates/unknown-feature.rs ... ok
test [ui] src/test/ui/ffi_const2.rs ... ok
---
test [codegen] src/test/codegen/simd-intrinsic/simd-intrinsic-float-pow.rs ... ok
test [codegen] src/test/codegen/slice-iter-len-eq-zero.rs ... ok
test [codegen] src/test/codegen/simd-intrinsic/simd-intrinsic-float-sin.rs ... ok
test [codegen] src/test/codegen/simd-intrinsic/simd-intrinsic-transmute-array.rs ... ok
test [codegen] src/test/codegen/some-abis-do-extend-params-to-32-bits.rs#aarch64-apple ... ok
test [codegen] src/test/codegen/some-abis-do-extend-params-to-32-bits.rs#x86_64 ... ok
test [codegen] src/test/codegen/some-abis-do-extend-params-to-32-bits.rs#i686 ... ok
test [codegen] src/test/codegen/some-abis-do-extend-params-to-32-bits.rs#arm ... ok
test [codegen] src/test/codegen/slice-ref-equality.rs ... ok
test [codegen] src/test/codegen/some-abis-do-extend-params-to-32-bits.rs#aarch64-linux ... ok
test [codegen] src/test/codegen/some-abis-do-extend-params-to-32-bits.rs#aarch64-windows ... ok
test [codegen] src/test/codegen/sparc-struct-abi.rs ... ok
test [codegen] src/test/codegen/sparc-struct-abi.rs ... ok
test [codegen] src/test/codegen/some-abis-do-extend-params-to-32-bits.rs#riscv ... ok
test [codegen] src/test/codegen/slice-position-bounds-check.rs ... ok
test [codegen] src/test/codegen/swap-large-types.rs ... ignored
test [codegen] src/test/codegen/swap-simd-types.rs ... ignored
test [codegen] src/test/codegen/swap-small-types.rs ... ignored
---
failures:

---- [codegen] src/test/codegen/intrinsics/mask.rs stdout ----

error: verification with 'FileCheck' failed
status: exit status: 1
command: "/checkout/obj/build/x86_64-unknown-linux-gnu/llvm/build/bin/FileCheck" "--input-file" "/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/intrinsics/mask/mask.ll" "/checkout/src/test/codegen/intrinsics/mask.rs" "--allow-unused-prefixes" "--check-prefixes" "CHECK,NONMSVC"
stdout: none
--- stderr -------------------------------
/checkout/src/test/codegen/intrinsics/mask.rs:9:17: error: CHECK-SAME: expected string not found in input
 // CHECK-SAME: @llvm.ptrmask.p0i8.[[WORD]](
                ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/intrinsics/mask/mask.ll:9:16: note: scanning from here
 %0 = tail call ptr @llvm.ptrmask.p0.i64(ptr %ptr, i64 %mask)
               ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/intrinsics/mask/mask.ll:9:16: note: with "WORD" equal to "i64"
 %0 = tail call ptr @llvm.ptrmask.p0.i64(ptr %ptr, i64 %mask)
               ^
/checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/intrinsics/mask/mask.ll:9:21: note: possible intended match here
 %0 = tail call ptr @llvm.ptrmask.p0.i64(ptr %ptr, i64 %mask)

Input file: /checkout/obj/build/x86_64-unknown-linux-gnu/test/codegen/intrinsics/mask/mask.ll
Check file: /checkout/src/test/codegen/intrinsics/mask.rs


-dump-input=help explains the following input dump.
Input was:
<<<<<<
<<<<<<
          1: ; ModuleID = 'mask.1ff5246e-cgu.0' 
          2: source_filename = "mask.1ff5246e-cgu.0" 
          3: target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" 
          4: target triple = "x86_64-unknown-linux-gnu" 
          5:  
          6: ; Function Attrs: mustprogress nofree nosync nounwind nonlazybind readnone willreturn uwtable 
          7: define ptr @mask_ptr(ptr readnone %ptr, i64 %mask) unnamed_addr #0 { 
          8: start: 
          9:  %0 = tail call ptr @llvm.ptrmask.p0.i64(ptr %ptr, i64 %mask) 
same:9'0                    X~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error: no match found
same:9'1                                                                    with "WORD" equal to "i64"
same:9'2                         ?                                          possible intended match
         10:  ret ptr %0 
same:9'0     ~~~~~~~~~~~~
         11: } 
same:9'0     ~~
         12:  
same:9'0     ~
         13: ; Function Attrs: mustprogress nocallback nofree nosync nounwind readnone speculatable willreturn 
same:9'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
         14: declare ptr @llvm.ptrmask.p0.i64(ptr, i64) #1 
same:9'0     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
          .
          .
>>>>>>
------------------------------------------

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.