| Age | Commit message (Collapse) | Author | Lines |
|---|
|
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
|
|
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
|
|
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 <https://github.com/rust-lang/rust/issues/120363>
```
because it [didn't make the cut](https://github.com/rust-lang/rust/issues/120363#issuecomment-2407833300) for the 2024 edition.
`@rustbot` label +L-non_local_definitions
|
|
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
|
|
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
|
|
stabilize duration_consts_float
Waiting for FCP in https://github.com/rust-lang/rust/issues/72440 to pass.
`as_millis_f32` and `as_millis_f64` are not stable at all yet, so I moved their const-stability together with their regular stability (tracked at https://github.com/rust-lang/rust/issues/122451).
Fixes https://github.com/rust-lang/rust/issues/72440
|
|
Migrate lib's `&Option<T>` into `Option<&T>`
Trying out my new lint https://github.com/rust-lang/rust-clippy/pull/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.
|
|
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).
|
|
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
|
|
|
|
|
|
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
|
|
RustWrapper: adapt for rename of Intrinsic::getDeclaration
llvm/llvm-project@fa789dffb1e12c2aece0187aeacc48dfb1768340 renamed getDeclaration to getOrInsertDeclaration.
`@rustbot` label: +llvm-main
|
|
coverage: Remove code related to LLVM 17
In-tree LLVM is 19, and the minimum external LLVM was increased to 18 in #130487.
|
|
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.
|
|
stabilize const_result
Waiting for FCP to complete in https://github.com/rust-lang/rust/issues/82814
Fixes #82814
|
|
Stabilize `debug_more_non_exhaustive`
Fixes: https://github.com/rust-lang/rust/issues/127942
|
|
Port sort-research-rs test suite to Rust stdlib tests
This PR is a followup to https://github.com/rust-lang/rust/pull/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 https://github.com/rust-lang/rust/pull/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 (f79a912d9 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.
|
|
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``
|
|
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).
|
|
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 https://github.com/rust-lang/rust/pull/131358 (see the [actual problem](https://github.com/rust-lang/rust/pull/131448#issuecomment-2406516261)). 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?
|
|
|
|
|
|
llvm/llvm-project@fa789dffb1e12c2aece0187aeacc48dfb1768340 renamed
getDeclaration to getOrInsertDeclaration.
@rustbot label: +llvm-main
|
|
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
|
|
|
|
next-solver: remove outdated FIXMEs
r? `@compiler-errors`
|
|
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.
|
|
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 https://github.com/rust-lang/rust/pull/123994.
Issue https://github.com/rust-lang/rust/issues/123427
When I changed `default-hidden-visibility` to `default-visibility` in https://github.com/rust-lang/rust/pull/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.
|
|
ismailarilik:fix/rustdoc/add-space-between-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`
|
|
ABI: Pass aggregates by value on AIX
On AIX we pass aggregates byval. Adds new ABI for AIX for powerpc64.
https://github.com/llvm/llvm-project/blob/313ad85dfa40a18f2edefd7ce2edc0528d5a554a/clang/lib/CodeGen/Targets/PPC.cpp#L216
Fixes the following 2 testcases on AIX:
```
tests/ui/abi/extern/extern-pass-TwoU16s.rs
tests/ui/abi/extern/extern-pass-TwoU8s.rs
```
|
|
Create `_imp__` symbols also when doing ThinLTO
When generating a rlib crate on Windows we create `dllimport` / `_imp__` symbols for each global. This effectively makes the rlib contain an import library for itself and allows them to both be dynamically and statically linked. However when doing ThinLTO we do not generate these and thus we end up with missing symbols. Microsoft's `link` can fix these up (and emits warnings), but `lld` seems to currently be unable to.
This PR also does this generation for ThinLTO avoiding those issues with `lld` and also avoids the warnings on `link`.
This is an workaround for https://github.com/rust-lang/rust/issues/81408.
cc `@lqd`
|
|
Retire the `unnamed_fields` feature for now
`#![feature(unnamed_fields)]` was implemented in part in #115131 and #115367, however work on that feature has (afaict) stalled and in the mean time there have been some concerns raised (e.g.[^1][^2]) about whether `unnamed_fields` is worthwhile to have in the language, especially in its current desugaring. Because it represents a compiler implementation burden including a new kind of anonymous ADT and additional complication to field selection, and is quite prone to bugs today, I'm choosing to remove the feature.
However, since I'm not one to really write a bunch of words, I'm specifically *not* going to de-RFC this feature. This PR essentially *rolls back* the state of this feature to "RFC accepted but not yet implemented"; however if anyone wants to formally unapprove the RFC from the t-lang side, then please be my guest. I'm just not totally willing to summarize the various language-facing reasons for why this feature is or is not worthwhile, since I'm coming from the compiler side mostly.
Fixes #117942
Fixes #121161
Fixes #121263
Fixes #121299
Fixes #121722
Fixes #121799
Fixes #126969
Fixes #131041
Tracking:
* https://github.com/rust-lang/rust/issues/49804
[^1]: https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/Unnamed.20struct.2Funion.20fields
[^2]: https://github.com/rust-lang/rust/issues/49804#issuecomment-1972619108
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
Rollup of 6 pull requests
Successful merges:
- #131464 (Update wasm-component-ld to 0.5.10)
- #131476 (coverage: Include the highest counter ID seen in `.cov-map` dumps)
- #131497 (Add myself to bootstrap review rotation)
- #131498 (Consider outermost const-anon in `non_local_def` lint)
- #131512 (Fixing rustDoc for LayoutError.)
- #131529 (rustdoc-json-types: fix typo in comment)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This was previously only including ordinary `aux-build` crates, and not files
associated with the other three kinds of auxiliary crate.
|
|
|
|
|
|
rustdoc-json-types: fix typo in comment
|
|
Fixing rustDoc for LayoutError.
I started reading the the std lib from start to finish and noticed that this rustdoc comment wasn't correct.
|
|
Consider outermost const-anon in `non_local_def` lint
This PR change the logic for finding the parent of the `impl` definition in the `non_local_definitions` lint to consider multiple level of const-anon items, instead of only one currently.
I also took the opportunity to cleanup the related code.
cc ``@traviscross``
Fixes https://github.com/rust-lang/rust/issues/131474
|
|
Add myself to bootstrap review rotation
r? `@onur-ozkan`
|
|
coverage: Include the highest counter ID seen in `.cov-map` dumps
When making changes that have a large impact on coverage counter creation, this makes it easier to see whether the number of physical counters has changed.
(The highest counter ID seen in coverage maps is not necessarily the same as the number of physical counters actually used by the instrumented code, but it's the best approximation we can get from looking only at the coverage maps, and it should be reasonably accurate in most cases.)
Extracted from #131398, since I'm still considering whether to make those changes as-is, whereas this PR is useful and good on its own.
|
|
Update wasm-component-ld to 0.5.10
This pulls in a bug fix relative to the 0.5.9 release which was updated-to recently.
|
|
When making changes that have a large impact on coverage counter creation, this
makes it easier to see whether the number of physical counters has changed.
(The highest counter ID seen in coverage maps is not necessarily the same as
the number of physical counters actually used by the instrumented code, but
it's the best approximation we can get from looking only at the coverage maps,
and it should be reasonably accurate in most cases.)
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #131305 (make `llvm::is_ci_llvm_modified` logic more precise)
- #131524 (compiletest: Remove the magic hacks for finding output with `lto=thin`)
- #131525 (compiletest: Simplify the choice of `--emit` mode for assembly tests)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
compiletest: Simplify the choice of `--emit` mode for assembly tests
Tiny little cleanup that I noticed while working on #131524. No functional change.
Historically, the original code structure (#58791) predates the `Emit` enum (#103298), so it was manually adding `--emit` flags to the compiler invocation. But now the match can just evaluate to the appropriate `Emit` value directly.
|
