rustdoc: get rid of unused path printing code
The code for printing a raw path is only used in utils.rs, which only prints the alternative (non-HTML) format. Path has
a function that does the same thing without HTML support, so use that instead.
fix incomplete diagnostic notes when closure returns conflicting for genric type
fixes#84128
Correctly report the span on for conflicting return type in closures
Builtin derive macros: fix error with const generics default
This fixes a bug where builtin derive macros (like Clone, Debug) would basically copy-paste the default from a const generic, causing a compile error with very confusing message - it would say defaults are not allowed in impl blocks, while pointing at struct/enum/union definition.
Detect when suggested paths enter extern crates more rigorously
When reporting resolution errors, the compiler tries to avoid suggesting importing inaccessible paths from other crates. However, the search for suggestions only recognized when it was entering a crate root directly, and so failed to recognize a path like `crate::module::private_item`, where `module` was imported from another crate with `use other_crate::module`, as entering another crate.
Fixes#80079Fixes#84081
rustdoc: clean up and test macro visibility print
This fixes the overly-complex invariant mentioned in <https://github.com/rust-lang/rust/pull/83237#issuecomment-815346570>, where the macro source can't have any links in it only because the cache hasn't been populated yet.
Allow allman style braces in `suspicious_else_formatting`
fixes: #3864
Indentation checks could be added as well, but the lint already doesn't check for it.
changelog: Allow allman style braces in `suspicious_else_formatting`
Fixing FPs for the `branches_sharing_code` lint
Fixes#7053Fixes#7054
And an additional CSS adjustment to support dark mode for every inline code. It currently only works in paragraphs, which was an oversight on my part 😅. [Current Example](https://rust-lang.github.io/rust-clippy/master/index.html#blacklisted_name)
This also includes ~50 lines of doc comments and is therefor not as big as the changes would indicate. 🐧
---
changelog: none
All of these bugs were introduced in this dev version and are therefor not worth a change log entry.
r? `@phansch`
cc: `@camsteffen` since you have a pretty good overview of the `SpanlessEq` implementation 🙃
The default illumos shell ("sh" in the default PATH) is ksh93, rather
than bash, and does not support constructs like "local" that came from
bash. The bootstrap function for invoking "install.sh" scripts should
use "bash" explicitly there to avoid issues.
Add `cloned_instead_of_copied` lint
Don't go cloning all willy-nilly.
Featuring a new `get_iterator_item_ty` util!
changelog: Add cloned_instead_of_copied lint
Closes#3870
Fix: redundant_pattern_matching drop order
Fixes#5746
A note about the change in drop order is added when the scrutinee (or any temporary in the expression) isn't known to be safe to drop in any order (i.e. doesn't implement the `Drop` trait, or contain such a type). There is a whitelist for some `std` types, but it's incomplete. Currently just `Vec<_>`, `Box<_>`, `Rc<_>` and `Arc<_>`, but only if the contained type is also safe to drop in any order.
Another lint for when the drop order changes could be added as allowed by default, but the drop order requirement is pretty subtle in this case. I think the note added to the lint should be enough to make someone think before applying the change.
changelog: Added a note to `redundant_pattern_matching` when the change in drop order might matter
std: Add a variant of thread locals with const init
This commit adds a variant of the `thread_local!` macro as a new
`thread_local_const_init!` macro which requires that the initialization
expression is constant (e.g. could be stuck into a `const` if so
desired). This form of thread local allows for a more efficient
implementation of `LocalKey::with` both if the value has a destructor
and if it doesn't. If the value doesn't have a destructor then `with`
should desugar to exactly as-if you use `#[thread_local]` given
sufficient inlining.
The purpose of this new form of thread locals is to precisely be
equivalent to `#[thread_local]` on platforms where possible for values
which fit the bill (those without destructors). This should help close
the gap in performance between `thread_local!`, which is safe, relative
to `#[thread_local]`, which is not easy to use in a portable fashion.
This commit adds a variant of the `thread_local!` macro as a new
`thread_local_const_init!` macro which requires that the initialization
expression is constant (e.g. could be stuck into a `const` if so
desired). This form of thread local allows for a more efficient
implementation of `LocalKey::with` both if the value has a destructor
and if it doesn't. If the value doesn't have a destructor then `with`
should desugar to exactly as-if you use `#[thread_local]` given
sufficient inlining.
The purpose of this new form of thread locals is to precisely be
equivalent to `#[thread_local]` on platforms where possible for values
which fit the bill (those without destructors). This should help close
the gap in performance between `thread_local!`, which is safe, relative
to `#[thread_local]`, which is not easy to use in a portable fashion.
The code for printing a raw path is only used in utils.rs,
which only prints the alternative (non-HTML) format. Path has
a function that does the same thing without HTML support,
so use that instead.
Improve `map_entry` suggestion
fixes: #5176fixes: #4674fixes: #4664fixes: #1450
Still need to handle the value returned by `insert` correctly.
changelog: Improve `map_entry` suggestion. Will now suggest `or_insert`, `insert_with` or `match _.entry(_)` as appopriate.
changelog: Fix `map_entry` false positives where the entry api can't be used. e.g. when the map is used for multiple things.
Compiler error messages: reduce assertiveness of message E0384
This message is emitted as guidance by the compiler when a developer attempts to reassign a value to an immutable variable. Following the message will always currently work, but it may not always be the best course of action; following the 'consider ...' messaging pattern provides a hint to the developer that it could be wise to explore other alternatives.
Resolves#84144
rustdoc: Hide item contents, not items
This tweaks rustdoc to hide item contents instead of items, and only when there are too many of them.
This means that users will _always_ see the type parameters, and will _often_ see fields/etc as long as they are small. Traits have some heuristics for hiding only the methods or only the methods and the consts, since the associated types are super important.
I'm happy to play around with the heuristics here; we could potentially make it so that structs/enums/etc are always hidden but traits will try really hard to show type aliases.
This needs a test, but you can see it rendered at https://manishearth.net/sand/doc_render/bar/
<details>
<summary> Code example </summary>
```rust
pub struct PubStruct {
pub a: usize,
pub b: usize,
}
pub struct BigPubStruct {
pub a: usize,
pub b: usize,
pub c: usize,
pub d: usize,
pub e: usize,
pub f: usize,
}
pub union BigUnion {
pub a: usize,
pub b: usize,
pub c: usize,
pub d: usize,
pub e: usize,
pub f: usize,
}
pub union Union {
pub a: usize,
pub b: usize,
pub c: usize,
}
pub struct PrivStruct {
a: usize,
b: usize,
}
pub enum Enum {
A, B, C,
D {
a: u8,
b: u8
}
}
pub enum LargeEnum {
A, B, C, D, E, F, G, H, I, J
}
pub trait Trait {
type A;
#[must_use]
fn foo();
fn bar();
}
pub trait GinormousTrait {
type A;
type B;
type C;
type D;
type E;
type F;
const N: usize = 1;
#[must_use]
fn foo();
fn bar();
}
pub trait HugeTrait {
type A;
const M: usize = 1;
const N: usize = 1;
const O: usize = 1;
const P: usize = 1;
const Q: usize = 1;
#[must_use]
fn foo();
fn bar();
}
pub trait BigTrait {
type A;
#[must_use]
fn foo();
fn bar();
fn baz();
fn quux();
fn frob();
fn greeble();
}
#[macro_export]
macro_rules! foo {
(a) => {a};
}
```
</details>
Fixes https://github.com/rust-lang/rust/issues/82114
