Disabling warnings can be tricky, because doing so can cause a different
compiler to create new warnings about unsupported disable flags. Also, some
warnings don't surface until they're paired with another warning (gcc). For
example, adding "-Wno-foo" won't cause any trouble, but if there's a legitimate
warning emitted, the "unknown option -Wno-foo" will show up as well.
Work around this in 2 ways:
1. When checking to see if -Wno-foo is supported, check for "-Wfoo" instead.
2. Enable -Werror while checking 1.
If "-Werror -Wfoo" compiles, "-Wno-foo" is almost guaranteed to be supported.
-Werror itself is also checked. If that fails to compile by itself, it likely
means that the user added a flag that adds a warning. In that case, -Werror
won't be used while checking, and the build may be extra noisy. The user would
need to fix the bad input flag.
Also, silence 2 more additional warnings that can show up post-c++11.
This was doing more harm than good. The original intention was to speed up
builds, since a PR's ccache results will be thrown away anyway.
However, each PR maintains its own cache, so disabling writes means that
subsequent pushes don't benefit from the fresh cache. This is significant when
(for example) many headers are touched in a PR, then the PR is updated. With
this change, the updated PR will take advantage of the cache generated during
the PR's previous build.
f154470 [contrib] Remove reference to sf and add doc to verify.sh (MarcoFalke)
182bec4 contrib: remove hardcoded version from verify.sh (Wladimir J. van der Laan)
c907f4d doc: Update release process (Wladimir J. van der Laan)
869cf12 dbwrapper: Move `HandleError` to `dbwrapper_private` (Wladimir J. van der Laan)
b69836d dbwrapper: Pass parent CDBWrapper into CDBBatch and CDBIterator (Wladimir J. van der Laan)
878bf48 dbwrapper: Remove CDBWrapper::GetObfuscateKeyHex (Wladimir J. van der Laan)
74f7b12 dbwrapper: Remove throw keywords in function signatures (Wladimir J. van der Laan)
Pass parent wrapper directly instead of obfuscation key. This
makes it possible for other databases which re-use this code
to use other properties from the database.
Add a namespace dbwrapper_private for private functions to be used
only in dbwrapper.h/cpp and dbwrapper_tests.
Using throw() specifications in function signatures is not only
not required in C++, it is considered deprecated for
[various reasons](https://stackoverflow.com/questions/1055387/throw-keyword-in-functions-signature).
It is not implemented by any of the common C++ compilers. The usage is
also inconsistent with the rest of the source code.
Without this patch:
- When I compile the GUI from the bitcoin directory itself, it works as
expected.
- When I build the GUI in an out-of-tree build, I cannot get it to
select tabs. When I click, say the "Receive" tab nothing happens,
the button selects but it doesn't switch the page. The rest - even
the debug window - seems to work.
See full discussion here:
https://github.com/bitcoin/bitcoin/pull/7911#issuecomment-212413442
This turned out to be caused by a mismatch in the arguments to moc,
preventing it from finding `bitcoin-config.h`. Fix this by passing
`$(DEFAULT_INCLUDES)` to it, which gets set to the appropriate
path by autoconf itself.
SetString seems to be passing the length of the wrong variable to
memory_cleanse, resulting in the last byte of the temporary buffer not being
securely erased.
Previously we would assert that if every block in vBlockHashesToAnnounce is in
chainActive, then the blocks to be announced must connect. However, there are
edge cases where this assumption could be violated (eg using invalidateblock /
reconsiderblock), so just check for this case and revert to inv-announcement
instead.
Rather than allowing CNetAddr/CService/CSubNet to launch DNS queries, require
that addresses are already resolved.
This greatly simplifies async resolve logic, and makes it harder to
accidentally leak DNS queries.
Note: Some seeds aren't actually returning an IP for their name entries, so
they're being added to addrman with a source of [::].
This commit shouldn't change that behavior, for better or worse.
Wladimir J. van der Laan