-
-
Notifications
You must be signed in to change notification settings - Fork 14.3k
Rollup of 15 pull requests #150914
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 15 pull requests #150914
Conversation
This test currently doesn't fulfill its purpose, as `external dso_local`
can still match `external {{.*}}`. Fix this by using CHECK-NOT directives.
Also, this test is expanded to all platforms where it makes sense, instead
of restricting to loongarch.
The current code applies `dso_local` to the internal generated symbols instead of the actually-externally one.
They were introduced back when std_detect was a standalone crate published to crates.io. The motivation for std_detect_dlsym_getauxval was to allow using getauxval without dlopen when statically linking musl, which we now unconditionally do for musl. And for std_detect_file_io to allow no_std usage, which std_detect now supports even with that feature enabled as it directly uses libc. This also prevents accidentally disabling runtime feature detection when using cargo build -Zbuild-std -Zbuild-std-features=
It is no longer a part of the stdarch repo and the rest is not necessary anymore due to no longer publishing to crates.io.
This will allow extra data to be attached to the `Pat` before it is returned.
std supports redirecting stdio file descriptors.
Rather than panicking.
- Make flush a noop since it is only for buffered writers. - Also forward fsync to datasync. UEFI does not have anything separate for metadata sync. Signed-off-by: Ayush Singh <[email protected]>
… a body. Handling for inherent associated consts is missing elsewhere, remove so it can be handled later in that handling. Diagnostic not always be emitted on associated constant Add a test case and Fix for a different ICE I encountered. I noticed when trying various permuations of the test case code to see if I could find anymore ICEs. I did, but not one that I expected. So in the instances of the a named const not having any args, insantiate it directly. Since it is likely an inherent assocaiated const. Added tests. Centralize the is_type_const() logic. I also noticed basically the exact same check in other part the code. Const blocks can't be a type_const, therefore this check is uneeded. Fix comment spelling error. get_all_attrs is not valid to call for all DefIds it seems. Make sure that if the type is omitted for a type_const that we don't ICE. Co-Authored-By: Boxy <[email protected]>
Rollup of 15 pull requests try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: test-various try-job: armhf-gnu try-job: aarch64-apple
This comment has been minimized.
This comment has been minimized.
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
Let's try again to check for flakiness: @bors try jobs=x86_64-msvc-1,i686-msvc-1,x86_64-mingw-1,test-various,armhf-gnu,aarch64-apple |
This comment has been minimized.
This comment has been minimized.
Rollup of 15 pull requests try-job: x86_64-msvc-1 try-job: i686-msvc-1 try-job: x86_64-mingw-1 try-job: test-various try-job: armhf-gnu try-job: aarch64-apple
|
#150131 is problematic |
|
This PR should not have been closed. |
|
(I don't intend to approve this rollup, but I'm keeping it open to help me keep track of the try-job results. If those jobs produce another failure, it will affect the contents of the next real rollup.) |
|
The try build succeeded, which is good news for future rollups that include these PRs. |
Successful merges:
AscribeUserTypeandExpandedConstantwrappers with per-node data #150788 (THIR patterns: ReplaceAscribeUserTypeandExpandedConstantwrappers with per-node data)can't type-check body of DefId#148729)r? @ghost
Create a similar rollup