Update the index of Option to make the summary more comprehensive
fix: #138955
This PR and #138968 are twin PR
By the way, this is my first time contributing to rust, and I'm not a native English speaker, so any suggestions—whether about the wording in the docs or the contribution process itself—would be greatly appreciated!
Deprecate the unstable `concat_idents!`
`concat_idents` has been around unstably for a long time, but there is now a better (but still unstable) way to join identifiers using `${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves a lot of the problems with `concat_idents` and is on a better track toward stabilization, so there is no need to keep both versions around. `concat_idents!` still has a lot of use in the ecosystem so deprecate it before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
Indents for `cbox` and `ibox` are 0 or `INDENT_UNIT` (4) except for a
couple of places which are `INDENT_UNIT - 1` for no clear reason.
This commit changes the three space indents to four spaces.
Enable PGO optimizations when installing rust-analyzer with the
--pgo flag. This mirrors functionality already available in dist
command, allowing developers to create optimized local builds.
Example:
cargo xtask install --server --pgo clap-rs/clap
PGO code has been extracted to a dedicated module for reuse.
Work around cygwin issue on condvar timeout
This workaround *just works*... Actually I don't quite understand why does it work in such way. With a simple test on Cygwin, it seems that the maximum value of `tv_sec` could be 12899331056917, while the maximum value of `tv_nsec` should be a value floating around 464600000. A larger `timespec` could block the syscall forever.
r? `@joboet`
Improved diagnostics for non-primitive cast on non-primitive types (`Arc`, `Option`)
here is a small fix that improving error messaging when user is trying to do something like this
```rust
let _ = "x" as Arc<str>;
let _ = 2 as Option<i32>;
```
before it looks like this
```rust
error[E0605]: non-primitive cast: `&'static str` as `Arc<str>`
--> src\main.rs:3:13
|
3 | let _ = "x" as Arc<str>;
| ^^^^^^^^^^^^^^^ help: consider using the `From` trait instead: `Arc<str>::from("x")`
error[E0605]: non-primitive cast: `i32` as `Option<i32>`
--> src\main.rs:4:13
|
4 | let _ = 2 as Option<i32>;
```
which looks horrible to be honest
so i made a small fix that make errors looks like this
```rust
error[E0605]: non-primitive cast: `&'static str` as `Arc<str>`
|
3 | let _ = "x" as Arc<str>;
| ^^^^^^^^^^^^^^^
|
= note: an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object
help: consider using the `From` trait instead
|
3 - let _ = "x" as Arc<str>;
3 + let _ = Arc::<str>::from("x");
|
error[E0605]: non-primitive cast: `i32` as `Option<i32>`
|
4 | let _ = 2 as Option<i32>;
| ^^^^^^^^^^^^^^^^
|
= note: an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object
help: consider using the `From` trait instead
|
4 - let _ = 2 as Option<i32>;
4 + let _ = Option::<i32>::from(2);
```
**What improves?**
1) `Arc<str>::from("x")` which makes no sense because of missing `::`
2) readability
**Related Issue**
fixes#135412
[AIX] Handle AIX dynamic library extensions within c-link-to-rust-dylib run-make test
Dynamic libraries on AIX have the ".a" extension. The c-link-to-rust-dylib run-make test checks for the extension explicitly, so the extension for AIX is also added to accommodate the test case on AIX.
Stabilize flags for doctest cross compilation
This makes the following changes in preparation for supporting doctest cross-compiling in cargo:
- Renames `--runtool` and `--runtool-arg` to `--test-runtool` and `--test-runtool-arg` to maintain consistency with other `--test-*` arguments.
- Stabilizes the `--test-runtool` and `--test-runtool-arg`. These are needed in order to support cargo's `target.runner` option which specifies a runner to execute a cross-compiled doctest (for example, qemu).
- Stabilizes the `--enable-per-target-ignores` flag by removing it and making it unconditionally enabled. This makes it possible to disable a doctest on a per-target basis, which I think will be helpful for rolling out this feature.
These changes were suggested in https://rust-lang.zulipchat.com/#narrow/channel/266220-t-rustdoc/topic/stabilizing.20doctest.20xcompile/near/409281127
The intent is to stabilize the doctest-xcompile feature in cargo. This will help ensure that for projects that do cross-compile testing that their doctests are also covered. Currently there is a somewhat surprising behavior that they are ignored.
Closes https://github.com/rust-lang/rust/issues/64245
try-job: x86_64-msvc-1
`concat_idents` has been around unstably for a long time, but there is
now a better (but still unstable) way to join identifiers using
`${concat(...)}` syntax with `macro_metavar_expr_concat`. This resolves
a lot of the problems with `concat_idents` and is on a better track
toward stabilization, so there is no need to keep both versions around.
`concat_idents!` still has a lot of use in the ecosystem so deprecate it
before removing, as discussed in [1].
Link: https://github.com/rust-lang/rust/issues/124225
[1]: https://rust-lang.zulipchat.com/#narrow/channel/219381-t-libs/topic/Removing.20.60concat_idents.60
This allows deref patterns to move out of boxes.
Implementation-wise, I've opted to put the information of whether a
deref pattern uses a built-in deref or a method call in the THIR. It'd
be a bit less code to check `.is_box()` everywhere, but I think this way
feels more robust (and we don't have a `mutability` field in the THIR
that we ignore when the smart pointer's a box). I'm not sure about the
naming (or using `ByRef`), though.
Since deref patterns on boxes will be lowered differently, I'll be
making a separate test file for them. This makes sure we're still
testing the generic `Deref(Mut)::deref(_mut)`-based lowering.
This commit picks up a few odd ends discovered during the work on #130227.
It adds some documentation and renames a few methods with too generic names
to describe what they actually do. It also adds some debug output that was
helpful during bug hunting.
Remove git repository from git config
It is no longer needed after https://github.com/rust-lang/rust/pull/138591. We could even remove the `nightly_branch` field, but it still has one usage.
r? ``@jieyouxu``
rustc_target: Adjust RISC-V feature implication
This commit adjusts feature implication of the RISC-V ISA for better feature detection from the user perspective.
The main rule is:
* If the feature `A` is a functional superset of the feature `B` (`A ⊃ B`),
`A` is to imply `B`, even if this implication is not on the manual.
Such implications (not directly written in the ISA manual) are commented as `A ⊃ B`
which means "`A` is a (functional) superset of `B`".
1. `Zbc` → `Zbkc` (add as a superset)
The `Zbkc` extension is a subset of the `Zbc` extension (`Zbc` minus `clmulr` instruction).
2. `Zkr` → (nothing) (remove dependency to `Zicsr`)
Implication to the `Zicsr` extension is removed because (although nearly harmless), the `Zkr` extension (or the `seed` CSR section) defines its own subset of the `Zicsr` extension (guaranteed to work against the `seed` CSR which needs read/write access).
3. `Zvbb` → `Zvkb` (comment as a superset)
This implication was already there but not denoted as a functional superset. This commit adds the comment.
4. `Zvfh` → `Zvfhmin` (comment as a superset)
This is similar to the case above (`Zvbb` → `Zvkb`).
5. `Zvfh` → `Zve32f` (add implication per the ISA specification)
This dependency is on the ISA manual but was missing (due to the fact that `Zvfh` indirectly implies `Zve32f` on the current implementation through `Zvfh` → `Zvfhmin` which is a functional relation). This commit ensures that this is *also* ISA-compliant in the source code level (there's no functional changes though).
6. `Zvknhb` → `Zvknha` (add as a superset)
The `Zvknhb` extension (SHA-256 / SHA-512) is a functional superset of the `Zvknha` extension (SHA-256 only).
Autodiff flags
Interestingly, it seems that some other projects have conflicts with exactly the same LLVM optimization passes as autodiff.
At least `LLVMRustOptimize` has exactly the flags that we need to disable problematic opt passes.
This PR enables us to compile code where users differentiate two identical functions in the same module. This has been especially common in test cases, but it's not impossible to encounter in the wild.
It also enables two new flags for testing/debugging. I consider writing an MCP to upgrade PrintPasses to be a standalone -Z flag, since it is *not* the same as `-Z print-llvm-passes`, which IMHO gives less useful output. A discussion can be found here: [#t-compiler/llvm > Print llvm passes. @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/187780-t-compiler.2Fllvm/topic/Print.20llvm.20passes.2E/near/511533038)
Finally, it improves `PrintModBefore` and `PrintModAfter`. They used to work reliable, but now we just schedule enzyme as part of an existing ModulePassManager (MPM). Since Enzyme is last in the MPM scheduling, PrintModBefore became very inaccurate. It used to print the input module, which we gave to the Enzyme and was great to create llvm-ir reproducer. However, lately the MPM would run the whole `default<O3>` pipeline, which heavily modifies the llvm module, before we pass it to Enzyme. That made it impossible to use the flag to create llvm-ir reproducers for Enzyme bugs. We now schedule a PrintModule pass just before Enzyme, solving this problem.
Based on the PrintPass output, it also _seems_ like changing `registerEnzymeAndPassPipeline(PB, true);` to `registerEnzymeAndPassPipeline(PB, false);` has no effect. In theory, the bool should tell Enzyme to schedule some helpful passes in the PassBuilder. However, since it doesn't do anything and I'm not 100% sure anymore on whether we really need it, I'll just disable it for now and postpone investigations.
r? ``@oli-obk``
closes#139471
Tracking:
- https://github.com/rust-lang/rust/issues/124509
Add `#[repr(u128)]`/`#[repr(i128)]` enums to `improper_ctypes_definitions`
This makes them warn whenever a plain `u128`/`i128` would. If the lang team decides to merge #137306 then this can be reverted.
Tracking issue: #56071
Suggest {to,from}_ne_bytes for transmutations between arrays and integers, etc
implements #136067
Rust has helper methods for many kinds of safe transmutes, for example integer<->bytes. This is a lint against using transmute for these cases.
```rs
fn bytes_at_home(x: [u8; 4]) -> u32 {
transmute(x)
}
// other examples
transmute::<[u8; 2], u16>();
transmute::<[u8; 8], f64>();
transmute::<u32, [u8; 4]>();
transmute::<char, u32>();
transmute::<u32, char>();
```
It would be handy to suggest `u32::from_ne_bytes(x)`.
This is implemented for `[u8; _]` -> `{float int}`
This also implements the cases:
`fXX` <-> `uXX` = `{from_bits, to_bits}`
`uXX` -> `iXX` via `cast_unsigned` and `cast_signed`
{`char` -> `u32`, `bool` -> `n8`} via `from`
`u32` -> `char` via `from_u32_unchecked` (note: notes `from_u32().unwrap()`) (contested)
`u8` -> `bool` via `==` (debatable)
---
try-job: aarch64-gnu
try-job: test-various
