Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
int
Rust
提交
73a4e8db
R
Rust
项目概览
int
/
Rust
大约 1 年 前同步成功
通知
1
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
DevOps
流水线
流水线任务
计划
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
R
Rust
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
DevOps
DevOps
流水线
流水线任务
计划
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
流水线任务
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
73a4e8db
编写于
9月 15, 2017
作者:
N
Niko Matsakis
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
apply various nits
上级
44e45d9f
变更
5
隐藏空白更改
内联
并排
Showing
5 changed file
with
46 addition
and
43 deletion
+46
-43
src/librustc/README.md
src/librustc/README.md
+6
-5
src/librustc/hir/README.md
src/librustc/hir/README.md
+4
-8
src/librustc/hir/mod.rs
src/librustc/hir/mod.rs
+3
-2
src/librustc/ty/README.md
src/librustc/ty/README.md
+29
-23
src/librustc/ty/context.rs
src/librustc/ty/context.rs
+4
-5
未找到文件。
src/librustc/README.md
浏览文件 @
73a4e8db
...
...
@@ -57,11 +57,12 @@ rustc_trans rustc_borrowck ... rustc_metadata
syntax_pos syntax_ext
```
The idea is that `rustc_driver`, at the top of this lattice, basically
defines the overall control-flow of the compiler. It doesn't have much
"real code", but instead ties together all of the code defined in the
other crates and defines the overall flow of execution.
The `rustc_driver` crate, at the top of this lattice, is effectively
the "main" function for the rust compiler. It doesn't have much "real
code", but instead ties together all of the code defined in the other
crates and defines the overall flow of execution. (As we transition
more and more to the [query model](ty/maps/README.md), however, the
"flow" of compilation is becoming less centrally defined.)
At the other extreme, the `rustc` crate defines the common and
pervasive data structures that all the rest of the compiler uses
...
...
src/librustc/hir/README.md
浏览文件 @
73a4e8db
...
...
@@ -45,10 +45,10 @@ The other reason to setup the representation this way is for better
integration with incremental compilation. This way, if you gain access
to a
`&hir::Item`
(e.g. for the mod
`foo`
), you do not immediately
gain access to the contents of the function
`bar()`
. Instead, you only
gain access to the
**id**
for
`bar()`
, and you must
some function to
lookup the contents of
`bar()`
given its id; this gives us a change to
observe that you accessed the data for
`bar()`
and record the
dependency.
gain access to the
**id**
for
`bar()`
, and you must
invoke some
function to lookup the contents of
`bar()`
given its id; this gives us
a chance to observe that you accessed the data for
`bar()`
and record
the
dependency.
### Identifiers in the HIR
...
...
@@ -117,7 +117,3 @@ associated with an **owner**, which is typically some kind of item
(e.g.,
`|x, y| x + y`
). You can use the HIR map to find find the body
associated with a given def-id (
`maybe_body_owned_by()`
) or to find
the owner of a body (
`body_owner_def_id()`
).
src/librustc/hir/mod.rs
浏览文件 @
73a4e8db
...
...
@@ -416,6 +416,7 @@ pub struct WhereEqPredicate {
/// The top-level data structure that stores the entire contents of
/// the crate currently being compiled.
///
/// For more details, see [the module-level README](README.md).
#[derive(Clone,
PartialEq,
Eq,
RustcEncodable,
RustcDecodable,
Debug)]
pub
struct
Crate
{
pub
module
:
Mod
,
...
...
@@ -935,9 +936,9 @@ pub struct BodyId {
/// (which is an expression), but also the argument patterns, since
/// those are something that the caller doesn't really care about.
///
///
Example:
///
# Examples
///
/// ```
rust
/// ```
/// fn foo((x, y): (u32, u32)) -> u32 {
/// x + y
/// }
...
...
src/librustc/ty/README.md
浏览文件 @
73a4e8db
...
...
@@ -21,7 +21,7 @@ tcx: TyCtxt<'a, 'gcx, 'tcx>
As you can see, the
`TyCtxt`
type takes three lifetime parameters.
These lifetimes are perhaps the most complex thing to understand about
the tcx. During
r
ust compilation, we allocate most of our memory in
the tcx. During
R
ust compilation, we allocate most of our memory in
**arenas**
, which are basically pools of memory that get freed all at
once. When you see a reference with a lifetime like
`'tcx`
or
`'gcx`
,
you know that it refers to arena-allocated data (or data that lives as
...
...
@@ -70,18 +70,24 @@ fn maybe_in_inference<'a, 'gcx, 'tcx>(tcx: TyCtxt<'a, 'gcx, 'tcx>, def_id: DefId
### Allocating and working with types
Rust types are represented using the
`ty::Ty<'tcx>`
type. This is in fact a simple type alias
for a reference with
`'tcx`
lifetime:
Rust types are represented using the
`Ty<'tcx>`
defined in the
`ty`
module (not to be confused with the
`Ty`
struct from [the HIR]). This
is in fact a simple type alias for a reference with
`'tcx`
lifetime:
```
rust
pub
type
Ty
<
'tcx
>
=
&
'tcx
TyS
<
'tcx
>
;
```
The
`TyS`
struct defines the actual details of how a type is
represented. The most interesting part of it is the
`sty`
field, which
contains an enum that lets us test what sort of type this is. For
example, it is very common to see code that tests what sort of type you have
that looks roughly like so:
[
the HIR
]:
../hir/README.md
You can basically ignore the
`TyS`
struct -- you will basically never
access it explicitly. We always pass it by reference using the
`Ty<'tcx>`
alias -- the only exception I think is to define inherent
methods on types. Instances of
`TyS`
are only ever allocated in one of
the rustc arenas (never e.g. on the stack).
One common operation on types is to
**match**
and see what kinds of
types they are. This is done by doing
`match ty.sty`
, sort of like this:
```
rust
fn
test_type
<
'tcx
>
(
ty
:
Ty
<
'tcx
>
)
{
...
...
@@ -92,10 +98,14 @@ fn test_type<'tcx>(ty: Ty<'tcx>) {
}
```
(Note though that doing such low-level tests on types during inference
can be risky, as there are may be inference variables and other things
to consider, or sometimes types are not yet known that will become
known later.).
The
`sty`
field (the origin of this name is unclear to me; perhaps
structural type?) is of type
`TypeVariants<'tcx>`
, which is an enum
definined all of the different kinds of types in the compiler.
> NB: inspecting the `sty` field on types during type inference can be
> risky, as there are may be inference variables and other things to
> consider, or sometimes types are not yet known that will become
> known later.).
To allocate a new type, you can use the various
`mk_`
methods defined
on the
`tcx`
. These have names that correpond mostly to the various kinds
...
...
@@ -114,13 +124,13 @@ any inference variables or other "temporary" types, they will be
allocated in the global arena). However, the lifetime
`'tcx`
is always
a safe approximation, so that is what you get back.
NB. Because types are interned, it is possible to compare them for
equality efficiently using
`==`
-- however, this is almost never what
you want to do unless you happen to be hashing and looking for
duplicates. This is because often in Rust there are multiple ways to
represent the same type, particularly once inference is involved. If
you are going to be testing for type equality, you probably need to
start looking into the inference code to do it right.
>
NB. Because types are interned, it is possible to compare them for
>
equality efficiently using `==` -- however, this is almost never what
>
you want to do unless you happen to be hashing and looking for
>
duplicates. This is because often in Rust there are multiple ways to
>
represent the same type, particularly once inference is involved. If
>
you are going to be testing for type equality, you probably need to
>
start looking into the inference code to do it right.
You can also find various common types in the tcx itself by accessing
`tcx.types.bool`
,
`tcx.types.char`
, etc (see
`CommonTypes`
for more).
...
...
@@ -153,7 +163,3 @@ In particular, since they are so common, the `Ty` and `TyCtxt` types
are imported directly. Other types are often referenced with an
explicit
`ty::`
prefix (e.g.,
`ty::TraitRef<'tcx>`
). But some modules
choose to import a larger or smaller set of names explicitly.
src/librustc/ty/context.rs
浏览文件 @
73a4e8db
...
...
@@ -793,11 +793,10 @@ fn new(interners: &CtxtInterners<'tcx>) -> CommonTypes<'tcx> {
}
}
/// The central data structure of the compiler. Keeps track of all the
/// information that typechecker generates so that so that it can be
/// reused and doesn't have to be redone later on.
///
/// See [the README](README.md) for more deatils.
/// The central data structure of the compiler. It stores references
/// to the various **arenas** and also houses the results of the
/// various **compiler queries** that have been performed. See [the
/// README](README.md) for more deatils.
#[derive(Copy,
Clone)]
pub
struct
TyCtxt
<
'a
,
'gcx
:
'a
+
'tcx
,
'tcx
:
'a
>
{
gcx
:
&
'a
GlobalCtxt
<
'gcx
>
,
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录