diff options
author | Gabor Marton <gabor.marton@ericsson.com> | 2019-08-27 11:36:10 +0000 |
---|---|---|
committer | Gabor Marton <gabor.marton@ericsson.com> | 2019-08-27 11:36:10 +0000 |
commit | f035b75d8f079a7b3c8d5c163e2ab0596ac59d17 (patch) | |
tree | 728488b68992c3688630151ee4ed9e29361066cb /lldb/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py | |
parent | c397a266f01d7907e45a1f5c54bd9be219e94ea3 (diff) | |
download | bcm5719-llvm-f035b75d8f079a7b3c8d5c163e2ab0596ac59d17.tar.gz bcm5719-llvm-f035b75d8f079a7b3c8d5c163e2ab0596ac59d17.zip |
[ASTImporter] Fix name conflict handling with different strategies
There are numorous flaws about the name conflict handling, this patch
attempts fixes them. Changes in details:
* HandleNameConflict return with a false DeclarationName
Hitherto we effectively never returned with a NameConflict error, even
if the preceding StructuralMatch indicated a conflict.
Because we just simply returned with the parameter `Name` in
HandleNameConflict and that name is almost always `true` when converted to
`bool`.
* Add tests which indicate wrong NameConflict handling
* Add to ConflictingDecls only if decl kind is different
Note, we might not indicate an ODR error when there is an existing record decl
and a enum is imported with same name. But there are other cases. E.g. think
about the case when we import a FunctionTemplateDecl with name f and we found a
simple FunctionDecl with name f. They overload. Or in case of a
ClassTemplateDecl and CXXRecordDecl, the CXXRecordDecl could be the 'templated'
class, so it would be false to report error. So I think we should report a
name conflict error only when we are 100% sure of that. That is why I think it
should be a general pattern to report the error only if the kind is the same.
* Fix failing ctu test with EnumConstandDecl
In ctu-main.c we have the enum class 'A' which brings in the enum
constant 'x' with value 0 into the global namespace.
In ctu-other.c we had the enum class 'B' which brought in the same name
('x') as an enum constant but with a different enum value (42). This is clearly
an ODR violation in the global namespace. The solution was to rename the
second enum constant.
* Introduce ODR handling strategies
Reviewers: a_sidorin, shafik
Differential Revision: https://reviews.llvm.org/D59692
llvm-svn: 370045
Diffstat (limited to 'lldb/packages/Python/lldbsuite/test/functionalities/completion/TestCompletion.py')
0 files changed, 0 insertions, 0 deletions