Rollup of 19 pull requests #57687
Closed
Rollup of 19 pull requests #57687
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
Using `!` for `c_void` would have the problem that pointers and potentially references to an uninhabited type would be created, and at least for references this is UB. Also document in addition that newtype wrappers around `c_void` are not recommended for representing opaque types (as a workaround for `extern type` not being stable) but instead refer to the Nomicon.
…rent implementation We need at least two variants of the enum as otherwise the compiler complains about the #[repr(u8)] attribute and we also need at least one variant as otherwise the enum would be uninhabitated and dereferencing pointers to it would be UB. As such, mark the variants not unstable because they should not actually exist but because they are temporary implementation details until `extern type` is stable and can be used instead.
- Cleanup the `impl PartialEq<BookFormat> for Book` implementation - Implement `impl PartialEq<Book> for BookFormat` so it’s symmetric - Fixes rust-lang#53844. - Removes the last example since it appears to be redundant with the previous two examples.
"trampolines", or "aliases (the default)) to allow targets to opt out of the MergeFunctions LLVM pass. Also add a corresponding -Z option with the same name and values. This works around: rust-lang#57356 Motivation: Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3, and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler ptxas). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does. Related work: The current behavior of rustc is to enable MergeFunctions at -O2 and -O3, and also to enable the use of function aliases within MergeFunctions. MergeFunctions both with and without function aliases is incompatible with the NVPTX target. clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default.
This may be needed with some host compilers.
A few items were referenced, but did not have links.
Better lifetime error message I propose the following error message as more user-friendly r? @nikomatsakis
Remove confusing comment about ideally using `!` for `c_void` Using `!` for `c_void` would have the problem that pointers and potentially references to an uninhabited type would be created, and at least for references this is UB. In addition document that newtype wrappers around `c_void` can be used safely in place of `extern type` until the latter is stabilized. ---- I'm not 100% sure about the usage for opaque types as the [nomicon](https://doc.rust-lang.org/nomicon/ffi.html#representing-opaque-structs) still recommends using `#[repr(C)] pub struct Foo { _private: [u8; 0] }` but it seems like these two should be equivalent in the end? Also the `#[repr(C)]` (in both cases) should be unneeded because such types never being passed by value, never being dereferenced but only passed around as pointer or reference, so the representation of (*values* of) the type itself should not matter at all? Also in context of `c_void` and `!` the second unresolved question in the [`extern type`](rust-lang#43467) stabilization ticket seems relevant > In [std's](https://github.com/rust-lang/rust/blob/164619a8cfe6d376d25bd3a6a9a5f2856c8de64d/src/libstd/os/raw.rs#L59-L64) source, it is mentioned that LLVM expects i8* for C's void*. > We'd need to continue to hack this for the two c_voids in std and libc. > But perhaps this should be done across-the-board for all extern types? > Somebody should check what Clang does. Please correct me if my understanding is wrong and everything's actually fine as is.
Move spin_loop_hint to core::hint module As mentioned in rust-lang#55002. The new name is kept unstable to decide whether the function should have `_hint` in its name.
Optimize try_mark_green and eliminate the lock on dep node colors Blocked on rust-lang#56614 r? @michaelwoerister
…tsakis Add a regression test for mutating a non-mut #[thread_local] This should close rust-lang#54901 since the regression has since been fixed.
Make privacy checking, intrinsic checking and liveness checking incremental Blocked on rust-lang#51487 r? @michaelwoerister
Add a target option "merge-functions", and a corresponding -Z flag (works around rust-lang#57356) This commit adds a target option "merge-functions", which takes values in ("disabled", "trampolines", or "aliases" (default is "aliases")), to allow targets to opt out of the MergeFunctions LLVM pass. Additionally, the latest commit also adds an optional -Z flag, "merge-functions", which takes the same values and has precedence over the target option when both are specified. This works around rust-lang#57356. cc @eddyb @japaric @oli-obk @nox @nagisa Also thanks to @denzp and @gnzlbg for discussing this on rust-cuda! ### Motivation Basically, the problem is that the MergeFunctions pass, which rustc currently enables by default at -O2 and -O3 [1], and `extern "ptx-kernel"` functions (specific to the NVPTX target) are currently not compatible with each other. If the MergeFunctions pass is allowed to run, rustc can generate invalid PTX assembly (i.e. a PTX file that is not accepted by the native PTX assembler `ptxas`). Therefore we would like a way to opt out of the MergeFunctions pass, which is what our target option does. ### Related work The current behavior of rustc is to enable MergeFunctions at -O2 and -O3 [1], and also to enable the use of function aliases within MergeFunctions [2] [3]. MergeFunctions seems to have some benefits, such as reducing code size and fixing a crash [4], which is why it is enabled. However, MergeFunctions both with and without function aliases is incompatible with the NVPTX target; a more detailed example for both cases is given below. clang's "solution" is to have a "-fmerge-functions" flag that opts in to the MergeFunctions pass, but it is not enabled by default. ### Examples/more details Consider an example Rust lib using `extern "ptx-kernel"` functions: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore.rs. If we try to compile this with nightly rustc, we get the following compiler error: LLVM ERROR: Module has aliases, which NVPTX does not support. This error happens because: (1) functions `foo` and `bar` have the same body, so are candidates to be merged by MergeFunctions; and (2) rustc configures MergeFunctions to generate function aliases using the "mergefunc-use-aliases" LLVM option [2] [3], but the NVPTX backend does not support those aliases. Okay, so we can try omitting "mergefunc-use-aliases", and then rustc will happily emit PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-mergefunc-nousealiases-bad.ptx. However, this PTX is invalid! When we try to assemble it with `ptxas` (I'm on the CUDA 9.2 toolchain), we get an assembler error: ptxas nocore-mergefunc-nousealiases-bad.ptx, line 38; error : Illegal call target, device function expected ptxas fatal : Ptx assembly aborted due to errors What's happening is that MergeFunctions rewrites the `bar` function to call `foo`. However, directly calling an `extern "ptx-kernel"` function from another `extern "ptx-kernel"` is wrong. If we disable the MergeFunctions pass from running at all, rustc generates correct PTX assembly: https://github.com/peterhj/nvptx-mergefunc-bug/blob/master/nocore-nomergefunc-ok.ptx [1] https://github.com/rust-lang/rust/blob/a36b960df626cbb8bea74f01243318b73f0bd201/src/librustc_codegen_ssa/back/write.rs#L155 [2] https://github.com/rust-lang/rust/blob/a36b960df626cbb8bea74f01243318b73f0bd201/src/librustc_codegen_llvm/llvm_util.rs#L64 [3] rust-lang#56358 [4] rust-lang#49479
…acrum Use correct tracking issue for c_variadic Fixes rust-lang#57306
…etMisdreavus Cleanup PartialEq docs. - Cleanup the `impl PartialEq<BookFormat> for Book` implementation - Implement `impl PartialEq<Book> for BookFormat` so it’s symmetric - Fixes rust-lang#53844. - Removes the last example since it appears to be redundant with the previous two examples.
Support passing cflags/cxxflags/ldflags to LLVM build This may be needed with some host compilers.
High priority resolutions for associated variants In rust-lang#56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage. This PR changes the rules to give variants highest priority instead. Some motivation: - If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits. - Inherent associated items have higher priority during resolution than associated items from traits. - The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority. - It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented. Crater found some regressions from this change, but they are all in type positions, e.g. ```rust fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`? ``` , so variants are not usable there right now, but they may become usable in the future if rust-lang/rfcs#2593 is accepted. This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.
resolve: Add a test for issue rust-lang#57539 Add a test for the bugfix regression reported in rust-lang#57539 Closes rust-lang#57539
…enkov Fix nested `?` matchers fix rust-lang#57597 I'm not 100% if this works yet... cc @alercah When this is ready (but perhaps not yet):
…erister use structured macro and path resolve suggestions
… r=QuietMisdreavus Fix sources sidebar not showing up Fixes rust-lang#57601. The order of imports made it so that the sidebar creation was called before the sidebar sources were created. Like this, when the sources are loaded, they create the sidebar as expected. r? @QuietMisdreavus
…reavus Fixes text becoming invisible when element targetted Fixes rust-lang#57628. r? @QuietMisdreavus
Add some links in std::fs. A few items were referenced, but did not have links.
…xcrichton Fix release manifest generation r? @alexcrichton
…-applicability, r=withoutboats Enhance `Pin` impl applicability for `PartialEq` and `PartialOrd`. This allows for comparing for equality or ordering a `Pin<P>` and a `Pin<Q>` as long as `P` and `Q` are correspondingly comparable themselves *even when `P` and `Q` are different types*. An example might be comparing a `Pin<&mut OsString>` to a `Pin<&mut PathBuf>`, which might arise from pin projections from a pair of larger contexts that aren't `Unpin`.
|
@bors r+ p=5 |
|
📌 Commit 40d0b44 has been approved by |
bors
added
the
S-waiting-on-bors
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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:
!forc_void#56594 (Remove confusing comment about ideally using!forc_void)?matchers #57610 (Fix nested?matchers)Pinimpl applicability forPartialEqandPartialOrd. #57685 (EnhancePinimpl applicability forPartialEqandPartialOrd.)Failed merges:
r? @ghost