8833 - Cannot declare constants of typedef'ed type

Status: RESOLVED FIXED

(Core :: XPCOM, defect, P3)

Description

[Alec Flett]

I can't do this:

typedef  long nsMsgRuleActionType;

and then put in an interface:
const nsMsgRuleActionType nsMsgFilterActionNone=0;

even though nsMsgRuleActionType is a long.
I get:
nsIMsgFilter.idl:42: Warning: const decl 'nsMsgFilterActionNone' was not of type
short or long, ignored

That's kind of lame...
(if I can't have enums, at least give me this)

Comment 1

[Alec Flett]

I know jband will want to have input on this

Comment 2

[John Bandhauer]

I think that this is a limitation we can live with. The way some of the code
is structured (esp. the xpidl_typelib.c) this looks like a pain to support. If
it gets fixed then it has to get fixed for all code generators. *And* it has to
be limited to the types that resolve down to the useful types that we can
support on all mappings - int16, uint16, int32, and uint32.

FWIW... alecf, I don't think that you really do your users a service by trying
to make it look like a C++ enum type when it isn't. You're not getting C++
enum type safely here , so why try to make it look like you are? These are xpcom
interfaces and the implementations need to do runtime bounds checking anyway for
continued safety as the code matures.

I think there are more inmportant things to fix, but I've been overruled before
:)

It is worth noting that shaver has code in the xpidl_typlib.c to try to supports
*lots* of types for constants. But most don't map into useful types for C++
class static constants that we can generate into .H files. I foolishly '#if 0'ed
the code out rather than deleting it. Please no one try to revive it.

Comment 3

[Alec Flett]

heh, well I'm making one more pass at the enum argument on mozilla.xpcom... I
was hoping this was a cheap solution..

I was hoping it was as simple as changing some code that might look like

if (typeof(ident) != long && typeof(ident) != short) then...

to

if (resolved_typeof(ident) != long && resolved_typeof(ident) != short) then...

and then storing it in the typelib as the resolved type.

Again, I'm not trying to change the behavior of XPConnect at runtime, just the
generated C++ headers.

Comment 4

[John Bandhauer]

*** Bug 8992 has been marked as a duplicate of this bug. ***

Comment 5

[Mike McCabe]

*** Bug 12601 has been marked as a duplicate of this bug. ***

Comment 6

[Mike McCabe]

Marking as assigned.

Comment 7

[Mike McCabe]

This is an enhancement, and doesn't need to be on dogfood or m12 radar; shifting
to m14.

Comment 8

[Mike McCabe]

Enhancement.  Kicking out a few milestones.

Comment 9

[Mike McCabe]

Fix checked in.

Comment 10

[Alec Flett]

oh thanks! I forgot about this and had gotten in the habit of just working 
around it.