Add missing Wrapping methods, use doc_comment!
Re-opened version of #49393 . Finishing touches for #32463.
Note that this adds `Shl` and `Shr` implementations for `Wrapping<i128>` and `Wrapping<u128>`, which were previously missed. This is technically insta-stable, but I don't know why this would be a problem.
str::from_raw_parts has been removed long ago because it can be obtained via
str::from_utf8_unchecked and slice::from_raw_parts. The same goes for
str::from_raw_parts_mut.
operate on `HirId` instead of `NodeId` in `hir::Pat::each_binding`, and consequences of that
See #50928 for motivation.
Questions—
* Is #50928 actually a good idea as a plan of record, or is there some reason to keep `NodeId`s?
* Are the uses of `find_node_for_hir_id` in this initial submission OK (see the FIXME comments)?
* Can we bikeshed a better method names `struct_span_lint_hir` _&c._? (Coined in analogy to the `struct_span_lint_node` and `NodeId`, but it feels kind of semantically clunky.)
r? @michaelwoerister
Add simd math intrinsics and gather/scatter
This PR adds simd math intrinsics for floating-point vectors (sqrt, sin, cos, pow, exp, log, fma, abs, etc.) and the generic simd gather/scatter intrinsics.
Michael Woerister pointed out that `hir_to_node_id` (introduced in
August 2017's 28ddd7a4e) supersedes the functionality of
`find_node_for_hir_id` (just a hash lookup compared to that linear
search).
Changing the `each_binding` utility method to take the `HirId` of a
binding pattern rather than its `NodeId` seems like a modest first step
in support of the `HirId`ification initiative #50928. (The inspiration
for choosing this in particular came from the present author's previous
work on diagnostics issued during liveness analysis, which is the most
greatly affected module in this change.)
add suggestion applicabilities to librustc and libsyntax
A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means).
r? @Manishearth
cc @killercup @estebank
Make anon params lint warn-by-default
This is intended as a followup on anonymous parameters deprecation.
Cross-posting from #41686:
> After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy:
> - We make the lint warn-by-default as soon as possible
> - We make anon parameters a hard error at the epoch boundary
cc @matklad @est31 @aturon
When encountering an unexisting method for a given trait where an
associated function has the same name, suggest using the appropriate
syntax, instead of using `help` text.
When only one candidate is found, do not call it "candidate #1", just
call it "the candidate".
