Also, avoid shadowing of the `ty` variable by giving the `cast_ty` and
`var_ty` variables different names. We want to get the user-provided
type from `cast_ty.hir_id`.
Add a `copysign` function to f32 and f64
This patch adds a `copysign` function to the float primitive types. It is an exceptionally useful function for writing efficient numeric code, as it often avoids branches, is auto-vectorizable, and there are efficient intrinsics for most platforms.
I think this might work as-is, as the relevant `copysign` intrinsic is already used internally for the implementation of `signum`. It's possible that an implementation might be needed in japaric/libm for portability across all platforms, in which case I'll do that also.
Part of the work towards #55107
Custom E0277 diagnostic for `Path`
r? @nikomatsakis we have a way to target `Path` exclusively, we need to identify the correct text to show to consider #23286 fixed.
NLL lacks various special case handling of closures
Part of #52663.
Firstly, this PR extends existing handling of closures to also support generators.
Second, this PR adds the note found in the AST when a closure is invoked twice and captures a variable by-value:
```text
note: closure cannot be invoked more than once because it moves the variable `dict` out of its environment
--> $DIR/issue-42065.rs:16:29
|
LL | for (key, value) in dict {
| ^^^^
```
r? @nikomatsakis
cc @pnkfelix
This commit extends existing special-casing of closures to highlight the
use of variables within generators that are causing the generator to
borrow them.
Add slice::rchunks(), rchunks_mut(), rchunks_exact() and rchunks_exact_mut()
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
----
The new iterators were motivated by a [comment](https://github.com/rust-lang/rust/issues/47115#issuecomment-424141121) by @DutchGhost.
~~~This currently includes the commits from https://github.com/rust-lang/rust/pull/54537 to not have to rename things twice or have merge conflicts. I'll force-push a new version of the branch ones those are in master.~~~
Also the stabilization tracking issue is just some number right now. I'll create the corresponding issue once this is reviewed and otherwise mergeable.
cc @DutchGhost
Rollup of 18 pull requests
Successful merges:
- #54646 (improve documentation on std:🧵:sleep)
- #54933 (Cleanup the rest of codegen_llvm)
- #54964 (Run both lldb and gdb tests)
- #55016 (Deduplicate some code and compile-time values around vtables)
- #55031 (Improve verify_llvm_ir config option)
- #55050 (doc std::fmt: the Python inspiration is already mentioned in precedin…)
- #55077 (rustdoc: Use dyn keyword when rendering dynamic traits)
- #55080 (Detect if access to localStorage is forbidden by the user's browser)
- #55090 (regression test for move out of borrow via pattern)
- #55102 (resolve: Do not skip extern prelude during speculative resolution)
- #55104 (Add test for #34229)
- #55111 ([Rustc Book] Explain --cfg's arguments)
- #55122 (Cleanup mir/borrowck)
- #55127 (Remove HybridBitSet::dummy)
- #55128 (Fix LLVMRustInlineAsmVerify return type mismatch)
- #55142 (miri: layout should not affect CTFE checks (outside of validation))
- #55151 (Cleanup nll)
- #55161 ([librustdoc] Disable spellcheck for search field)
[Rustc Book] Explain --cfg's arguments
I removed this from the reference since it's rustc specific, and noticed it wasn't well documented on the page that should document it well. It does seem to go against the grain of one line per command line flag though.
[librustdoc] Disable spellcheck for search field
This disables spellchecking for the search field in the rustdoc web interface.
As someone who uses Safari to browse through Rust docs, spellchecking gets really annoying.
miri: layout should not affect CTFE checks (outside of validation)
Either the enum has no valid discriminant, then the code later will catch that; or it does, then we shouldn't error out so early (absent enforcing validity).
Interestingly, the miri test suite still passes; my guess is we don't even get here for uninhabited types?
r? @oli-obk
