Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

implement rfc-2528 type_changing-struct-update #90035

Merged
merged 4 commits into from
Nov 9, 2021

Conversation

SparrowLii
Copy link
Member

@SparrowLii SparrowLii commented Oct 19, 2021

This PR implement rfc2528-type_changing-struct-update.
The main change process is as follows:

  1. Move the processing part of base_expr into check_expr_struct_fields to avoid returning remaining_fields (a relatively complex hash table)
  2. Before performing the type consistency check(check_expr_has_type_or_error), if the type_changing_struct_update feature is set, enter a different processing flow, otherwise keep the original flow
  3. In the case of the same structure definition, check each field in remaining_fields. If the field in base_expr is not the suptype of the field in adt_ty, an error(FeildMisMatch) will be reported.

The MIR part does not need to be changed, because only the items contained in remaining_fields will be extracted from base_expr when MIR is generated. This means that fields with different types in base_expr will not be used
Updates #86618
cc @nikomatsakis

@rust-highfive
Copy link
Collaborator

r? @jackh726

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 19, 2021
@rust-log-analyzer

This comment has been minimized.

@jackh726
Copy link
Member

#89730 is smaller, just the feature gate - let's land that first, then rebase on that

@jackh726 jackh726 added S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 21, 2021
@SparrowLii
Copy link
Member Author

OK, that sounds good

@bors
Copy link
Contributor

bors commented Oct 23, 2021

☔ The latest upstream changes (presumably #90188) made this pull request unmergeable. Please resolve the merge conflicts.

@jackh726
Copy link
Member

@SparrowLii can you rebase on master now that #89730 has been merged?

I'm going to try to do a proper review here this weekend.

@jackh726 jackh726 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-blocked Status: Marked as blocked ❌ on something else such as an RFC or other implementation work. labels Oct 23, 2021
@SparrowLii
Copy link
Member Author

That is encouraging! But I don't have a test environment at hand right now. I will resolve the conflict this Monday, as soon as possible

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

@SparrowLii
Copy link
Member Author

The rebasing and modification of tests are done. I think it is ready to be reviewed.

@jackh726 jackh726 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 25, 2021
Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Overall pretty straightforward, a few nits. Can you squash the commits (other than spliting out that one commit)?

@@ -686,7 +686,7 @@ declare_features! (

/// Allows creation of instances of a struct by moving fields that have
/// not changed from prior instances of the same struct (RFC #2528)
(incomplete, type_changing_struct_update, "1.58.0", Some(86555), None),
(active, type_changing_struct_update, "1.58.0", Some(86555), None),
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is still incomplete

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I say this because, even though it "works", I'd like a few more tests for better coverage before switching this to "active".

Copy link
Member Author

@SparrowLii SparrowLii Oct 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, it is incomplete now

let m1: Machine<State1> = Machine {
state: State1,
lt_str: &s,
//~^ ERROR `s` does not live long enough [E0597]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So...this is behavior on nightly today. The intention is in fact to allow changing lifetime parameters, right? Probably, the error should get moved to line 20 (creating m1 should be fine, we should infer '_ as lifetime, but trying to create m2 without updating the lifetime on lt is a problem.

I don't think this needs to be changed in this PR, but it does need a FIXME (and probably either an issue filed or a mention in the (implementation?) tracking issue)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's right. I added FIXME in lifetime-update.rs

Comment on lines 7 to 8
LL | let m2: Machine<'static, State1> = Machine {
| ------------------------ type annotation requires that `s` is borrowed for `'static`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, at least the information is around; just the span needs to change I think

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added FIXME in lifetime-update.rs

@@ -1,3 +1,5 @@
// gate-test-type_changing_struct_update
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noting that the FIXME probably isn't correct. But, perhaps this should give a suggest to add the feature if on nightly.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I correct the location of FIXME. But if we want to add a feature trigger, we can no longer use the original check_expr_has_type_or_error function, because we need to know which field caused a type error. This may require us to merge the two feature branches. I will submit a new commit to try to implement it.

compiler/rustc_typeck/src/check/expr.rs Show resolved Hide resolved
span: base_expr.span,
});
};
variant
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, why use variant here but non_enum_variant() below? These should be the same thing, but just a bit weird. (Probably an opportunity for a bit of cleanup)

Copy link
Member Author

@SparrowLii SparrowLii Oct 29, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep they both use variant now. I didn’t find other code that need to be cleaned up, please let me know if there are any

