Document that "extern blocks must be unsafe" in Rust 2024
The [documentation on `extern`](https://doc.rust-lang.org/std/keyword.extern.html) contains the following code sample:
```rust
#[link(name = "my_c_library")]
extern "C" {
fn my_c_function(x: i32) -> bool;
}
```
Due to #123743, attempting to compile such code with the 2024 edition of Rust fails:
```
error: extern blocks must be unsafe
```
This PR extends the `extern` documentation with a brief explanation of the new requirement. It also adds the missing `unsafe` keyword to the code sample, which should be compatible with rustc since v1.82.
**Related docs:**
- https://doc.rust-lang.org/reference/items/external-blocks.html
- https://doc.rust-lang.org/edition-guide/rust-2024/unsafe-extern.html
Stabilize proc_macro::Span::{start,end,line,column}.
This stabilizes part of https://github.com/rust-lang/rust/issues/54725
Specifically, the part related to getting the location of a span:
```rust
impl Span {
pub fn start(&self) -> Span; // Empty span at the start of this span
pub fn end(&self) -> Span; // Empty span at the end of this span
pub fn line(&self) -> usize; // Line where the span starts
pub fn column(&self) -> usize; // Column where the span starts
}
```
History of this part of the API:
Originally, `start` and `end` returned a `LineColumn` struct (containing the line and column).
This has been simplified/changed:
- No more `LineColumn`: `Span` now directly has `.line()` and `.column()` methods. This means we can easily add `.byte_offset()` or `.byte_range()` in the future if we want to.
- `Span::start()` and `Span::end()` are now the equivalent of rustc's internal `shrink_to_lo()` and `shrink_to_hi()`. This means you can do e.g. `span.end().column()`, removing the need for a `span.end_column()` or similar.
Rollup of 8 pull requests
Successful merges:
- #137683 (Add a tidy check for GCC submodule version)
- #138968 (Update the index of Result to make the summary more comprehensive)
- #139572 (docs(std): mention const blocks in const keyword doc page)
- #140152 (Unify the format of rustc cli flags)
- #140193 (fix ICE in `#[naked]` attribute validation)
- #140205 (Tidying up UI tests [2/N])
- #140284 (remove expect() in `unnecessary_transmutes`)
- #140290 (rustdoc: fix typo change from equivelent to equivalent)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 8 pull requests
Successful merges:
- #137653 (Deprecate the unstable `concat_idents!`)
- #138957 (Update the index of Option to make the summary more comprehensive)
- #140006 (ensure compiler existance of tools on the dist step)
- #140143 (Move `sys::pal::os::Env` into `sys::env`)
- #140202 (Make #![feature(let_chains)] bootstrap conditional in compiler/)
- #140236 (norm nested aliases before evaluating the parent goal)
- #140257 (Some drive-by housecleaning in `rustc_borrowck`)
- #140278 (Don't use item name to look up associated item from trait item)
r? `@ghost`
`@rustbot` modify labels: rollup
Move `sys::pal::os::Env` into `sys::env`
Although `Env` (as `Vars`), `Args`, path functions, and OS constants are publicly exposed via `std::env`, their implementations are each self-contained. Keep them separate in `std::sys` and make a new module, `sys::env`, for `Env`.
Also fix `unsafe_op_in_unsafe_fn` for Unix and update the `!DynSend` and `!DynSync` impls which had grown out of sync with the platforms (see #48005 for discussion on that).
r? joboet
Tracked in #117276.
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
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`
`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
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
std: Add performance warnings to HashMap::get_disjoint_mut
Closes#139296
The `get_disjoint_mut` in `HashMap` also performs a complexity O(n^2) check. So we need to be reminded of that as well.
b5b0655a37/src/raw/mod.rs (L1216-L1220)
I found these by grepping for `&[a-z_\.]*\.clone()`, i.e. expressions
like `&a.b.clone()`, which are sometimes unnecessary clones, and also
looking at clones nearby to cases like that.
Validate extension in `PathBuf::add_extension`
The extension is validated in `PathBuf::set_extension`, but not `add_extension`. Fix that. Check for both `/` and `\` path separators on Windows, even when the path is verbatim, since this is logically like `PathBuf::push` which normalizes separators (i.e., keeping the current behavior).
`PathBuf::add_extension` is tracked in #127292.
r? `@ChrisDenton`
The extension is validated in `PathBuf::set_extension`, but not
`add_extension`. Fix that. Check for both / and \ path separators on
Windows, even when the path is verbatim, since this is logically like
`PathBuf::push` which normalizes separators (i.e., keeping the current
behavior).
