Closed Bug 1616181 Opened 4 years ago Closed 4 years ago

error: reference to 'InputType' is ambiguous


(Core :: DOM: Core & HTML, defect, P3)






(Reporter: Sylvestre, Unassigned)


(Blocks 1 open bug, )


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.
Type: defect → enhancement
Priority: -- → P3

As we cannot build Firefox with clang 11 trunk, I don't think it is an enhancement (but I agree with P3)

Type: enhancement → defect

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).

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, though I'm still not sure if it was intentional.

I filed to ask whether this change was intended.

This was fixed in llvmorg-11-init-4344-g98ed0c5475d.

Let's close it

Closed: 4 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.