Reject `CVarArgs` in `parse_ty_for_where_clause`
Fixes#125847. This regressed in #77035 where the `parse_ty` inside `parse_ty_where_predicate` was replaced with the at the time new `parse_ty_for_where_clause` which incorrectly stated it would permit CVarArgs (maybe a copy/paste error).
r? parser
Stabilize `custom_code_classes_in_docs` feature
Fixes#79483.
This feature has been around for quite some time now, I think it's fine to stabilize it now.
## Summary
## What is the feature about?
In short, this PR changes two things, both related to codeblocks in doc comments in Rust documentation:
* Allow to disable generation of `language-*` CSS classes with the `custom` attribute.
* Add your own CSS classes to a code block so that you can use other tools to highlight them.
#### The `custom` attribute
Let's start with the new `custom` attribute: it will disable the generation of the `language-*` CSS class on the generated HTML code block. For example:
```rust
/// ```custom,c
/// int main(void) {
/// return 0;
/// }
/// ```
```
The generated HTML code block will not have `class="language-c"` because the `custom` attribute has been set. The `custom` attribute becomes especially useful with the other thing added by this feature: adding your own CSS classes.
#### Adding your own CSS classes
The second part of this feature is to allow users to add CSS classes themselves so that they can then add a JS library which will do it (like `highlight.js` or `prism.js`), allowing to support highlighting for other languages than Rust without increasing burden on rustdoc. To disable the automatic `language-*` CSS class generation, you need to use the `custom` attribute as well.
This allow users to write the following:
```rust
/// Some code block with `{class=language-c}` as the language string.
///
/// ```custom,{class=language-c}
/// int main(void) {
/// return 0;
/// }
/// ```
fn main() {}
```
This will notably produce the following HTML:
```html
<pre class="language-c">
int main(void) {
return 0;
}</pre>
```
Instead of:
```html
<pre class="rust rust-example-rendered">
<span class="ident">int</span> <span class="ident">main</span>(<span class="ident">void</span>) {
<span class="kw">return</span> <span class="number">0</span>;
}
</pre>
```
To be noted, we could have written `{.language-c}` to achieve the same result. `.` and `class=` have the same effect.
One last syntax point: content between parens (`(like this)`) is now considered as comment and is not taken into account at all.
In addition to this, I added an `unknown` field into `LangString` (the parsed code block "attribute") because of cases like this:
```rust
/// ```custom,class:language-c
/// main;
/// ```
pub fn foo() {}
```
Without this `unknown` field, it would generate in the DOM: `<pre class="language-class:language-c language-c">`, which is quite bad. So instead, it now stores all unknown tags into the `unknown` field and use the first one as "language". So in this case, since there is no unknown tag, it'll simply generate `<pre class="language-c">`. I added tests to cover this.
EDIT(camelid): This description is out-of-date. Using `custom,class:language-c` will generate the output `<pre class="language-class:language-c">` as would be expected; it treats `class:language-c` as just the name of a language (similar to the langstring `c` or `js` or what have you) since it does not use the designed class syntax.
Finally, I added a parser for the codeblock attributes to make it much easier to maintain. It'll be pretty easy to extend.
As to why this syntax for adding attributes was picked: it's [Pandoc's syntax](https://pandoc.org/MANUAL.html#extension-fenced_code_attributes). Even if it seems clunkier in some cases, it's extensible, and most third-party Markdown renderers are smart enough to ignore Pandoc's brace-delimited attributes (from [this comment](https://github.com/rust-lang/rust/pull/110800#issuecomment-1522044456)).
r? `@notriddle`
Support mdBook preprocessors for TRPL in rustbook
`rust-lang/book` recently added two mdBook preprocessors. Enable `rustbook` to use those preprocessors for books where they are requested by the `book.toml` by adding the preprocessors as path dependencies, and ignoring them where they are not requested, i.e. by all the books other than TRPL at present.
Addresses rust-lang/book#3927
don't inhibit random field reordering on repr(packed(1))
`inhibit_struct_field_reordering_opt` being false means we exclude this type from random field shuffling. However, `packed(1)` types can still be shuffled! The logic was added in https://github.com/rust-lang/rust/pull/48528 since it's pointless to reorder fields in packed(1) types (there's no padding that could be saved) -- but that shouldn't inhibit `-Zrandomize-layout` (which did not exist at the time).
We could add an optimization elsewhere to not bother sorting the fields for `repr(packed)` types, but I don't think that's worth the effort.
This *does* change the behavior in that we may now reorder fields of `packed(1)` structs (e.g. if there are niches, we'll try to move them to the start/end, according to `NicheBias`). We were always allowed to do that but so far we didn't. Quoting the [reference](https://doc.rust-lang.org/reference/type-layout.html):
> On their own, align and packed do not provide guarantees about the order of fields in the layout of a struct or the layout of an enum variant, although they may be combined with representations (such as C) which do provide such guarantees.
A small diagnostic improvement for dropping_copy_types
For a value `m` which implements `Copy` trait, `drop(m);` does nothing.
We now suggest user to ignore it by a abstract and general note: `let _ = ...`.
I think we can give a clearer note here: `let _ = m;`
fixes#125189
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
rustdoc: Clarify const-stability with regard to normal stability
Fixes#125511.
- Elide const-unstable if also unstable overall
- Show "const" for const-unstable if also overall unstable
drop region constraints for ambiguous goals
See the comment in `compute_external_query_constraints`. While the underlying issue is preexisting, this fixes a bug introduced by #125343.
It slightly weakens the leak chec, even if we didn't have any test which was affected. I want to write such a test before merging this PR.
r? `@compiler-errors`
[perf] Delay the construction of early lint diag structs
Attacks some of the perf regressions from https://github.com/rust-lang/rust/pull/124417#issuecomment-2123700666.
See individual commits for details. The first three commits are not strictly necessary.
However, the 2nd one (06bc4fc67145e3a7be9b5a2cf2b5968cef36e587, *Remove `LintDiagnostic::msg`*) makes the main change way nicer to implement.
It's also pretty sweet on its own if I may say so myself.
Remove `DefId` from `EarlyParamRegion`
Currently we represent usages of `Region` parameters via the `ReEarlyParam` or `ReLateParam` variants. The `ReEarlyParam` is effectively equivalent to `TyKind::Param` and `ConstKind::Param` (i.e. it stores a `Symbol` and a `u32` index) however it also stores a `DefId` for the definition of the lifetime parameter.
This was used in roughly two places:
- Borrowck diagnostics instead of threading the appropriate `body_id` down to relevant locations. Interestingly there were already some places that had to pass down a `DefId` manually.
- Some opaque type checking logic was using the `DefId` field to track captured lifetimes
I've split this PR up into a commit for generate rote changes to diagnostics code to pass around a `DefId` manually everywhere, and another commit for the opaque type related changes which likely require more careful review as they might change the semantics of lints/errors.
Instead of manually passing the `DefId` around everywhere I previously tried to bundle it in with `TypeErrCtxt` but ran into issues with some call sites of `infcx.err_ctxt` being unable to provide a `DefId`, particularly places involved with trait solving and normalization. It might be worth investigating adding some new wrapper type to pass this around everywhere but I think this might be acceptable for now.
This pr also has the effect of reducing the size of `EarlyParamRegion` from 16 bytes -> 8 bytes. I wouldn't expect this to have any direct performance improvement however, other variants of `RegionKind` over `8` bytes are all because they contain a `BoundRegionKind` which is, as far as I know, mostly there for diagnostics. If we're ever able to remove this it would shrink the `RegionKind` type from `24` bytes to `12` (and with clever bit packing we might be able to get it to `8` bytes). I am curious what the performance impact would be of removing interning of `Region`'s if we ever manage to shrink `RegionKind` that much.
Sidenote: by removing the `DefId` the `Debug` output for `Region` has gotten significantly nicer. As an example see this opaque type debug print before vs after this PR:
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), [DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0, T, DefId(0:9 ~ impl_trait_captures[aeb9]::foo::'a)_'a/#0])`
`Opaque(DefId(0:13 ~ impl_trait_captures[aeb9]::foo::{opaque#0}), ['a/#0, T, 'a/#0])`
r? `@compiler-errors` (I would like someone who understands the opaque type setup to atleast review the type system commit, but the rest is likely reviewable by anyone)
Rollup of 8 pull requests
Successful merges:
- #124048 (Support C23's Variadics Without a Named Parameter)
- #125046 (Only allow immutable statics with #[linkage])
- #125466 (Don't continue probing for method if in suggestion and autoderef hits ambiguity)
- #125469 (Don't skip out of inner const when looking for body for suggestion)
- #125544 (Also mention my-self for other check-cfg docs changes)
- #125559 (Simplify the `unchecked_sh[lr]` ub-checks a bit)
- #125566 (Notify T-rustdoc for beta-accepted and stable-accepted too)
- #125582 (Avoid a `FieldIdx::from_usize` in InstSimplify)
r? `@ghost`
`@rustbot` modify labels: rollup
Support C23's Variadics Without a Named Parameter
Fixes#123773
This PR removes the static check that disallowed extern functions
with ellipsis (varargs) as the only parameter since this is now
valid in C23.
This will not break any existing code as mentioned in the proposal
document: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2975.pdf.
Also, adds a doc comment for `check_decl_cvariadic_pos()` and
fixes the name of the function (`varadic` -> `variadic`).
Less syscalls for the `copy_file_range` probe
If it's obvious from the actual syscall results themselves that the syscall is supported or unsupported, don't do an extra syscall with an invalid file descriptor.
CC #122052
Avoid clone when constructing runnable label.
I stumbled across this when reading this code. This seems like an unnecessary allocation (though likely small?)
Use correct format for setting environment variables when debugging with cpptools
The RA VSCode extension uses an incorrect format for the environment variables in the `launch.json` when debugging with the C/C++ Extension. This extension uses a different format than CodeLLDB or NativeDebug, which means that the environment variables are not actually set for the debuggee.
What it currently looks like:
```json
"env": {
"NAME": "VALUE"
}
```
What the C/C++ extension expects:
```json
"environment": [
{ "name": "NAME", "value": "VALUE" }
]
```
For reference: https://code.visualstudio.com/docs/cpp/launch-json-reference#_environment
Turn remaining non-structural-const-in-pattern lints into hard errors
This completes the implementation of https://github.com/rust-lang/rust/issues/120362 by turning our remaining future-compat lints into hard errors: indirect_structural_match and pointer_structural_match.
They have been future-compat lints for a while (indirect_structural_match for many years, pointer_structural_match since Rust 1.75 (released Dec 28, 2023)), and have shown up in dependency breakage reports since Rust 1.78 (just released on May 2, 2024). I don't expect a lot of code will still depend on them, but we will of course do a crater run.
A lot of cleanup is now possible in const_to_pat, but that is deferred to a later PR.
Fixes https://github.com/rust-lang/rust/issues/70861
Panic if `PathBuf::set_extension` would add a path separator
This is likely never intended and potentially a security vulnerability if it happens.
I'd guess that it's mostly literal strings that are passed to this function in practice, so I'm guessing this doesn't break anyone.
CC #125060
Warn (or error) when `Self` ctor from outer item is referenced in inner nested item
This implements a warning `SELF_CONSTRUCTOR_FROM_OUTER_ITEM` when a self constructor from an outer impl is referenced in an inner nested item. This is a proper fix mentioned https://github.com/rust-lang/rust/pull/117246#discussion_r1374648388.
This warning is additionally bumped to a hard error when the self type references generic parameters, since it's almost always going to ICE, and is basically *never* correct to do.
This also reverts part of https://github.com/rust-lang/rust/pull/117246, since I believe this is the proper fix and we shouldn't need the helper functions (`opt_param_at`/`opt_type_param`) any longer, since they shouldn't really ever be used in cases where we don't have this problem.
Fix inconsistent cwd of `run` and `debug` command in client
Fix#17012. Also related to #13022 and #15993.
When the `kind` of runnable is `bin`, Cargo would use the workspace root as the cwd for the `run` command; otherwise, Cargo defaults to the package root as the cwd for `run`.
Initially, r-a assumed the workspace root as the cwd for all runnables in `debug` command, which led to issue #13022. In this case, during unit testing, the `run` command would use the package root while `debug` would use the workspace root, causing inconsistency.
PR #15993 addressed this problem by using the package root as the cwd for `debug` command. However, it also resulted in an inconsistency: when executing the `run` command within the main fn of a package (whose target is `bin`), Cargo would use the workspace root, whereas `debug` would use the package root, leading to issue #17012.
The preferable approach is to determine the cwd based on the runnable's type. To resolve this, this PR introduces a new `cwd` field within `CargoRunnable`, allowing r-a to decide the appropriate cwd depending on the specific kind of the runnable.
Allow sysroots to only consist of the source root dir
Fixes https://github.com/rust-lang/rust-analyzer/issues/17159
This PR encodes the `None` case of an optional sysroot into `Sysroot` itself. This simplifies a lot of things and allows us to have sysroots that consist of nothing, only standard library sources, everything but the standard library sources or everything. This makes things a lot more flexible. Additionally, this removes the workspace status bar info again, as it turns out that that can be too much information for the status bar to handle (this is better rendered somewhere else, like in the status view).
Fix: infer type of async block with tail return expr
Fixes#17106
The `infer_async_block` method calls the `infer_block` method internally, which returns the never type without coercion when `tail_expr` is `None` and `ctx.diverges` is `Diverges::Always`.This is the reason for the bug in this issue.
cfce2bb46d/crates/hir-ty/src/infer/expr.rs (L1411-L1413)
This PR solves the bug by adding a process to coerce after calling `infer_block` method.
This code passes all the tests, including tests I added for this isuue, however, I am not sure if this solution is right. I think that this solution is an ad hoc solution. So, I would appreciate to have your review.
I apologize if I'm off the mark, but `infer_async_block` method should be rewritten to share code with the process of infering type of `expr::Closure` instead of the `infer_block` method. That way it will be closer to the infer process of rustc.
handle {self} when removing unused imports
Fixes#17139
On master
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner::{self, X}$0;
fn f() {
let y = inner::Y();
}
}
```
becomes
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner:self;
fn f() {
let y = inner::Y();
}
}
```
with this fix it instead becomes
```
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner;
fn f() {
let y = inner::Y();
}
}
```
fix: ensure implied bounds from associated types are considered in autocomplete
closes: #16989
rust-analyzer needs to consider implied bounds from associated types in order to get all methods suggestions people expect. A pretty easy way to do that is to keep the `candidate_trait_id`'s receiver if it matches `TyFingerprint::Unnameable`. When benchmarking this change, I didn't notice a meaningful difference in autocomplete latency.
(`TyFingerprint::Unnameable` corresponds to `TyKind::AssociatedType`, `TyKind::OpaqueType`, `TyKind::FnDef`, `TyKind::Closure`, `TyKind::Coroutine`, and `TyKind::CoroutineWitness`.)
internal: refactor `prefer_no_std`/`prefer_prelude` bools into a struct
I noticed that there's a large number of functions/arguments during an unrelated change that take two booleans and realized they're _probably_ better off being in a single struct—less error-prone, etc.
Feel free to suggest a better name than `ImportPathConfig`/close this entirely! I can also make these args enums; just hopefully making this a little more misuse-resistant.
offset: allow zero-byte offset on arbitrary pointers
As per prior `@rust-lang/opsem` [discussion](https://github.com/rust-lang/opsem-team/issues/10) and [FCP](https://github.com/rust-lang/unsafe-code-guidelines/issues/472#issuecomment-1793409130):
- Zero-sized reads and writes are allowed on all sufficiently aligned pointers, including the null pointer
- Inbounds-offset-by-zero is allowed on all pointers, including the null pointer
- `offset_from` on two pointers derived from the same allocation is always allowed when they have the same address
This removes surprising UB (in particular, even C++ allows "nullptr + 0", which we currently disallow), and it brings us one step closer to an important theoretical property for our semantics ("provenance monotonicity": if operations are valid on bytes without provenance, then adding provenance can't make them invalid).
The minimum LLVM we require (v17) includes https://reviews.llvm.org/D154051, so we can finally implement this.
The `offset_from` change is needed to maintain the equivalence with `offset`: if `let ptr2 = ptr1.offset(N)` is well-defined, then `ptr2.offset_from(ptr1)` should be well-defined and return N. Now consider the case where N is 0 and `ptr1` dangles: we want to still allow offset_from here.
I think we should change offset_from further, but that's a separate discussion.
Fixes https://github.com/rust-lang/rust/issues/65108
[Tracking issue](https://github.com/rust-lang/rust/issues/117945) | [T-lang summary](https://github.com/rust-lang/rust/pull/117329#issuecomment-1951981106)
Cc `@nikic`
