Closed Bug 68790 Opened 24 years ago Closed 24 years ago

fixing C++ standard problems in some headers

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED
mozilla0.9

People

(Reporter: brendan, Assigned: harishd)

Details

Attachments

(1 file)

I'm slowly trying to massage mozilla so it will build successfully with the current development copy of gcc, which is destined to come out as gcc 3.0. I had to make some changes to headers to not introduce declarations of ostream and other things that were plain classes, but are now templates according to the C++ standard. In htmlparser/src/nsHTMLContentSinkStream.h, I had to make it also see the newer g++: #if !defined(XP_MAC) && !defined(__KCC) && !(defined(__GNUC__) && defined(__GNUC_MINOR__) && __GNUC_MINOR__ >= 97) class ostream; #endif B
Marking NEW to get someone to get it into tbe build.
Status: UNCONFIRMED → NEW
Component: Layout → Build Config
Ever confirmed: true
Keywords: patch, review
Parser stuff
Assignee: karnaze → harishd
This is akkana's realm. Handing over to her.
Assignee: harishd → akkana
Why are we even building nsHTMLContentSinkStream? I thought that was replaced by the html content serializer. Johnny and Joe, what's up with this? Is this all duplicate code with the html serializer now?
Assignee: akkana → jst
after staring at lxr a while I think no one is using it. But it is a supported component in parser, ie somone in the future could ask the parser "hey give me an nsHTMLContentSinkStream". right now no one is I think (though several files include it's header and a couple even have the cid defined). It's worth noting that this thing isn't really the same as the serializer. The serializer is for going from content to stream. nsHTMLContentSinkStream is just a sink for the parser that builds a stream rather than content. AFAIK it's really for parser testing. Seems like a useful thing. I wouldn't nuke it, though we could take it out of the opt build.
The html serializer can act as a content sink, too, or that was my understanding. The code in nsHTMLContentSinkStream is orphaned and will bitrot, so it should be removed and anyone who wants a content sink that does that should ask for the serializer instead. (Johnny can correct me if I'm wrong about that.) Having two classes which do the same thing, where only one of them is used in our code but a client can ask for the other one, is just asking for trouble.
ok, i'll shut up. Looking at the serializers i see some methods that use parser nodes and some that use content, so i guess they can be parser sinks. In which casde I agree that the other sink should go.
The sink is currently needed in one place only, and that's in nsParser::IsValidFragment(), which is called from nsRange::IsValidFragmen() that is defined in nsIDOMNSRange, i.e. in our proprietary range interface. nsIDOMNSRange::IsValidFragment() is not used anywhere in our codebase, and I talked to Vidur and he said if it's not used and nobody is planning on using it any time soon, let's get rid of it. If we'd do that we can remove the HTMLContentSinkStream once n' for all. Editor people, thoughts?
If it's no longer needed for CreateContextualFragment (and if Vidur says it isn't, then it isn't), let's nuke that puppy.
I'm sure Harish would love to rip this code out of the parser :-) Reassigning.
Assignee: jst → harishd
OS: Linux → All
Hardware: PC → All
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
Attached patch Patch v1.1Splinter Review
sr=jst, when you check in, please remove the nsHTMLContentSinkStream_CID definition from xpcom/base/IIDS.h too.
Like Johnny said, remove also nsHTMLContentSinkStream_CID in xpcom/base/IIDS.h. Also, remove nsHTMLContentSinkStream.h export in htmlparser/src/MANIFEST. With those fixes, r=heikki.
Fix is in... Marking FIXED.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Marking verified per last comments.
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: