Implement RFC 1560 behind `#![feature(item_like_imports)]`
This implements https://github.com/rust-lang/rfcs/pull/1560 (cc #35120) behind the `item_like_imports` feature gate.
The [RFC text](https://github.com/rust-lang/rfcs/blob/master/text/1560-name-resolution.md#changes-to-name-resolution-rules) describes the changes to name resolution enabled by `#![feature(item_like_imports)` in detail. To summarize,
- Items and named imports shadow glob imports.
- Multiple globs can import the same name if the name is unused or the imports are shadowed.
- Multiple globs can import the same name if the imports are of the same item (following re-exports).
- The visibility of such a name is the maximum visibility of the imports.
- Equivalently, adding a glob import will never reduce the visibility of a name, nor will removing one increase it.
- Non-prelude private imports can be used wherever we currently allow private items to be used.
- Prelude-imported names are unaffected, i.e. they continue to be usable only in lexical scopes.
- Globs import all visible names, not just public names.
- Equivalently, glob importing from an ancestor module imports all of the ancestor's names, and glob importing from other modules is unchanged.
r? @nrc
We've got tests which require a particular version of LLVM to run as they're
testing bug fixes. Our build system, however, supports multiple LLVM versions,
so we can't run these tests on all LLVM versions.
This adds a new `min-llvm-version` directive for tests so they can opt out of
being run on older versions of LLVM. This then namely applies that logic to the
`issue-36023.rs` test case and...
Closes#36138
Cache projections in trans
This introduces a cache for the results of projection and normalization in trans. This is in addition to the existing cache that is per-inference-context. Trans is an easy place to put the cache because we are guaranteed not to have type parameters and also we don't expect any failures or inference variables, so there is no need to cache or follow-up on obligations that come along with. (As evidenced by the fact that this particular code would panic if any error occurred.)
That said, I am not sure this is 100% the best place for it; I sort of wanted a cache like we have in the fulfillment context for global names; but that cache only triggers when all subsequent obligations are satisfied, and since projections don't have an entry in the obligation jungle there is no easy place to put it. I considered caching both the result and obligations globally, but haven't really tried implementing it. It might be a good next step.
Regardless, this cache seems to have no real effect on bootstrap time (maybe a slight improvement), but on [the futures.rs test case I was looking at](https://github.com/rust-lang-nursery/rustc-benchmarks/pull/6), it improves performance quite a bit:
| phase | before | after |
| ----- | ------ | ----- |
| collection | 0.79s | 0.46s |
| translation | 6.8s | 3.2s |
| total | 11.92s | 7.15s |
r? @arielb1
Allow specification of the system V AMD64 ABI constraint.
This can be specified using `extern "sysV64" fn` on all platforms.
This ABI is used as the C ABI on unix platforms, but can only be specified there using extern "C". It was impossible to specify on other platforms. Meanwhile the win64 ABI, which was the extern "C" ABI on the windows platform could be specified on other platforms using extern "win64".
This pull request adds the the "sysV64" ABI constraint which exposes this calling convention on platforms where it is not the C ABI.
Turn the RFC1592 warnings into hard errors
The warnings have already reached stable, and I want to improve the trait error reporting code.
Turning warnings into errors, this is obviously a [breaking-change].
r? @nikomatsakis
cc @rust-lang/compiler
Implement std::convert traits for char
This is motivated by avoiding the `as` operator, which sometimes silently truncates, and instead use conversions that are explicitly lossless and infallible.
I’m less certain that `From<u8> for char` should be implemented: while it matches an existing behavior of `as`, it’s not necessarily the right thing to use for non-ASCII bytes. It effectively decodes bytes as ISO/IEC 8859-1 (since Unicode designed its first 256 code points to be compatible with that encoding), but that is not apparent in the API name.