Added new lint: `reserve_after_initialization`
Closes https://github.com/rust-lang/rust-clippy/issues/11330.
A new lint that informs the user about a more concise way to create a vector with a known capacity.
Example:
```rust
let mut v: Vec<usize> = vec![];
v.reserve(10);
```
Produces the following help:
```rust
|
2 | / let mut v: Vec<usize> = vec![];
3 | | v.reserve(10);
| |__________________^ help: consider using `Vec::with_capacity(space_hint)`: `let v: Vec<usize> = Vec::with_capacity(10);`
|
```
And can be rewritten as:
```rust
let v: Vec<usize> = Vec::with_capacity(10);
```
changelog: new lint [`reserve_after_initialization`]
ci: Update FreeBSD and illumos binutils to 2.40
The current old 2.25 seems to cause trouble to #106511.
Install texinfo to dist-x86_64-freebsd/Dockerfile like other containers
to fix
```
MAKEINFO doc/bfd.info
/binutils/binutils-2.40/missing: 81: /binutils/binutils-2.40/missing: makeinfo: not found
WARNING: 'makeinfo' is missing on your system.
```
---
https://www.freshports.org/devel/binutils uses 2.40 for FreeBSD 12.x as well.
`@nikic`
Fix tuple_array_conversions lint on nightly
```
changelog: ICE: [`tuple_array_conversions`]: Don't expect array length to always be usize
```
tl;dr: changed [`Const::eval_target_usize`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/ty/consts.rs#L359) to [`Consts::try_eval_target_usize`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_middle/src/ty/consts.rs#L327) to get rid of ICE.
I have encountered a problem with clippy: it caught ICE when working with a codebase that uses a lot of nightly features.
Here's a (stripped) ICE info:
```
error: internal compiler error: /rustc/5c6a7e71cd66705c31c9af94077901a220f0870c/compiler/rustc_middle/src/ty/consts.rs:361:32: expected usize, got Const { ty: usize, kind: N/#1 }
thread 'rustc' panicked at /rustc/5c6a7e71cd66705c31c9af94077901a220f0870c/compiler/rustc_errors/src/lib.rs:1635:9:
Box<dyn Any>
stack backtrace:
...
16: 0x110b9c590 - rustc_middle[449edf845976488d]::util:🐛:bug_fmt
17: 0x102f76ae0 - clippy_lints[71754038dd04c2d2]::tuple_array_conversions::all_bindings_are_for_conv
...
```
I don't really know what's going on low-level-wise, but seems like this lin assumed that the length of the array can always be treated as `usize`, and *I assume* this doesn't play well with `feat(generic_const_exprs)`.
I wasn't able to build a minimal reproducible example, but locally this fix does resolve the issue.
Rollup of 7 pull requests
Successful merges:
- #114930 (Automatically add OS labels to std PRs)
- #115053 (docs: Add example, reference link for `type` keyword.)
- #115092 (Add generics_of to smir)
- #115096 (Add regression test for not `memcpy`ing padding bytes)
- #115100 (Add support for `ptr::write`s for the `invalid_reference_casting` lint)
- #115114 (Contents of reachable statics is reachable)
- #115122 (Fix clippy lint for identical `if`/`else` contraining `?` expressions)
r? `@ghost`
`@rustbot` modify labels: rollup
Add support for `ptr::write`s for the `invalid_reference_casting` lint
This PR adds support for `ptr::write` and others for the `invalid_reference_casting` lint.
Detecting instances where instead of using the deref (`*`) operator to assign someone uses `ptr::write`, `ptr::write_unaligned` or `ptr::write_volatile`.
```rust
let data_len = 5u64;
std::ptr::write(
std::mem::transmute::<*const u64, *mut u64>(&data_len),
new_data_len,
);
```
r? ``@est31``
Add regression test for not `memcpy`ing padding bytes
Closes#56297
See this comparison: https://rust.godbolt.org/z/jjzfonfcE
I don't have any experience with codegen tests, I hope this is correct
Automatically add OS labels to std PRs
I'd love to have `library/std/src/sys` PRs that touch Windows stuff to have the `O-windows` label for easier discovery (and rediscovery). While I'm here I added a couple of other auto OS labels. Perhaps `O-unix` is a little too broad but it's hard to be more specific and I think it's still useful insomuch as POSIX is a thing.
r? libs
Update the links for Stabilized APIs in 1.72.0
* Use `stable` instead of `nightly` paths.
* Fix the anchors for `CStr::to_*` links.
r? `@Mark-Simulacrum`
Update cargo
3 commits in 80eca0e58fb2ff52c1e94fc191b55b37ed73e0e4..2cc50bc0b63ad20da193e002ba11d391af0104b7
2023-08-19 00:52:06 +0000 to 2023-08-22 22:43:08 +0000
- config: merge lists in precedence order (rust-lang/cargo#12515)
- ci: test `resolver-tests` in a separate job (rust-lang/cargo#12540)
- refactor: Use clap to suggest alternative argument for unsupported arguments (rust-lang/cargo#12529)
r? ghost
Don't do intra-pass validation on MIR shims
Fixes#114375
In the test that was committed, we end up generating the drop shim for `struct Foo` that looks like:
```
fn std::ptr::drop_in_place(_1: *mut Foo) -> () {
let mut _0: ();
bb0: {
goto -> bb5;
}
bb1: {
return;
}
bb2 (cleanup): {
resume;
}
bb3: {
goto -> bb1;
}
bb4 (cleanup): {
drop(((*_1).0: foo::WrapperWithDrop<()>)) -> [return: bb2, unwind terminate];
}
bb5: {
drop(((*_1).0: foo::WrapperWithDrop<()>)) -> [return: bb3, unwind: bb2];
}
}
```
In `bb4` and `bb5`, we assert that `(*_1).0` has type `WrapperWithDrop<()>`. However, In a user-facing param env, the type is actually `WrapperWithDrop<Tait>`. These types are not equal in a user-facing param-env (and can't be made equal even if we use `DefiningAnchor::Bubble`, since it's a non-local TAIT).
The current old 2.25 seems to cause trouble to #106511.
Install texinfo to dist-x86_64-freebsd/Dockerfile like other containers
to fix
```
MAKEINFO doc/bfd.info
/binutils/binutils-2.40/missing: 81: /binutils/binutils-2.40/missing: makeinfo: not found
WARNING: 'makeinfo' is missing on your system.
```
1. Turned patch-binaries-for-nix from a boolean into a ternary flag: true,
false, and unset.
2. When patch-binaries-for-nix is unset, we continue with the existing NixOS
detection heuristic (look for nixos in /etc/os-release, if present), but if
we are not atop NixOS, then issue a note if we see the IN_NIX_SHELL
environment variable telling the user to consider setting
patch-binaries-for-nix explicitly.
Use the same DISubprogram for each instance of the same inlined function within a caller
# Issue Details:
The call to `panic` within a function like `Option::unwrap` is translated to LLVM as a `tail call` (as it will never return), when multiple calls to the same function like this is inlined LLVM will notice the common `tail call` block (i.e., loading the same panic string + location info and then calling `panic`) and merge them together.
When merging these instructions together, LLVM will also attempt to merge the debug locations as well, but this fails (i.e., debug info is dropped) as Rust emits a new `DISubprogram` at each inline site thus LLVM doesn't recognize that these are actually the same function and so thinks that there isn't a common debug location.
As an example of this when building for x86_64 Windows (note the lack of `.cv_loc` before the call to `panic`, thus it will be attributed to the same line at the `addq` instruction):
```
.cv_loc 0 1 23 0 # src\lib.rs:23:0
addq $40, %rsp
retq
leaq .Lalloc_f570dea0a53168780ce9a91e67646421(%rip), %rcx
leaq .Lalloc_629ace53b7e5b76aaa810d549cc84ea3(%rip), %r8
movl $43, %edx
callq _ZN4core9panicking5panic17h12e60b9063f6dee8E
int3
```
# Fix Details:
Cache the `DISubprogram` emitted for each inlined function instance within a caller so that this can be reused if that instance is encountered again, this also requires caching the `DILexicalBlock` and `DIVariable` objects to avoid creating duplicates.
After this change the above assembly now looks like:
```
.cv_loc 0 1 23 0 # src\lib.rs:23:0
addq $40, %rsp
retq
.cv_inline_site_id 5 within 0 inlined_at 1 0 0
.cv_inline_site_id 6 within 5 inlined_at 1 12 0
.cv_loc 6 2 935 0 # library\core\src\option.rs:935:0
leaq .Lalloc_5f55955de67e57c79064b537689facea(%rip), %rcx
leaq .Lalloc_e741d4de8cb5801e1fd7a6c6795c1559(%rip), %r8
movl $43, %edx
callq _ZN4core9panicking5panic17hde1558f32d5b1c04E
int3
```
By default, `x check` doesn't compile the rust-analyzer. But when it's enabled in the config's
tools section, there's no reason not to do it. This change allows `x check` to compile rust-analyzer
if it's enabled in config's tools section.
Signed-off-by: ozkanonur <work@onurozkan.dev>
triagebot: add dependency licensing pings
If a compiler dependency is added, it's probably worth having that double-checked by compiler co-leads to confirm the licensing is okay.
r? `@wesleywiser`
Always use `os-release` rather than `/lib` to detect `NixOS` (bootstrap)
[Two users over on zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Bootstrapping.20on.20NixOS) bumped into issues where NixOS wasn't being properly detected.
I believe this was caused by the presence of `/lib` on their machines. `/lib` is not standard on NixOS but can still be created by users or scripts.
We are already checking `/etc/os-release`. The presence of `ID=nixos` in it's output should be trustworthy and we shouldn't then go on to also check for `/lib`.
Add disclaimer on size assertion macro
Sometimes people are inspired by rustc to add size assertions to their code and copy the macro. This is bad because it causes hard build errors. rustc happens to be special where it makes this okay.
For example, see #115028 (not sure whether they were directly inspired by this function), but I think I've also seen other cases.
Warn on elided lifetimes in associated constants (`ELIDED_LIFETIMES_IN_ASSOCIATED_CONSTANT`)
Elided lifetimes in associated constants (in impls) erroneously resolve to fresh lifetime parameters on the impl since #97313. This is not correct behavior (see #38831).
I originally opened #114716 to fix this, but given the time that has passed, the crater results seem pretty bad: https://github.com/rust-lang/rust/pull/114716#issuecomment-1682091952
This PR alternatively implements a lint against this behavior, and I'm hoping to bump this to deny in a few versions.
fix#113702 emit a proper diagnostic message for unstable lints passed from CLI
Current output:
```bash
$ build/host/stage1/bin/rustc hello.rs -Wunnameable_types
warning: unknown lint: `unnameable_types`
|
= note: the `unnameable_types` lint is unstable
= note: see issue #48054 <https://github.com/rust-lang/rust/issues/48054> for more information
= help: add `-Zcrate-attr="feature(type_privacy_lints)"` to the command-line options to enable
= note: `#[warn(unknown_lints)]` on by default
warning: 1 warning emitted
```
Previously, the feature gate diagnostic message is like below, which is the same as the message for unstable lints from the root module.
```shell
= help: add `#![feature(type_privacy_lints)]` to the crate attributes to enable
```
Fixes https://github.com/rust-lang/rust/issues/113702
