uriloader/prefetch - compiler warnings on mac

RESOLVED FIXED in mozilla21

Status

()

Core
Networking: HTTP
RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: joey, Unassigned)

Tracking

(Blocks: 1 bug)

unspecified
mozilla21
x86
Mac OS X
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [build_warning])

(Reporter)

Description

7 years ago
% uname -a
Darwin banshee.local 10.7.4 Darwin Kernel Version 10.7.4: Mon Apr 18 21:24:17 PDT 2011; root:xnu-1504.14.12~3/RELEASE_X86_64 x86_64


/mozilla/sandbox/gml/uriloader/prefetch/nsOfflineCacheUpdateService.cpp:96:1: warning: "LOG" redefined
/mozilla/sandbox/gml/ipc/chromium/src/base/logging.h:92:1: warning: this is the location of the previous definition
/mozilla/sandbox/gml/uriloader/prefetch/nsPrefetchService.cpp:857: warning: large integer implicitly truncated to unsigned type
/mozilla/sandbox/gml/uriloader/prefetch/OfflineCacheUpdateChild.cpp:77:1: warning: "LOG" redefined
/mozilla/sandbox/gml/ipc/chromium/src/base/logging.h:92:1: warning: this is the location of the previous definition
/mozilla/sandbox/gml/uriloader/prefetch/OfflineCacheUpdateParent.cpp:55:1: warning: "LOG" redefined
/mozilla/sandbox/gml/ipc/chromium/src/base/logging.h:92:1: warning: this is the location of the previous definition
/mozilla/sandbox/gml/uriloader/prefetch/OfflineCacheUpdateParent.cpp:145: warning: ignoring return value of 'bool mozilla::docshell::POfflineCacheUpdateParent::SendNotifyStateEvent(const PRUint32&)', declared with attribute warn_unused_result
/mozilla/sandbox/gml/uriloader/prefetch/OfflineCacheUpdateParent.cpp:156: warning: ignoring return value of 'bool mozilla::docshell::POfflineCacheUpdateParent::SendFinish(const bool&, const bool&)', declared with attribute warn_unused_result
/mozilla/sandbox/gml/uriloader/prefetch/OfflineCacheUpdateParent.cpp:175: warning: ignoring return value of 'bool mozilla::docshell::POfflineCacheUpdateParent::SendAssociateDocuments(const nsCString&, const nsCString&)', declared with attribute warn_unused_result
(Reporter)

Updated

7 years ago
Whiteboard: [build_warnings]
bz: do you know if we want to have FORCE_PR_LOG set for uriloader?  I can't seem to discern any coherent policy about what types of logging we actually want to be available in release builds.

The LOG redefine warnings are all the result of including some e10s-related file, which causes chromium .h files to include prlog.h and also #define LOG differently than we do.

If we want uriloader logging on in releases, we'll need to #define FORCE_PR_LOG and go through the whole song-and-dance routine that's in nsHttp.h to get it all right (see bug 545995).  If we don't need release logging, we can just put #undef LOG before all our #define LOG calls.

I haven't looked at the other warnings--likely to be unrelated.
> bz: do you know if we want to have FORCE_PR_LOG set for uriloader? 

It might be nice.

> I can't seem to discern any coherent policy about what types of logging we
> actually want to be available in release builds.

"All logging that doesn't hurt performance" is what I would prefer.  ;)

Updated

7 years ago
Whiteboard: [build_warnings] → [build_warning]

Updated

7 years ago
Blocks: 187528

Comment 3

5 years ago
https://hg.mozilla.org/mozilla-central/rev/97e4d66bc5fc fixed:
  nsOfflineCacheUpdateService.cpp [...] "LOG" redefined
  OfflineCacheUpdateChild.cpp     [...] "LOG" redefined

Bug 782594 ( https://hg.mozilla.org/mozilla-central/rev/3bb941410b40 ) fixed:
  nsPrefetchService.cpp [...] large integer implicitly truncated to unsigned type

Bug 756717 ( https://hg.mozilla.org/mozilla-central/diff/293dee8a857a/uriloader/prefetch/OfflineCacheUpdateParent.cpp ) fixed (or at least looks fixed to me):
  OfflineCacheUpdateParent.cpp [...] "LOG" redefined

Bug 833931 fixed/silenced:
  OfflineCacheUpdateParent.cpp [...] ignoring return value [...] SendNotifyStateEvent
  OfflineCacheUpdateParent.cpp [...] ignoring return value [...] SendFinish
  OfflineCacheUpdateParent.cpp [...] ignoring return value [...] SendAssociateDocuments


Not sure if I'm allowed to touch the Target Milestone field for a bug resolved fixed in this fashion, so I'm leaving it alone.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
I usually go off the TM of the last-resolved bug for situations like these :)
Target Milestone: --- → mozilla21

Comment 5

5 years ago
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #4)
> I usually go off the TM of the last-resolved bug for situations like these :)

OK, thanks!
You need to log in before you can comment on or make changes to this bug.