Comment on lines 1 to 8
error[E0308]: mismatched types
--> $DIR/type-generic-update.rs:31:11
|
LL | ..m1
| ^^ field type mismatch: Machine.state
|
= note: expected type `i32`
found type `f64`
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is...fine...for now, but this needs better diagnostics. Should be a followup issue filed or noted on tracking issue.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added a FIXME to indicate that the diagnostic information needs to be enhanced

// the fields with the base_expr. This could cause us to hit errors later
// when certain fields are assumed to exist that in fact do not.
if !error_happened {
let fru_tys = if self.tcx.features().type_changing_struct_update {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think having these be two separate branches is fine for now, but I think it'd be nice to eventually merge them as much as possible. Can you add a FIXME?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, have add a FIXME here. In order to add a feature trigger, I think it is necessary to merge them. I will submit a new commit to try to implement it.

compiler/rustc_typeck/src/check/expr.rs Show resolved Hide resolved
@jackh726 jackh726 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Oct 26, 2021
put the test dir in test/ui/rfcs
@apiraino apiraino added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Oct 28, 2021
@SparrowLii
Copy link
Member Author

SparrowLii commented Oct 29, 2021

Overall pretty straightforward, a few nits. Can you squash the commits (other than spliting out that one commit)?

OK. Have made a squash.

@SparrowLii
Copy link
Member Author

As stated by FIXME in lifetime-update.rs, spans generated by type errors caused by lifetime should be corrected. We may need to raise this point in the tracking issue.

@jackh726 jackh726 added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Oct 29, 2021
Copy link
Member

@jackh726 jackh726 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Last commit feels a bit messy to me; not sure how best to clean it up though.

Left a couple commits.

Comment on lines 1388 to 1402
if ty.is_never() {
assert!(
!self.typeck_results.borrow().adjustments().contains_key(base_expr.hir_id),
"expression with never type wound up being adjusted"
);
let adj_ty = self.next_ty_var(TypeVariableOrigin {
kind: TypeVariableOriginKind::AdjustmentType,
span: base_expr.span,
});
self.apply_adjustments(
base_expr,
vec![Adjustment { kind: Adjust::NeverToAny, target: adj_ty }],
);
ty = adj_ty;
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, what is this needed for? If this is needed, can you add a test for it?

let cause = self.misc(base_expr.span);
let mut fru_tys = None;
let mut err = None;
let is_struct;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why define this here?

};
self.typeck_results.borrow_mut().fru_field_types_mut().insert(expr_id, fru_tys);
err = self.demand_suptype_diag(base_expr.span, expected_ty, ty);
is_struct = false;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just emit the error here?

Or, better yet, any way we can just return early and do away with the nesting?

@SparrowLii
Copy link
Member Author

SparrowLii commented Nov 5, 2021

Thanks for reviewing. I manually copied most of the implementation of check_expr_has_type_or_error for adding the feature error, which would make the code messy. That is unwise. So I went back to the previous submission and found a new way. It should be clear enough now and can be reviewed.

@jackh726
Copy link
Member

jackh726 commented Nov 9, 2021

I think this can definitely be cleaned up a bit in the future, and there is a FIXME for that, so @bors r+

@bors
Copy link
Contributor

bors commented Nov 9, 2021

📌 Commit 926892d has been approved by jackh726

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Nov 9, 2021
bors added a commit to rust-lang-ci/rust that referenced this pull request Nov 9, 2021
…askrgr

Rollup of 7 pull requests

Successful merges:

 - rust-lang#89561 (Type inference for inline consts)
 - rust-lang#90035 (implement rfc-2528 type_changing-struct-update)
 - rust-lang#90613 (Allow to run a specific rustdoc-js* test)
 - rust-lang#90683 (Make `compiler-docs` only control the default instead of being a hard off-switch)
 - rust-lang#90685 (x.py: remove fixme by deleting code)
 - rust-lang#90701 (Record more artifact sizes during self-profiling.)
 - rust-lang#90723 (Better document `Box` and `alloc::alloc::box_free` connection)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 610b4e5 into rust-lang:master Nov 9, 2021
@rustbot rustbot added this to the 1.58.0 milestone Nov 9, 2021
@crlf0710 crlf0710 added the F-type-changing-struct-update `#![feature(type_changing_struct_update)]` label Nov 15, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
F-type-changing-struct-update `#![feature(type_changing_struct_update)]` S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants