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
Move `#[rustc_coherence_is_core]` to the `crate_level` file
I implemented this one without realizing it already was since it was (in my opinion) in the wrong file and implemented in a batch of all non-crate-level attributes. This commit just cleans it up slightly and moves it. Should be trivial
r? `@oli-obk`
Make llvm_enzyme a regular cargo feature
This makes it clearer that it is set by the build system rather than by the rustc that compiles the current rustc. It also avoids bootstrap needing to pass `--check-cfg llvm_enzyme` to rustc.
Remove unsized arg handling in `ArgAbiBuilderMethods::store_fn_arg` implementations
... since it is unreachable and would ICE anyway.
These branches are unreachable with how `store_fn_arg` is currently used (where it is called, unsized arguments are either: 1. not (yet) supported, or 2. handled differently)[^1], and even if they were reachable, they would ICE anyway, since they call [`OperandValue::store`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#855-861), which calls [`OperandValue::store_with_flags`](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#887-926) which [panics on any unsized layout](https://doc.rust-lang.org/nightly/nightly-rustc/src/rustc_codegen_ssa/mir/operand.rs.html#900-903).
Also updates the `bug!` message in `store_arg` to not suggest `store_fn_arg` for unsized args.
[^1]: `store_fn_arg` is only nontrivially[^2] called in `compiler/rustc_codegen_ssa/src/mir/mod.rs` for: Line 428 `extern "rust-call"` tuple (un)splitting, which does not support unsized arguments, Line 496 which is only for sized `PassMode::Indirect` (`meta_attrs: None`) arguments, and Line 521 which is only for non-`PassMode::Indirect` arguments which can never be unsized.
[^2]: `<Bx as ArgAbiBuilderMethods>::store_fn_arg` is what is actually called, but codegen_llvm and codegen_gcc's builders both delegate to their own `codegen_crate::ArgAbiExt::store_fn_arg`, which contain the actual implementations that are changed in this PR.
Add parallel-frontend-threads to bootstrap.toml and enable multi-threaded parallel compilation
Add the option to use the parallel compiler when building Rust code in bootstrap.
