Notable changes in the range:
* r132735 (hopefully) fixes a bug introduced in r131951 that made
gold 1.10 crash with
/usr/bin/ld: internal error in set_offset, at output.cc:4030
* r132535 fixes the crash at -O3 on mac
* r132565 adds a warning for "x + y ? a : b" to -Wparentheses
BUG=85289,84424
TEST=none
TBR=evan
Review URL: http://codereview.chromium.org/7046048
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88344 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
clang recently added a warning that warns when invoking 'delete' on a polymorphic non-final class without a virtual destructor. This finds real bugs – see the bug referenced below for a few examples.
However, one common pattern where it fires is this case:
class SomeInterface {
public:
virtual void interfaceMethod() {} // or = 0;
protected:
~SomeInterface() {}
}
class WorkerClass : public SomeInterface {
public:
// many non-virtual functions, but also:
virtual void interfaceMethod() override { /* do actual work */ }
};
void f() {
scoped_ptr<WorkerClass> c(new WorkerClass); // simplified example
}
(See the 2nd half of http://www.gotw.ca/publications/mill18.htm for an explanation of this pattern.)
It is arguably correct to fire the warning here, since someone might make a subclass of WorkerClass and replace |new WorkerClass| with |new WorkerClassSubclass|. This would be broken since WorkerClass doesn't have a virtual destructor.
The solution that the clang folks recommend is to mark WorkerClass as |final| (a c++0x keyword that clang supports as an extension in normal c++ mode – like override). But chrome's base/OWNERS deemed that as too complicated and we decided to make virtual the destructors of leaf classes that implement these interfaces and that are deleted dynamically. All of the changes in this CL are to shut up the warning, not because of real problems (I fixed these in separate CLs).
(For the gtk files, this is necessary because the CHROMEGTK_CALLBACK_ macros add virtual functions.)
BUG=84424
TEST=none
Review URL: http://codereview.chromium.org/7087028
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88270 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
The OS-level registration isn't implemented on Linux, and so every time the
browser starts it will act as though another program has been registered to
handle the protocols it knows about and deregister them all internally.
Review URL: http://codereview.chromium.org/7024043
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88246 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
In chrome/browser/task_manager I moved notifications related code to their own files and allow exclusion and stubbing via GYP. Similarly I have added stubs for other parts including a chrome/browser/notifications/notification_stubs.cc which takes care of classes within that directory.
I also created some static methods in DesktopNotificationService to wrap commonly used notification related code so that we reduce the amount of stubs required.
BUG=none
TEST=existing notification tests succeed
Review URL: http://codereview.chromium.org/7053041
git-svn-id: http://src.chromium.org/svn/trunk/src/build@88040 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This change implements a settings page that allows users to manage protocol
handlers registered via navigator.registerProtocolHandler.
tony: could you review the ProtocolHandlerRegistry stuff?
estade: could you review the webui stuff?
Thanks!
TEST=Unit tests provided.
Review URL: http://codereview.chromium.org/7033018
git-svn-id: http://src.chromium.org/svn/trunk/src/build@86762 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
is just a prototype for us to play with. There are plenty of issues to
resolve before its made real, but I wanted to check something in for
others to play with rather than keeping it all local. To get it to
compile you need to set the GYP_DEFINE to views_compositor.
BUG=none
TEST=none
R=ben@chromium.org,apatrick@chromium.org
Review URL: http://codereview.chromium.org/7067029
git-svn-id: http://src.chromium.org/svn/trunk/src/build@86516 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Chromium has also been built on other BSDs, so rather than adding each Unix to every gyp file individually every time another port is added, these broad defines can be used instead and modified with specific logic only where necessary.
I included a few modified gyp files so the usage can be seen. I also added sunos5 to some grd/html files and set the default host_arch on i86pc solaris to ia32.
BUG=0
TEST={}
Patch by ruben <chromium@hybridsource.org>.
Review URL: http://codereview.chromium.org/6965007
git-svn-id: http://src.chromium.org/svn/trunk/src/build@85154 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With ICF the linker merges identical functions into one block of assembly,
which leads to
a) wrong symbols for some functions - which is debugger/Valgrind-unfriendly
b) all ThreadSanitizer annotations end up being one function which makes TSan crazy.
Since we run release code (with -O1 -g) on Valgrind bots,
we have to disable ICF if release_valgrind_build!=0.
BUG=82114
TEST=linux_tsan trybot goes green
TEST=`gclient runhooks` with and w/o GYP_DEFINES="release_valgrind_build=1"
and `grep "\-\-icf" base/base.target.mk`
Review URL: http://codereview.chromium.org/7004005
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84833 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With ICF the linker merges identical functions into one block of assembly,
which leads to
a) wrong symbols for some functions - which is debugger/Valgrind-unfriendly
b) all ThreadSanitizer annotations end up being one function which makes TSan crazy.
Since we run release code (with -O1 -g) on Valgrind bots,
we have to disable ICF if release_valgrind_build!=0.
BUG=82114
TEST=linux_tsan trybot goes green
Review URL: http://codereview.chromium.org/6991009TBR=timurrrr@chromium.org
Review URL: http://codereview.chromium.org/6995026
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84804 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
With ICF the linker merges identical functions into one block of assembly,
which leads to
a) wrong symbols for some functions - which is debugger/Valgrind-unfriendly
b) all ThreadSanitizer annotations end up being one function which makes TSan crazy.
Since we run release code (with -O1 -g) on Valgrind bots,
we have to disable ICF if release_valgrind_build!=0.
BUG=82114
TEST=linux_tsan trybot goes green
Review URL: http://codereview.chromium.org/6991009
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84802 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Mark says: "When GCC_STRICT_ALIASING is YES, Xcode adds -fstrict-aliasing to the compiler command line. When it’s NO, it doesn’t add anything (not even -fno-strict-aliasing). Xcode doesn’t know that -fstrict-aliasing is on at our selected optimization level."
So add this directly to OTHER_CLFAGS.
BUG=32204
TEST=none
Review URL: http://codereview.chromium.org/6909037
git-svn-id: http://src.chromium.org/svn/trunk/src/build@84064 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
This requires disabling most /W4 warnings so the patch doesn't get too large.
I still fixed a few bugs so I didn't have to disable some more serious warnings. Most of these warnings are already enabled on gcc so it's mostly windows-specific code that is affected.
BUG=none
TEST=none
Review URL: http://codereview.chromium.org/6902069
git-svn-id: http://src.chromium.org/svn/trunk/src/build@83840 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
- Add two gypi files to src/build for the boilerplate added to targets and actions
- Update grit_info to also support the -E flag so it can share more of the grit build commandline
- switch over all but the webkit and webkit glue grd files to use the common support
BUG=22247
TEST=everything still localized correctly
Review URL: http://codereview.chromium.org/6705030
git-svn-id: http://src.chromium.org/svn/trunk/src/build@79548 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Missing variable definition added.
We have found that being forced to pass '--debug-devtools' isn't
convenient for DevTools developers, and decided to always load DevTools
files from disk, if Chromium was compiled with 'debug_devtools' flag set
in .gyp
BUG=none
TEST=none
TBR=pfeldman@chromium.org
git-svn-id: http://src.chromium.org/svn/trunk/src/build@79528 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
Gives 'out of the box' compatability with VC2008 express - i.e. no modifications needed to system headers or .gyp* files or related hacks. Just set the GYP_MSVS_VERSION to 200Xe (e for express, same as the linked blog on the issue and first google hit as well).
1) Changes to build\common.gypi to turn off to define COMPILER_MSVC_EXPRESS if a express is detected (through the GYP_MSVC_VERSION environment variable), turn off the _SECURE_ATL define (which is flagged as an error with WinDDK's ATL, _SECURE_ATL adds [more] CRT checks to other ATL versions) and hard to link to the atl stdthunk library with express editions. Also, explicitly link to the base WinSDK libraries in common.gypi and mini_installer.gypi for MSVC 2005 express.
2) Fixes a few .cc files that have the wrong include order with the ATL headers when using the Windows DDK ATL. The Windows DDK ATL brings in intsafe.h (WinSDK, not WinDDK) with atlwin.h and generates multiple INTXX_MIN/MAX def warnings which get
flagged as errors with the warnings as errors flag if not included before other libraries that have the same definitions like ICU.
3) Changes to .rc files to avoid pulling in afxres.h (an MFC header -
it's available in the WinDDK) and winres.h which VCExpress doesn't have (it's available in a WinSDK sample, but that kind of the purpose of it). The main Chromium .rc files are already structured this way, I just changed the rest and changed the output of grit to do the same.
4) Removes the memset obj file linking in mini_installer.gyp and simply implements memset for mini_installer.cc.
Only changes to the chromium branch now. There are some .rc files in the Python26, Native Client, and Angle in samples that could #3 changes. They are not required for Chromium, however.
------
VC2005SP1 can be downloaded at
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=7B0B0339-613A-46E6-AB4D-080D4D4A8C4E&displaylang=en
(or non-SP1 at http://download.microsoft.com/download/8/3/a/83aad8f9-38ba-4503-b3cd-ba28c360c27b/ENU/vcsetup.exe)
VC2008SP1 can be downloaded at
http://www.microsoft.com/downloads/en/details.aspx?FamilyId=F3FBB04E-92C2-4701-B4BA-92E26E408569&displaylang=en
currently.
The base developer instructions work fine afterwards with a couple tweaks for express versions:
http://www.chromium.org/developers/how-tos/build-instructions-windows
Under "Additional (free) downloads" under step 2:
X) Only the first 3 Non-SP KB Patches are needed for express. Don't forget to forget GYP_MSVS_VERSION environment as appropriate - 2008e for Visual C++ 2008 Express, for example.
Under "Additional (free) downloads" after step 5
[These only apply to 2008 express, 2005 works fine out of the box]:
6A) Download the WinDDK for the atl headers and libs -
http://msdn.microsoft.com/en-us/windows/hardware/gg487463.aspx. It works fine, but you do not need to install the whole DDK. In the WDK directory just install headers.msi, libs_x86fre.msi, and libs_x64fre.msi; just grab the atl headers and atl*.lib libs; right click the installers and uninstall afterwards. Add the appropriate include and lib paths to your global settings.
6B) To build x64 targets (x64 Native Client) download:
http://www.cppblog.com/Files/xcpp/VCE64BIT_WIN7SDK.zip
Follow the readme instructions.
Further information behind that and x64 target building with express:
- http://jenshuebel.wordpress.com/2009/02/12/visual-c-2008-express-edition-and-64-bit-targets/
- http://www.cppblog.com/xcpp/archive/2009/09/09/vc2008express_64bit_win7sdk.html
----------------
BUG=1433, 5026, 72885
TEST=Compiles in both Debug and Release mode in Visual C++ Express 2008/2005 and does not effect other build setups. In addition, the WinDDK ATL compiles with the secure_atl=0 in the GYP_DEFINES environment variable on non-express versions of MSVC.
Review URL: http://codereview.chromium.org/6676030
git-svn-id: http://src.chromium.org/svn/trunk/src/build@78921 4ff67af0-8c30-449e-8e8b-ad334ec8d88c
thakis@chromium.org
jam@chromium.org
koz@chromium.org
satish@chromium.org
piman@chromium.org
jknotten@chromium.org
tony@chromium.org
nirnimesh@chromium.org
nirnimesh@google.com
sky@chromium.org
hashimoto@chromium.org
fta@sofaraway.org
evan@chromium.org
mdm@chromium.org
mark@chromium.org
rkc@chromium.org
timurrrr@chromium.org
bradnelson@google.com
maruel@chromium.org
raymes@chromium.org
rvargas@google.com
penghuang@chromium.org
zelidrag@chromium.org
fischman@chromium.org
thomasvl@chromium.org
mnaganov@chromium.org