make trait-aliases work across crates
This is rebase of a small part of @alexreg's PR #55994. It focuses just on the changes that integrate trait aliases properly into crate metadata, excluding the stylistic edits and the trait objects.
The stylistic edits I also rebased and can open a separate PR.
The trait object stuff I found challenging and decided it basically needed to be reimplemented. For now I've excluded it.
Since this is really @alexreg's work (I really just rebased) I am going to make it r=me once it is working.
Fixes#56488.
Fixes#57023.
Generalize `huge-enum.rs` test and expected stderr for more cross platform cases
With this change, I am able to build and test cross-platform `rustc`
In particular, I can use the following in my `config.toml`:
```
[build]
host = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
```
Before this change, my attempt to run the test suite would fail
because the error output differs depending on what your host and
targets are.
----
To be concrete, here are the actual messages one can observe:
```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `std::option::Option<[u32; 35184372088831]>` is too big for the current architecture
error: aborting due to previous error
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `[u32; 35184372088831]` is too big for the current architecture
error: aborting due to previous error
```
To address these variations, I changed the test to be more aggressive
in its normalization strategy. We cannot (and IMO should not)
guarantee that `Option` will appear in the error output here. So I
normalized both types `Option<[u32; N]>` and `[u32; N]` to just `TYPE`
High priority resolutions for associated variants
In https://github.com/rust-lang/rust/pull/56225 variants were assigned lowest priority during name resolution to avoid crater run and potential breakage.
This PR changes the rules to give variants highest priority instead.
Some motivation:
- If variants (and their constructors) are treated as associated items, then they are obviously *inherent* associated items since they don't come from traits.
- Inherent associated items have higher priority during resolution than associated items from traits.
- The reason is that there is a way to disambiguate in favor of trait items (`<Type as Trait>::Ambiguous`), but there's no way to disambiguate in favor of inherent items, so they became unusable in case of ambiguities if they have low priority.
- It's technically problematic to fallback from associated types to anything until lazy normalization (?) is implemented.
Crater found some regressions from this change, but they are all in type positions, e.g.
```rust
fn f() -> Self::Ambiguos { ... } // Variant `Ambiguous` or associated type `Ambiguous`?
```
, so variants are not usable there right now, but they may become usable in the future if https://github.com/rust-lang/rfcs/pull/2593 is accepted.
This PR keeps code like this successfully resolving, but introduces a future-compatibility lint `ambiguous_associated_items` that recommends rewriting it as `<Self as Trait>::Ambiguous`.
Fix stack overflow when finding blanket impls
Currently, SelectionContext tries to prevent stack overflow by keeping
track of the current recursion depth. However, this depth tracking is
only used when performing normal section (which includes confirmation).
No such tracking is performed for evaluate_obligation_recursively, which
can allow a stack overflow to occur.
To fix this, this commit tracks the current predicate evaluation depth.
This is done separately from the existing obligation depth tracking:
an obligation overflow can occur across multiple calls to 'select' (e.g.
when fulfilling a trait), while a predicate evaluation overflow can only
happen as a result of a deep recursive call stack.
Fixes#56701
I've re-used `tcx.sess.recursion_limit` when checking for predication evaluation overflows. This is such a weird corner case that I don't believe it's necessary to have a separate setting controlling the maximum depth.
Fix suggestions given mulitple bad lifetimes
When given multiple lifetimes prior to type parameters in generic
parameters, do not ICE and print the correct suggestion.
r? @estebank
CC @pnkfelix
Fixes: #57521
librustc_metadata: Pass a default value when unwrapping a span
Fixes#57323.
When compiling with `static-nobundle` a-la
`rustc -l static-nobundle=nonexistent main.rs`
we now get a neat output in the form of:
```
error[E0658]: kind="static-nobundle" is feature gated (see issue #37403)
|
= help: add #![feature(static_nobundle)] to the crate attributes to enable
error: aborting due to previous error
For more information about this error, try `rustc --explain E0658`.
```
The build and tests completed successfully on my machine. Should I be adding a new test?
Better error note on unimplemented Index trait for string
fixes#56740
I've tried to compile suggestion from comments in the issue #56740, but unsure of it. So I'm open to advice :)
Current output will be like this:
```rust
error[E0277]: the type `str` cannot be indexed by `{integer}`
--> $DIR/str-idx.rs:3:17
|
LL | let c: u8 = s[4]; //~ ERROR the type `str` cannot be indexed by `{integer}`
| ^^^^ `str` cannot be indexed by `{integer}`
|
= help: the trait `std::ops::Index<{integer}>` is not implemented for `str`
= note: you can use `.chars().nth()` or `.bytes().nth()`
see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>
error: aborting due to previous error
For more information about this error, try `rustc --explain E0277`.
```
`x.py test src/test/ui` succeeded and I've also tested output manually by compiling the following code:
```rust
fn _f() {
let s = std::string::String::from("hello");
let _c = s[0];
let s = std::string::String::from("hello");
let mut _c = s[0];
let s = "hello";
let _c = s[0];
let s = "hello";
let mut _c = &s[0];
}
```
Not sure if some docs should be changed too. I will also fix error message in the [Book :: Indexing into Strings](db53e2e3cd/src/ch08-02-strings.md (indexing-into-strings)) if that PR will get approved :)
Implement basic input validation for built-in attributes
Correct top-level shape (`#[attr]` vs `#[attr(...)]` vs `#[attr = ...]`) is enforced for built-in attributes, built-in attributes must also fit into the "meta-item" syntax (aka the "classic attribute syntax").
For some subset of attributes (found by crater run), errors are lowered to deprecation warnings.
NOTE: This PR previously included https://github.com/rust-lang/rust/pull/57367 as well.
In particular, I can use the following in my `config.toml`:
```
[build]
host = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
target = ["i686-unknown-linux-gnu", "x86_64-unknown-linux-gnu"]
```
Before this change, my attempt to run the test suite would fail
because the error output differs depending on what your host and
targets are.
----
To be concrete, here are the actual messages one can observe:
```
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `std::option::Option<[u32; 35184372088831]>` is too big for the current architecture
error: aborting due to previous error
% ./build/x86_64-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=i686-unknown-linux-gnu
error: the type `std::option::Option<[u32; 536870911]>` is too big for the current architecture
error: aborting due to previous error
% ./build/i686-unknown-linux-gnu/stage1/bin/rustc ../src/test/ui/huge-enum.rs -Aunused --target=x86_64-unknown-linux-gnu
error: the type `[u32; 35184372088831]` is too big for the current architecture
error: aborting due to previous error
```
To address these variations, I changed the test to be more aggressive
in its normalization strategy. We cannot (and IMO should not)
guarantee that `Option` will appear in the error output here. So I
normalized both types `Option<[u32; N]>` and `[u32; N]` to just `TYPE`
rustc: Remove platform intrinsics crate
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
forbid manually impl'ing one of an object type's marker traits
This shouldn't break compatibility for crates that do not use
`feature(optin_builtin_traits)`, because as the test shows, it is
only possible to impl a marker trait for a trait object in the crate the
marker trait is defined in, which must define
`feature(optin_builtin_traits)`.
Fixes#56934.
r? @nikomatsakis
Modify some parser diagnostics to continue evaluating beyond the parser
Continue evaluating further errors after parser errors on:
- trailing type argument attribute
- lifetime in incorrect location
- incorrect binary literal
- missing `for` in `impl Trait for Foo`
- type argument in `where` clause
- incorrect float literal
- incorrect `..` in pattern
- associated types
- incorrect discriminator value variant error
and others. All of these were found by making `continue-parse-after-error` `true` by default to identify errors that would need few changes. There are now only a handful of errors that have any change with `continue-parse-after-error` enabled.
These changes make it so `rust` _won't_ stop evaluation after finishing parsing, enabling type checking errors to be displayed on the existing code without having to fix the parse errors.
Each commit has an individual diagnostic change with their corresponding tests.
CC #48724.
This was originally attempted in #57048 but it was realized that we
could fully remove the crate via the `"unadjusted"` ABI on intrinsics.
This means that all intrinsics in stdsimd are implemented directly
against LLVM rather than using the abstraction layer provided here. That
ends up meaning that this crate is no longer used at all.
This crate developed long ago to implement the SIMD intrinsics, but we
didn't end up using it in the long run. In that case let's remove it!
Stabilize cfg_target_vendor
This stabilizes the use of `cfg(target_vendor = "...")` and removes the corresponding `cfg_target_vendor` feature. Other unstable cfgs remain behind their existing feature gates.
This functionality was added back in 2015 in #28612 to complete the coverage of target tuples (`<arch><sub>-<vendor>-<os>-<env>`). [RFC 131](https://github.com/rust-lang/rfcs/blob/master/text/0131-target-specification.md) governs the target specification, not including `target_vendor` seems to have just been an oversight. `target_os`, `target_family`, and `target_arch` are stable as of 1.0.0. `target_env` was also not mentioned in RFC 131, was added in #24777, never behind a feature_gate, and insta-stable at 1.1.0.
The functionality is tested in [test/run-pass/cfg/cfg-target-vendor.rs](https://github.com/rust-lang/rust/blob/master/src/test/run-pass/cfg/cfg-target-vendor.rs).
Closes#29718
Stabilize core::convert::identity
r? @SimonSapin
fixes https://github.com/rust-lang/rust/issues/53500
This is waiting for FCP to complete but in the interim it would be good to review.
