Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
int
Rust
提交
85fdb34d
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,发现更多精彩内容 >>
提交
85fdb34d
编写于
12月 22, 2020
作者:
N
Nadrieril
提交者:
Nadrieril
12月 22, 2020
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
Apply suggestions from code review
Co-authored-by:
N
varkor
<
github@varkor.com
>
上级
1c176d11
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
15 addition
and
14 deletion
+15
-14
compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs
compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs
+5
-5
compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
+10
-9
未找到文件。
compiler/rustc_mir_build/src/thir/pattern/deconstruct_pat.rs
浏览文件 @
85fdb34d
...
...
@@ -451,7 +451,7 @@ fn is_covered_by(self, other: Self) -> bool {
///
/// A slice pattern `[x, .., y]` behaves like the infinite or-pattern `[x, y] | [x, _, y] | [x, _,
/// _, y] | ...`. The corresponding value constructors are fixed-length array constructors above a
/// given minimum length. We obviously can't list
all of this infinity
of constructors. Thankfully,
/// given minimum length. We obviously can't list
this infinitude
of constructors. Thankfully,
/// it turns out that for each finite set of slice patterns, all sufficiently large array lengths
/// are equivalent.
///
...
...
@@ -491,7 +491,7 @@ fn is_covered_by(self, other: Self) -> bool {
/// middle. This means that the set of witnesses for length `l >= 5` if equivalent to the set for
/// any other `l' >= 5`: simply add or remove wildcards in the middle to convert between them.
///
/// This applies to any set of slice patterns: there will be a length `L` above which all length
/// This applies to any set of slice patterns: there will be a length `L` above which all length
s
/// behave the same. This is exactly what we need for constructor splitting. Therefore a
/// variable-length slice can be split into a variable-length slice of minimal length `L`, and many
/// fixed-length slices of lengths `< L`.
...
...
@@ -736,8 +736,8 @@ pub(super) fn split<'a>(
// ranges check.
IntRange
(
ctor_range
)
if
!
ctor_range
.is_singleton
()
=>
{
let
mut
split_range
=
SplitIntRange
::
new
(
ctor_range
.clone
());
let
intranges
=
ctors
.filter_map
(|
ctor
|
ctor
.as_int_range
());
split_range
.split
(
intranges
.cloned
());
let
int
_
ranges
=
ctors
.filter_map
(|
ctor
|
ctor
.as_int_range
());
split_range
.split
(
int
_
ranges
.cloned
());
split_range
.iter
()
.map
(
IntRange
)
.collect
()
}
&
Slice
(
Slice
{
kind
:
VarLen
(
self_prefix
,
self_suffix
),
array_len
})
=>
{
...
...
@@ -1080,7 +1080,7 @@ fn kept(self) -> Option<&'p Pat<'tcx>> {
///
/// If a private or `non_exhaustive` field is uninhabited, the code mustn't observe that it is
/// uninhabited. For that, we filter these fields out of the matrix. This is handled automatically
/// in `Fields`. This filtering is uncommon in practice, because uninhabited fields are rare used,
/// in `Fields`. This filtering is uncommon in practice, because uninhabited fields are rare
ly
used,
/// so we avoid it when possible to preserve performance.
#[derive(Debug,
Clone)]
pub
(
super
)
enum
Fields
<
'p
,
'tcx
>
{
...
...
compiler/rustc_mir_build/src/thir/pattern/usefulness.rs
浏览文件 @
85fdb34d
...
...
@@ -19,7 +19,7 @@
//!
//! The algorithm implemented here is a modified version of the one described in [this
//! paper](http://moscova.inria.fr/~maranget/papers/warn/index.html). We have however generalized
//! it to accom
odate the variety of patterns that r
ust supports. We thus explain our version here,
//! it to accom
modate the variety of patterns that R
ust supports. We thus explain our version here,
//! without being as rigorous.
//!
//!
...
...
@@ -27,13 +27,13 @@
//!
//! The core of the algorithm is the notion of "usefulness". A pattern `q` is said to be *useful*
//! relative to another pattern `p` of the same type if there is a value that is matched by `q` and
//! not matched by `p`. This generalizes to many `p`s: `q` is useful w
rt a list of patterns `p_1 ..
//! p_n` if there is a value that is matched by `q` and by none of the `p_i`. We write
//! not matched by `p`. This generalizes to many `p`s: `q` is useful w
.r.t. a list of patterns
//!
`p_1 ..
p_n` if there is a value that is matched by `q` and by none of the `p_i`. We write
//! `usefulness(p_1 .. p_n, q)` for a function that returns a list of such values. The aim of this
//! file is to compute it efficiently.
//!
//! This is enough to compute reachability: a pattern in a `match` expression is reachable iff it
//! is useful w
rt
the patterns above it:
//! is useful w
.r.t.
the patterns above it:
//! ```rust
//! match x {
//! Some(_) => ...,
...
...
@@ -44,8 +44,8 @@
//! ```
//!
//! This is also enough to compute exhaustiveness: a match is exhaustive iff the wildcard `_`
//! pattern is _not_ useful w
rt the patterns in the match. The values returned by `usefulness` are
//! used to tell the user which values are missing.
//! pattern is _not_ useful w
.r.t. the patterns in the match. The values returned by `usefulness`
//!
are
used to tell the user which values are missing.
//! ```rust
//! match x {
//! Some(0) => ...,
...
...
@@ -102,7 +102,7 @@
//!
//! Note: this constructors/fields distinction may not straightforwardly apply to every Rust type.
//! For example a value of type `Rc<u64>` can't be deconstructed that way, and `&str` has an
//! infinit
y
of constructors. There are also subtleties with visibility of fields and
//! infinit
ude
of constructors. There are also subtleties with visibility of fields and
//! uninhabitedness and various other things. The constructors idea can be extended to handle most
//! of these subtleties though; caveats are documented where relevant throughout the code.
//!
...
...
@@ -184,7 +184,8 @@
//!
//! `specialize(c, p0 | p1) := specialize(c, p0) ++ specialize(c, p1)`
//!
//! - We treat the other pattern constructors lik big or-patterns of all the possibilities:
//! - We treat the other pattern constructors as if they were a large or-pattern of all the
//! possibilities:
//!
//! `specialize(c, _) := specialize(c, Variant1(_) | Variant2(_, _) | ...)`
//!
...
...
@@ -193,7 +194,7 @@
//! `specialize(c, [p0, .., p1]) := specialize(c, [p0, p1] | [p0, _, p1] | [p0, _, _, p1] | ...)`
//!
//! - If `c` is a pattern-only constructor, `specialize` is defined on a case-by-case basis. See
//! the discussion abou
n
t constructor splitting in [`super::deconstruct_pat`].
//! the discussion about constructor splitting in [`super::deconstruct_pat`].
//!
//!
//! We then extend this function to work with pattern-stacks as input, by acting on the first
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录