Auto merge of #155655 - JonathanBrouwer:rollup-KFUw3UR, r=JonathanBrouwer

Rollup of 10 pull requests

Successful merges:

 - rust-lang/rust#154794 (Add on_unmatch_args)
 - rust-lang/rust#155133 (Document precision considerations of `Duration`-float methods)
 - rust-lang/rust#154283 (Remove `nodes_in_current_session` field and related assertions)
 - rust-lang/rust#155374 (rustdoc: fix a few spots where emit isn't respected)
 - rust-lang/rust#155587 (Immediately feed visibility on DefId creation)
 - rust-lang/rust#155622 (c-variadic: `va_arg` fixes )
 - rust-lang/rust#155629 (rustc_public: Add `constness` & `asyncness` in `FnDef`)
 - rust-lang/rust#155632 (Some metadata cleanups)
 - rust-lang/rust#155639 (BinOpAssign always returns unit)
 - rust-lang/rust#155647 (rustc-dev-guide subtree update)

Author: bors

rust-version

@@ -1 +1 @@
-30d0309fa821f7a0984a9629e0d227ca3c0d2eda
+cf1817bc6ecd2d14ca492247c804bad31948dd56

src/about-this-guide.md

@@ -98,7 +98,7 @@ You might also find the following sites useful:
 [gsearchdocs]: https://www.google.com/search?q=site:doc.rust-lang.org+your+query+here
 [stddocs]: https://doc.rust-lang.org/std
 [rif]: http://internals.rust-lang.org
-[rr]: https://doc.rust-lang.org/book/
+[rr]: https://doc.rust-lang.org/reference/
 [rustforge]: https://forge.rust-lang.org/
 [tlgba]: https://tomlee.co/2014/04/a-more-detailed-tour-of-the-rust-compiler/
 [ro]: https://www.rustaceans.org/

src/building/suggested.md

