-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix ItemKind::TraitAlias encoding #56541
Conversation
ItemKind::TraitAlias should be encoded just like a regular Trait.
(rust_highfive has picked a reviewer for you, use r? to override) |
r? @Centril |
The test I wrote doesn't include all of the example in #56488 but it still causes nightly to panic. |
Hmm, this doesn't seem like the right fix. I think the bug is a touch deeper though (cc @alexreg). In particular, the /// Returns `true` if `def_id` is a trait alias.
pub fn is_trait_alias(tcx: TyCtxt<'_, '_, '_>, def_id: DefId) -> bool {
if let Some(node_id) = tcx.hir.as_local_node_id(def_id) {
if let Node::Item(item) = tcx.hir.get(node_id) {
if let hir::ItemKind::TraitAlias(..) = item.node {
return true;
}
}
}
false
} but I think that it will not work correctly when you try to actually use a trait alias across crates, as a result. i.e., can we make a test like // Crate A
trait Foo = Send + Sync;
// Crate b:
use crate_a::Foo;
fn use_b<T: Foo>() { }
fn main() {
use_b::<u32>(); // Expect Ok
use_b::<Rc<u32>>(); // Expect error
} and see what behavior is? |
In any case, I feel like we can't just pretend a trait is a trait alias across crates. |
Ah, right... good point. |
Thanks for having a go at this @dlrobertson! I think @nikomatsakis is right; the |
👍 |
ItemKind::TraitAlias
should be encoded just like a regularTrait
.Fixes: #56488