This patch allows detecting conflicts with variables defined in the current
CompoundStmt or If/While/For variable init statements.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Unit Tests
Time | Test | |
---|---|---|
160 ms | x64 windows > Clang.Driver::crash-report-null.test |
Event Timeline
Thanks, this looks right to me.
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
338 | I found that the current structure (we have two places of this If cases, and they are separated) is a bit hard to follow, I'd suggest union them, just like the code below, it seems straight-forward to me, and easy to extend. if (const auto* CompoundStmtEnclosing = Parents.begin()->get<CompoundStmt>()) { CheckCompoundStmt(CompoundStmtEnclosing); // below we detect conflicts in conditions or others (if the CompoundStmt is a function body, we could detect the parameter decls as well) getParents(CompoundStmtEnclosing); if ( ...<IfStmt>()) { CheckConditionVariable(); } else if (...) { } } else if (const auto* IfEnclosing = ... <IfStmt>()) { CheckCompoundStmt(If->getThen()); // possibly CheckCompoundStmt(If->getElse) } else { ... } | |
339 | thinking more about the if case, I think else should be included as well? no need to address in this patch. like if (int a = 0) { } else { int s; // rename s=>a will cause a compiling error. } | |
352 | nit: VarDecl => NamedDecl |
Resolve review comments.
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
339 | This case is already supported: else's CompoundStmt is attached to the same IfStmt with variable declaration and is checked just like the "main" branch. The other one wasn't (renaming a into s) but I've added this and also added tests for this. |
thanks, looks better now, just some nits to improve the code readability.
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
330 | since we repeat this code multiple times, I think we can use wrap it with a lambda (e.g. getSingleParent etc). | |
336 | maybe name it LookupInDeclStmt and pass the Name as a parameter, the same below. | |
343 | the same lookupInCompoundStmt. | |
348 | nit: can be just return CheckDeclStmt(DS); | |
353 | nit: explicit spell out the auto type? | |
357 | nit: the same here, return CheckDeclStmt (Scope->getConditionVariableDeclStmt()), just adding the nullptr handling in CheckDeclStmt. | |
362 | I understand all cases of these if branches at the moment, but I think we'd better to add some comments, or examples here -- help us understand this code in case that we forget the context in the future :) | |
380 | I think we need a return null here (or use if-else pattern), otherwise, the following if-stmt will be examined as well, which seems no necessary. |
Resolve most comments but one: some comments & examples in the code incoming in
the next diff.
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
353 | That's the idea behind this helper: it's used both on IfStmt and WhileStmt, so the point here is that getConditionVariableDeclStmt() is available in both but not via interface/inheritance. |
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
331 | If the intention is for storage, maybe call it Storage. | |
332 | const DynTypedNode & | |
360 | I think we need to iterate *all* children, rather than the first one. looks like our testcase doesn't cover this, maybe add one. | |
370 | CompoundStmt is the most common enclosing scope for function-local symbols. | |
376 | maybe just GetSingleParent(Parent), rather than creating a new DynTypeNode. | |
388 | be careful about nullptr here, the init-statement could be a nullptr, which will trigger a crash in dyn_cast, thinking about the case below: for (; ; ;) { int var; } use dyn_cast_or_null. |
Fix a couple problems pointed out during the review.
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
332 | Sorry, I'm a bit confused: this can return nullptr when there are _no parents_. Is there any way I can return the reference safely? |
clang-tools-extra/clangd/refactor/Rename.cpp | ||
---|---|---|
409 | another case we could add is FunctionDecl, if we rename a parameter decl, we could check collisions in the function body. this can be addressed in a follow-up. |
since we repeat this code multiple times, I think we can use wrap it with a lambda (e.g. getSingleParent etc).