- Modified ExtractVariable to stop extraction for MemberExpr, DeclRefExpr and Assignment Expr
- Fixed unittests
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp | ||
---|---|---|
80–81 | nit: Could you reduce nesting by early returns and add braces to outer if statements if there are any nested statements left. | |
clang-tools-extra/clangd/unittests/TweakTests.cpp | ||
304 | left out this one ? | |
307 | how come these changes part of that patch? is it possible that this tweak was changed to not trigger on empty selections, but tests were not updated? If that's the case could you please send these on a different patch and rebase this patch on that one? | |
307 |
how come these changes *are* part of that patch? |
Are you sure we want to disable extraction here, rather than just do the extraction at a higher level?
E.g. if bar(1,2,3, f[[o]]o(4,5)); seems like it should extract the call too foo(4,5), not fail to trigger entirely.
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp | ||
---|---|---|
81 | this comment repeats the implementation, but should explain why instead |
clang-tools-extra/clangd/unittests/TweakTests.cpp | ||
---|---|---|
304 | nvm this one, it was for "empyt selection triggering" case. | |
328–329 | I thought extractor didn't handle this case(missing braces). What is the extraction in this case? Because if it is auto dummy = a++; while (a < 1) dummy++; it is not going to be semantically same. |
Selecting f[[o]]o(4,5) will just extract the foo which would be a DeclRefExpr. We want to extract the CallExpr for which we would need to select the brackets as well.
clang-tools-extra/clangd/unittests/TweakTests.cpp | ||
---|---|---|
328–329 | We don't check for missing braces and continuing traversing up the AST until we find the CompoundStmt. Yes, it's not going to be semantically the same. We only check if after extraction, the extracted expression will reference a variable that hasn't been declared till that point. |
clang-tools-extra/clangd/unittests/TweakTests.cpp | ||
---|---|---|
328–329 | I believe this behavior is not expected and we should address that as well, the expressions you extract might have weird side effects, therefore if some expression is within a loop body it should stay there. |
I agree, but this patch doesn't do that. (I think?)
Instead it bans extraction entirely in this case.
Yes it doesn't. Our current model doesn't extend the user selection and as such we only check the commonAncestor of whatever the user has selected. Should this be changed then?
Yes I think you want to walk up the tree like you do for finding the target stmt, giving up when you hit a non-expr.
This didn't matter prior to this patch as void subexprs are extremely rare. But declrefs are not!
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp | ||
---|---|---|
198 | comment seems to be repeating the code, instead lets comment about the assumptions, like not working on declrefexpr's etc. | |
214 | maybe instead of checking internals like Target just make computeExtractionContext return an llvm::Error and check for success? | |
233 | I don't think traversing the tree without any conditions is a good idea, for example: struct Foo { int bar(int); int z; }; void foo() { Foo f; f.bar([[f.z]]); } above selection is on a memberexpr, that has a parent membercallexpr but it is actually not related to selection at all but I believe we'll extract the whole thing in that case. | |
275 | nit: braces | |
278 | nit: instead of checking success check failure and bail out? if(!TargetNode || !canBeass...) return; |
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp | ||
---|---|---|
214 | Should it instead return a bool since there's actually no error? |
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp | ||
---|---|---|
296 | Changed to checking if target is extractable. |
clang-tools-extra/clangd/refactor/tweaks/ExtractVariable.cpp | ||
---|---|---|
214 | i was trying to say: having a function named computeExtractionContext that will require you to check some other state even when it returns true sounds like a bad idea. | |
296 | any reasons for not returning Target->isExtractable() ? | |
clang-tools-extra/clangd/unittests/TweakTests.cpp | ||
304 | i suppose this is done | |
457 | I think auto dummy = 1; should be within the label. otherwise we might break codes like(which is basically anything with labels): void foo() { goto label; label: a = 1; } I don't think it is that important though, and have no idea about the effort necessary feel free to just add a FIXME if it turns out hard. |
Thanks, LGTM from my side. Do you have any concerns @sammccall ?
clang-tools-extra/clangd/unittests/TweakTests.cpp | ||
---|---|---|
457 | could you keep the previous test case within a checkNotAvailable block ? |
clang-tools-extra/clangd/unittests/TweakTests.cpp | ||
---|---|---|
457 | I've disabled extraction from label statements and added a fixme because the fix for all kinds of loops as well as if statement needs another patch. |
nit: Could you reduce nesting by early returns and add braces to outer if statements if there are any nested statements left.