If `&T` implements these traits, `Arc<T>` has no reason not to do so
either. This is useful for operating system handles like `File` or
`TcpStream` which don't need a mutable reference to implement these
traits.
CC #53835.
CC #94744.
Avoid guessing unknown trait implementation in suggestions
When a trait is used without specifying the implementation (e.g. calling a non-member associated function without fully-qualified syntax) and there are multiple implementations available, use a placeholder comment for the implementation type in the suggestion instead of picking a random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
Fixes#112897
style-guide: Add language disclaiming any effects on non-default Rust styles
Make it clear that the style guide saying "must" doesn't forbid
developers from doing differently (as though any power on this Earth
could do that) and doesn't forbid tools from allowing any particular
configuration options.
Otherwise, people might wonder (for instance) if there's a semantic difference
between "must" and "should" in the style guide, and whether tools are "allowed"
to offer configurability of something that says "must".
style-guide: Organizational and editing tweaks (no semantic changes)
I'd recommend reviewing this PR commit-by-commit; each commit is self-contained
and should be easy to review at a glance.
- style-guide: Move text about block vs visual indent to indentation section
- style-guide: Move and expand text about trailing commas
- style-guide: s/right-ward/rightward/
- style-guide: Consistently refer to rustfmt as `rustfmt`
- style-guide: Remove inaccurate statement about rustfmt
- style-guide: Define (and capitalize) "ASCIIbetically"
- style-guide: Update cargo.md for authors being optional and not recommended
- style-guide: Avoid normative recommendations for formatting tool configurability
- style-guide: Clarify advice on names matching keywords
- style-guide: Reword an awkwardly phrased recommendation (and fix a typo)
- style-guide: Rephrase a confusingly ordered, ambiguous sentence (and fix a typo)
- style-guide: Avoid hyphenating "semicolon"
- style-guide: Make link text in SUMMARY.md match the headings in the linked pages
- style-guide: Define what an item is
- style-guide: Avoid referring to the style team in the past tense
slice::from_raw_parts: mention no-wrap-around condition
Cc https://github.com/rust-lang/rust/issues/83996. This probably needs to be mentioned in more places, so I am not closing that issue, but this here should help at least.
Don't structurally resolve during method ambiguity in probe
See comment in UI test for reason for the failure. This is all on the error path anyways, not really sure what the assertion is there to achieve anyways...
Fixes#111739
Remove markdown injection again
I really tried to make this work, but this stuff is so underdocumented and basically none of the regex options worked for me (not `match`, nor using `begin` and `end` pairs), VSCode basically doesn't help you out at all as it doesn't ever seem to report errors even when debugging an extension, so at this point I'm inclined to just remove this again, as it is only causing issues.
Closes https://github.com/rust-lang/rust-analyzer/issues/15114
Closes https://github.com/rust-lang/rust-analyzer/issues/15111
When a trait is used without specifying the implementation (e.g. calling
a non-member associated function without fully-qualified syntax) and
there are multiple implementations available, use a placeholder comment
for the implementation type in the suggestion instead of picking a
random implementation.
Example:
```
fn main() {
let _ = Default::default();
}
```
Previous output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = <FileTimes as Default>::default();
| +++++++++++++ +
```
New output:
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> test.rs:2:13
|
2 | let _ = Default::default();
| ^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation (273 found)
|
2 | let _ = </* self type */ as Default>::default();
| +++++++++++++++++++ +
```
