Rollup of 15 pull requests #142396
Closed
Rollup of 15 pull requests #142396
Conversation
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
…g macro prelude changes
Add that the enum must be `#[repr(Rust)]` and not `#[repr(packed)]` or `#[repr(align)]` in order to be ABI-compatible with its null-pointer-optimized field.
Explicitly cross-build it for GPU targets and check it errors on hosts.
Some architectures gain target-cpu minimums in doing so.
- Rewords existing Considerations section on `fetch_update` and friends to make clear that the limitations are inherent to an implementation based on any CAS operation, rather than the weak version of `compare_exchange` in particular - Add Considerations to `compare_exchange` and `compare_exchange_weak` which details similar considerations and when they may be relevant.
This was attempted in [1] then reverted in [2] because of fallout. Recently, this was made an edition-dependent error in [3]. Make missing fragment specifiers an unconditional error again. [1]: rust-lang#75516 [2]: rust-lang#80210 [3]: rust-lang#128006
This removes the `compiler_builtins` dependency from a handful of library dependencies, which is progress toward [1]. [1]: rust-lang#142265
…r-unconditional, r=petrochenkov,traviscross Make `missing_fragment_specifier` an unconditional error This was attempted in [1] then reverted in [2] because of fallout. Recently, this was made an edition-dependent error in [3]. Make missing fragment specifiers an unconditional error again, across all editions. More context: rust-lang#128006 Most recent crater: rust-lang#128425 (comment) Fixes: rust-lang#40107 [1]: rust-lang#75516 [2]: rust-lang#80210 [3]: rust-lang#128006
…rors,traviscross Lint on fn pointers comparisons in external macros This PR extends the recently stabilized `unpredictable_function_pointer_comparisons` lint ~~to also lint on `Option<{function pointer}>` and~~ as well as linting in external macros (as to catch `assert_eq!` and others). ```rust assert_eq!(Some::<FnPtr>(func), Some(func as unsafe extern "C" fn())); //~^ WARN function pointer comparisons #[derive(PartialEq, Eq)] struct A { f: fn(), //~^ WARN function pointer comparisons } ``` Fixes rust-lang#134527 …e, r=dtolnay Added `Clone` implementation for `ChunkBy` Added `Clone` implementation for `ChunkBy` Closes rust-lang#137969.
add `extern "custom"` functions tracking issue: rust-lang#140829 previous discussion: rust-lang#140566 In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly. The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention. At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this. r? `@traviscross` cc `@tgross35`
…r-errors resolve: Tweak `private_macro_use` lint to be compatible with upcoming macro prelude changes Unblocks rust-lang#139493. Zulip thread requesting help - [#t-compiler/help > Help requested for effects of rust-lang#139493](https://rust-lang.zulipchat.com/#narrow/channel/182449-t-compiler.2Fhelp/topic/Help.20requested.20for.20effects.20of.20.23139493/with/514653911). This PR by itself shouldn't cause any observable changes, its only observable effect is that the prelude changes from rust-lang#139493 will no longer cause regressions in tests like `tests/ui/imports/issue-119369.rs` or `tests/ui/extern/issue-80074.rs`. This is achieved by moving the "is this thing in stdlib prelude" check from an early point (`fn process_macro_use_imports`) to a later point (`fn record_use_inner`), at which the stdlib prelude is already populated and can be inspected. (The `is_builtin_macro` check is subsumed by the stdlib prelude check, all built-in macros go through the stdlib prelude anyway.)
…traviscross Specify that "option-like" enums must be `#[repr(Rust)]` to be ABI-compatible with their non-1ZST field. Add that the enum must be `#[repr(Rust)]` and not `#[repr(packed)]` or `#[repr(align)]` in order to be ABI-compatible with its null-pointer-optimized field. The specific rules here were decided on here: rust-lang#130628 (comment) but `repr` was not mentioned. In practice, only `#[repr(Rust)]` (or no `repr` attribute, which is equivalent) works for this, so add that to the docs. ----- Restrict to `#[repr(Rust)]` only, since: * `#[repr(C)]` and the primitive representations (`#[repr(u8)]` etc) definitely disqualify the enum from NPO, since they have defined layouts that store the tag separately to the payload. * `#[repr(transparent)]` enums are covered two bullet points above this (line 1830), and cannot have multiple variants, so would fail the "The enum has exactly two variants" requirement anyway. As for `#[repr(align)]`: my current wording that it is completely disallowed may be too strong: it seems like `#[repr(align(<= alignment of T))] enum Foo { X, Y(T) }` currently does still have the same ABI as `T` in practice, though this may not be something we want to promise. (`#[repr(align(> alignment of T))]` definitely disqualifies the enum from being ABI-compatible with T currently). I added the note about `packed` to match `align`, but `#[repr(packed)]` currently can't be applied to `enum`s at all anyway, so might be unnecessary. ----- I think this needs T-lang approval? cc `@workingjubilee`
…piler-errors docs: autogenerate compiler flag stubs based on -Zhelp Adds autogenerated compiler flag stubs to the unstable book by building rustc, passing it's path to `unstable-book-gen`, and using that to call the compiler with `-Zhelp` and create a similar `Features` that is used for library and lang stubs. Example: ```md # `combine_cgu` combine CGUs into a single one This feature has no tracking issue, and is therefore likely internal to the compiler, not being intended for general use. ------------------------ ``` Closes rust-lang#141525
…-per-arch, r=nikic tests: Split dont-shuffle-bswaps along opt-levels and arches This duplicates dont-shuffle-bswaps in order to make each opt level its own test. Then -opt3.rs gets split into a revision per arch we want to test, with certain architectures gaining new target-cpu minimums.
Add supported asm types for LoongArch32 r? ````@Amanieu````
Improve clarity of `core::sync::atomic` docs about "Considerations" in regards to CAS operations ## Motivation The existing documentation for atomic `fetch_update` (and other similar methods) has a section that reads like so: > ### Considerations > This method is not magic; it is not provided by the hardware. It is implemented in > terms of `AtomicBlah::compare_exchange_weak`, and suffers from the same drawbacks. > In particular, this method will not circumvent the [ABA Problem]. > > [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem The wording here seems to imply that the drawbacks being discusses are caused by the *`weak` version* of `compare_exchange`, and that one may avoid those drawbacks by using `compare_exchange` instead. Indeed, a conversation in the `#dark-arts` channel on the Rust community discord based on this interpretation led to this PR. In reality, the drawbacks are inherent to implementing such an operation based on *any* compare-and-swap style operation, as opposed to an [LL,SC](https://en.wikipedia.org/wiki/Load-link/store-conditional) operation, and they apply equally to `compare_exchange` and `compare_exchange_weak` as well. ## Changes - Rewords existing Considerations section on `fetch_update` and friends to make clear that the limitations are inherent to an implementation based on any CAS operation, rather than the weak version of `compare_exchange` in particular. New version: > ### Considerations > > This method is not magic; it is not provided by the hardware, and does not act like a > critical section or mutex. > > It is implemented on top of an atomic [compare-and-swap operation], and thus is subject to > the usual drawbacks of CAS operations. In particular, be careful of the [ABA problem] > if this atomic integer is an index or more generally if knowledge of only the *bitwise value* > of the atomic is not in and of itself sufficient to ensure any required preconditions. > > [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem > [compare-and-swap operation]: https://en.wikipedia.org/wiki/Compare-and-swap - Add Considerations to `compare_exchange` and `compare_exchange_weak` which details similar considerations and when they may be relevant. New version: > ### Considerations > > `compare_exchange` is a [compare-and-swap operation] and thus exhibits the usual downsides > of CAS operations. In particular, a load of the value followed by a successful > `compare_exchange` with the previous load *does not ensure* that other threads have not > changed the value in the interim. This is usually important when the *equality* check in > the `compare_exchange` is being used to check the *identity* of a value, but equality > does not necessarily imply identity. In this case, `compare_exchange` can lead to the > [ABA problem]. > > [ABA Problem]: https://en.wikipedia.org/wiki/ABA_problem > [compare-and-swap operation]: https://en.wikipedia.org/wiki/Compare-and-swap
…n-ast-lowering, r=oli-obk assert more in release in `rustc_ast_lowering` My understanding of the compiler's architecture is that in the `ast_lowering` crate, we are constructing the HIR as a one-time thing per crate. This is after tokenizing, parsing, resolution, expansion, possible reparsing, reresolution, reexpansion, and so on. In other words, there are many reasons that perf-focused PRs spend a lot of time touching `rustc_parse`, `rustc_expand`, `rustc_ast`, and then `rustc_hir` and "onwards", but `ast_lowering` is a little bit of an odd duck. In this crate, we have a number of debug assertions. Some are clearly expensive checks that seem like they are prohibitive to run in actual optimized compiler builds, but then there are a number that are simple asserts on integer equalities, `is_empty`, or the like. I believe we should do some of them even in release builds, because the correctness gain is worth the performance cost: almost zero.
…eature-gate-test, r=jieyouxu tests: Minicore `extern "gpu-kernel"` feature test Explicitly cross-build it for GPU targets and check it errors on hosts. A relatively minor cleanup from my other ABI-related PRs that I got tired of rebasing.
…r=Mark-Simulacrum Update dependencies in `library/Cargo.lock` This removes the `compiler_builtins` dependency from a handful of library dependencies, which is progress toward [1]. [1]: rust-lang#142265
miri: add flag to suppress float non-determinism We have flags controlling most non-determinism, so this seems generally useful for debugging. It is also needed to work around rust-lang/portable-simd#463 in miri-test-libstd. I made this a rustc PR so that it propagates faster to unbreak miri-test-libstd. r? `@oli-obk`
…cl-and-other-abis, r=RalfJung compiler: Ease off the accelerator on `unsupported_calling_conventions` This is to give us more time to discuss rust-lang#142330 without the ecosystem having an anxiety attack. I have withdrawn `unsupported_calling_conventions` from report-in-deps I believe we should consider this a simple suspension of the decision in rust-lang#141435 to start this process, rather than a reversal. That is, we may continue with linting again. But I believe we are about to get a... reasonable amount of feedback just from currently available information and should allow ourselves time to process it.
rustbot added A-LLVM 
| @bors r+ rollup=never p=5 |
bors added S-waiting-on-bors 
| The job Click to see the possible cause of the failure (guessed by this bot) |
| @bors r- |
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
14 participants
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:
missing_fragment_specifieran unconditional error #128425 (Makemissing_fragment_specifieran unconditional error)Cloneimplementation forChunkBy#138016 (AddedCloneimplementation forChunkBy)extern "custom"functions #140770 (addextern "custom"functions)private_macro_uselint to be compatible with upcoming macro prelude changes #141934 (resolve: Tweakprivate_macro_uselint to be compatible with upcoming macro prelude changes)#[repr(Rust)]to be ABI-compatible with their non-1ZST field. #141947 (Specify that "option-like" enums must be#[repr(Rust)]to be ABI-compatible with their non-1ZST field.)core::sync::atomicdocs about "Considerations" in regards to CAS operations #142252 (Improve clarity ofcore::sync::atomicdocs about "Considerations" in regards to CAS operations)rustc_ast_lowering#142267 (assert more in release inrustc_ast_lowering)extern "gpu-kernel"feature test #142273 (tests: Minicoreextern "gpu-kernel"feature test)library/Cargo.lock#142276 (Update dependencies inlibrary/Cargo.lock)unsupported_calling_conventions#142353 (compiler: Ease off the accelerator onunsupported_calling_conventions)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup