Get performance closer to the glibc implementations by adding assembly
fma routines, with runtime feature detection so they are used even if
not compiled with `+fma` (as the distributed standard library is often
not). Glibc uses ifuncs, this implementation stores a function pointer
in an atomic.
Results of CPU flags are also cached in order to avoid repeating the
startup time in calls to different functions. The feature detection code
is a slightly simplified version of `std-detect`.
Musl sources were used as a reference [1].
Fixes: https://github.com/rust-lang/rust/issues/140452 once synced
[1]: c47ad25ea3/src/math/x32/fma.c
By consecutively initializing `tracing` and `rustc_log`, Rustdoc assumes
that these involve 2 different tracing crates.
I would like to be able to build rustdoc against the same tracing crate
that rustc_log is also built against. Previously this arrangement would
crash rustdoc:
thread 'main' panicked at rust/compiler/rustc_log/src/lib.rs:142:65:
called `Result::unwrap()` on an `Err` value: SetGlobalDefaultError("a global default trace dispatcher has already been set")
stack backtrace:
0: rust_begin_unwind
1: core::panicking::panic_fmt
2: core::result::unwrap_failed
3: rustc_log::init_logger
4: rustc_driver_impl::init_logger
5: rustdoc::main
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-rustdoc&template=ice.md
note: please make sure that you have updated to the latest nightly
query stack during panic:
end of query stack
doc(std): fix typo lchown -> lchmod
chown is irrelevant here, as this function does not affect file ownership. chmod is the correct function to reference here.
Remove fragile equal-pointers-unequal tests.
Same as https://github.com/rust-lang/rust/pull/139176
---
These tests were added in #127003
These tests stop working when I change implementation details of format_args!(). These tests shouldn't rely on such implementation details.
Do these tests test anything that isn't already covered by other tests? If so, they should be expressed in a less fragile way that doesn't rely on internal details of format_args!().
cc `@GrigorenkoPV,` author of these tests.
organize and extend forbidden target feature tests
In particular this adds some loongarch tests for https://github.com/rust-lang/rust/pull/135015, Cc `@heiher`
Seems like the tests change so much git does not detect the renames; a commit-by-commit review should help.
try-job: `x86_64-gnu-llvm-20-*`
resolve: Support imports of associated types and glob imports from traits
Follow up to https://github.com/rust-lang/rust/pull/134754, part of https://github.com/rust-lang/rust/issues/134691.
This PR also closes https://github.com/rust-lang/rust/issues/138711 now.
Prohibiting `use Trait::AssocType;` at name resolution stage doesn't make sense, the name itself is perfectly resolveable.
It's a type checker's problem that the necessary generic args are not passed when the imported `AssocType` is used, so an error should be reported there.
And since we can import associated trait items now, glob imports from traits can also be allowed.
Use a closure instead of three chained iterators
Fixes the perf regression from #123948
That PR had chained a third option to the iterator which apparently didn't optimize well
Fix the test for s390x by enabling s390x vector extension via
`target_feature(enable = "vector")`(#127506). As this is is still
gated by `#![feature(s390x_target_feature)]` we need that attribute
also.
Rollup of 8 pull requests
Successful merges:
- #139343 (Change signature of File::try_lock and File::try_lock_shared)
- #140505 (linker: Quote symbol names in .def files)
- #140534 (PassWrapper: adapt for llvm/llvm-project@f137c3d592e96330e450a8fd63ef…)
- #140546 (Remove backtrace dep from anyhow in features status dump tool)
- #140548 (Emit user type annotations for free consts in pattern position)
- #140564 (Use present indicative tense in std::io::pipe() API docs)
- #140568 (Add regression test for #140545)
- #140606 (Improve hir pretty printing)
r? `@ghost`
`@rustbot` modify labels: rollup
Add regression test for #140545Closes#140545
I am not very knowledgable about the typesystem internals, so I couldn't come up with a good name for the test. But I'm happy to move it to a more appropriate place if there is one (`tests/ui/impl-trait/non-defining-uses` maybe?)
r? types (or reroll as appropriate if this is not actually a T-types issue; i'm clueless)
Use present indicative tense in std::io::pipe() API docs
The inline documentation for all other free functions in the `std::io` module use the phrase "creates a" instead of "create a", except for the currently nightly-only `std::io::pipe()` function. This commit updates the text to align with the predominant wording in the `std::io` module.
I recognize this PR is quite a minuscule nitpick, so feel free to ignore and close if you disagree and/or there are bigger fish to fry. Thanks in advance! 😄
Relates to https://github.com/rust-lang/rust/issues/127154.
Emit user type annotations for free consts in pattern position
This previously wasnt done because free consts couldn't have any generic parameters that need to be preserved for borrowck. This is no longer the case with `feature(generic_const_items)`
r? fmease
Remove backtrace dep from anyhow in features status dump tool
According to `anyhow`'s Cargo.toml:
> On compilers older than 1.65, features=["backtrace"] may be used to enable
> backtraces via the `backtrace` crate. This feature has no effect on 1.65+
> besides bringing in an unused dependency, as `std::backtrace` is always
> preferred.
So this is just bringing in an unused dependency.
PassWrapper: adapt for llvm/llvm-project@f137c3d592e96330e450a8fd63ef…
…7e8877fc1908
In LLVM 21 PR https://github.com/llvm/llvm-project/pull/130940 `TargetRegistry::createTargetMachine` was changed to take a `const Triple&` and has deprecated the old `StringRef` method.
``@rustbot`` label llvm-main
