From d517207f5f051b88b549133d7137022532b5f908 Mon Sep 17 00:00:00 2001
From: GHA CI <gha@ci.invalid>
Date: Fri, 13 Sep 2024 17:00:37 +0000
Subject: [PATCH] Automatic deploy to GitHub Pages:
 25367459176bf0fd385594611d5a7c76fbcfa883

---
 master/lints.json | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/master/lints.json b/master/lints.json
index d4298d87f..380435ed0 100644
--- a/master/lints.json
+++ b/master/lints.json
@@ -586,7 +586,7 @@
   },
   {
     "id": "cmp_null",
-    "id_location": "clippy_lints/src/ptr.rs#L91",
+    "id_location": "clippy_lints/src/ptr.rs#L89",
     "group": "style",
     "level": "warn",
     "docs": "### What it does\nThis lint checks for equality comparisons with `ptr::null`\n\n### Why is this bad?\nIt's easier and more readable to use the inherent\n`.is_null()`\nmethod instead\n\n### Example\n```rust\nuse std::ptr;\n\nif x == ptr::null {\n    // ..\n}\n```\n\nUse instead:\n```rust\nif x.is_null() {\n    // ..\n}\n```\n",
@@ -2053,7 +2053,7 @@
   },
   {
     "id": "invalid_null_ptr_usage",
-    "id_location": "clippy_lints/src/ptr.rs#L147",
+    "id_location": "clippy_lints/src/ptr.rs#L145",
     "group": "correctness",
     "level": "deny",
     "docs": "### What it does\nThis lint checks for invalid usages of `ptr::null`.\n\n### Why is this bad?\nThis causes undefined behavior.\n\n### Example\n```rust\n// Undefined behavior\nunsafe { std::slice::from_raw_parts(ptr::null(), 0); }\n```\n\nUse instead:\n```rust\nunsafe { std::slice::from_raw_parts(NonNull::dangling().as_ptr(), 0); }\n```\n",
@@ -3493,7 +3493,7 @@
   },
   {
     "id": "mut_from_ref",
-    "id_location": "clippy_lints/src/ptr.rs#L124",
+    "id_location": "clippy_lints/src/ptr.rs#L122",
     "group": "correctness",
     "level": "deny",
     "docs": "### What it does\nThis lint checks for functions that take immutable references and return\nmutable ones. This will not trigger if no unsafe code exists as there\nare multiple safe functions which will do this transformation\n\nTo be on the conservative side, if there's at least one mutable\nreference with the output lifetime, this lint will not trigger.\n\n### Why is this bad?\nCreating a mutable reference which can be repeatably derived from an\nimmutable reference is unsound as it allows creating multiple live\nmutable references to the same object.\n\nThis [error](https://github.com/rust-lang/rust/issues/39465) actually\nlead to an interim Rust release 1.15.1.\n\n### Known problems\nThis pattern is used by memory allocators to allow allocating multiple\nobjects while returning mutable references to each one. So long as\ndifferent mutable references are returned each time such a function may\nbe safe.\n\n### Example\n```rust\nfn foo(&Foo) -> &mut Bar { .. }\n```\n",
@@ -4393,7 +4393,7 @@
   },
   {
     "id": "ptr_arg",
-    "id_location": "clippy_lints/src/ptr.rs#L61",
+    "id_location": "clippy_lints/src/ptr.rs#L59",
     "group": "style",
     "level": "warn",
     "docs": "### What it does\nThis lint checks for function arguments of type `&String`, `&Vec`,\n`&PathBuf`, and `Cow<_>`. It will also suggest you replace `.clone()` calls\nwith the appropriate `.to_owned()`/`to_string()` calls.\n\n### Why is this bad?\nRequiring the argument to be of the specific type\nmakes the function less useful for no benefit; slices in the form of `&[T]`\nor `&str` usually suffice and can be obtained from other types, too.\n\n### Known problems\nThere may be `fn(&Vec)`-typed references pointing to your function.\nIf you have them, you will get a compiler error after applying this lint's\nsuggestions. You then have the choice to undo your changes or change the\ntype of the reference.\n\nNote that if the function is part of your public interface, there may be\nother crates referencing it, of which you may not be aware. Carefully\ndeprecate the function before applying the lint suggestions in this case.\n\n### Example\n```rust\nfn foo(&Vec<u32>) { .. }\n```\n\nUse instead:\n```rust\nfn foo(&[u32]) { .. }\n```\n",