Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
// Copyright 2018 The Rust Project Developers. See the COPYRIGHT
|
|
|
|
// file at the top-level directory of this distribution and at
|
|
|
|
// http://rust-lang.org/COPYRIGHT.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0> or the MIT license
|
|
|
|
// <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your
|
|
|
|
// option. This file may not be copied, modified, or distributed
|
|
|
|
// except according to those terms.
|
|
|
|
|
2018-04-05 18:10:15 +00:00
|
|
|
use rustc::traits::auto_trait as auto;
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
use rustc::ty::TypeFoldable;
|
2018-03-20 03:35:23 +00:00
|
|
|
use std::fmt::Debug;
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
|
|
|
|
use super::*;
|
|
|
|
|
|
|
|
pub struct AutoTraitFinder<'a, 'tcx: 'a, 'rcx: 'a> {
|
|
|
|
pub cx: &'a core::DocContext<'a, 'tcx, 'rcx>,
|
2018-04-05 18:10:15 +00:00
|
|
|
pub f: auto::AutoTraitFinder<'a, 'tcx>,
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a, 'tcx, 'rcx> AutoTraitFinder<'a, 'tcx, 'rcx> {
|
2018-04-05 18:10:15 +00:00
|
|
|
pub fn new(cx: &'a core::DocContext<'a, 'tcx, 'rcx>) -> Self {
|
2018-04-06 22:12:51 +00:00
|
|
|
let f = auto::AutoTraitFinder::new(&cx.tcx);
|
2018-04-05 18:10:15 +00:00
|
|
|
|
|
|
|
AutoTraitFinder { cx, f }
|
|
|
|
}
|
|
|
|
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
pub fn get_with_def_id(&self, def_id: DefId) -> Vec<Item> {
|
|
|
|
let ty = self.cx.tcx.type_of(def_id);
|
|
|
|
|
|
|
|
let def_ctor: fn(DefId) -> Def = match ty.sty {
|
|
|
|
ty::TyAdt(adt, _) => match adt.adt_kind() {
|
|
|
|
AdtKind::Struct => Def::Struct,
|
|
|
|
AdtKind::Enum => Def::Enum,
|
|
|
|
AdtKind::Union => Def::Union,
|
2018-02-23 17:06:05 +00:00
|
|
|
}
|
2018-05-07 12:01:53 +00:00
|
|
|
ty::TyInt(_) |
|
|
|
|
ty::TyUint(_) |
|
|
|
|
ty::TyFloat(_) |
|
|
|
|
ty::TyStr |
|
|
|
|
ty::TyBool |
|
|
|
|
ty::TyChar => return self.get_auto_trait_impls(def_id, &move |_: DefId| {
|
|
|
|
match ty.sty {
|
|
|
|
ty::TyInt(x) => Def::PrimTy(hir::TyInt(x)),
|
|
|
|
ty::TyUint(x) => Def::PrimTy(hir::TyUint(x)),
|
|
|
|
ty::TyFloat(x) => Def::PrimTy(hir::TyFloat(x)),
|
|
|
|
ty::TyStr => Def::PrimTy(hir::TyStr),
|
|
|
|
ty::TyBool => Def::PrimTy(hir::TyBool),
|
|
|
|
ty::TyChar => Def::PrimTy(hir::TyChar),
|
|
|
|
_ => unreachable!(),
|
|
|
|
}
|
|
|
|
}, None),
|
|
|
|
_ => {
|
|
|
|
debug!("Unexpected type {:?}", def_id);
|
|
|
|
return Vec::new()
|
|
|
|
}
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
};
|
|
|
|
|
2018-05-07 12:01:53 +00:00
|
|
|
self.get_auto_trait_impls(def_id, &def_ctor, None)
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
pub fn get_with_node_id(&self, id: ast::NodeId, name: String) -> Vec<Item> {
|
|
|
|
let item = &self.cx.tcx.hir.expect_item(id).node;
|
|
|
|
let did = self.cx.tcx.hir.local_def_id(id);
|
|
|
|
|
|
|
|
let def_ctor = match *item {
|
|
|
|
hir::ItemStruct(_, _) => Def::Struct,
|
|
|
|
hir::ItemUnion(_, _) => Def::Union,
|
|
|
|
hir::ItemEnum(_, _) => Def::Enum,
|
|
|
|
_ => panic!("Unexpected type {:?} {:?}", item, id),
|
|
|
|
};
|
|
|
|
|
2018-05-07 12:01:53 +00:00
|
|
|
self.get_auto_trait_impls(did, &def_ctor, Some(name))
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
|
2018-05-07 12:01:53 +00:00
|
|
|
pub fn get_auto_trait_impls<F>(
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
&self,
|
|
|
|
def_id: DefId,
|
2018-05-07 12:01:53 +00:00
|
|
|
def_ctor: &F,
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
name: Option<String>,
|
2018-05-07 12:01:53 +00:00
|
|
|
) -> Vec<Item>
|
|
|
|
where F: Fn(DefId) -> Def {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
if self.cx
|
|
|
|
.tcx
|
|
|
|
.get_attrs(def_id)
|
|
|
|
.lists("doc")
|
|
|
|
.has_word("hidden")
|
|
|
|
{
|
|
|
|
debug!(
|
2018-05-07 12:01:53 +00:00
|
|
|
"get_auto_trait_impls(def_id={:?}, def_ctor=...): item has doc('hidden'), \
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
aborting",
|
2018-05-07 12:01:53 +00:00
|
|
|
def_id
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
);
|
|
|
|
return Vec::new();
|
|
|
|
}
|
|
|
|
|
|
|
|
let tcx = self.cx.tcx;
|
|
|
|
let generics = self.cx.tcx.generics_of(def_id);
|
|
|
|
|
|
|
|
debug!(
|
2018-05-07 12:01:53 +00:00
|
|
|
"get_auto_trait_impls(def_id={:?}, def_ctor=..., generics={:?}",
|
|
|
|
def_id, generics
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
);
|
|
|
|
let auto_traits: Vec<_> = self.cx
|
|
|
|
.send_trait
|
|
|
|
.and_then(|send_trait| {
|
|
|
|
self.get_auto_trait_impl_for(
|
|
|
|
def_id,
|
|
|
|
name.clone(),
|
|
|
|
generics.clone(),
|
|
|
|
def_ctor,
|
|
|
|
send_trait,
|
|
|
|
)
|
|
|
|
})
|
|
|
|
.into_iter()
|
|
|
|
.chain(self.get_auto_trait_impl_for(
|
|
|
|
def_id,
|
|
|
|
name.clone(),
|
|
|
|
generics.clone(),
|
|
|
|
def_ctor,
|
|
|
|
tcx.require_lang_item(lang_items::SyncTraitLangItem),
|
|
|
|
).into_iter())
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
debug!(
|
|
|
|
"get_auto_traits: type {:?} auto_traits {:?}",
|
|
|
|
def_id, auto_traits
|
|
|
|
);
|
|
|
|
auto_traits
|
|
|
|
}
|
|
|
|
|
2018-05-07 12:01:53 +00:00
|
|
|
fn get_auto_trait_impl_for<F>(
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
&self,
|
|
|
|
def_id: DefId,
|
|
|
|
name: Option<String>,
|
|
|
|
generics: ty::Generics,
|
2018-05-07 12:01:53 +00:00
|
|
|
def_ctor: &F,
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
trait_def_id: DefId,
|
2018-05-07 12:01:53 +00:00
|
|
|
) -> Option<Item>
|
|
|
|
where F: Fn(DefId) -> Def {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
if !self.cx
|
|
|
|
.generated_synthetics
|
|
|
|
.borrow_mut()
|
|
|
|
.insert((def_id, trait_def_id))
|
|
|
|
{
|
|
|
|
debug!(
|
2018-05-07 12:01:53 +00:00
|
|
|
"get_auto_trait_impl_for(def_id={:?}, generics={:?}, def_ctor=..., \
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
trait_def_id={:?}): already generated, aborting",
|
2018-05-07 12:01:53 +00:00
|
|
|
def_id, generics, trait_def_id
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
);
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
|
|
|
let result = self.find_auto_trait_generics(def_id, trait_def_id, &generics);
|
|
|
|
|
|
|
|
if result.is_auto() {
|
|
|
|
let trait_ = hir::TraitRef {
|
|
|
|
path: get_path_for_type(self.cx.tcx, trait_def_id, hir::def::Def::Trait),
|
|
|
|
ref_id: ast::DUMMY_NODE_ID,
|
|
|
|
};
|
|
|
|
|
|
|
|
let polarity;
|
|
|
|
|
|
|
|
let new_generics = match result {
|
|
|
|
AutoTraitResult::PositiveImpl(new_generics) => {
|
|
|
|
polarity = None;
|
|
|
|
new_generics
|
|
|
|
}
|
|
|
|
AutoTraitResult::NegativeImpl => {
|
|
|
|
polarity = Some(ImplPolarity::Negative);
|
|
|
|
|
|
|
|
// For negative impls, we use the generic params, but *not* the predicates,
|
|
|
|
// from the original type. Otherwise, the displayed impl appears to be a
|
|
|
|
// conditional negative impl, when it's really unconditional.
|
|
|
|
//
|
|
|
|
// For example, consider the struct Foo<T: Copy>(*mut T). Using
|
|
|
|
// the original predicates in our impl would cause us to generate
|
|
|
|
// `impl !Send for Foo<T: Copy>`, which makes it appear that Foo
|
|
|
|
// implements Send where T is not copy.
|
|
|
|
//
|
|
|
|
// Instead, we generate `impl !Send for Foo<T>`, which better
|
|
|
|
// expresses the fact that `Foo<T>` never implements `Send`,
|
|
|
|
// regardless of the choice of `T`.
|
|
|
|
let real_generics = (&generics, &Default::default());
|
|
|
|
|
|
|
|
// Clean the generics, but ignore the '?Sized' bounds generated
|
|
|
|
// by the `Clean` impl
|
|
|
|
let clean_generics = real_generics.clean(self.cx);
|
|
|
|
|
|
|
|
Generics {
|
|
|
|
params: clean_generics.params,
|
|
|
|
where_predicates: Vec::new(),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_ => unreachable!(),
|
|
|
|
};
|
|
|
|
|
|
|
|
let path = get_path_for_type(self.cx.tcx, def_id, def_ctor);
|
|
|
|
let mut segments = path.segments.into_vec();
|
|
|
|
let last = segments.pop().unwrap();
|
|
|
|
|
2018-03-24 18:17:27 +00:00
|
|
|
let real_name = name.map(|name| Symbol::intern(&name));
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
|
|
|
|
segments.push(hir::PathSegment::new(
|
|
|
|
real_name.unwrap_or(last.name),
|
|
|
|
self.generics_to_path_params(generics.clone()),
|
|
|
|
false,
|
|
|
|
));
|
|
|
|
|
|
|
|
let new_path = hir::Path {
|
|
|
|
span: path.span,
|
|
|
|
def: path.def,
|
|
|
|
segments: HirVec::from_vec(segments),
|
|
|
|
};
|
|
|
|
|
|
|
|
let ty = hir::Ty {
|
|
|
|
id: ast::DUMMY_NODE_ID,
|
|
|
|
node: hir::Ty_::TyPath(hir::QPath::Resolved(None, P(new_path))),
|
|
|
|
span: DUMMY_SP,
|
|
|
|
hir_id: hir::DUMMY_HIR_ID,
|
|
|
|
};
|
|
|
|
|
|
|
|
return Some(Item {
|
|
|
|
source: Span::empty(),
|
|
|
|
name: None,
|
|
|
|
attrs: Default::default(),
|
|
|
|
visibility: None,
|
|
|
|
def_id: self.next_def_id(def_id.krate),
|
|
|
|
stability: None,
|
|
|
|
deprecation: None,
|
|
|
|
inner: ImplItem(Impl {
|
|
|
|
unsafety: hir::Unsafety::Normal,
|
|
|
|
generics: new_generics,
|
|
|
|
provided_trait_methods: FxHashSet(),
|
|
|
|
trait_: Some(trait_.clean(self.cx)),
|
|
|
|
for_: ty.clean(self.cx),
|
|
|
|
items: Vec::new(),
|
|
|
|
polarity,
|
|
|
|
synthetic: true,
|
|
|
|
}),
|
|
|
|
});
|
|
|
|
}
|
|
|
|
None
|
|
|
|
}
|
|
|
|
|
2018-02-23 17:48:54 +00:00
|
|
|
fn generics_to_path_params(&self, generics: ty::Generics) -> hir::GenericArgs {
|
|
|
|
let mut args = vec![];
|
2018-04-12 23:57:38 +00:00
|
|
|
|
|
|
|
for param in generics.params.iter() {
|
2018-04-18 23:40:22 +00:00
|
|
|
match param.kind {
|
2018-05-10 22:46:57 +00:00
|
|
|
ty::GenericParamDefKind::Lifetime => {
|
2018-04-18 23:40:22 +00:00
|
|
|
let name = if param.name == "" {
|
2018-06-01 22:23:48 +00:00
|
|
|
hir::ParamName::Plain(keywords::StaticLifetime.name())
|
2018-04-12 23:57:38 +00:00
|
|
|
} else {
|
2018-06-01 22:23:48 +00:00
|
|
|
hir::ParamName::Plain(param.name.as_symbol())
|
2018-04-12 23:57:38 +00:00
|
|
|
};
|
|
|
|
|
2018-02-23 17:48:54 +00:00
|
|
|
args.push(hir::GenericArg::Lifetime(hir::Lifetime {
|
2018-04-12 23:57:38 +00:00
|
|
|
id: ast::DUMMY_NODE_ID,
|
|
|
|
span: DUMMY_SP,
|
2018-06-01 22:23:48 +00:00
|
|
|
name: hir::LifetimeName::Param(name),
|
2018-02-23 17:48:54 +00:00
|
|
|
}));
|
2018-04-12 23:57:38 +00:00
|
|
|
}
|
2018-05-16 10:03:04 +00:00
|
|
|
ty::GenericParamDefKind::Type {..} => {
|
2018-02-23 17:48:54 +00:00
|
|
|
args.push(hir::GenericArg::Type(P(self.ty_param_to_ty(param.clone()))));
|
2018-04-12 23:57:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
|
2018-02-23 17:48:54 +00:00
|
|
|
hir::GenericArgs {
|
|
|
|
args: HirVec::from_vec(args),
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
bindings: HirVec::new(),
|
|
|
|
parenthesized: false,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-04-18 23:40:22 +00:00
|
|
|
fn ty_param_to_ty(&self, param: ty::GenericParamDef) -> hir::Ty {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
debug!("ty_param_to_ty({:?}) {:?}", param, param.def_id);
|
|
|
|
hir::Ty {
|
|
|
|
id: ast::DUMMY_NODE_ID,
|
|
|
|
node: hir::Ty_::TyPath(hir::QPath::Resolved(
|
|
|
|
None,
|
|
|
|
P(hir::Path {
|
|
|
|
span: DUMMY_SP,
|
|
|
|
def: Def::TyParam(param.def_id),
|
2018-04-03 14:18:13 +00:00
|
|
|
segments: HirVec::from_vec(vec![
|
2018-04-11 21:02:41 +00:00
|
|
|
hir::PathSegment::from_name(param.name.as_symbol())
|
2018-04-03 14:18:13 +00:00
|
|
|
]),
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}),
|
|
|
|
)),
|
|
|
|
span: DUMMY_SP,
|
|
|
|
hir_id: hir::DUMMY_HIR_ID,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn find_auto_trait_generics(
|
|
|
|
&self,
|
|
|
|
did: DefId,
|
|
|
|
trait_did: DefId,
|
|
|
|
generics: &ty::Generics,
|
|
|
|
) -> AutoTraitResult {
|
2018-04-05 18:10:15 +00:00
|
|
|
match self.f.find_auto_trait_generics(did, trait_did, generics,
|
|
|
|
|infcx, mut info| {
|
|
|
|
let region_data = info.region_data;
|
|
|
|
let names_map =
|
|
|
|
info.names_map
|
|
|
|
.drain()
|
2018-04-15 13:47:56 +00:00
|
|
|
.map(|name| (name.clone(), Lifetime(name)))
|
2018-04-05 18:10:15 +00:00
|
|
|
.collect();
|
|
|
|
let lifetime_predicates =
|
|
|
|
self.handle_lifetimes(®ion_data, &names_map);
|
|
|
|
let new_generics = self.param_env_to_generics(
|
|
|
|
infcx.tcx,
|
|
|
|
did,
|
|
|
|
info.full_user_env,
|
|
|
|
generics.clone(),
|
|
|
|
lifetime_predicates,
|
|
|
|
info.vid_to_region,
|
|
|
|
);
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
|
|
|
|
debug!(
|
|
|
|
"find_auto_trait_generics(did={:?}, trait_did={:?}, generics={:?}): \
|
2018-04-05 18:10:15 +00:00
|
|
|
finished with {:?}",
|
|
|
|
did, trait_did, generics, new_generics
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
);
|
|
|
|
|
2018-04-05 18:10:15 +00:00
|
|
|
new_generics
|
|
|
|
}) {
|
|
|
|
auto::AutoTraitResult::ExplicitImpl => AutoTraitResult::ExplicitImpl,
|
|
|
|
auto::AutoTraitResult::NegativeImpl => AutoTraitResult::NegativeImpl,
|
|
|
|
auto::AutoTraitResult::PositiveImpl(res) => AutoTraitResult::PositiveImpl(res),
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
fn get_lifetime(&self, region: Region, names_map: &FxHashMap<String, Lifetime>) -> Lifetime {
|
|
|
|
self.region_name(region)
|
|
|
|
.map(|name| {
|
|
|
|
names_map.get(&name).unwrap_or_else(|| {
|
|
|
|
panic!("Missing lifetime with name {:?} for {:?}", name, region)
|
|
|
|
})
|
|
|
|
})
|
|
|
|
.unwrap_or(&Lifetime::statik())
|
|
|
|
.clone()
|
|
|
|
}
|
|
|
|
|
|
|
|
fn region_name(&self, region: Region) -> Option<String> {
|
|
|
|
match region {
|
2018-04-12 20:16:26 +00:00
|
|
|
&ty::ReEarlyBound(r) => Some(r.name.to_string()),
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
_ => None,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// This method calculates two things: Lifetime constraints of the form 'a: 'b,
|
|
|
|
// and region constraints of the form ReVar: 'a
|
|
|
|
//
|
|
|
|
// This is essentially a simplified version of lexical_region_resolve. However,
|
|
|
|
// handle_lifetimes determines what *needs be* true in order for an impl to hold.
|
|
|
|
// lexical_region_resolve, along with much of the rest of the compiler, is concerned
|
|
|
|
// with determining if a given set up constraints/predicates *are* met, given some
|
|
|
|
// starting conditions (e.g. user-provided code). For this reason, it's easier
|
|
|
|
// to perform the calculations we need on our own, rather than trying to make
|
2018-02-10 19:34:46 +00:00
|
|
|
// existing inference/solver code do what we want.
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
fn handle_lifetimes<'cx>(
|
|
|
|
&self,
|
|
|
|
regions: &RegionConstraintData<'cx>,
|
|
|
|
names_map: &FxHashMap<String, Lifetime>,
|
|
|
|
) -> Vec<WherePredicate> {
|
|
|
|
// Our goal is to 'flatten' the list of constraints by eliminating
|
|
|
|
// all intermediate RegionVids. At the end, all constraints should
|
|
|
|
// be between Regions (aka region variables). This gives us the information
|
2018-02-10 19:34:46 +00:00
|
|
|
// we need to create the Generics.
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
let mut finished = FxHashMap();
|
|
|
|
|
|
|
|
let mut vid_map: FxHashMap<RegionTarget, RegionDeps> = FxHashMap();
|
|
|
|
|
|
|
|
// Flattening is done in two parts. First, we insert all of the constraints
|
|
|
|
// into a map. Each RegionTarget (either a RegionVid or a Region) maps
|
|
|
|
// to its smaller and larger regions. Note that 'larger' regions correspond
|
|
|
|
// to sub-regions in Rust code (e.g. in 'a: 'b, 'a is the larger region).
|
|
|
|
for constraint in regions.constraints.keys() {
|
|
|
|
match constraint {
|
|
|
|
&Constraint::VarSubVar(r1, r2) => {
|
|
|
|
{
|
|
|
|
let deps1 = vid_map
|
|
|
|
.entry(RegionTarget::RegionVid(r1))
|
|
|
|
.or_insert_with(|| Default::default());
|
|
|
|
deps1.larger.insert(RegionTarget::RegionVid(r2));
|
|
|
|
}
|
|
|
|
|
|
|
|
let deps2 = vid_map
|
|
|
|
.entry(RegionTarget::RegionVid(r2))
|
|
|
|
.or_insert_with(|| Default::default());
|
|
|
|
deps2.smaller.insert(RegionTarget::RegionVid(r1));
|
|
|
|
}
|
|
|
|
&Constraint::RegSubVar(region, vid) => {
|
|
|
|
let deps = vid_map
|
|
|
|
.entry(RegionTarget::RegionVid(vid))
|
|
|
|
.or_insert_with(|| Default::default());
|
|
|
|
deps.smaller.insert(RegionTarget::Region(region));
|
|
|
|
}
|
|
|
|
&Constraint::VarSubReg(vid, region) => {
|
|
|
|
let deps = vid_map
|
|
|
|
.entry(RegionTarget::RegionVid(vid))
|
|
|
|
.or_insert_with(|| Default::default());
|
|
|
|
deps.larger.insert(RegionTarget::Region(region));
|
|
|
|
}
|
|
|
|
&Constraint::RegSubReg(r1, r2) => {
|
|
|
|
// The constraint is already in the form that we want, so we're done with it
|
|
|
|
// Desired order is 'larger, smaller', so flip then
|
|
|
|
if self.region_name(r1) != self.region_name(r2) {
|
|
|
|
finished
|
|
|
|
.entry(self.region_name(r2).unwrap())
|
|
|
|
.or_insert_with(|| Vec::new())
|
|
|
|
.push(r1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Here, we 'flatten' the map one element at a time.
|
|
|
|
// All of the element's sub and super regions are connected
|
|
|
|
// to each other. For example, if we have a graph that looks like this:
|
|
|
|
//
|
|
|
|
// (A, B) - C - (D, E)
|
|
|
|
// Where (A, B) are subregions, and (D,E) are super-regions
|
|
|
|
//
|
|
|
|
// then after deleting 'C', the graph will look like this:
|
|
|
|
// ... - A - (D, E ...)
|
|
|
|
// ... - B - (D, E, ...)
|
|
|
|
// (A, B, ...) - D - ...
|
|
|
|
// (A, B, ...) - E - ...
|
|
|
|
//
|
|
|
|
// where '...' signifies the existing sub and super regions of an entry
|
|
|
|
// When two adjacent ty::Regions are encountered, we've computed a final
|
|
|
|
// constraint, and add it to our list. Since we make sure to never re-add
|
|
|
|
// deleted items, this process will always finish.
|
|
|
|
while !vid_map.is_empty() {
|
|
|
|
let target = vid_map.keys().next().expect("Keys somehow empty").clone();
|
|
|
|
let deps = vid_map.remove(&target).expect("Entry somehow missing");
|
|
|
|
|
|
|
|
for smaller in deps.smaller.iter() {
|
|
|
|
for larger in deps.larger.iter() {
|
|
|
|
match (smaller, larger) {
|
|
|
|
(&RegionTarget::Region(r1), &RegionTarget::Region(r2)) => {
|
|
|
|
if self.region_name(r1) != self.region_name(r2) {
|
|
|
|
finished
|
|
|
|
.entry(self.region_name(r2).unwrap())
|
|
|
|
.or_insert_with(|| Vec::new())
|
|
|
|
.push(r1) // Larger, smaller
|
|
|
|
}
|
|
|
|
}
|
|
|
|
(&RegionTarget::RegionVid(_), &RegionTarget::Region(_)) => {
|
|
|
|
if let Entry::Occupied(v) = vid_map.entry(*smaller) {
|
|
|
|
let smaller_deps = v.into_mut();
|
|
|
|
smaller_deps.larger.insert(*larger);
|
|
|
|
smaller_deps.larger.remove(&target);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
(&RegionTarget::Region(_), &RegionTarget::RegionVid(_)) => {
|
|
|
|
if let Entry::Occupied(v) = vid_map.entry(*larger) {
|
|
|
|
let deps = v.into_mut();
|
|
|
|
deps.smaller.insert(*smaller);
|
|
|
|
deps.smaller.remove(&target);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
(&RegionTarget::RegionVid(_), &RegionTarget::RegionVid(_)) => {
|
|
|
|
if let Entry::Occupied(v) = vid_map.entry(*smaller) {
|
|
|
|
let smaller_deps = v.into_mut();
|
|
|
|
smaller_deps.larger.insert(*larger);
|
|
|
|
smaller_deps.larger.remove(&target);
|
|
|
|
}
|
|
|
|
|
|
|
|
if let Entry::Occupied(v) = vid_map.entry(*larger) {
|
|
|
|
let larger_deps = v.into_mut();
|
|
|
|
larger_deps.smaller.insert(*smaller);
|
|
|
|
larger_deps.smaller.remove(&target);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
let lifetime_predicates = names_map
|
|
|
|
.iter()
|
|
|
|
.flat_map(|(name, lifetime)| {
|
|
|
|
let empty = Vec::new();
|
2018-06-14 11:08:58 +00:00
|
|
|
let bounds: FxHashSet<GenericBound> = finished.get(name).unwrap_or(&empty).iter()
|
|
|
|
.map(|region| GenericBound::Outlives(self.get_lifetime(region, names_map)))
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
.collect();
|
|
|
|
|
|
|
|
if bounds.is_empty() {
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
Some(WherePredicate::RegionPredicate {
|
|
|
|
lifetime: lifetime.clone(),
|
|
|
|
bounds: bounds.into_iter().collect(),
|
|
|
|
})
|
|
|
|
})
|
|
|
|
.collect();
|
|
|
|
|
|
|
|
lifetime_predicates
|
|
|
|
}
|
|
|
|
|
|
|
|
fn extract_for_generics<'b, 'c, 'd>(
|
|
|
|
&self,
|
|
|
|
tcx: TyCtxt<'b, 'c, 'd>,
|
|
|
|
pred: ty::Predicate<'d>,
|
2018-04-12 16:53:29 +00:00
|
|
|
) -> FxHashSet<GenericParamDef> {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
pred.walk_tys()
|
|
|
|
.flat_map(|t| {
|
|
|
|
let mut regions = FxHashSet();
|
|
|
|
tcx.collect_regions(&t, &mut regions);
|
|
|
|
|
|
|
|
regions.into_iter().flat_map(|r| {
|
|
|
|
match r {
|
|
|
|
// We only care about late bound regions, as we need to add them
|
|
|
|
// to the 'for<>' section
|
|
|
|
&ty::ReLateBound(_, ty::BoundRegion::BrNamed(_, name)) => {
|
2018-05-27 15:56:01 +00:00
|
|
|
Some(GenericParamDef {
|
|
|
|
name: name.to_string(),
|
|
|
|
kind: GenericParamDefKind::Lifetime,
|
|
|
|
})
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
&ty::ReVar(_) | &ty::ReEarlyBound(_) => None,
|
|
|
|
_ => panic!("Unexpected region type {:?}", r),
|
|
|
|
}
|
|
|
|
})
|
|
|
|
})
|
|
|
|
.collect()
|
|
|
|
}
|
|
|
|
|
|
|
|
fn make_final_bounds<'b, 'c, 'cx>(
|
|
|
|
&self,
|
2018-06-14 11:08:58 +00:00
|
|
|
ty_to_bounds: FxHashMap<Type, FxHashSet<GenericBound>>,
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
ty_to_fn: FxHashMap<Type, (Option<PolyTrait>, Option<Type>)>,
|
2018-06-14 11:08:58 +00:00
|
|
|
lifetime_to_bounds: FxHashMap<Lifetime, FxHashSet<GenericBound>>,
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
) -> Vec<WherePredicate> {
|
2018-02-10 19:34:46 +00:00
|
|
|
ty_to_bounds
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
.into_iter()
|
|
|
|
.flat_map(|(ty, mut bounds)| {
|
|
|
|
if let Some(data) = ty_to_fn.get(&ty) {
|
|
|
|
let (poly_trait, output) =
|
|
|
|
(data.0.as_ref().unwrap().clone(), data.1.as_ref().cloned());
|
|
|
|
let new_ty = match &poly_trait.trait_ {
|
|
|
|
&Type::ResolvedPath {
|
|
|
|
ref path,
|
|
|
|
ref typarams,
|
|
|
|
ref did,
|
|
|
|
ref is_generic,
|
|
|
|
} => {
|
|
|
|
let mut new_path = path.clone();
|
|
|
|
let last_segment = new_path.segments.pop().unwrap();
|
|
|
|
|
2018-02-23 17:48:54 +00:00
|
|
|
let (old_input, old_output) = match last_segment.args {
|
|
|
|
GenericArgs::AngleBracketed { types, .. } => (types, None),
|
|
|
|
GenericArgs::Parenthesized { inputs, output, .. } => {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
(inputs, output)
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
if old_output.is_some() && old_output != output {
|
|
|
|
panic!(
|
|
|
|
"Output mismatch for {:?} {:?} {:?}",
|
|
|
|
ty, old_output, data.1
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2018-02-23 17:48:54 +00:00
|
|
|
let new_params = GenericArgs::Parenthesized {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
inputs: old_input,
|
|
|
|
output,
|
|
|
|
};
|
|
|
|
|
|
|
|
new_path.segments.push(PathSegment {
|
|
|
|
name: last_segment.name,
|
2018-02-23 17:48:54 +00:00
|
|
|
args: new_params,
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
});
|
|
|
|
|
|
|
|
Type::ResolvedPath {
|
|
|
|
path: new_path,
|
|
|
|
typarams: typarams.clone(),
|
|
|
|
did: did.clone(),
|
|
|
|
is_generic: *is_generic,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_ => panic!("Unexpected data: {:?}, {:?}", ty, data),
|
|
|
|
};
|
2018-06-14 11:08:58 +00:00
|
|
|
bounds.insert(GenericBound::TraitBound(
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
PolyTrait {
|
|
|
|
trait_: new_ty,
|
|
|
|
generic_params: poly_trait.generic_params,
|
|
|
|
},
|
|
|
|
hir::TraitBoundModifier::None,
|
|
|
|
));
|
|
|
|
}
|
|
|
|
if bounds.is_empty() {
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
2018-03-20 03:35:23 +00:00
|
|
|
let mut bounds_vec = bounds.into_iter().collect();
|
|
|
|
self.sort_where_bounds(&mut bounds_vec);
|
|
|
|
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
Some(WherePredicate::BoundPredicate {
|
|
|
|
ty,
|
2018-03-20 03:35:23 +00:00
|
|
|
bounds: bounds_vec,
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
})
|
|
|
|
})
|
|
|
|
.chain(
|
|
|
|
lifetime_to_bounds
|
|
|
|
.into_iter()
|
|
|
|
.filter(|&(_, ref bounds)| !bounds.is_empty())
|
2018-03-20 03:35:23 +00:00
|
|
|
.map(|(lifetime, bounds)| {
|
|
|
|
let mut bounds_vec = bounds.into_iter().collect();
|
2018-05-28 14:23:16 +00:00
|
|
|
self.sort_where_bounds(&mut bounds_vec);
|
2018-03-20 03:35:23 +00:00
|
|
|
WherePredicate::RegionPredicate {
|
|
|
|
lifetime,
|
|
|
|
bounds: bounds_vec,
|
|
|
|
}
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}),
|
|
|
|
)
|
2018-02-10 19:34:46 +00:00
|
|
|
.collect()
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Converts the calculated ParamEnv and lifetime information to a clean::Generics, suitable for
|
|
|
|
// display on the docs page. Cleaning the Predicates produces sub-optimal WherePredicate's,
|
|
|
|
// so we fix them up:
|
|
|
|
//
|
|
|
|
// * Multiple bounds for the same type are coalesced into one: e.g. 'T: Copy', 'T: Debug'
|
|
|
|
// becomes 'T: Copy + Debug'
|
|
|
|
// * Fn bounds are handled specially - instead of leaving it as 'T: Fn(), <T as Fn::Output> =
|
|
|
|
// K', we use the dedicated syntax 'T: Fn() -> K'
|
|
|
|
// * We explcitly add a '?Sized' bound if we didn't find any 'Sized' predicates for a type
|
|
|
|
fn param_env_to_generics<'b, 'c, 'cx>(
|
|
|
|
&self,
|
|
|
|
tcx: TyCtxt<'b, 'c, 'cx>,
|
|
|
|
did: DefId,
|
|
|
|
param_env: ty::ParamEnv<'cx>,
|
|
|
|
type_generics: ty::Generics,
|
|
|
|
mut existing_predicates: Vec<WherePredicate>,
|
|
|
|
vid_to_region: FxHashMap<ty::RegionVid, ty::Region<'cx>>,
|
|
|
|
) -> Generics {
|
|
|
|
debug!(
|
|
|
|
"param_env_to_generics(did={:?}, param_env={:?}, type_generics={:?}, \
|
|
|
|
existing_predicates={:?})",
|
|
|
|
did, param_env, type_generics, existing_predicates
|
|
|
|
);
|
|
|
|
|
|
|
|
// The `Sized` trait must be handled specially, since we only only display it when
|
|
|
|
// it is *not* required (i.e. '?Sized')
|
|
|
|
let sized_trait = self.cx
|
|
|
|
.tcx
|
|
|
|
.require_lang_item(lang_items::SizedTraitLangItem);
|
|
|
|
|
|
|
|
let mut replacer = RegionReplacer {
|
|
|
|
vid_to_region: &vid_to_region,
|
|
|
|
tcx,
|
|
|
|
};
|
|
|
|
|
|
|
|
let orig_bounds: FxHashSet<_> = self.cx.tcx.param_env(did).caller_bounds.iter().collect();
|
|
|
|
let clean_where_predicates = param_env
|
|
|
|
.caller_bounds
|
|
|
|
.iter()
|
|
|
|
.filter(|p| {
|
|
|
|
!orig_bounds.contains(p) || match p {
|
|
|
|
&&ty::Predicate::Trait(pred) => pred.def_id() == sized_trait,
|
|
|
|
_ => false,
|
|
|
|
}
|
|
|
|
})
|
|
|
|
.map(|p| {
|
|
|
|
let replaced = p.fold_with(&mut replacer);
|
|
|
|
(replaced.clone(), replaced.clean(self.cx))
|
|
|
|
});
|
|
|
|
|
|
|
|
let full_generics = (&type_generics, &tcx.predicates_of(did));
|
|
|
|
let Generics {
|
|
|
|
params: mut generic_params,
|
|
|
|
..
|
|
|
|
} = full_generics.clean(self.cx);
|
|
|
|
|
|
|
|
let mut has_sized = FxHashSet();
|
|
|
|
let mut ty_to_bounds = FxHashMap();
|
|
|
|
let mut lifetime_to_bounds = FxHashMap();
|
|
|
|
let mut ty_to_traits: FxHashMap<Type, FxHashSet<Type>> = FxHashMap();
|
|
|
|
|
|
|
|
let mut ty_to_fn: FxHashMap<Type, (Option<PolyTrait>, Option<Type>)> = FxHashMap();
|
|
|
|
|
|
|
|
for (orig_p, p) in clean_where_predicates {
|
|
|
|
match p {
|
|
|
|
WherePredicate::BoundPredicate { ty, mut bounds } => {
|
|
|
|
// Writing a projection trait bound of the form
|
|
|
|
// <T as Trait>::Name : ?Sized
|
|
|
|
// is illegal, because ?Sized bounds can only
|
|
|
|
// be written in the (here, nonexistant) definition
|
|
|
|
// of the type.
|
|
|
|
// Therefore, we make sure that we never add a ?Sized
|
|
|
|
// bound for projections
|
|
|
|
match &ty {
|
|
|
|
&Type::QPath { .. } => {
|
|
|
|
has_sized.insert(ty.clone());
|
|
|
|
}
|
|
|
|
_ => {}
|
|
|
|
}
|
|
|
|
|
|
|
|
if bounds.is_empty() {
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
let mut for_generics = self.extract_for_generics(tcx, orig_p.clone());
|
|
|
|
|
|
|
|
assert!(bounds.len() == 1);
|
|
|
|
let mut b = bounds.pop().unwrap();
|
|
|
|
|
|
|
|
if b.is_sized_bound(self.cx) {
|
|
|
|
has_sized.insert(ty.clone());
|
|
|
|
} else if !b.get_trait_type()
|
|
|
|
.and_then(|t| {
|
|
|
|
ty_to_traits
|
|
|
|
.get(&ty)
|
|
|
|
.map(|bounds| bounds.contains(&strip_type(t.clone())))
|
|
|
|
})
|
|
|
|
.unwrap_or(false)
|
|
|
|
{
|
|
|
|
// If we've already added a projection bound for the same type, don't add
|
|
|
|
// this, as it would be a duplicate
|
|
|
|
|
|
|
|
// Handle any 'Fn/FnOnce/FnMut' bounds specially,
|
|
|
|
// as we want to combine them with any 'Output' qpaths
|
|
|
|
// later
|
|
|
|
|
|
|
|
let is_fn = match &mut b {
|
2018-06-14 11:08:58 +00:00
|
|
|
&mut GenericBound::TraitBound(ref mut p, _) => {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
// Insert regions into the for_generics hash map first, to ensure
|
|
|
|
// that we don't end up with duplicate bounds (e.g. for<'b, 'b>)
|
|
|
|
for_generics.extend(p.generic_params.clone());
|
|
|
|
p.generic_params = for_generics.into_iter().collect();
|
|
|
|
self.is_fn_ty(&tcx, &p.trait_)
|
|
|
|
}
|
|
|
|
_ => false,
|
|
|
|
};
|
|
|
|
|
|
|
|
let poly_trait = b.get_poly_trait().unwrap();
|
|
|
|
|
|
|
|
if is_fn {
|
|
|
|
ty_to_fn
|
|
|
|
.entry(ty.clone())
|
|
|
|
.and_modify(|e| *e = (Some(poly_trait.clone()), e.1.clone()))
|
|
|
|
.or_insert(((Some(poly_trait.clone())), None));
|
|
|
|
|
|
|
|
ty_to_bounds
|
|
|
|
.entry(ty.clone())
|
|
|
|
.or_insert_with(|| FxHashSet());
|
|
|
|
} else {
|
|
|
|
ty_to_bounds
|
|
|
|
.entry(ty.clone())
|
|
|
|
.or_insert_with(|| FxHashSet())
|
|
|
|
.insert(b.clone());
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
WherePredicate::RegionPredicate { lifetime, bounds } => {
|
|
|
|
lifetime_to_bounds
|
|
|
|
.entry(lifetime)
|
|
|
|
.or_insert_with(|| FxHashSet())
|
|
|
|
.extend(bounds);
|
|
|
|
}
|
|
|
|
WherePredicate::EqPredicate { lhs, rhs } => {
|
|
|
|
match &lhs {
|
|
|
|
&Type::QPath {
|
|
|
|
name: ref left_name,
|
|
|
|
ref self_type,
|
|
|
|
ref trait_,
|
|
|
|
} => {
|
|
|
|
let ty = &*self_type;
|
|
|
|
match **trait_ {
|
|
|
|
Type::ResolvedPath {
|
|
|
|
path: ref trait_path,
|
|
|
|
ref typarams,
|
|
|
|
ref did,
|
|
|
|
ref is_generic,
|
|
|
|
} => {
|
|
|
|
let mut new_trait_path = trait_path.clone();
|
|
|
|
|
|
|
|
if self.is_fn_ty(&tcx, trait_) && left_name == FN_OUTPUT_NAME {
|
|
|
|
ty_to_fn
|
|
|
|
.entry(*ty.clone())
|
|
|
|
.and_modify(|e| *e = (e.0.clone(), Some(rhs.clone())))
|
|
|
|
.or_insert((None, Some(rhs)));
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
// FIXME: Remove this scope when NLL lands
|
|
|
|
{
|
2018-02-23 17:48:54 +00:00
|
|
|
let args =
|
|
|
|
&mut new_trait_path.segments.last_mut().unwrap().args;
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
|
2018-02-23 17:48:54 +00:00
|
|
|
match args {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
// Convert somethiung like '<T as Iterator::Item> = u8'
|
|
|
|
// to 'T: Iterator<Item=u8>'
|
2018-02-23 17:48:54 +00:00
|
|
|
&mut GenericArgs::AngleBracketed {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
ref mut bindings,
|
|
|
|
..
|
|
|
|
} => {
|
|
|
|
bindings.push(TypeBinding {
|
|
|
|
name: left_name.clone(),
|
|
|
|
ty: rhs,
|
|
|
|
});
|
|
|
|
}
|
2018-02-23 17:48:54 +00:00
|
|
|
&mut GenericArgs::Parenthesized { .. } => {
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
existing_predicates.push(
|
|
|
|
WherePredicate::EqPredicate {
|
|
|
|
lhs: lhs.clone(),
|
|
|
|
rhs,
|
|
|
|
},
|
|
|
|
);
|
|
|
|
continue; // If something other than a Fn ends up
|
|
|
|
// with parenthesis, leave it alone
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
let bounds = ty_to_bounds
|
|
|
|
.entry(*ty.clone())
|
|
|
|
.or_insert_with(|| FxHashSet());
|
|
|
|
|
2018-06-14 11:08:58 +00:00
|
|
|
bounds.insert(GenericBound::TraitBound(
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
PolyTrait {
|
|
|
|
trait_: Type::ResolvedPath {
|
|
|
|
path: new_trait_path,
|
|
|
|
typarams: typarams.clone(),
|
|
|
|
did: did.clone(),
|
|
|
|
is_generic: *is_generic,
|
|
|
|
},
|
|
|
|
generic_params: Vec::new(),
|
|
|
|
},
|
|
|
|
hir::TraitBoundModifier::None,
|
|
|
|
));
|
|
|
|
|
|
|
|
// Remove any existing 'plain' bound (e.g. 'T: Iterator`) so
|
|
|
|
// that we don't see a
|
|
|
|
// duplicate bound like `T: Iterator + Iterator<Item=u8>`
|
|
|
|
// on the docs page.
|
2018-06-14 11:08:58 +00:00
|
|
|
bounds.remove(&GenericBound::TraitBound(
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
PolyTrait {
|
|
|
|
trait_: *trait_.clone(),
|
|
|
|
generic_params: Vec::new(),
|
|
|
|
},
|
|
|
|
hir::TraitBoundModifier::None,
|
|
|
|
));
|
|
|
|
// Avoid creating any new duplicate bounds later in the outer
|
|
|
|
// loop
|
|
|
|
ty_to_traits
|
|
|
|
.entry(*ty.clone())
|
|
|
|
.or_insert_with(|| FxHashSet())
|
|
|
|
.insert(*trait_.clone());
|
|
|
|
}
|
|
|
|
_ => panic!("Unexpected trait {:?} for {:?}", trait_, did),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
_ => panic!("Unexpected LHS {:?} for {:?}", lhs, did),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
}
|
|
|
|
|
|
|
|
let final_bounds = self.make_final_bounds(ty_to_bounds, ty_to_fn, lifetime_to_bounds);
|
|
|
|
|
|
|
|
existing_predicates.extend(final_bounds);
|
|
|
|
|
2018-05-27 15:56:01 +00:00
|
|
|
for param in generic_params.iter_mut() {
|
|
|
|
match param.kind {
|
|
|
|
GenericParamDefKind::Type { ref mut default, ref mut bounds, .. } => {
|
|
|
|
// We never want something like `impl<T=Foo>`.
|
|
|
|
default.take();
|
|
|
|
let generic_ty = Type::Generic(param.name.clone());
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
if !has_sized.contains(&generic_ty) {
|
2018-06-14 11:08:58 +00:00
|
|
|
bounds.insert(0, GenericBound::maybe_sized(self.cx));
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
}
|
2018-05-27 15:56:01 +00:00
|
|
|
GenericParamDefKind::Lifetime => {}
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-20 01:27:28 +00:00
|
|
|
self.sort_where_predicates(&mut existing_predicates);
|
|
|
|
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
Generics {
|
|
|
|
params: generic_params,
|
|
|
|
where_predicates: existing_predicates,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2018-02-20 01:27:28 +00:00
|
|
|
// Ensure that the predicates are in a consistent order. The precise
|
|
|
|
// ordering doesn't actually matter, but it's important that
|
|
|
|
// a given set of predicates always appears in the same order -
|
|
|
|
// both for visual consistency between 'rustdoc' runs, and to
|
|
|
|
// make writing tests much easier
|
2018-03-20 03:35:23 +00:00
|
|
|
#[inline]
|
|
|
|
fn sort_where_predicates(&self, mut predicates: &mut Vec<WherePredicate>) {
|
2018-02-20 01:27:28 +00:00
|
|
|
// We should never have identical bounds - and if we do,
|
|
|
|
// they're visually identical as well. Therefore, using
|
|
|
|
// an unstable sort is fine.
|
2018-03-20 03:35:23 +00:00
|
|
|
self.unstable_debug_sort(&mut predicates);
|
|
|
|
}
|
2018-03-20 05:02:15 +00:00
|
|
|
|
2018-03-20 03:35:23 +00:00
|
|
|
// Ensure that the bounds are in a consistent order. The precise
|
|
|
|
// ordering doesn't actually matter, but it's important that
|
|
|
|
// a given set of bounds always appears in the same order -
|
|
|
|
// both for visual consistency between 'rustdoc' runs, and to
|
|
|
|
// make writing tests much easier
|
|
|
|
#[inline]
|
2018-06-14 11:08:58 +00:00
|
|
|
fn sort_where_bounds(&self, mut bounds: &mut Vec<GenericBound>) {
|
2018-03-20 03:35:23 +00:00
|
|
|
// We should never have identical bounds - and if we do,
|
|
|
|
// they're visually identical as well. Therefore, using
|
|
|
|
// an unstable sort is fine.
|
|
|
|
self.unstable_debug_sort(&mut bounds);
|
|
|
|
}
|
|
|
|
|
|
|
|
// This might look horrendously hacky, but it's actually not that bad.
|
|
|
|
//
|
|
|
|
// For performance reasons, we use several different FxHashMaps
|
|
|
|
// in the process of computing the final set of where predicates.
|
|
|
|
// However, the iteration order of a HashMap is completely unspecified.
|
|
|
|
// In fact, the iteration of an FxHashMap can even vary between platforms,
|
|
|
|
// since FxHasher has different behavior for 32-bit and 64-bit platforms.
|
|
|
|
//
|
|
|
|
// Obviously, it's extremely undesireable for documentation rendering
|
|
|
|
// to be depndent on the platform it's run on. Apart from being confusing
|
|
|
|
// to end users, it makes writing tests much more difficult, as predicates
|
|
|
|
// can appear in any order in the final result.
|
|
|
|
//
|
2018-06-14 11:08:58 +00:00
|
|
|
// To solve this problem, we sort WherePredicates and GenericBounds
|
2018-03-20 03:35:23 +00:00
|
|
|
// by their Debug string. The thing to keep in mind is that we don't really
|
|
|
|
// care what the final order is - we're synthesizing an impl or bound
|
|
|
|
// ourselves, so any order can be considered equally valid. By sorting the
|
|
|
|
// predicates and bounds, however, we ensure that for a given codebase, all
|
|
|
|
// auto-trait impls always render in exactly the same way.
|
|
|
|
//
|
|
|
|
// Using the Debug impementation for sorting prevents us from needing to
|
|
|
|
// write quite a bit of almost entirely useless code (e.g. how should two
|
|
|
|
// Types be sorted relative to each other). It also allows us to solve the
|
2018-06-14 11:08:58 +00:00
|
|
|
// problem for both WherePredicates and GenericBounds at the same time. This
|
2018-03-20 03:35:23 +00:00
|
|
|
// approach is probably somewhat slower, but the small number of items
|
|
|
|
// involved (impls rarely have more than a few bounds) means that it
|
|
|
|
// shouldn't matter in practice.
|
|
|
|
fn unstable_debug_sort<T: Debug>(&self, vec: &mut Vec<T>) {
|
2018-03-30 09:44:12 +00:00
|
|
|
vec.sort_by_cached_key(|x| format!("{:?}", x))
|
2018-02-20 01:27:28 +00:00
|
|
|
}
|
|
|
|
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
fn is_fn_ty(&self, tcx: &TyCtxt, ty: &Type) -> bool {
|
|
|
|
match &ty {
|
|
|
|
&&Type::ResolvedPath { ref did, .. } => {
|
|
|
|
*did == tcx.require_lang_item(lang_items::FnTraitLangItem)
|
|
|
|
|| *did == tcx.require_lang_item(lang_items::FnMutTraitLangItem)
|
|
|
|
|| *did == tcx.require_lang_item(lang_items::FnOnceTraitLangItem)
|
|
|
|
}
|
|
|
|
_ => false,
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// This is an ugly hack, but it's the simplest way to handle synthetic impls without greatly
|
2018-02-10 19:34:46 +00:00
|
|
|
// refactoring either librustdoc or librustc. In particular, allowing new DefIds to be
|
Generate documentation for auto-trait impls
A new section is added to both both struct and trait doc pages.
On struct/enum pages, a new 'Auto Trait Implementations' section displays any
synthetic implementations for auto traits. Currently, this is only done
for Send and Sync.
On trait pages, a new 'Auto Implementors' section displays all types
which automatically implement the trait. Effectively, this is a list of
all public types in the standard library.
Synthesized impls for a particular auto trait ('synthetic impls') take
into account generic bounds. For example, a type 'struct Foo<T>(T)' will
have 'impl<T> Send for Foo<T> where T: Send' generated for it.
Manual implementations of auto traits are also taken into account. If we have
the following types:
'struct Foo<T>(T)'
'struct Wrapper<T>(Foo<T>)'
'unsafe impl<T> Send for Wrapper<T>' // pretend that Wrapper<T> makes
this sound somehow
Then Wrapper will have the following impl generated:
'impl<T> Send for Wrapper<T>'
reflecting the fact that 'T: Send' need not hold for 'Wrapper<T>: Send'
to hold
Lifetimes, HRTBS, and projections (e.g. '<T as Iterator>::Item') are
taken into account by synthetic impls
However, if a type can *never* implement a particular auto trait
(e.g. 'struct MyStruct<T>(*const T)'), then a negative impl will be
generated (in this case, 'impl<T> !Send for MyStruct<T>')
All of this means that a user should be able to copy-paste a synthetic
impl into their code, without any observable changes in behavior
(assuming the rest of the program remains unchanged).
2017-11-22 21:16:55 +00:00
|
|
|
// registered after the AST is constructed would require storing the defid mapping in a
|
|
|
|
// RefCell, decreasing the performance for normal compilation for very little gain.
|
|
|
|
//
|
|
|
|
// Instead, we construct 'fake' def ids, which start immediately after the last DefId in
|
|
|
|
// DefIndexAddressSpace::Low. In the Debug impl for clean::Item, we explicitly check for fake
|
|
|
|
// def ids, as we'll end up with a panic if we use the DefId Debug impl for fake DefIds
|
|
|
|
fn next_def_id(&self, crate_num: CrateNum) -> DefId {
|
|
|
|
let start_def_id = {
|
|
|
|
let next_id = if crate_num == LOCAL_CRATE {
|
|
|
|
self.cx
|
|
|
|
.tcx
|
|
|
|
.hir
|
|
|
|
.definitions()
|
|
|
|
.def_path_table()
|
|
|
|
.next_id(DefIndexAddressSpace::Low)
|
|
|
|
} else {
|
|
|
|
self.cx
|
|
|
|
.cstore
|
|
|
|
.def_path_table(crate_num)
|
|
|
|
.next_id(DefIndexAddressSpace::Low)
|
|
|
|
};
|
|
|
|
|
|
|
|
DefId {
|
|
|
|
krate: crate_num,
|
|
|
|
index: next_id,
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
let mut fake_ids = self.cx.fake_def_ids.borrow_mut();
|
|
|
|
|
|
|
|
let def_id = fake_ids.entry(crate_num).or_insert(start_def_id).clone();
|
|
|
|
fake_ids.insert(
|
|
|
|
crate_num,
|
|
|
|
DefId {
|
|
|
|
krate: crate_num,
|
|
|
|
index: DefIndex::from_array_index(
|
|
|
|
def_id.index.as_array_index() + 1,
|
|
|
|
def_id.index.address_space(),
|
|
|
|
),
|
|
|
|
},
|
|
|
|
);
|
|
|
|
|
|
|
|
MAX_DEF_ID.with(|m| {
|
|
|
|
m.borrow_mut()
|
|
|
|
.entry(def_id.krate.clone())
|
|
|
|
.or_insert(start_def_id);
|
|
|
|
});
|
|
|
|
|
|
|
|
self.cx.all_fake_def_ids.borrow_mut().insert(def_id);
|
|
|
|
|
|
|
|
def_id.clone()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Replaces all ReVars in a type with ty::Region's, using the provided map
|
|
|
|
struct RegionReplacer<'a, 'gcx: 'a + 'tcx, 'tcx: 'a> {
|
|
|
|
vid_to_region: &'a FxHashMap<ty::RegionVid, ty::Region<'tcx>>,
|
|
|
|
tcx: TyCtxt<'a, 'gcx, 'tcx>,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl<'a, 'gcx, 'tcx> TypeFolder<'gcx, 'tcx> for RegionReplacer<'a, 'gcx, 'tcx> {
|
|
|
|
fn tcx<'b>(&'b self) -> TyCtxt<'b, 'gcx, 'tcx> {
|
|
|
|
self.tcx
|
|
|
|
}
|
|
|
|
|
|
|
|
fn fold_region(&mut self, r: ty::Region<'tcx>) -> ty::Region<'tcx> {
|
|
|
|
(match r {
|
|
|
|
&ty::ReVar(vid) => self.vid_to_region.get(&vid).cloned(),
|
|
|
|
_ => None,
|
|
|
|
}).unwrap_or_else(|| r.super_fold_with(self))
|
|
|
|
}
|
|
|
|
}
|