macros: hygienize use of `core`/`std` in builtin macros
Today, if a builtin macro wants to access an item from `core` or `std` (depending `#![no_std]`), it generates `::core::path::to::item` or `::std::path::to::item` respectively (c.f. `fn std_path()` in `libsyntax/ext/base.rs`).
This PR refactors the builtin macros to instead always emit `$crate::path::to::item` here. That is, the def site of builtin macros is taken to be in `extern crate core;` or `extern crate std;`. Since builtin macros are macros 1.0 (i.e. mostly unhygienic), changing the def site can only effect the resolution of `$crate`.
r? @nrc
Record all imports (`use`, `extern crate`) in the crate metadata
This PR adds non-`pub` `use` and `extern crate` imports in the crate metadata since hygienic macros invoked in other crates may use them. We already include all other non-`pub` items in the crate metadata. This improves import suggestions in some cases.
Fixes#42337.
r? @nrc
Implement impl Trait lifetime elision
Fixes#43396.
There's one weird ICE in the interaction with argument-position `impl Trait`. I'm still debugging it-- I've left a test for it commented out with a FIXME.
Also included a FIXME to ensure that `impl Trait` traits are caught under the lint in https://github.com/rust-lang/rust/issues/45992.
r? @nikomatsakis
Fix return value of `LLVMRustMetadataAsValue`
`LLVMRustMetadataAsValue` would previously return `void`, despite the
corresponding Rust function expecting to return a `ValueRef`.
Remove armv5te target from dist-various-1
Reverts https://github.com/rust-lang/rust/pull/46498
I must have made some mistake when I tested that commit and thought armv5te target worked. but testing it now the produced binaries segfaults (https://github.com/rust-lang/rust/pull/46498#issuecomment-350599233).
I tried using crosstool-ng and buildroot toolchain (for armv5te) but the produced binaries also segfaults. Maybe there is a issue with the target, but I cannot investigate it any further.
I think the best for now is not to distribute the armv5te target.
I'm sorry for what happened.
Mark ascii methods on primitive types stable in 1.23.0 not 1.21.0.
The ascii_methods_on_intrinsics feature stabilization
didn't land in time for 1.21.0. Update the annotation
so the documentation is correct about when these
methods became available.
move `resolve_lifetimes` into a proper query
Now that we made `resolve_lifetimes` into a query, elision errors no
longer abort compilation, which affects some tests.
Also, remove `dep_graph_crosscontaminate_tables` -- there is no a path in
the dep-graph, though red-green handles it. The same scenario
is (correctly) tested by issue-42602.rs in any case.
r? @michaelwoerister
Reverts https://github.com/rust-lang/rust/pull/46498
I must have made some mistake when I tested that commit and thought
armv5te target worked. but testing it now the produced binaries
segfaults
(https://github.com/rust-lang/rust/pull/46498#issuecomment-350599233).
I tried using crosstool-ng and buildroot toolchain (for armv5te) but
the produced binaries also segfaults. Maybe there is a issue with the
target, but I cannot investigate it any further.
I think the best for now is not to distribute the armv5te target.
I'm sorry for what happened.
Now that we made `resolve_lifetimes` into a query, elision errors no
longer abort compilation, which affects some tests.
Also, remove `dep_graph_crosscontaminate_tables` -- there is no a path in
the dep-graph, though red-green handles it. The same scenario
is (correctly) tested by issue-42602.rs in any case.
