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

RESOLVED WORKSFORME

Status

()

P5
normal
RESOLVED WORKSFORME
16 years ago
a year ago

People

(Reporter: john, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Future
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [build_warning])

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
*** Bug 179029 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 2

16 years ago
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
Depends on: 35544, 42634, 129147, 129148
Summary: "X hides Y" warnings → Remove "X hides Y" warnings
(Reporter)

Comment 3

16 years ago
Created attachment 105603 [details] [diff] [review]
nsIsIndex patch

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

Comment 4

16 years ago
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.
Depends on: 179118
OS: Windows XP → All
Priority: -- → P5
Target Milestone: --- → Future
(Reporter)

Comment 5

16 years ago
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 *)'

Updated

16 years ago
Blocks: 187528
would we be able to use |using| in NS_FORWARD_NSI* macros?
Product: Browser → Seamonkey

Comment 7

10 years ago
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
Status: NEW → UNCONFIRMED

Comment 8

10 years ago
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

10 years ago
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

Updated

9 years ago
Assignee: asa → nobody
Component: General → General
Product: SeaMonkey → Core
QA Contact: asa → general

Updated

7 years ago
Whiteboard: [build_warning]

Comment 10

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

Verified it with linux/mac nightly builds also.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Summary: Remove "X hides Y" warnings → Remove "X hides Y" warnings in layout/html/forms/src/nsIsIndexFrame.cpp file
You need to log in before you can comment on or make changes to this bug.