Emit a hint for bad call return types due to generic arguments
When the return type of a function call depends on the type of an argument, e.g.
```
fn foo<T>(x: T) -> T {
x
}
```
and the expected type is set due to either an explicitly typed binding, or because the call to the function is in a tail position without semicolon, the current error implies that the argument in the call has the wrong type.
This new hint highlights that the expected type doesn't match the returned type, which matches the argument type, and that that's why we're flagging the argument type.
Fixes#43608.
Add note when `FnPtr` vs. `FnDef` impl trait
I encountered an instance where an `FnPtr` implemented a trait, but I was passing an `FnDef`. I was confused for an hour and to examine the source code of the trait's crate's tests in order to understand how to cast it properly (it didn't help that it was behind a reference). To the end user, it might not be immediately obvious that they are different and how to convert from an `FnDef` to an `FnPtr`, but it is necessary to cast to the generic function in order to compile. It is thus useful to suggest `as` in the help note, (even if the `Fn` output implements the trait).
Update the wasi-libc used for the wasm32-wasi target
This commit updates the wasi-libc revision used to build with the wasm32-wasi target. This notably pulls in WebAssembly/wasi-libc#377 which is needed to fix a use case I've been working on recently. This should be a relatively small update hopefully and is not expected to have any user impact.
Emit a single error for contiguous sequences of unknown tokens
Closes#106101
On encountering a sequence of identical source characters which are unknown tokens, note the amount of subsequent characters and advance past them silently. The old behavior was to emit an error and 'help' note for every single one.
`@rustbot` label +A-diagnostics +A-parser
tidy: Don't include wasm32 in compiler dependency check
This changes the tidy compiler dependency check so that it does not include wasm32-unknown-unknown dependencies in the PERMITTED_RUSTC_DEPENDENCIES. This just helps keep the list cleaner under the assumption that the compiler will never work on wasm32-unknown-unknown.
This also fixes a bug in the check to verify there are no unused dependencies in the PERMITTED_RUSTC_DEPENDENCIES. Previously the check was verifying that the dependency was used *anywhere* in the workspace, when it should have been checking if it was used for the compiler.
There's also just a little general cleanup here. For example, the old `normal_deps_of_r` function was changed a while ago to return *all* dependencies, but the function name and description wasn't updated to remove `normal_`.
Fix mir-opt tests for big-endian platforms
The test cases src/test/mir-opt/building/custom/consts.rs and src/test/mir-opt/const_prop/mutable_variable_no_prop.rs are currently failing on big-endian platforms as the binary encoding of some constants is hard-coded in the MIR test files. Fix this by choosing constant values that have the same encoding on big- and little-endian platforms.
The test case src/test/mir-opt/issues/issue_75439.rs is failing as well, but since the purpose of the test is to validate handling of big-endian integer encodings on a little-endian platform, it does not make much sense to run it on big-endian platforms in the first place - we can just ignore it there.
Fixed part of https://github.com/rust-lang/rust/issues/105383.
I encountered an instance where an `FnPtr` implemented a trait, but I was passing an `FnDef`. To
the end user, there is really no way to differentiate each of them, but it is necessary to cast
to the generic function in order to compile. It is thus useful to suggest `as` in the help note,
(even if the Fn output implements the trait).
Fix aarch64-unknown-linux-gnu_ilp32 target
This was broken because the synthetic object files produced by rustc were for 64-bit AArch64, which caused link failures when combined with 32-bit ILP32 object files.
This PR updates the object crate to 0.30.1 which adds support for generating ILP32 AArch64 object files.
Update mdbook
This updates mdbook from 0.4.21 to 0.4.25. The list of changes is [here](https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0425). The only user-visible changes are some changes around the theme picker, and change to the copy-to-clipboard ignoring hidden lines.
Internally there were some dependency updates and small fixes.
This also updates `clap` from 4.0.15 to 4.0.32 whose changelog is [here](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#4032---2022-12-22). This impacts tools like cargo. I don't see anything particularly noteworthy there, though there are some small user-visible changes.
Unfortunately this required adding a hack for building `rustix` with a bootstrap tool. The comment explains why. I am unable to think of some other workaround (or even a cleaner way to set the rustflag). Ideas are welcome if you can think of alternatives. I'm struggling to even think of a long-term solution, other than asking projects not to do auto-nightly feature detection.
One medium-term solution is to avoid the clap dependency for the mdbook library (which is how rustix gets pulled in). That is one of my goals for the 0.5 release of mdbook, but that probably won't happen until later this year. It would also require dropping clap from `rustbook` and using some other means to parse arguments (there's only two options, so it can probably be done manually).
rustdoc: remove unnecessary DOM class `h1.fqn`
It's misleading. The main heading sometimes isn't an fully qualified name at all.
It's also redundant. It's always a child of `div.main-heading`, so just use that.
Update `rental` hack to work with remapped paths.
This PR simply switches to an already-existing helper instead of hard-coding a specific enum variant. The new revision of the test fails without the other changes in this PR.
Context: I'm exploring running UI tests with remapped paths by default in #105924 and the rental test was one of the ones that failed.
This may also be useful in the context of https://github.com/rust-lang/rfcs/pull/3127 ("New rustc and Cargo options to allow path sanitisation by default").
Remove duplicate sha-1 dependency
[`sha-1`](https://crates.io/crates/sha-1) is more or less a duplicate of [`sha1`](https://crates.io/crates/sha1). The `sha-1` is deprecated and no longer updated. This updates the dependencies to use the new name.
Some other dependencies that got updated as a consequence:
* The updated pest dependencies are currently only used by mdbook, and shouldn't have any issues.
* ucd-trie 0.1.3 to 0.1.5: No changelog, but looks like some tables were updated for new unicode versions: https://github.com/BurntSushi/ucd-generate/commits/master/ucd-trie. This is only used by pest (and thus mdbook).
* thiserror 1.33 to 1.38: Nothing significant in the notes at https://github.com/dtolnay/thiserror/releases.
rustdoc: rename CSS rustdoc-toggle -> toggle and toggle -> settings-toggle
This swaps things around so that the class that gets used more often has the shorter name.
mv binary_heap.rs binary_heap/mod.rs
I confess this request is somewhat selfish, as it's made in order to ease synchronisation with my [copse](https://crates.io/crates/copse) crate (see eggyal/copse#6 for explanation). I wholly understand that such grounds may be insufficient to justify merging this request—but no harm in asking, right?
reword Option::as_ref and Option::map examples
The description for the examples of `Option::as_ref` and `Option::map` imply that the example is only doing type conversion, when it is actually finding the length of a string.
Changes the wording to imply that some operation is being run on the value contained in the `Option`
closes#104476
This commit builds on b72de9be74, which removes
the `docblock` class from the All Items page, and
9457380ac9, which removes the `docblock` class
from the item decl.
Fixes#92974
This commit updates the wasi-libc revision used to build with the
wasm32-wasi target. This notably pulls in WebAssembly/wasi-libc#377
which is needed to fix a use case I've been working on recently. This
should be a relatively small update hopefully and is not expected to
have any user impact.
