[pull] master from rust-lang:master #14
Open
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
![pull[bot]](https://avatars.githubusercontent.com/in/12910?s=60&v=4){kind=small}
…didates, r=Kobzol skip in-tree compiler build for llvm-bitcode-linker if ci-rustc is on Similar to #108767, resolves the `multiple candidates` problem for ci-rustc. See #122709 (comment) for more context. Blocker for #122709.
Couple of changes to make it easier to compile rustc for wasm This is a subset of the patches I have on my rust fork to compile rustc for wasm32-wasip1.
`rustc_borrowck` memory management tweaks Minor cleanups in `rustc_borrowck` relating to memory management. r? `@lqd`
Remove valgrind test suite and support from compiletest, bootstrap and opt-dist The `run-pass-valgrind` test suite is not exercised in CI, and as far as I'm aware nobody runs it (asked in https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/Are.20the.20valgrind.20tests.20even.20used.20by.20anyone.3F). What's remaining of valgrind support in compiletest isn't even properly hooked up with bootstrap. The existing valgrind logic in compiletest is also straight up questionable, i.e. https://github.com/rust-lang/rust/blob/1b3b8e7b0265162853c650ead09905bc3cdaeae9/src/tools/compiletest/src/runtest/valgrind.rs#L7-L12 It just runs valgrind tests as `rpass` if no valgrind path is provided to compiletest from bootstrap -- but bootstrap doesn't even pass a valgrind path to compiletest in the first place, so this always ran as `rpass` tests. So what is this even testing? So if it's not testing anything, let's delete it. Closes #44816 by deleting the test suite :3 <img src="https://github.com/user-attachments/assets/99525bf7-e85b-40ba-9281-e4e1e275c4e8" width=300 />
…jieyouxu
Fix used_underscore_binding in rustc_serialize
Hi,
This PR fixes the following clippy warnings in rustc_serialize
```
warning: used underscore-prefixed binding
--> compiler/rustc_serialize/src/opaque.rs:443:27
|
443 | debug_assert_eq!((_end_pos - _start_pos), IntEncodedWithFixedSize::ENCODED_SIZE);
| ^^^^^^^^
|
note: binding is defined here
--> compiler/rustc_serialize/src/opaque.rs:442:13
|
442 | let _end_pos = e.position();
| ^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#used_underscore_binding
= note: requested on the command line with `-W clippy::used-underscore-binding`
warning: used underscore-prefixed binding
--> compiler/rustc_serialize/src/opaque.rs:443:38
|
443 | debug_assert_eq!((_end_pos - _start_pos), IntEncodedWithFixedSize::ENCODED_SIZE);
| ^^^^^^^^^^
|
note: binding is defined here
--> compiler/rustc_serialize/src/opaque.rs:440:13
|
440 | let _start_pos = e.position();
| ^^^^^^^^^^
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#used_underscore_binding
```
Best regards,
Michal
Mark Boxy as on vacation Boxy asked me to do this since she's busy :D cc `@BoxyUwU`
Rollup of 7 pull requests Successful merges: - #128721 (Don't allow the `#[pointee]` attribute where it doesn't belong) - #130479 (skip in-tree compiler build for llvm-bitcode-linker if ci-rustc is on) - #130899 (Couple of changes to make it easier to compile rustc for wasm) - #131225 (`rustc_borrowck` memory management tweaks) - #131351 (Remove valgrind test suite and support from compiletest, bootstrap and opt-dist) - #131359 (Fix used_underscore_binding in rustc_serialize) - #131367 (Mark Boxy as on vacation) r? `@ghost` `@rustbot` modify labels: rollup
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
The BOM was accidentally removed in #57108
- Don't touch rustc's `-Zon-broken-pipe=kill` env var in `compile.rs`. - Use an untracked env var to pass `-Zon-broken-pipe=kill` for tools but skip cargo still, because cargo wants `-Zon-broken-pipe=kill` unset.
Add precondition checks to ptr::offset, ptr::add, ptr::sub All of `offset`, `add`, and `sub` (currently) have the trivial preconditions that the offset in bytes must be <= isize::MAX, and the computation of the new address must not wrap. This adds precondition checks for these, and like in slice indexing, we use intrinsics directly to implement unsafe APIs that have explicit checks, because we get a clearer error message that mentions the misused API not an implementation detail. Experimentation indicates these checks have 1-2% compile time overhead, due primarily to adding the checks for `add`. A crater run (#130251 (comment)) indicates some people currently have buggy calls to `ptr::offset` that apply a negative offset to a null pointer, but the crater run does not hit the `ptr::add` or `ptr::sub` checks, which seems like an argument for cfg'ing out those checks on account of their overhead.
Add missing module flags for `-Zfunction-return=thunk-extern` This fixes a bug in the `-Zfunction-return=thunk-extern` flag. The flag needs to be passed onto LLVM to ensure that functions such as `asan.module_ctor` and `asan.module_dtor` that are created internally in LLVM have the mitigation applied to them. This was originally discovered [in the Linux kernel](https://lore.kernel.org/all/CANiq72myZL4_poCMuNFevtpYYc0V0embjSuKb7y=C+m3vVA_8g@mail.gmail.com/). Original flag PR: #116892 PR for similar issue: #129373 Tracking issue: #116853 cc ``@ojeda`` r? ``@wesleywiser``
…jubilee Fix `target_vendor` in non-IDF Xtensa ESP32 targets `rustc`'s Xtensa ESP32 targets are the following: - `xtensa-esp32-none-elf` - `xtensa-esp32-espidf` - `xtensa-esp32s2-none-elf` - `xtensa-esp32s2-espidf` - `xtensa-esp32s3-none-elf` - `xtensa-esp32s3-espidf` The ESP-IDF targets already set `target_vendor="espressif"`, however, the ESP32 is, from my understanding, produced by Espressif regardless of whether using the IDF or not, so we should set the target vendor there as well?
Update books ## rust-lang/book 8 commits in 99cf75a5414fa8adbe3974bd0836661ca901708f..f38ce8baef98cb20229e56f1be2d50e345f11792 2024-10-07 13:21:46 UTC to 2024-09-25 22:46:26 UTC - Swap assert_eq! parameters (rust-lang/book#4058) - Add a short discussion of assignment and ownership in ch. 04 (rust-lang/book#4049) - Standardize on 'adapter', not 'adaptor' (rust-lang/book#4057) - A bit more clarity about all the stack types in 3.2 (rust-lang/book#4055) - Mention move of individual struct fields in struct update syntax (rust-lang/book#4046) - Convert ch05 to `<Listing>` (rust-lang/book#4051) - Convert ch04 to `<Listing>` (rust-lang/book#4043) - Fixed Ukrainian translation link to community repo (rust-lang/book#4039) ## rust-embedded/book 1 commits in dbae36bf3f8410aa4313b3bad42e374735d48a9d..f40a8b420ec4b4505d9489965e261f1d5c28ba23 2024-09-30 19:16:36 UTC to 2024-09-30 19:16:36 UTC - Update macOS installation instructions (rust-embedded/book#379) ## rust-lang/nomicon 1 commits in 14649f15d232d509478206ee9ed5105641aa60d0..456b904f791751892b01282fd2757904993c4c26 2024-10-05 17:29:16 UTC to 2024-10-05 17:29:16 UTC - Improve/fix description of drops (rust-lang/nomicon#465) ## rust-lang/reference 7 commits in 24fb2687cdbc54fa18ae4acf5d879cfceca77b2c..c64e52a3d306eac0129f3ad6c6d8806ab99ae2e9 2024-10-05 00:33:03 UTC to 2024-09-24 22:04:59 UTC - Fix inline-assembly documentation for LoongArch (rust-lang/reference#1644) - Explain how to name rule identifiers (rust-lang/reference#1609) - Add `expr_2021` macro fragment specifier (rust-lang/reference#1580) - Add spec identifier syntax to macro subchapters (rust-lang/reference#1625) - Authoring guide: clarify standard library linking (rust-lang/reference#1629) - Add spec identifiers to comments.md (rust-lang/reference#1563) - Add identifier syntax to visibility-and-privacy.md (rust-lang/reference#1627) ## rust-lang/rust-by-example 3 commits in c79ec345f08a1e94494cdc8c999709a90203fd88..8bede1b919a81ab7d0c961f6bbf68d3efa297bd2 2024-09-30 13:38:03 UTC to 2024-09-30 13:32:58 UTC - Minor improvements (rust-lang/rust-by-example#1888) - Clarify that the associated type is also required by the Iterator trait (rust-lang/rust-by-example#1887) - Add Chinese(zh) translation (rust-lang/rust-by-example#1886) ## rust-lang/rustc-dev-guide 34 commits in 555f3de2fa0d61c4294b74d245f1cbad6fcbf589..07bc9ca9eb1cd6d9fbbf758c2753b748804a134f 2024-10-07 15:09:03 UTC to 2024-09-24 17:49:14 UTC - rustdoc: docs for search deduplication (rust-lang/rustc-dev-guide#1850) - Revise test naming advice to discourage using issue numbers alone (rust-lang/rustc-dev-guide#2090) - Document `bootstrap` integration with `rustc-perf` (rust-lang/rustc-dev-guide#2005) - building: Update instructions for ./x setup editor (rust-lang/rustc-dev-guide#2086) - [Testing 2/2] Revise revisions docs (rust-lang/rustc-dev-guide#2089) - [Testing 1/2] Revise testing chapters excluding the directives chapter (rust-lang/rustc-dev-guide#2088) - Fixed links to rust-analyzer configs for Emacs and Helix (rust-lang/rustc-dev-guide#2087) - update `x install` documentation (rust-lang/rustc-dev-guide#2084) - Rename "object safe" to "dyn compatible" (rust-lang/rustc-dev-guide#2083) - Small follow-up to my "internal `#[rustc_*]` TEST attributes" PR (rust-lang/rustc-dev-guide#2082) - Add documentation for `{{rust-src-base}}` (rust-lang/rustc-dev-guide#2079) - building/suggested: Add instructions for Emacs & Helix (rust-lang/rustc-dev-guide#2080) - Fix file paths to section 35.1 & 35.2 example code (rust-lang/rustc-dev-guide#2078) - Clarify how to disable warnings in deps (rust-lang/rustc-dev-guide#2015) - Update compiler-src.md (rust-lang/rustc-dev-guide#1899) - Update rustdoc build instructions (rust-lang/rustc-dev-guide#1917) - Update salsa.md (rust-lang/rustc-dev-guide#1906) - Update memory.md (rust-lang/rustc-dev-guide#1907) - Update serialization.md (rust-lang/rustc-dev-guide#1909) - update rustc-driver.md (rust-lang/rustc-dev-guide#1929) - Update syntax-intro.md (rust-lang/rustc-dev-guide#1932) - Update the-parser.md (rust-lang/rustc-dev-guide#1933) - Update macro-expansion.md (rust-lang/rustc-dev-guide#1934) - Clarify a little bit in MIR chapter (rust-lang/rustc-dev-guide#1986) - Update name-resolution.md (rust-lang/rustc-dev-guide#1935) - feat: Add section about partial clones with `git clone --filter='blob:none'` (rust-lang/rustc-dev-guide#2035) - Mention rustc's stable-item-through-unstable-path bug being fixed (rust-lang/rustc-dev-guide#2064) - Fix `is_diagnostic_item()` example (rust-lang/rustc-dev-guide#2013) - Revise lldb debuginfo note wording to not imply *only* Python 3.10 can be installed (rust-lang/rustc-dev-guide#2077) - Document `crashes` test suite (rust-lang/rustc-dev-guide#2075) - Fix getting diagnostics example (rust-lang/rustc-dev-guide#2067) - Document `#[rustc_default_body_unstable]` (rust-lang/rustc-dev-guide#2065) - Describe `.git-blame-ignore-rev` (rust-lang/rustc-dev-guide#2072) - Note lldb debuginfo requires `python310.dll` to be present in `PATH` on Windows (rust-lang/rustc-dev-guide#2076)
…=GuillaumeGomez rustdoc: improve `<wbr>`-insertion for SCREAMING_CAMEL_CASE
…struct-fields-and-their-descriptions, r=GuillaumeGomez fix(rustdoc): add space between struct fields and their descriptions Stolen from #128541. Fixes #128260. <table> <thead> <tr> <th scope="col">Before</th> <th scope="col">After</th> </tr> </thead> <tbody> <tr> <td scope="row"> <img src="https://github.com/user-attachments/assets/b1d3cb47-77c9-4897-a5d2-2192b11cb8a3" /> </td> <td> <img src="https://github.com/user-attachments/assets/0b104672-d2be-49f4-ac9b-3506526fe2f1" /> </td> </tr> </tbody> </table> <table> <thead> <tr> <th scope="col">Before</th> <th scope="col">After</th> </tr> </thead> <tbody> <tr> <td scope="row"> <img src="https://github.com/user-attachments/assets/650c3e74-a067-492a-9ba3-557f9214f875" /> </td> <td> <img src="https://github.com/user-attachments/assets/413ef9b0-8fca-4e16-978a-7b88d05299dc" /> </td> </tr> </tbody> </table> Unlike original PR, I didn't add space between field headers; I put it between headers and descriptions. So if there are only headers, the space is not changed. Otherwise, I put a space like the space between paragraphs (.75em) which makes sense for me but feel free to adjust it or ask me to do so. r? `@GuillaumeGomez`
Use Default visibility for rustc-generated C symbol declarations Non-default visibilities should only be used for definitions, not declarations, otherwise linking can fail. This is based on #123994. Issue #123427 When I changed `default-hidden-visibility` to `default-visibility` in #130005, I updated all places in the code that used `default-hidden-visibility`, replicating the hidden-visibility bug to also happen for protected visibility. Without this change, trying to build rustc with `-Z default-visibility=protected` fails with a link error.
compiletest: Extract auxiliary-crate properties to their own module/struct This moves the values of the 4 different `aux-*` directives into their own sub-struct. That struct, along with its directive-parsing code, can then be shared by both `TestProps` and `EarlyProps`. The final patch also fixes an oversight in up-to-date checking, by including *all* auxiliary crates in the timestamp, not just ordinary `aux-build` ones.
next-solver: remove outdated FIXMEs r? `@compiler-errors`
Rollup of 6 pull requests Successful merges: - #129079 (Create `_imp__` symbols also when doing ThinLTO) - #131208 (ABI: Pass aggregates by value on AIX) - #131394 (fix(rustdoc): add space between struct fields and their descriptions) - #131519 (Use Default visibility for rustc-generated C symbol declarations) - #131541 (compiletest: Extract auxiliary-crate properties to their own module/struct) - #131542 (next-solver: remove outdated FIXMEs) r? `@ghost` `@rustbot` modify labels: rollup
llvm/llvm-project@fa789df renamed getDeclaration to getOrInsertDeclaration. @rustbot label: +llvm-main
move dummy commit logic into x86_64-gnu-llvm-18 Doing the dummy commit logic in a runner that uses CI-LLVM breaks in merge CI. This should be properly fixed by #131358 (see the [actual problem](#131448 (comment))). Since we can also fix it by moving the dummy commit into the runner where we use in-tree LLVM, so why not do that as well?
Add intrinsics `fmuladd{f16,f32,f64,f128}`. This computes `(a * b) +
c`, to be fused if the code generator determines that (i) the target
instruction set has support for a fused operation, and (ii) that the
fused operation is more efficient than the equivalent, separate pair
of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
MIRI support is included for f32 and f64.
The codegen_cranelift uses the `fma` function from libc, which is a
correct implementation, but without the desired performance semantic. I
think this requires an update to cranelift to expose a suitable
instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same
way (using `fma` from libc).
…r=aDotInTheVoid rustdoc-json: change item ID's repr from a string to an int Following [this discussion on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Optimizing.20the.20.60Id.60.20type.20in.20.60rustdoc-types.60), I've changed the repr of `rustdoc_json_types::Id` from a String to a u32, by adding a `clean::ItemId` interner to `JsonRenderer` r? ``@aDotInTheVoid``
Port sort-research-rs test suite to Rust stdlib tests This PR is a followup to #124032. It replaces the tests that test the various sort functions in the standard library with a test-suite developed as part of https://github.com/Voultapher/sort-research-rs. The current tests suffer a couple of problems: - They don't cover important real world patterns that the implementations take advantage of and execute special code for. - The input lengths tested miss out on code paths. For example, important safety property tests never reach the quicksort part of the implementation. - The miri side is often limited to `len <= 20` which means it very thoroughly tests the insertion sort, which accounts for 19 out of 1.5k LoC. - They are split into to core and alloc, causing code duplication and uneven coverage. - ~~The randomness is tied to a caller location, wasting the space exploration capabilities of randomized testing.~~ The randomness is not repeatable, as it relies on `std::hash::RandomState::new().build_hasher()`. Most of these issues existed before #124032, but they are intensified by it. One thing that is new and requires additional testing, is that the new sort implementations specialize based on type properties. For example `Freeze` and non `Freeze` execute different code paths. Effectively there are three dimensions that matter: - Input type - Input length - Input pattern The ported test-suite tests various properties along all three dimensions, greatly improving test coverage. It side-steps the miri issue by preferring sampled approaches. For example the test that checks if after a panic the set of elements is still the original one, doesn't do so for every single possible panic opportunity but rather it picks one at random, and performs this test across a range of input length, which varies the panic point across them. This allows regular execution to easily test inputs of length 10k, and miri execution up to 100 which covers significantly more code. The randomness used is tied to a fixed - but random per process execution - seed. This allows for fully repeatable tests and fuzzer like exploration across multiple runs. Structure wise, the tests are previously found in the core integration tests for `sort_unstable` and alloc unit tests for `sort`. The new test-suite was developed to be a purely black-box approach, which makes integration testing the better place, because it can't accidentally rely on internal access. Because unwinding support is required the tests can't be in core, even if the implementation is, so they are now part of the alloc integration tests. Are there architectures that can only build and test core and not alloc? If so, do such platforms require sort testing? For what it's worth the current implementation state passes miri `--target mips64-unknown-linux-gnuabi64` which is big endian. The test-suite also contains tests for properties that were and are given by the current and previous implementations, and likely relied upon by users but weren't tested. For example `self_cmp` tests that the two parameters `a` and `b` passed into the comparison function are never references to the same object, which if the user is sorting for example a `&mut [Mutex<i32>]` could lead to a deadlock. Instead of using the hashed caller location as rand seed, it uses seconds since unix epoch / 10, which given timestamps in the CI should be reasonably easy to reproduce, but also allows fuzzer like space exploration. --- Test run-time changes: Setup: ``` Linux 6.10 rustc 1.83.0-nightly (f79a912 2024-09-18) AMD Ryzen 9 5900X 12-Core Processor (Zen 3 micro-architecture) CPU boost enabled. ``` master: e9df22f Before core integration tests: ``` $ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/coretests-219cbd0308a49e2f Time (mean ± σ): 869.6 ms ± 21.1 ms [User: 1327.6 ms, System: 95.1 ms] Range (min … max): 845.4 ms … 917.0 ms 10 runs # MIRIFLAGS="-Zmiri-disable-isolation" to get real time $ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/core finished in 738.44s ``` After core integration tests: ``` $ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/coretests-219cbd0308a49e2f Time (mean ± σ): 865.1 ms ± 14.7 ms [User: 1283.5 ms, System: 88.4 ms] Range (min … max): 836.2 ms … 885.7 ms 10 runs $ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/core finished in 752.35s ``` Before alloc unit tests: ``` LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloc-19c15e6e8565aa54 Time (mean ± σ): 295.0 ms ± 9.9 ms [User: 719.6 ms, System: 35.3 ms] Range (min … max): 284.9 ms … 319.3 ms 10 runs $ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc finished in 322.75s ``` After alloc unit tests: ``` LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloc-19c15e6e8565aa54 Time (mean ± σ): 97.4 ms ± 4.1 ms [User: 297.7 ms, System: 28.6 ms] Range (min … max): 92.3 ms … 109.2 ms 27 runs $ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc finished in 309.18s ``` Before alloc integration tests: ``` $ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloctests-439e7300c61a8046 Time (mean ± σ): 103.2 ms ± 1.7 ms [User: 135.7 ms, System: 39.4 ms] Range (min … max): 99.7 ms … 107.3 ms 28 runs $ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc finished in 231.35s ``` After alloc integration tests: ``` $ LD_LIBRARY_PATH=build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/ hyperfine build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/deps/alloctests-439e7300c61a8046 Time (mean ± σ): 379.8 ms ± 4.7 ms [User: 4620.5 ms, System: 1157.2 ms] Range (min … max): 373.6 ms … 386.9 ms 10 runs $ MIRIFLAGS="-Zmiri-disable-isolation" ./x.py miri library/alloc finished in 449.24s ``` In my opinion the results don't change iterative library development or CI execution in meaningful ways. For example currently the library doc-tests take ~66s and incremental compilation takes 10+ seconds. However I only have limited knowledge of the various local development workflows that exist, and might be missing one that is significantly impacted by this change.
…e, r=joboet Stabilize `debug_more_non_exhaustive` Fixes: #127942
Stabilise `const_char_encode_utf8`. Closes: #130512 This PR stabilises the `const_char_encode_utf8` feature gate (i.e. support for `char::encode_utf8` in const scenarios). Note that the linked tracking issue is currently awaiting FCP.
coverage: Remove code related to LLVM 17 In-tree LLVM is 19, and the minimum external LLVM was increased to 18 in #130487.
…uviper RustWrapper: adapt for rename of Intrinsic::getDeclaration llvm/llvm-project@fa789df renamed getDeclaration to getOrInsertDeclaration. `@rustbot` label: +llvm-main
Rollup of 7 pull requests Successful merges: - #130078 (rustdoc-json: change item ID's repr from a string to an int) - #131065 (Port sort-research-rs test suite to Rust stdlib tests) - #131109 (Stabilize `debug_more_non_exhaustive`) - #131287 (stabilize const_result) - #131463 (Stabilise `const_char_encode_utf8`.) - #131543 (coverage: Remove code related to LLVM 17) - #131552 (RustWrapper: adapt for rename of Intrinsic::getDeclaration) r? `@ghost` `@rustbot` modify labels: rollup
For the expr with attributes, like `let _ = (#[inline] || println!("Hello!"));`, the suggestion's span should contains the attributes, or the suggestion will remove them.
fixes #129833
intrinsics fmuladdf{32,64}: expose llvm.fmuladd.* semantics
Add intrinsics `fmuladd{f32,f64}`. This computes `(a * b) + c`, to be fused if the code generator determines that (i) the target instruction set has support for a fused operation, and (ii) that the fused operation is more efficient than the equivalent, separate pair of `mul` and `add` instructions.
https://llvm.org/docs/LangRef.html#llvm-fmuladd-intrinsic
The codegen_cranelift uses the `fma` function from libc, which is a correct implementation, but without the desired performance semantic. I think this requires an update to cranelift to expose a suitable instruction in its IR.
I have not tested with codegen_gcc, but it should behave the same way (using `fma` from libc).
---
This topic has been discussed a few times on Zulip and was suggested, for example, by `@workingjubilee` in [Effect of fma disabled](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Effect.20of.20fma.20disabled/near/274179331).
Migrate lib's `&Option<T>` into `Option<&T>` Trying out my new lint rust-lang/rust-clippy#13336 - according to the [video](https://www.youtube.com/watch?v=6c7pZYP_iIE), this could lead to some performance and memory optimizations. Basic thoughts expressed in the video that seem to make sense: * `&Option<T>` in an API breaks encapsulation: * caller must own T and move it into an Option to call with it * if returned, the owner must store it as Option<T> internally in order to return it * Performance is subject to compiler optimization, but at the basics, `&Option<T>` points to memory that has `presence` flag + value, whereas `Option<&T>` by specification is always optimized to a single pointer.
Support clobber_abi in MSP430 inline assembly This supports `clobber_abi` which is one of the requirements of stabilization mentioned in #93335. Refs: Section 3.2 "Register Conventions" in [MSP430 Embedded Application Binary Interface](https://www.ti.com/lit/an/slaa534a/slaa534a.pdf) cc ``@cr1901`` r? ``@Amanieu`` ``@rustbot`` label +O-msp430
Make unused_parens's suggestion considering expr's attributes.
For the expr with attributes,
like `let _ = (#[inline] || println!("Hello!"));`,
the suggestion's span should contains the attributes, or the suggestion will remove them.
fixes #129833
…r-errors Remove deprecation note in the `non_local_definitions` lint This PR removes the edition deprecation note emitted by the `non_local_definitions` lint. Specifically this part: ``` = note: this lint may become deny-by-default in the edition 2024 and higher, see the tracking issue <#120363> ``` because it [didn't make the cut](#120363 (comment)) for the 2024 edition. `@rustbot` label +L-non_local_definitions
Flatten redundant test module `run_make_support::diff::tests::tests` This module is already named `tests`, and is already gated by `#[cfg(test)]`, so there's no need for it to also contain `mod tests`. r? jieyouxu
Rollup of 7 pull requests Successful merges: - #124874 (intrinsics fmuladdf{32,64}: expose llvm.fmuladd.* semantics) - #130962 (Migrate lib's `&Option<T>` into `Option<&T>`) - #131289 (stabilize duration_consts_float) - #131310 (Support clobber_abi in MSP430 inline assembly) - #131546 (Make unused_parens's suggestion considering expr's attributes.) - #131565 (Remove deprecation note in the `non_local_definitions` lint) - #131576 (Flatten redundant test module `run_make_support::diff::tests::tests`) r? `@ghost` `@rustbot` modify labels: rollup
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.
See Commits and Changes for more details.
Created by
pull[bot]
Can you help keep this open source service alive? 💖 Please sponsor : )