Skip to content

R
Rust

int / Rust
12 个月 前同步成功

通知 1
Star 0
Fork 0
R
Rust

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 09 7月, 2022 9 次提交
    • N
      Minor updates based on review comments. · 0578697a
      由 Nicholas Nethercote 提交于
      0578697a
    • N
      Simplify `cs_fold`. · 16a286b0
      由 Nicholas Nethercote 提交于 
      `cs_fold` has four distinct cases, covered by three different function
arguments:

- first field
- combine current field with previous results
- no fields
- non-matching enum variants

This commit clarifies things by replacing the three function arguments
with one that takes a new `CsFold` type with four slightly different)
cases

- single field
- combine result for current field with results for previous fields
- no fields
- non-matching enum variants

This makes the code shorter and clearer.
      16a286b0
    • N
      Fix some inconsistencies. · 559398fa
      由 Nicholas Nethercote 提交于 
      This makes `cs_cmp`, `cs_partial_cmp`, and `cs_op` (for `PartialEq`)
more similar. It also fixes some out of date comments.
      559398fa
    • N
      Cut down large comment about zero-variant enums. · 65d0bfbc
      由 Nicholas Nethercote 提交于 
      When deriving functions for zero-variant enums, we just generated a
function body that calls `std::instrincs::unreachable`. There is a large
comment with some not-very-useful historical discussion about
alternatives, including some discussion of feature-gating zero-variant
enums, which is clearly irrelevant today.

This commit cuts the comment down greatly.
      65d0bfbc
    • N
      Avoid transposes in deriving code. · 7f1dfcab
      由 Nicholas Nethercote 提交于 
      The deriving code has some complex parts involving iterations over
selflike args and also fields within structs and enum variants.

The return types for a few functions demonstrate this:

- `TraitDef::create_{struct_pattern,enum_variant_pattern}` returns a
  `(P<ast::Pat>, Vec<(Span, Option<Ident>, P<Expr>)>)`
- `TraitDef::create_struct_field_accesses` returns a `Vec<(Span,
  Option<Ident>, P<Expr>)>`.

This results in per-field data stored within per-selflike-arg data, with
lots of repetition within the per-field data elements. This then has to
be "transposed" in two places (`expand_struct_method_body` and
`expand_enum_method_body`) into per-self-like-arg data stored within
per-field data. It's all quite clumsy and confusing.

This commit rearranges things greatly. Data is obtained in the needed
form up-front, avoiding the need for transposition. Also, various
functions are split, removed, and added, to make things clearer and
avoid tuple return values.

The diff is hard to read, which reflects the messiness of the original
code -- there wasn't an easy way to break these changes into small
pieces. (Sorry!) It's a net reduction of 35 lines and a readability
improvement. The generated code is unchanged.
      7f1dfcab
    • N
      Remove `FieldInfo::attrs`. · 27571da5
      由 Nicholas Nethercote 提交于 
      It's unused. This also removes the need for the lifetime on `FieldInfo`,
which is nice.
      27571da5
    • N
      Rename `FieldInfo` fields. · d3057b5c
      由 Nicholas Nethercote 提交于 
      Use `self_exprs` and `other_selflike_exprs` in a manner similar to the
previous commit.
      d3057b5c
    • N
      Clarify args terminology. · 32c9ffb9
      由 Nicholas Nethercote 提交于 
      The deriving code has inconsistent terminology to describe args.

In some places it distinguishes between:
- the `&self` arg (if present), versus
- all other args.

In other places it distinguishes between:
- the `&self` arg (if present) and any other arguments with the same
  type (in practice there is at most one, e.g. in `PartialEq::eq`),
  versus
- all other args.

The terms "self_args" and "nonself_args" are sometimes used for the
former distinction, and sometimes for the latter. "args" is also
sometimes used for "all other args".

This commit makes the code consistently uses "self_args"/"nonself_args"
for the former and "selflike_args"/"nonselflike_args" for the latter.
This change makes the code easier to read.

The commit also adds a panic on an impossible path (the `Self_` case) in
`extract_arg_details`.
      32c9ffb9
    • B
      Auto merge of #98614 - oli-obk:take_unsound_opaque_types, r=wesleywiser · 052495d0
      由 bors 提交于 
      don't succeed `evaluate_obligation` query if new opaque types were registered

fixes #98608
fixes #98604

The root cause of all this is that in type flag computation we entirely ignore nongeneric things like struct fields and the signature of function items. So if a flag had to be set for a struct if it is set for a field, that will only happen if the field is generic, as only the generic parameters are checked.

I now believe we cannot use type flags to handle opaque types. They seem like the wrong tool for this.

Instead, this PR replaces the previous logic by adding a new variant of `EvaluatedToOk`: `EvaluatedToOkModuloOpaqueTypes`, which says that there were some opaque types that got hidden types bound, but that binding may not have been legal (because we don't know if the opaque type was in its defining scope or not).
      052495d0
  3. 08 7月, 2022 31 次提交