Specialize `Iterator::eq{_by}` for `TrustedLen` iterators
I'm sure I got some stuff wrong here, but opening this to get feedback and make sure it's a viable idea at all.
### Motivation
I had a piece of code that open-coded `Iterator::eq`, something like:
```rust
if current.len() != other.len()
|| current.iter().zip(other.iter()).any(|(a, b)| a != b) { ... }
```
... where both `current` and `other` are slices of the same type.
Changing the code to use `current.iter().eq(other)` made it a lot slower, since it wasn't checking the length of the two slices beforehand anymore, which in this instance made a big difference in perf. So I thought I'd see if I can improve `Iterator::eq`.
### Questions
1. I can't specialize for `ExactSizeIterator`, I think it's a limitation of `min_specialization` but not sure exactly why. Is specializing for `TrustedLen` good enough?
2. Should I make a codegen test for this? If so, then how? (I manually checked the assembly to make sure it works as expected)
3. Where should I put `SpecIterCompare`?
4. Can I get a perf run for this, please? I think the compiler uses this in a few places, so it might have an affect.
Clean up universe evaluation during type test evaluation
The logic was, as the removed comments suggest, hackish and meant to implement previous logic that was factored out. The new logic does exactly what the comments say, and is much less surprising.
I'm afraid we may want
r? `@lcnr`
for this one too.
I am sorry, but at least it should be easier to review.
Add regression test for issue #91831
The requested test for rust-lang/rust#91831. I'm unsure about the filename, the file structure in `tests/ui/lifetimes/lifetime-errors/` isn't entirely clear to me. Any suggestions?
Closesrust-lang/rust#91831
c-variadic: allow c-variadic inherent and trait methods
tracking issue: https://github.com/rust-lang/rust/issues/44930
Continuing the work of https://github.com/rust-lang/rust/pull/146342, allow inherent and trait methods to be c-variadic. However, a trait that contains a c-variadic method is no longer dyn-compatible.
There is, presumably, some way to make c-variadic methods dyn-compatible. However currently, we don't have confidence that it'll work reliably: when methods from a `dyn` object are cast to a function pointer, a `ReifyShim` is created. If that shim is c-variadic, it would need to forward the C variable argument list.
That does appear to work, because the `va_list` is not represented in MIR at all in this case, so the registers from the call site are untouched by the shim and can be read by the actual implementation. That just does not seem like a solid implementation.
Also, intuitively, why would c-variadic function, primarily needed for FFI, need to be used with `dyn` objects at all? We can revisit this limitation if a need arises.
r? `@workingjubilee`
`.unwrap_or(vec![])` is as readable as `.unwrap_or_default()`.
Also, this ensures by adding tests that expressions such as
`.unwrap_or(DEFAULT_LITERAL)` (`0`, `""`, etc.) are not replaced by
`.unwrap_or_default()` either.
Related to the discussion in the [Zulip
discussion](https://rust-lang.zulipchat.com/#narrow/channel/257328-clippy/topic/FCP.20concealed_obvious_default)
about PR rust-lang/rust-clippy#15037.
changelog: [`unwrap_or_default`]: do not replace `.unwrap_or(vec![])` by
`.unwrap_or_default()`
The logic was, as the removed comments suggest, hackish
and meant to implement previous logic that was factored out.
The new logic does exactly what the comments say, and is much
less surprising.
Prevent ABI changes affect EnzymeAD
This PR handles ABI changes for autodiff input arguments to improve Enzyme compatibility. Fundamentally this adjusts activities when a function argument is lowered as an `ScalarPair`, so there's no mismatch between diff activities and args. Also removes activities corresponding to ZSTs.
fixes: https://github.com/rust-lang/rust/issues/144025
r? `@ZuseZ4`
This fixes an issue where clippy suggests passing a function that takes
no arguments as the first argument of `Result::map_or_else`. The
function needs to take one argument. Example that triggers the issue:
[Playground
link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=0b6f9bc7b6ab4dcd26745065544e0b8a)
Fixes#10335.
changelog: [`option_if_let_else`]: fix incorrect suggestion when the
contents of an `Err` variant are ignored
cg_llvm: Replace some DIBuilder wrappers with LLVM-C API bindings (part 4)
- Part of rust-lang/rust#134001
- Follow-up to rust-lang/rust#146631
---
This is another batch of LLVMDIBuilder binding migrations, replacing some our own LLVMRust bindings with bindings to upstream LLVM-C APIs.
Clean up `ty::Dynamic`
1. As a follow-up to PR rust-lang/rust#143036, remove `DynKind` entirely.
2. Inside HIR ty lowering, consolidate modules `dyn_compatibility` and `lint` into `dyn_trait`
* `dyn_compatibility` wasn't about dyn compatibility itself, it's about lowering trait object types
* `lint` contained dyn-Trait-specific diagnostics+lints only
Cleanup `FnDecl::inner_full_print`
`inner_full_print` was pretty hard to follow IMHO.
Hopefully this cleans it up a little bit.
Also, it was checking whether `self.inputs` is empty twice, and then handling an unreachable match arm:
f836ae4e66/src/librustdoc/html/format.rs (L1368C1-L1368C33)
`last_input_index` could only be `None` if the fn has no parameters, in which case the loop body would never run.
r? ``@GuillaumeGomez`` if you have the capacity :)
BTW, can we rename `FnDecl::inputs` to `parameters` or something? And `output` to `return_ty`?
Lint more overlapping assignments in MIR.
In an effort to make bugs like https://github.com/rust-lang/rust/issues/146383 more easily discovered, this PR extends the "overlapping assignment" MIR lint.
I had to whitelist some rvalues, as they are actually allowed to alias, like `a = a + 1`.
This test, which checks that we do not define new profiles directly in
Clippy's multiple `Cargo.toml` files, must not look inside `target` as
`lintcheck` might place some third-party sources there. Of course those
third-party sources are allowed to define profiles in their
`Cargo.toml`.
changelog: none
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#146458 (Add parallel-frontend-threads to bootstrap.toml and enable multi-threaded parallel compilation)
- rust-lang/rust#146485 (Remove unsized arg handling in `ArgAbiBuilderMethods::store_fn_arg` implementations)
- rust-lang/rust#146536 (clean up several trait related UI tests)
- rust-lang/rust#146598 (Make llvm_enzyme a regular cargo feature)
- rust-lang/rust#146647 (Move `#[rustc_coherence_is_core]` to the `crate_level` file)
- rust-lang/rust#146654 (Do not use `git -C dir`)
- rust-lang/rust#146681 (Add space after brace in `Box<[T]>::new_uninit_slice` example)
r? `@ghost`
`@rustbot` modify labels: rollup
Do not use `git -C dir`
Older versions of git (≤ 1.8.5) do not support the `-C dir` global option. Use the `cwd` optional argument when using Python's `subprocess` functionality instead.
Fixrust-lang/rust#142534
