179028 - Remove "X hides Y" warnings in layout/html/forms/src/nsIsIndexFrame.cpp file

Status: RESOLVED WORKSFORME

(Core :: General, defect, P5)

Description

[John Keiser (jkeiser)]

We can fix "X hides Y" warnings using the "using" construct, as pointed out by
bbaetz.  We must, of course, ensure that there isn't a genuine hiding problem
going on in these spots first :)  We also need to determine if "using" works on
our platforms.  (We can always use an autoconf and #ifdef if it doesn't work.) 
It works on Windows (VC++ 6.0) and Linux (gcc 3.2) so far.

Comment 1

[John Keiser (jkeiser)]

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

Comment 2

[John Keiser (jkeiser)]

Setting dependent on known warning bugs.  From the gcc manual:

       -Woverloaded-virtual
              (C++ only.)  In a derived class, the
              definitions of virtual functions must
              match the type signature of a virtual
              function declared in the base class.  Use
              this option to request warnings when
              a derived class declares a function that
              may be an erroneous attempt to define a
              virtual function: that is, warn when a
              function with the same name as a
              virtual function in the base class, but
              with a type signature that doesn't match
              any virtual functions from the base class.

Documentation on "using" from MS:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclang/html/_pluslang_using_declaration.asp

Comment 3

[John Keiser (jkeiser)]

Attachment: nsIsIndex patch

This fixes the IsIndex problem with "using" ... uploading so that people can
test.

Comment 4

[John Keiser (jkeiser)]

Perhaps we should revisit this when all our supported compilers support "using."
 Without that, as jag points out, you have to actually have a delegating call in
the subclass (virtual void x() { super::x(); }) in order to have parity on
non-compliant platforms.  Particularly, if you do "using X::x;" and someone
actually calls "x()" directly on your class, it will compile on major platforms
but break on OS/2 and OS9.

Setting dependent on bug 179118, the "drop VisualAge compiler on OS/2" bug.

Comment 5

[John Keiser (jkeiser)]

Thanks to biesi, who compiled on gcc 2.95.1 (I did it on gcc 3.2).  He reports
that gcc 2.95.1 errors out and doesn't want "using" to work in this circumstance:

In file included from ../../../../../layout/html/forms/src/nsIsIndexFrame.cpp:38:
../../../../../layout/html/forms/src/nsIsIndexFrame.h:160: cannot adjust access
to `nsresult nsBlockFrame::HandleEvent(nsIPresContext *, nsGUIEvent *,
nsEventStatus *)' in `class nsIsIndexFrame'
../../../../../layout/html/forms/src/nsIsIndexFrame.h:132: because of local
method `nsresult nsIsIndexFrame::HandleEvent(nsIDOMEvent *)' with same name
../../../../../layout/html/forms/src/../../base/src/nsBlockFrame.h:143: warning:
`nsBlockFrame::HandleEvent(nsIPresContext *, nsGUIEvent *, nsEventStatus *)' was
hidden
../../../../../layout/html/forms/src/nsIsIndexFrame.h:132: warning: by
`nsIsIndexFrame::HandleEvent(nsIDOMEvent *)'

Comment 6

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

would we be able to use |using| in NS_FORWARD_NSI* macros?

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 9

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Atul Aggarwal]

I could not find any errors in nsBlockFrame class. File nsIsIndexFrame.cpp does not exists anymore.

Verified it with linux/mac nightly builds also.