Change leak check and suspicious auto trait lint warning messages
The leak check lint message "this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!" is misleading as some cases may not be phased out and could end being accepted. This is under discussion still.
The suspicious auto trait lint the change in behavior already happened, so the new message is probably more accurate.
r? `@lcnr`
Closes#93367
Reimpl meaningful test name lint MCP658
This reintroduces the tidy rule originally proposed in https://github.com/rust-lang/rust/pull/113583 that then became an MCP in https://github.com/rust-lang/compiler-team/issues/658 which eventually surfaced a quite-reasonable request for a diagnostic enhancement. I have added that to the rule. It produces output like this:
```
tidy error: file `ui/unsized/issue-115809.rs` must begin with a descriptive name, try `{reason}-issue-115809.rs`
tidy error: file `ui/unsized/issue-115203.rs` must begin with a descriptive name, try `{reason}-issue-115203.rs`
tidy error: file `ui/privacy/issue-113860-2.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/issue-119463.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/auxiliary/issue-117997.rs` must begin with a descriptive name, try `{reason}-issue-117997.rs`
tidy error: file `ui/privacy/auxiliary/issue-119463-extern.rs` must begin with a descriptive name, try `{reason}-issue-119463.rs`
tidy error: file `ui/privacy/issue-113860-1.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/privacy/issue-113860.rs` must begin with a descriptive name, try `{reason}-issue-113860.rs`
tidy error: file `ui/const-generics/generic_const_exprs/const_kind_expr/issue_114151.rs` must begin with a descriptive name, try `{reason}-issue-114151.rs`
tidy error: file `ui/did_you_mean/issue-114112.rs` must begin with a descriptive name, try `{reason}-issue-114112.rs`
tidy error: file `ui/did_you_mean/issue-105225.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
tidy error: file `ui/did_you_mean/issue-105225-named-args.rs` must begin with a descriptive name, try `{reason}-issue-105225.rs`
```
You get the idea.
There are some tests which merely would require reordering of the name according to the rule. I could modify the diagnostic further to identify those, but doing such would make it prone to bad suggestions. I have opted to trust contributors to recognize the diagnostic is robotic, as the pattern we are linting on is easier to match if we do not speculate on what parts of the name are meaningful: sometimes a word is a reason, but sometimes it is a mere "tag", such as with a pair like:
- issue-314159265-blue.rs
- issue-314159265-red.rs
Starting them with `red-` and `blue-` means they do not sort together, despite being related, and the color names are still not very descriptive. Recognizing a good name is an open-ended task, though this pair might be:
- colored-circle-gen-blue.rs
- colored-circle-gen-red.rs
Deciding exactly *how* to solve this is not the business of tidy, only recognizing a what.
r? `@compiler-errors`
deduplicate infer var instantiation
Having 3 separate implementations of one of the most subtle parts of our type system is not a good strategy if we want to maintain a sound type system ✨ while working on this I already found some subtle bugs in the existing code, so that's awesome 🎉 cc #121159
This was necessary as I am not confident in my nll changes in #119106, so I am first cleaning this up in a separate PR.
r? `@BoxyUwU`
distribute tool documentations and avoid file conflicts on `x install`
I suggest reading commits one-by-one with the descriptions for more context about the changes.
Fixes#115213
Specialize some methods of `io::Chain`
This PR specializes the implementation of some methods of `io::Chain`, which could bring performance improvements when using it.
Portable SIMD subtree update
Syncs nightly to the latest changes from rust-lang/portable-simd
r? `@rust-lang/libs`
Also, fixes#119904 which is now fixed upstream.
macro_rules: Preserve all metavariable spans in a global side table
This PR preserves spans of `tt` metavariables used to pass tokens to declarative macros.
Such metavariable spans can then be used in span combination operations like `Span::to` to improve all kinds of diagnostics.
Spans of non-`tt` metavariables are currently kept in nonterminal tokens, but the long term plan is remove all nonterminal tokens from rustc parser and rely on the proc macro model with invisible delimiters (#114647, #67062).
In particular, `NtIdent` nonterminal (corresponding to `ident` metavariables) becomes easy to remove when this PR lands (#119412 does it).
The metavariable spans are kept in a global side table keyed by `Span`s of original tokens.
The alternative to the side table is keeping them in `SpanData` instead, but the performance regressions would be large because any spans from tokens passed to declarative macros would stop being inline and would work through span interner instead, and the penalty would be paid even if we never use the metavar span for the given original span.
(But also see the comment on `fn maybe_use_metavar_location` describing the map collision issues with the side table approach.)
There are also other alternatives - keeping the metavar span in `Token` or `TokenTree`, but associating it with `Span` itsel is the most natural choice because metavar spans are used in span combining operations, and those operations are not necessarily tied to tokens.
Tracking import use types for more accurate redundant import checking
fixes#117448
By tracking import use types to check whether it is scope uses or the other situations like module-relative uses, we can do more accurate redundant import checking.
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
fixes#117448
For example unnecessary imports in std::prelude that can be eliminated:
```rust
use std::option::Option::Some;//~ WARNING the item `Some` is imported redundantly
use std::option::Option::None; //~ WARNING the item `None` is imported redundantly
```
Properly deal with weak alias types as self types of impls
Fixes#114216.
Fixes#116100.
Not super happy about the two ad hoc “normalization” implementations for weak alias types:
1. In `inherent_impls`: The “peeling”, normalization to [“WHNF”][whnf]: Semantically that's exactly what we want (neither proper normalization nor shallow normalization would be correct here). Basically a weak alias type is “nominal” (well...^^) if the WHNF is nominal. [#97974](https://github.com/rust-lang/rust/pull/97974) followed the same approach.
2. In `constrained_generic_params`: Generic parameters are constrained by a weak alias type if the corresp. “normalized” type constrains them (where we only normalize *weak* alias types not arbitrary ones). Weak alias types are injective if the corresp. “normalized” type is injective.
Both have ad hoc overflow detection mechanisms.
**Coherence** is handled in #117164.
r? `@oli-obk` or types
[whnf]: https://en.wikipedia.org/wiki/Lambda_calculus_definition#Weak_head_normal_form
Make `io::BorrowedCursor::advance` safe
This also keeps the old `advance` method under `advance_unchecked` name.
This makes pattern like `std::io::default_read_buf` safe to write.
Support configuring the set of codegen backends to build per host triple
This allows building the compiler itself with one backend while using another backend at runtime. For example this allows compiling rustc to wasm using LLVM, while using Cranelift at runtime to produce actual code. Cranelift can't compile to wasm, but is perfectly capable of running on wasm. LLVM can compile to wasm, but can't run on wasm. [^1]
[^1]: The prototype of this still requires a couple of other patches.
fix: Fix snippets being placed leftwards of where they should be
Snippet bits were being escaped before placing snippets, shifting snippets leftwards. Snippets were also being shifted leftwards on files with CRLF line endings since they were placed done after the Unix -> DOS line ending conversion.
Hoping this fixes all of the little bugs related to snippet rendering 😅
internal: Parse (nightly) `const` and `async` trait bounds
Both of these bound modifiers were added recently:
* `const` trait bounds: https://github.com/rust-lang/rust/pull/119099
* `async` trait bounds: https://github.com/rust-lang/rust/pull/120392
The latter will certainly will not do the right thing; namely, `async Fn` needs to be mapped to the `AsyncFn` trait. IDK how to do that, so advice would be appreciated, though perhaps we could land this first so the parser isn't complaining about these bounds?
ci: Update GitHub Actions and Node version
Use newer versions of actions; Node 16 -> 18
Fix several warnings in the actions tab regarding usage of the EOL Node 16
Rename MaybeUninit::write_slice
A step to push #79995 forward.
https://github.com/rust-lang/libs-team/issues/122 also suggested to make them inherent methods, but they can't be — they'd conflict with slice's regular methods.
fix: Don't show type mismatches for `{unknown}` to non-`{unknown}` mismatches
Fixes https://github.com/rust-lang/rust-analyzer/issues/15704
Basically we zip the two types, inspecting their substitutions if the constructors are the same, if we encounter a zip step with an `{unknown}` on one side and a non-`{unknown}` on the other we error out and discard the diagnostic. Otherwise we keep it.
Implement intrinsics with fallback bodies
fixes#93145 (though we can port many more intrinsics)
cc #63585
The way this works is that the backend logic for generating custom code for intrinsics has been made fallible. The only failure path is "this intrinsic is unknown". The `Instance` (that was `InstanceDef::Intrinsic`) then gets converted to `InstanceDef::Item`, which represents the fallback body. A regular function call to that body is then codegenned. This is currently implemented for
* codegen_ssa (so llvm and gcc)
* codegen_cranelift
other backends will need to adjust, but they can just keep doing what they were doing if they prefer (though adding new intrinsics to the compiler will then require them to implement them, instead of getting the fallback body).
cc `@scottmcm` `@WaffleLapkin`
### todo
* [ ] miri support
* [x] default intrinsic name to name of function instead of requiring it to be specified in attribute
* [x] make sure that the bodies are always available (must be collected for metadata)
lsp-server: add license files
The `lsp-server` crate is currently published without license files, which is needed when packaging in Linux distributions.
Symlink the files from the repository root so they are kept in sync.
Test showing the files get picked up by `cargo package`:
```
michel in rust-analyzer/lib/lsp-server on add-lsp-server-license [+] is 📦 v0.7.6 via 🐍 v3.12.1 (.venv311) via 🦀 v1.76.0
⬢ [fedora:39] ❯ cargo package --allow-dirty --no-verify
Updating crates.io index
Packaging lsp-server v0.7.6 (/home/michel/src/github/rust-lang/rust-analyzer/lib/lsp-server)
Updating crates.io index
Packaged 12 files, 59.6KiB (16.3KiB compressed)
michel in rust-analyzer/lib/lsp-server on add-lsp-server-license [+] is 📦 v0.7.6 via 🐍 v3.12.1 (.venv311) via 🦀 v1.76.0
⬢ [fedora:39] ❯ tar tf ../../target/package/lsp-server-0.7.6.crate | grep LICENSE
lsp-server-0.7.6/LICENSE-APACHE
lsp-server-0.7.6/LICENSE-MIT
```
internal: Migrate assists to the structured snippet API, part 7/7
Continuing from #16467
Migrates the following assists:
- `generate_trait_from_impl`
This adds `add_placeholder_snippet_group`, which adds a group of placeholder snippets which are linked together and allows for renaming generated items without going through a separate rename step.
This also removes the last usages of `SourceChangeBuilder::{insert,replace}_snippet`, as all assists have finally been migrated to the structured snippet versions of those methods.
The eventual LSP representation looks like it will diverge from RA's representation of `SnippetTextEdit`s, so this'll make it easier to transition to the LSP representation later.
