Closed Bug 754244 Opened 10 years ago Closed 10 years ago

xpidl parses long longValue as long long Value

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
12 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla15

People

(Reporter: dcs25, Assigned: benjamin)

Details

Attachments

(1 file)

Parse multi-word identifier tokens correctly, rev. 1
1.16 KB, patch
khuey
: review+
Details | Diff | Splinter Review 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_3) AppleWebKit/536.5 (KHTML, like Gecko) Chrome/19.0.1084.41 Safari/536.5

Steps to reproduce:

Picked up work on a very old project and moved to the new python based xpidl after grabbing XULRunner 12.


Actual results:

It appears that the lexer chokes on:

attribute long longValue;

which generates:

  /* attribute long long Value; */
  NS_SCRIPTABLE NS_IMETHOD GetValue(PRInt64 *aValue) = 0;
  NS_SCRIPTABLE NS_IMETHOD SetValue(PRInt64 aValue) = 0;


Expected results:

Of course, this actually a long type named longValue, which worked fine with the old binary build.

I tried unsigned long long, expecting it to break as well, and sure enough, it did.
That's bizarre!
Assignee: nobody → benjamin
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Attachment #623182 - Flags: review?(khuey)
https://hg.mozilla.org/integration/mozilla-inbound/rev/be715fe9c916
Target Milestone: --- → mozilla15
https://hg.mozilla.org/mozilla-central/rev/be715fe9c916
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.