Add the identity function as core::convert::identity
## New notes
This implements rust-lang/rfcs#2306 (see https://github.com/rust-lang/rust/issues/53500).
## Old notes (ignore this in new reviews)
Adds the identity function `fn id<T>(x: T) -> T { x }` to core::convert and the prelude.
Some motivations for why this is useful are explained in the doc tests.
Another is that using the identity function instead of `{ x }` or `|x| x` makes it clear that you intended to use an identity conversion on purpose.
The reasoning:
+ behind adding this to `convert` and not `mem` is that this is an identity *conversion*.
+ for adding this to the prelude is that it should be easy enough to use that the ease of writing your own identity function or using a closure `|x| x` doesn't overtake that.
I've separated this out into two feature gates so that the addition to the prelude can be considered and stabilized separately.
cc @bluss
try to infer linker flavor from linker name and vice versa
This is a second take on PR #50359 that implements the logic proposed in https://github.com/rust-lang/rust/pull/50359#pullrequestreview-116663121
With this change it would become possible to link `thumb*` binaries using GNU's LD on stable as `-C linker=arm-none-eabi-ld` would be enough to change both the linker and the linker flavor from their default values of `arm-none-eabi-gcc` and `gcc`.
To link `thumb*` binaries using rustc's LLD on stable `-Z linker-flavor` would need to be stabilized as `-C linker=rust-lld -Z linker-flavor=ld.lld` are both required to change the linker and the linker flavor, but this PR doesn't propose that. We would probably need some sort of stability guarantee around `rust-lld`'s name and availability to make linking with rustc's LLD truly stable.
With this change it would also be possible to link `thumb*` binaries using a system installed LLD on stable using the `-C linker=ld.lld` flag (provided that `ld.lld` is a symlink to the system installed LLD).
r? @alexcrichton
52985: cause cycle err on inf trait normalization
Issue: #52985
- If an existential type is defined, but no user code infers the
concrete type behind the existential type, normalization would
infinitely recurse on this existential type which is only defined in
terms of itself.
- Instead of raising an inf recurse error, we cause a cycle error to
help highlight that the issue is that the type is only defined in terms
of itself.
- Three known potential improvements:
- If type folding itself was exposed as a query, used by
normalization and other mechanisms, cases that would cause infinite recursion would
automatically cause a cycle error.
- The span for the cycle error should be improved to point to user
code that fails to allow inference of the concrete type of the existential type,
assuming that this error occurs because no user code can allow inference the
concrete type.
- A mechanism to extend the cycle error with a helpful note would be nice. Currently,
the error is built and maintained by src/librustc/ty/query/plumbing,
with no known way to extend the information that the error gets built
with.
r? @oli-obk
