error: reference to 'InputType' is ambiguous
Categories
(Core :: DOM: Core & HTML, defect, P3)
Tracking
()
People
(Reporter: Sylvestre, Unassigned)
References
(Blocks 1 open bug, )
Details
with clang trunk:
In file included from Unified_cpp_dom_events1.cpp:74:
In file included from /var/lib/jenkins/workspace/firefox-clang-lld/dom/events/IMEStateManager.cpp:30:
In file included from /var/lib/jenkins/workspace/firefox-clang-lld/dom/html/HTMLInputElement.h:28:
In file included from /var/lib/jenkins/workspace/firefox-clang-lld/obj-x86_64-pc-linux-gnu/dist/include/SingleLineTextInputTypes.h:10:
/var/lib/jenkins/workspace/firefox-clang-lld/obj-x86_64-pc-linux-gnu/dist/include/InputType.h:236:41: error: reference to 'InputType' is ambiguous
void operator()(::InputType* p) { p->~InputType(); }
^
/var/lib/jenkins/workspace/firefox-clang-lld/obj-x86_64-pc-linux-gnu/dist/include/InputType.h:35:7: note: candidate found by name lookup is 'InputType'
class InputType {
^
/var/lib/jenkins/workspace/firefox-clang-lld/obj-x86_64-pc-linux-gnu/dist/include/InputData.h:39:3: note: candidate found by name lookup is 'mozilla::InputType'
InputType, (
^
1 warning generated.
|
||
Updated•5 years ago
|
|
Reporter | |
Comment 1•5 years ago
|
||
As we cannot build Firefox with clang 11 trunk, I don't think it is an enhancement (but I agree with P3)
Are we certain that this isn't a bug in clang? The code looks pretty unambiguous to my eye, but I admit that there are lots of C++ corner cases that can be counterintuitive. Perhaps it would help to bisect to the change that introduced this, and see if the commit message or code change give any clues (maybe they even added a test case for exactly this type of code, that would be a pretty clear signal that it's intentional).
|
|
Reporter | |
Comment 3•5 years ago
|
||
Maybe it is, I will wait for a few days to see what happens
If the change was unintentional, we can get better results by notifying the author while they still have the topic on their mind. Plus it helps prevent the new code from being cemented by later patches landing on top.
I had a lucky guess by looking through zygoloid commits, so I managed to avoid bisecting. This started in https://github.com/llvm/llvm-project/commit/0e3a4877840, though I'm still not sure if it was intentional.
|
|
Reporter | |
Comment 7•5 years ago
|
||
|
|
Reporter | |
Updated•5 years ago
|
I filed https://bugs.llvm.org/show_bug.cgi?id=44978 to ask whether this change was intended.
|
|
Reporter | |
Comment 10•5 years ago
|
||
thanks!
Let's close it
Description
•