-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Add suggestion for nested fields #81480
Conversation
This comment has been minimized.
This comment has been minimized.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for tackling this!
return Some(field_path_clone); | ||
} else { | ||
field_path_clone.push(ident); | ||
if let Some(path) = self.check_for_nested_field( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting, I hadn't thought about doing an exhaustive search... We probably want to keep some limits here to avoid accidentally blowing up the compilation time, as this is O(n^2) in the worst case. Maybe up to 4 levels deep and 1000 fields, otherwise early return.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's actually exponential run-time in the worst case. Even limiting the recursion depth and the number of fields to 4 and 1000, resp. still would result in 1000^4 calls in the worst case. I changed this to 3 and 100. 100 might be too low, alternatively we could maybe track and limit the number of recursive calls instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, 100 should be fine. Keep in mind that the degenerate case requires all levels of nesting to be structs with 100 fields each. A cheeky solution would be to have a global count of fields per level that we pass down (so at any added dot you're always sure you're not going above N total subfields) but that complicates the logic unnecessarily.
@estebank Thanks for the review. I fixed the previous commit. Can you take another look, please? |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
67e452d
to
3fad75f
Compare
This comment has been minimized.
This comment has been minimized.
There's a recently added check to keep the number of tests in the |
I just noticed that we don't check for the fields being accessible (privacy), but that is fine. People will try it and get an error telling them that. I think this PR can be merged as soon as we make CI happy :) Also, if you could squash your commits into a single one, that will make navigating the history much easier. (I know we could squash merge on our side, but we don't because for larger PRs we want to keep that history if it has semantic meaning.) |
3fad75f
to
73b1cef
Compare
This comment has been minimized.
This comment has been minimized.
@estebank I don't understand why the test fails. I did bless the test. |
It seems like you need to |
Mh it has something to do with |
https://github.com/rust-lang/rust/pull/81480/files#diff-5dbdd13d22e9b8f4724e3435534639a8047d8714c72bc1fdd6e46eac5b68d8f7 and https://github.com/rust-lang/rust/pull/81480/files#diff-22da95cc8535eeedafa55938fb4e4bd1293014cf79a3ceaa1808c2849e4eaa26 look different. |
73b1cef
to
6e1986b
Compare
This comment has been minimized.
This comment has been minimized.
@estebank That's not the reason, I pushed the latest changes and it still fails. Does |
Ah! Yes. That's what's happening. The resulting code has to be compilable without errors/warnings. There are two options. If we want to ensure this doesn't regress what I do is split the test into two different files. One that will always be fixable and one that isn't. The other alternative is to just remove the |
6e1986b
to
9946b54
Compare
@estebank CI passes now. I seperated the tests, but thinking about it, I don't really see the usefulness of the second test if we have no way to fix that no suggestion is included in the stderr output. Do you want me to remove that test again? |
📌 Commit 9946b54 has been approved by |
…as-schievink Rollup of 11 pull requests Successful merges: - rust-lang#80092 (2229: Fix issues with move closures and mutability) - rust-lang#80404 (Remove const_in_array_repeat) - rust-lang#81255 (Don't link with --export-dynamic on wasm32-wasi) - rust-lang#81480 (Add suggestion for nested fields) - rust-lang#81549 (Misc ip documentation fixes) - rust-lang#81566 (Add a test for rust-lang#71202) - rust-lang#81568 (Fix an old FIXME in redundant paren lint) - rust-lang#81571 (Fix typo in E0759) - rust-lang#81572 (Edit multiple error code Markdown files) - rust-lang#81589 (Fix small typo in string.rs) - rust-lang#81590 (Stabilize int_bits_const) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fix non-existent-field ICE for generic fields. I mentioned this ICE in a chat and it took about 3 milliseconds before `@eddyb` found the problem and said this change would fix it. :) This also changes one the field types in the related test to one that triggered the ICE. Fixes rust-lang#81627. Fixes rust-lang#81672. Fixes rust-lang#81709. Cc rust-lang#81480 `@b-naber` `@estebank.`
Closes #81220
r? @estebank