Fix test simd/extract-insert-dyn on s390x
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.
Check if format argument is identifier to avoid error err-emit
Fixes#139104
When `argument` is not an identifier, it should not be considered a field access. I checked this and if not emit an invalid format string error. I think we could do with a little finer error handling, I'll open an issue to track this down later.
The first commit submits the ui test, the second commits the code and the changes to the test output.
r? compiler
Add the AVX10 target features
Parent #138843
Adds the `avx10_target_feature` feature gate, and `avx10.1` and `avx10.2` target features.
It is confirmed that Intel is dropping AVX10/256 (see [this comment](https://github.com/rust-lang/rust/issues/111137#issuecomment-2795442288)), so this should be safe to implement now.
The LLVM fix for llvm/llvm-project#135394 was merged, and has been backported to LLVM20, and the patch has also been propagated to rustc in #140502
`@rustbot` label O-x86_64 O-x86_32 A-target-feature A-SIMD
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
mono collector: Reduce # of locking while walking the graph
While profiling Zed's dev build I've noticed that while most of the time `upstream_monomorphizations` takes a lot of time in monomorpization_collector, in some cases (e.g. build of `editor` itself) the rest of monomorphization_collector_graph_walk dominates it. Most of the time is spent in collect_items_rec.
This PR aims to reduce the number of locks taking place; instead of locking output MonoItems once per children of current node, we do so once per *current node*. We also get to reuse locks for mentioned and used items. While this commit does not reduce Wall time of Zed's build, it does shave off CPU time (measured with `cargo build -j1`) from 48s to 47s. I've also tested it with parallel frontend against Zed and ripgrep and found no regressions.
Rollup of 9 pull requests
Successful merges:
- #140485 (Optimize the codegen for `Span::from_expansion`)
- #140509 (transmutability: merge contiguous runs with a common destination)
- #140519 (Use select in projection lookup in `report_projection_error`)
- #140521 (interpret: better error message for out-of-bounds pointer arithmetic and accesses)
- #140536 (Rename `*Guard::try_map` to `filter_map`.)
- #140550 (Stabilize `select_unpredictable`)
- #140563 (extend the list of registered dylibs on `test::prepare_cargo_test`)
- #140572 (Add useful comments on `ExprKind::If` variants.)
- #140574 (Add regression test for 133065)
r? `@ghost`
`@rustbot` modify labels: rollup
Use select in projection lookup in `report_projection_error`
Using `for_each_relevant_impl` doesn't actually select the correct impl; we can use `select` here to actually get the correct impl with certainty. Follow-up to https://github.com/rust-lang/rust/pull/140278.
r? oli-obk
Optimize the codegen for `Span::from_expansion`
See https://godbolt.org/z/bq65Y6bc4 for the difference. the new version is less than half the number of instructions.
Also tried fully writing the function by hand:
```rust
sp.ctxt_or_parent_or_marker != 0
&& (
sp.len_with_tag_or_marker == BASE_LEN_INTERNED_MARKER
|| sp.len_with_tag_or_marker & PARENT_TAG == 0
)
```
But that was no better than this PR's current use of `match_span_kind`.
