refactor: removing library/alloc/src/vec/mod.rs ignore-tidy-filelength
This PR removes the need for ignore-tidy-filelength for library/alloc/src/vec/mod.rs which is part of the issue #60302
It is probably easiest to review this PR by looking at it commit by commit rather than looking at the overall diff.
Rollup of 7 pull requests
Successful merges:
- #80185 (Fix ICE when pointing at multi bytes character)
- #80260 (slightly more typed interface to panic implementation)
- #80311 (Improvements to NatVis support)
- #80337 (Use `desc` as a doc-comment for queries if there are no doc comments)
- #80381 (Revert "Cleanup markdown span handling")
- #80492 (remove empty wraps, don't return Results from from infallible functions)
- #80509 (where possible, pass slices instead of &Vec or &String (clippy::ptr_arg))
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Revert "Cleanup markdown span handling"
Reverts rust-lang/rust#80244. This caused a diagnostic regression, originally it was:
```
warning: unresolved link to `std::process::Comman`
--> link.rs:3:10
|
3 | //! [a]: std::process::Comman
| ^^^^^^^^^^^^^^^^^^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
but after that PR rustdoc now displays
```
warning: unresolved link to `std::process::Comman`
--> link.rs:1:14
|
1 | //! Links to [a] [link][a]
| ^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
which IMO is much less clear.
cc `@bugadani,` thanks for catching this in https://github.com/rust-lang/rust/pull/77859.
r? `@GuillaumeGomez`
Improvements to NatVis support
NatVis files describe how to display types in some Windows debuggers,
such as Visual Studio, WinDbg, and VS Code.
This commit makes several improvements:
* Adds visualizers for Rc<T>, Weak<T>, and Arc<T>.
* Changes [size] to [len], for consistency with the Rust API.
Visualizers often use [size] to mirror the size() method on C++ STL
collections.
* Several visualizers used the PVOID and ULONG typedefs. These are part
of the Windows API; they are not guaranteed to always be defined in a
pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to
`unsigned long`.
* Cosmetic change: Removed {} braces around the visualized display
for `Option` types. They now display simply as `Some(value)` or
`None`, which reflects what is written in source code.
* The visualizer for `alloc::string::String` makes assumptions about
the layout of `String` (it casts `String*` to another type), rather
than using symbolic expressions. This commit changes the visualizer
so that it simply uses symbolic expressions to access the string
data and string length.
* The visualizers for `str` and `String` now place the character data
array under a synthetic `[chars]` node. When expanding a `String`
node, users rarely want to see an array of characters. This just places
them behind one expansion node / level.
Lint on redundant trailing semicolon after item
We now lint on code like this:
```rust
fn main() {
fn foo() {};
struct Bar {};
}
```
Previously, this caused warnings in Cargo, so it was disabled.
NatVis files describe how to display types in some Windows debuggers,
such as Visual Studio, WinDbg, and VS Code.
This commit makes several improvements:
* Adds visualizers for Rc<T>, Weak<T>, and Arc<T>.
* Changes [size] to [len], for consistency with the Rust API.
Visualizers often use [size] to mirror the size() method on C++ STL
collections.
* Several visualizers used the PVOID and ULONG typedefs. These are part
of the Windows API; they are not guaranteed to always be defined in a
pure Rust DLL/EXE. I converted PVOID to `void*` and `ULONG` to
`unsigned long`.
* Cosmetic change: Removed {} braces around the visualized display
for `Option` types. They now display simply as `Some(value)` or
`None`, which reflects what is written in source code.
* The visualizer for `alloc::string::String` makes assumptions about
the layout of `String` (it casts `String*` to another type), rather
than using symbolic expressions. This commit changes the visualizer
so that it simply uses symbolic expressions to access the string
data and string length.
Add regression test for #80375
This will also make sure that #80375 is handled if #79135 has to be reverted (which won't happen 🤞).
Closes#80375.
r? `@lcnr`
Suggest fn ptr rather than fn item and suggest to use `Fn` trait bounds rather than the unique closure type in E0121
Previously, using `_` as a return type in a function that returned a function/closure would provide a diagnostic that would cause a papercut. For example:
```rust
fn f() -> i32 { 0 }
fn fn_ptr() -> _ { f }
fn closure() -> _ { || 0 }
```
would result in this diagnostic:
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32 {f}`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `[closure@<anon>:3:21: 3:25]`
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen, it was suggested to use the function definition return type `fn() -> i32 { f }` which is not valid syntax as a return type. Additionally, closures cause a papercut as unique closure types (notated in this case as `[closure@<anon>:3:21: 3:25]`) are not valid syntax either.
Instead, this PR implements this version of the diagnostic (this example is for the same code featured above):
```rust
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:2:16
|
2 | fn fn_ptr() -> _ { f }
| ^
| |
| not allowed in type signatures
| help: replace with the correct return type: `fn() -> i32`
error[E0121]: the type placeholder `_` is not allowed within types on item signatures
--> <anon>:3:17
|
3 | fn closure() -> _ { || 0 }
| ^ not allowed in type signatures
|
= help: consider using an `Fn`, `FnMut`, or `FnOnce` trait bound
= note: for more information on `Fn` traits and closure types, see https://doc.rust-lang.org/book/ch13-01-closures.html
error: aborting due to 2 previous errors
For more information about this error, try `rustc --explain E0121`.
```
As can be seen in this diagnostic, the papercut for returning a function item is fixed by suggesting the usage of a function pointer as the return type. As for closures, it's suggested to use an `Fn`, `FnMut`, or `FnOnce` trait bound (with further reading on closures and `Fn` traits in *The Book* for beginners). I did not implement a suggestion to use `impl Fn() -> i32` syntax as that was out-of-scope for my abilities at the moment, therefore someone in the future may want to implement that. Also, it's possible to use either `impl Trait` syntax, generics, or generics with a `where` clause, and some users may not want to use `impl Trait` syntax for their own reasons.
This PR fixes#80179.
Fix intra-doc links for non-path primitives
This does *not* currently work for associated items that are
auto-implemented by the compiler (e.g. `never::eq`), because they aren't
present in the source code. I plan to fix this in a follow-up PR.
Fixes https://github.com/rust-lang/rust/issues/63351 using the approach mentioned in https://github.com/rust-lang/rust/issues/63351#issuecomment-683352130.
r? `@Manishearth`
cc `@petrochenkov` - this makes `rustc_resolve::Res` public, is that ok? I'd just add an identical type alias in rustdoc if not, which seems a waste.
This caused a diagnostic regression, originally it was:
```
warning: unresolved link to `std::process::Comman`
--> link.rs:3:10
|
3 | //! [a]: std::process::Comman
| ^^^^^^^^^^^^^^^^^^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
but after that PR rustdoc now displays
```
warning: unresolved link to `std::process::Comman`
--> link.rs:1:14
|
1 | //! Links to [a] [link][a]
| ^^^ no item named `Comman` in module `process`
|
= note: `#[warn(broken_intra_doc_links)]` on by default
```
which IMO is much less clear.
Prevent caching normalization results with a cycle
When normalizing a projection which results in a cycle, we would cache the result of `project_type` without the nested obligations (because they're not needed for inference). This would result in the nested obligations only being handled once in fulfill, which would avoid the cycle error. `get_paranoid_cache_value_obligation` used to add an obligation that resulted in a cycle in this case previously, but was removed by #73905.
This PR makes the projection cache not cache the value of a projection if it was ever normalized in a cycle (except in a snapshot that's rolled back).
Fixes#79714.
r? `@nikomatsakis`
Exclude unnecessary info from CodegenResults
`foreign_module` and `wasm_import_module` are not needed for linking, and hence can be removed from CodegenResults.
Fixes#77857
Implemented a compiler diagnostic for move async mistake
Fixes#79694
First time contributing, so I hope I'm doing everything right.
(If not, please correct me!)
This code performs a check when a move capture clause is parsed. The check is to detect if the user has reversed the async move keywords and to provide a diagnostic with a suggestion to fix it.
Checked code:
```rust
fn main() {
move async { };
}
```
Previous output:
```txt
PS C:\Repos\move_async_test> cargo build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: expected one of `|` or `||`, found keyword `async`
--> src\main.rs:2:10
|
2 | move async { };
| ^^^^^ expected one of `|` or `||`
error: aborting due to previous error
error: could not compile `move_async_test`
```
New output:
```txt
PS C:\Repos\move_async_test> cargo +dev build
Compiling move_async_test v0.1.0 (C:\Repos\move_async_test)
error: the order of `move` and `async` is incorrect
--> src\main.rs:2:13
|
2 | let _ = move async { };
| ^^^^^^^^^^
|
help: try switching the order
|
2 | let _ = async move { };
| ^^^^^^^^^^
error: aborting due to previous error
error: could not compile `move_async_test`
```
Is there a file/module where these kind of things are tested?
Would love some feedback 😄
Remap instrument-coverage line numbers in doctests
This uses the `SourceMap::doctest_offset_line` method to re-map line
numbers from doctests. Remapping columns is not yet done, and rustdoc
still does not output the correct filename when running doctests in a
workspace.
Part of #79417 although I dont consider that fixed until both filenames
and columns are mapped correctly.
r? `@richkadel`
I might jump on zulip the comming days. Still need to figure out how to properly write tests for this, and deal with other doctest issues in the meantime.
Move tooltips messages out of html
First thing first: nothing in the output has changed. You still have the "i" on the left of code blocks examples when they have `ignore`, `compile_fail`, `should_panic` and `edition`. The behavior also remains the same: when you hover the "i", you have the corresponding message showing up.
So now, why this PR then? I realized recently that we were actually generating those messages into the HTML every time whereas all messages are the same (except for the edition ones, I'll come back to it later). So instead of generating more content, I simply moved it inside the CSS thanks to pseudo elements (`::before` and `::after`). The message is now inside `::after` and we use the `::before` to have the small triangle on the left of the message. So now, we have less HTML generated which is seems pretty nice.
So now, back to the `edition` change: the message is globally the same, but the "edition" itself can be different (2015 or 2018 currently, I expect 2021 to arrive not too far in the future). So the only difference for it is that I added a new attribute on the tooltip called `edition` which contains this information. Then, the `::after` uses it inside its `content` (you can get the content of an element's attribute by using `attr` and concat different strings by simply having them after the other).
Don't hesitate if a part of my explanations isn't clear.
r? `@jyn514`
Deprecate atomic compare_and_swap method
Finish implementing [RFC 1443](https://github.com/rust-lang/rfcs/blob/master/text/1443-extended-compare-and-swap.md) (https://github.com/rust-lang/rfcs/pull/1443).
It was decided to deprecate `compare_and_swap` [back in Rust 1.12 already](https://github.com/rust-lang/rust/issues/31767#issuecomment-215903038). I can't find any info about that decision being reverted. My understanding is just that it has been forgotten. If there has been a decision on keeping `compare_and_swap` then it's hard to find, and even if this PR does not go through it can act as a place where people can find out about the decision being reverted.
Atomic operations are hard to understand, very hard. And it does not help that there are multiple similar methods to do compare and swap with. They are so similar that for a reader it might be hard to understand the difference. This PR aims to make that simpler by finally deprecating `compare_and_swap` which is essentially just a more limited version of `compare_exchange`. The documentation is also updated (according to the RFC text) to explain the differences a bit better.
Even if we decide to not deprecate `compare_and_swap`. I still think the documentation for the atomic operations should be improved to better describe their differences and similarities. And the documentation can be written nicer than the PR currently proposes, but I wanted to start somewhere. Most of it is just copied from the RFC.
The documentation for `compare_exchange` and `compare_exchange_weak` indeed describe how they work! The problem is that they are more complex and harder to understand than `compare_and_swap`. So for someone who does not fully grasp this they might fall back to using `compare_and_swap`. Making the documentation outline the similarities and differences might build a bridge for people so they can cross over to the more powerful and sometimes more efficient operations.
The conversions I do to avoid the `std` internal deprecation errors are very straight forward `compare_and_swap -> compare_exchange` changes where the orderings are just using the mapping in the new documentation. Only in one place did I use `compare_exchange_weak`. This can probably be improved further. But the goal here was not for those operations to be perfect. Just to not get worse and to allow the deprecation to happen.
Remove redundant test
Remove ignored test. This test can also be found at src/test/rustdoc-ui/intra-doc/double-anchor.rs and the second version isn't ignored.
r? ``@jyn514``
This does *not* currently work for associated items that are
auto-implemented by the compiler (e.g. `never::eq`), because they aren't
present in the source code. I plan to fix this in a follow-up PR.
