666670 - uriloader/prefetch - compiler warnings on mac

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect)

Description

[Joey Armstrong [:joey]]

% 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

Comment 1

[Jason Duell]

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.

Comment 2

[Boris Zbarsky [:bzbarsky]]

> 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.  ;)

Comment 3

[:Cykesiopka]

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.

Comment 4

[Ryan VanderMeulen [:RyanVM]]

I usually go off the TM of the last-resolved bug for situations like these :)

Comment 5

[:Cykesiopka]

(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!