@@ -144,77 +144,82 @@ If running `./x check` on save is inconvenient, in VS Code you can use a [Build
 
 ### Neovim
 
-For Neovim users, there are a few options.
-The easiest way is by using [neoconf.nvim](https://github.com/folke/neoconf.nvim/),
-which allows for project-local configuration files with the native LSP.
-The steps for how to use it are below.
-Note that they require rust-analyzer to already be configured with Neovim.
-Steps for this can be [found here](https://rust-analyzer.github.io/manual.html#nvim-lsp).
+For Neovim users, there are a few options:
+
+1. The easiest way is using [neoconf.nvim][neoconf.nvim] but it uses the
+   deprecated `require('lspconfig')` API which displays a warning on neovim 0.11+.
+2. Using `coc.nvim` is another option but it requires node.js to be installed.
+3. Using a custom script to load rust-analyzer settings.
+
+#### neoconf.nvim
+
+[neoconf.nvim][neoconf.nvim] allows for project-local configuration
+files with the native LSP. The steps for how to use it are below. Note that they require
+rust-analyzer to already be configured with Neovim. Steps for this can be
+[found here][r-a nvim lsp].
 
 1. First install the plugin.
    This can be done by following the steps in the README.
 2. Run `./x setup editor`, and select `vscode` to create a `.vscode/settings.json` file.
    `neoconf` is able to read and update
    rust-analyzer settings automatically when the project is opened when this file is detected.
 
+#### coc.nvim
+
 If you're using `coc.nvim`, you can run `./x setup editor` and select `vim` to
 create a `.vim/coc-settings.json`.
 The settings can be edited with `:CocLocalConfig`.
 The recommended settings live at [`src/etc/rust_analyzer_settings.json`].
 
-Another way is without a plugin, and creating your own logic in your configuration.
-The following code will work for any checkout of rust-lang/rust (newer than February 2025):
+#### Custom LSP settings
+
+If you're running neovim 0.11+, you can configure rust-analyzer with just
+[nvim-lspconfig](https://github.com/neovim/nvim-lspconfig) and a custom script.
+
+1. Make sure [rust-analyzer LSP][r-a nvim lsp] is set up
+2. Create `$HOME/.config/nvim/after/plugged/rust_analyzer.lua` with the following content:
 
 ```lua
-local function expand_config_variables(option)
-    local var_placeholders = {
-        ['${workspaceFolder}'] = function(_)
-            return vim.lsp.buf.list_workspace_folders()[1]
-        end,
-    }
-
-    if type(option) == "table" then
-        local mt = getmetatable(option)
-        local result = {}
-        for k, v in pairs(option) do
-            result[expand_config_variables(k)] = expand_config_variables(v)
+-- Capture the default functions from nvim-lspconfig/lsp/rust_analyzer.lua before overriding it.
+-- This file is in after/plugin to guarantee nvim-lspconfig has been initialised already.
+local default_root_dir = vim.lsp.config["rust_analyzer"].root_dir
+local default_before_init = vim.lsp.config["rust_analyzer"].before_init
+
+vim.lsp.config("rust_analyzer", {
+    cmd = { "rust-analyzer" },
+    filetypes = { "rust" },
+    -- To support rust-lang/rust, we need to detect when we're in the rust repo and use the git root
+    -- instead of cargo project root.
+    root_dir = function(bufnr, on_dir)
+        local git_root = vim.fs.root(bufnr, { ".git" })
+        if git_root then
+            if vim.uv.fs_stat(vim.fs.joinpath(git_root, "src/etc/rust_analyzer_zed.json")) then
+                on_dir(git_root)
+                return
+            end
         end
-        return setmetatable(result, mt)
-    end
-    if type(option) ~= "string" then
-        return option
-    end
-    local ret = option
-    for key, fn in pairs(var_placeholders) do
-        ret = ret:gsub(key, fn)
-    end
-    return ret
-end
-lspconfig.rust_analyzer.setup {
-    root_dir = function()
-        local default = lspconfig.rust_analyzer.config_def.default_config.root_dir()
-        -- the default root detection uses the cargo workspace root.
-        -- but for rust-lang/rust, the standard library is in its own workspace.
-        -- use the git root instead.
-        local compiler_config = vim.fs.joinpath(default, "../src/bootstrap/defaults/config.compiler.toml")
-        if vim.fs.basename(default) == "library" and vim.uv.fs_stat(compiler_config) then
-            return vim.fs.dirname(default)
-        end
-        return default
+        -- For anything that doesn't match rust-lang/rust, fallback to default root_dir
+        default_root_dir(bufnr, on_dir)
     end,
-    on_init = function(client)
-        local path = client.workspace_folders[1].name
-        local config = vim.fs.joinpath(path, "src/etc/rust_analyzer_zed.json")
-        if vim.uv.fs_stat(config) then
-            -- load rust-lang/rust settings
-            local file = io.open(config)
-            local json = vim.json.decode(file:read("*a"))
-            client.config.settings["rust-analyzer"] = expand_config_variables(json.lsp["rust-analyzer"].initialization_options)
-            client.notify("workspace/didChangeConfiguration", { settings = client.config.settings })
+    before_init = function(init_params, config)
+        -- When inside rust-lang/rust, we need to use the special rust-analyzer settings.
+        local settings = vim.fs.joinpath(config.root_dir, "src/etc/rust_analyzer_zed.json")
+        if vim.uv.fs_stat(settings) then
+            local file = io.open(settings)
+            -- nvim 0.12+ supports comments otherwise you'll need content:gsub("//[^\n]*", "").
+            local json = vim.json.decode(file:read("*a"), { skip_comments = true })
+            file:close()
+            config.settings["rust-analyzer"] = vim.tbl_deep_extend(
+                "force", -- Overwrite with the special settings when there is a conflict.
+                config.settings["rust-analyzer"] or {},
+                json.lsp["rust-analyzer"].initialization_options
+            )
         end
-        return true
-    end
-}
+        default_before_init(init_params, config)
+    end,
+})
+
+vim.lsp.enable("rust_analyzer")
 ```
 
 If you would like to use the build task that is described above, you may either
@@ -223,6 +228,9 @@ make your own command in your config, or you can install a plugin such as
 files](https://github.com/stevearc/overseer.nvim/blob/master/doc/guides.md#vs-code-tasks),
 and follow the same instructions as above.
 
+[neoconf.nvim]: https://github.com/folke/neoconf.nvim/
+[r-a nvim lsp]: https://rust-analyzer.github.io/book/other_editors.html#nvim-lsp
+
 ### Emacs
 
 Emacs provides support for rust-analyzer with project-local configuration

src/coherence.md

@@ -8,13 +8,14 @@ Coherence checking is what detects both of trait impls and inherent impls overla
 Overlapping trait impls always produce an error,
 while overlapping inherent impls result in an error only if they have methods with the same name.
 
-Checking for overlaps is split in two parts. First there's the [overlap check(s)](#overlap-checks), 
+Checking for overlaps is split in two parts.
+First there's the [overlap check(s)](#overlap-checks),
 which finds overlaps between traits and inherent implementations that the compiler currently knows about.
 
 However, Coherence also results in an error if any other impls **could** exist,
-even if they are currently unknown. 
+even if they are currently unknown.
 This affects impls which may get added to upstream crates in a backwards compatible way,
-and impls from downstream crates. 
+and impls from downstream crates.
 This is called the Orphan check.
 
 ## Overlap checks
@@ -25,7 +26,7 @@ Overlap checks always consider pairs of implementations, comparing them to each
 
 Overlap checking for inherent impl blocks is done through `fn check_item` (in coherence/inherent_impls_overlap.rs),
 where you can very clearly see that (at least for small `n`), the check really performs `n^2`
-comparisons between impls. 
+comparisons between impls.
 
 In the case of traits, this check is currently done as part of building the [specialization graph](traits/specialization.md),
 to handle specializing impls overlapping with their parent, but this may change in the future.
@@ -37,7 +38,7 @@ Overlapping is sometimes partially allowed:
 1. for marker traits
 2. under [specialization](traits/specialization.md)
 
-but normally isn't. 
+It normally isn't.
 
 The overlap check has various modes (see [`OverlapMode`]).
 Importantly, there's the explicit negative impl check, and the implicit negative impl check.
@@ -47,9 +48,9 @@ Both try to prove that an overlap is definitely impossible.
 
 ### The explicit negative impl check
 
-This check is done in [`impl_intersection_has_negative_obligation`]. 
+This check is done in [`impl_intersection_has_negative_obligation`].
 
-This check tries to find a negative trait implementation. 
+This check tries to find a negative trait implementation.
 For example:
 
 ```rust
@@ -64,7 +65,7 @@ In this example, we'd get:
 `MyCustomErrorType: From<&str>` and `MyCustomErrorType: From<?E>`, giving `?E = &str`.
 
 And thus, these two implementations would overlap.
-However, libstd provides `&str: !Error`, and therefore guarantees that there 
+However, libstd provides `&str: !Error`, and therefore guarantees that there
 will never be a positive implementation of `&str: Error`, and thus there is no overlap.
 
 Note that for this kind of negative impl check, we must have explicit negative implementations provided.
@@ -77,18 +78,17 @@ This is not currently stable.
 This check is done in [`impl_intersection_has_impossible_obligation`],
 and does not rely on negative trait implementations and is stable.
 
-Let's say there's a 
+Let's say there's a
 ```rust
 impl From<MyLocalType> for Box<dyn Error> {}  // in your own crate
 impl<E> From<E> for Box<dyn Error> where E: Error {} // in std
 ```
 
-This would give: `Box<dyn Error>: From<MyLocalType>`, and `Box<dyn Error>: From<?E>`,  
+This would give: `Box<dyn Error>: From<MyLocalType>`, and `Box<dyn Error>: From<?E>`,
 giving `?E = MyLocalType`.
 
 In your crate there's no `MyLocalType: Error`, downstream crates cannot implement `Error` (a remote trait) for `MyLocalType` (a remote type).
 Therefore, these two impls do not overlap.
 Importantly, this works even if there isn't a `impl !Error for MyLocalType`.
 
 [`impl_intersection_has_impossible_obligation`]: https://doc.rust-lang.org/beta/nightly-rustc/rustc_trait_selection/traits/coherence/fn.impl_intersection_has_impossible_obligation.html
-

src/effects.md

@@ -2,16 +2,16 @@
 
 ## The `HostEffect` predicate
 
-[`HostEffectPredicate`]s are a kind of predicate from `~const Tr` or `const Tr` bounds.
+[`HostEffectPredicate`]s are a kind of predicate from `[const] Tr` or `const Tr` bounds.
 It has a trait reference, and a `constness` which could be `Maybe` or
 `Const` depending on the bound.
-Because `~const Tr`, or rather `Maybe` bounds
+Because `[const] Tr`, or rather `Maybe` bounds
 apply differently based on whichever contexts they are in, they have different
 behavior than normal bounds.
 Where normal trait bounds on a function such as
 `T: Tr` are collected within the [`predicates_of`] query to be proven when a
 function is called and to be assumed within the function, bounds such as
-`T: ~const Tr` will behave as a normal trait bound and add `T: Tr` to the result
+`T: [const] Tr` will behave as a normal trait bound and add `T: Tr` to the result
 from `predicates_of`, but also adds a `HostEffectPredicate` to the [`const_conditions`] query.
 
 On the other hand, `T: const Tr` bounds do not change meaning across contexts,
@@ -37,7 +37,7 @@ In a similar vein,
 an item *in const contexts*. If we adjust the example above to use `const` trait bounds:
 
 ```rust
-const fn foo<T>() where T: ~const Default {}
+const fn foo<T>() where T: [const] Default {}
 ```
 
 Then `foo` would get a `HostEffect(T: Default, maybe)` in the `const_conditions`
@@ -55,7 +55,7 @@ Note that we don't check
 if the function is only referred to but not called, as the following code needs to compile:
 
 ```rust
-const fn hi<T: ~const Default>() -> T {
+const fn hi<T: [const] Default>() -> T {
     T::default()
 }
 const X: fn() -> u32 = hi::<u32>;
@@ -69,7 +69,7 @@ Here's an example:
 
 ```rust
 const trait Bar {}
-const trait Foo: ~const Bar {}
+const trait Foo: [const] Bar {}
 // `const_conditions` contains `HostEffect(Self: Bar, maybe)`
 
 impl const Bar for () {}
@@ -86,13 +86,13 @@ We do the same for `const_conditions`:
 
 ```rust
 const trait Foo {
-    fn hi<T: ~const Default>();
+    fn hi<T: [const] Default>();
 }
 
-impl<T: ~const Clone> Foo for Vec<T> {
-    fn hi<T: ~const PartialEq>();
-    // ^ we can't prove `T: ~const PartialEq` given `T: ~const Clone` and
-    // `T: ~const Default`, therefore we know that the method on the impl
+impl<T: [const] Clone> Foo for Vec<T> {
+    fn hi<T: [const] PartialEq>();
+    // ^ we can't prove `T: [const] PartialEq` given `T: [const] Clone` and
+    // `T: [const] Default`, therefore we know that the method on the impl
     // is stricter than the method on the trait.
 }
 ```
@@ -117,11 +117,11 @@ Bounds on associated types, opaque types, and supertraits such as the following
 have their bounds represented differently:
 
 ```rust
-trait Foo: ~const PartialEq {
-    type X: ~const PartialEq;
+trait Foo: [const] PartialEq {
+    type X: [const] PartialEq;
 }
 
-fn foo() -> impl ~const PartialEq {
+fn foo() -> impl [const] PartialEq {
     // ^ unimplemented syntax
 }
 ```

src/git.md

@@ -385,8 +385,8 @@ the history becomes easier to work with.
 
 The easiest way to squash your commits in a PR on the `rust-lang/rust` repository is to use the `@bors squash` command in a comment on the PR.
 By default, [bors] combines all commit messages of the PR into the squashed commit message.
-To customize the commit message, use `@bors squash msg=<commit message>`.
-
+To customize the commit message, use `@bors squash msg="<commit message>"`.
+For example, `@bors squash msg="Improve diagnostics for missing lifetime parameter"`.
 
 If you want to squash commits using local git operations, read on below.