5e531e6beb5381c0be5efaa24b7e423e593568e4 assumptions: check C++17 assumption with MSVC (fanquake)
c7b46489f8c4d880382248fb47266d81948bbce0 assumptions: assume a C++17 compiler (fanquake)
Pull request description:
This has been the case since #20413.
This should also enable the check for MSVC. From my reading of https://docs.microsoft.com/en-us/cpp/build/reference/zc-cplusplus?view=msvc-160 and https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/ if we set the `/Zc:__cplusplus` switch in additional options, MSVC will report the correct value for `__cplusplus`. However I have not tested this.
ACKs for top commit:
laanwj:
Code review ACK 5e531e6beb5381c0be5efaa24b7e423e593568e4
hebasto:
ACK 5e531e6beb5381c0be5efaa24b7e423e593568e4, checked the MS docs, and AppVeyor build is green.
practicalswift:
ACK 5e531e6beb5381c0be5efaa24b7e423e593568e4
Tree-SHA512: a4fb525cf5c33abc944c614edb0313a39c8a39a1637a03c09342c15ba0925f4eb037062e65e51b42ade667506b7e554c7159acf86e6b8c35d0a87dd79a6f239b
By default, a popup menu contains checkable entries for the toolbars
and dock widgets present in the main window. This allows users to
accidentally hide the toolbar.
5786a818e1a96bc1dd65b0e81b05998876357a74 Verify that all validation flags are backward compatible (gzhao408)
b10ce9aa48c8937cb91fca05e29c68098a364d93 [test] check verification flags are minimal/maximal (gzhao408)
a260c22cad0672dda11f42f649ebdc7cfa53b16a [test] Check for invalid flag combinations (gzhao408)
a7098a2a8d2d23ee3be1d71ab8c71475bf5a31ee [refactor] use CheckTxScripts, TrimFlags, FillFlags (gzhao408)
7a77727b2f66f3d723e03e917f0cabb459c49d62 Apply minimal validation flags to tx_invalid tests (gzhao408)
9532591bedaecf7c2debe779dec0a0debec2623b [test] add BADTX setting for invalid txns that fail CheckTransaction (gzhao408)
4c06ebf1281f0f387ab7493fe15176a05247525e [test] fix two witness tests in invalid tests with empty vout (gzhao408)
158a0b268ca2f73a5d504791359d1eff2cf27715 Apply maximal validation flags to tx_valid tests (gzhao408)
0a76a39b633760d4668d39859605c05629ee0025 [test] fix CSV test missing OP_ADD (gzhao408)
19db590d044efe7d474a16720e5b56e7b55db54c [test] remove unnecessary OP_1s from CSV and CLTV tests (gzhao408)
Pull request description:
This uses the first 4 commits of #15045, rebased and added some comments. The diff is quite large already and I want to make it easy to review, so I'm splitting it into 2 PRs (transaction and script). Script one is WIP, I'll link it when I open it.
Interpretation of scripts is dependent on the script verification flags passed in.
In tests, we should always apply **maximal** verification flags when checking that a transaction is **valid**; any additional flags should invalidate the transaction. A transaction should not be valid because we forgot to include a flag, and we should apply all flags by default.
We should apply **minimal** verification flags when asserting that a transaction is **invalid**; if verification flags are applied, removing any one of them should mean the transaction is valid.
New verify flags must be backwards compatible; tests should check backwards compatibility and apply the new flags by default. All `tx_invalid` tests should continue to be invalid with the exact same verify flags. All `tx_valid` tests that don't pass with new flags should _explicitly_ indicate that the flags need to be excluded, and fail otherwise.
1. Flip the meaning of `verifyFlags` in tx_valid.json to mean _excluded_ verification flags instead of included flags. Edit the test data accordingly.
2. Trim unneeded flags from tx_invalid.json.
3. Add check to verify that tx_valid tests have maximal flags and tx_invalid tests have minimal flags.
4. Add checks to verify that flags are soft forks (#10699) i.e. adding any flag should only decrease the number of acceptable scripts. Test by adding/removing random flags.
ACKs for top commit:
achow101:
ACK 5786a818e1a96bc1dd65b0e81b05998876357a74
laanwj:
ACK 5786a818e1a96bc1dd65b0e81b05998876357a74
Tree-SHA512: 19195d8cf3299e62f47dd3443ae4a95430c5c9d497993a18ab80de9e24b1869787af972774993bf05717784879bc4592fdabaae0fddebd437963d8f3c96d9a73
e348d7ea2c0b5d2eb8039dab33b0b9a48655885f qt: Add Copy Address Action to Payment Requests (Jarol Rodriguez)
Pull request description:
Currently, the only way to copy the address of a payment request is to double-click on the payment request and then click on the copy address button. This PR adds a convenient context menu action to copy the address of a payment request.
| Master | PR |
| ----------- | ------------ |
|<img width="169" alt="Screen Shot 2021-02-18 at 8 33 08 PM" src="https://user-images.githubusercontent.com/23396902/108444489-b6703f80-7228-11eb-8684-945fbcd04772.png"> |<img width="169" alt="Screen Shot 2021-02-18 at 8 33 50 PM" src="https://user-images.githubusercontent.com/23396902/108444505-c12ad480-7228-11eb-9eee-473fee877ad7.png">|
ACKs for top commit:
hebasto:
re-ACK e348d7ea2c0b5d2eb8039dab33b0b9a48655885f, only suggested changes since my [previous](https://github.com/bitcoin-core/gui/pull/213#pullrequestreview-595520204) review.
Tree-SHA512: 2b75930ca326ef1d695afc1c6f25853ef55d06d20b66c3c3c372188a6cdfa4686c07f9c56824b766e46b660c731f8a9c2e5b935aa26b316fd46f9e396b29b802
Currently, the only way to copy the address of a payment request is to double-click on the payment request and then click on the copy address button. This commit adds a convenient context menu action to copy the address of a payment request.
fa1f3a26a7541ba82a28c2a5fd09401be825c888 doc: Clarify that squashing should happen before review (MarcoFalke)
Pull request description:
Unlike other repos, in our repo code review happens before merge, ideally.
Thus, rebases, solving merge conflicts and squashing should happen before review, which again happens before merge.
ACKs for top commit:
theStack:
ACK fa1f3a26a7541ba82a28c2a5fd09401be825c888
fanquake:
ACK fa1f3a26a7541ba82a28c2a5fd09401be825c888
Tree-SHA512: e9222191a6e9cf9867bd1f29982526dd7b746b70dd2cc94f485256ec98ff2d3941c9b40728935e151d13795239334e334b71ad41044909cb2849f57776811a94
a6a1b106dcc4350e420c461171c47e4934087175 guix: only download sources for hosts being built (fanquake)
Pull request description:
For example, if a user is only interested in building for Linux, this saves downloading the macOS compiler and additional dependencies, which is meaningful on a slow/poor connection. This will result in a few additional `make` invocations, for the Linux hosts, however this is low overhead, and time-wise irrelevant in terms of the overall build.
ACKs for top commit:
laanwj:
Code review ACK a6a1b106dcc4350e420c461171c47e4934087175
Tree-SHA512: 34c916ae6f69fed0d5845690b39111a8bee37208fd727176f375cf5eb4860f512abe12bde2680d697c859b4d50a3bc5688ddca7c2f28f9968fcf358753cf3f6d
95990b9f3278360b63e79d6975af4ab5009c66ba guix: Update conservative space requirements (Carl Dong)
5e6df1132656995ce5b9ce279d5a9808ea52ab32 guix: Add support for powerpc64{,le} (Carl Dong)
Pull request description:
```
The new time-machine commit contains a few small changes that make the
powerpc cross-toolchain work.
```
See this compare to review my custom patches to Guix: 7d6bd44da5...6c9d16db96
ACKs for top commit:
fanquake:
ACK 95990b9f3278360b63e79d6975af4ab5009c66ba
Tree-SHA512: 464b0fb93d65962d8c27499293edb618d13d18f40d44e3eed96935e86d430666dfb1c5b8a30f99ffdfd17b44514ad88e358977390b689a2e3831d521f6f7b86a
The warning label shown on the overview page does not look clickable.
This PR makes the warning label look clickable by removing the 'flat' property.
Additionally, the Maximum Width is updated to fix the small hit-box issue.
...also update comments to remove mention of ::ChainActive()
From: https://github.com/bitcoin/bitcoin/pull/20750#discussion_r579400663
> Also, what about passing a const reference instead of a pointer? I
> know this is only theoretical, but previously if the tip was nullptr,
> then Height() evaluated to -1, now it evaluates to UB
ccb7b6a97652b45f60e0ac680a239bc6058b9773 contrib: run test-symbol check for RISCV (fanquake)
Pull request description:
Now that we are using Focal for gitian building (glibc 2.31), we can use a newer introduced symbol, and include RISC-V in this test.
ACKs for top commit:
laanwj:
Code review re-ACK ccb7b6a97652b45f60e0ac680a239bc6058b9773
Tree-SHA512: 4ddaafc0b6cced49a504847ed8da02b0a514eca69014fdc2ad01068c6f8ddf9ad992525f47b2a182c3b4a5845f8dacfe5a7e4acf2f303a5dab6a70daa3b89509
-BEGIN VERIFY SCRIPT-
# Rename
sed -i -e 's/MakeFuzzingContext/MakeNoLogFileContext/g' $(git grep -l MakeFuzzingContext)
# Bump the copyright of touched files in this scripted diff to avoid touching them again later
./contrib/devtools/copyright_header.py update ./src/test/fuzz/
-END VERIFY SCRIPT-
25c57d640992255ed67964a44b17afbfd4bed0cf [doc] Add a note about where lock annotations should go. (Amiti Uttarwar)
ad5f01b96045f304b6cf9100879592b835c49c40 [validation] Move the lock annotation from function definition to declaration (Amiti Uttarwar)
Pull request description:
Based on reviewing #21188
the first commit switches the lock annotations on `CheckInputScripts` to be on the function declaration instead of on the function definition. this ensures that all call sites are checked, not just ones that come after the definition.
the second commit adds a note to the developer-notes section to clarify where the annotations should be applied.
ACKs for top commit:
MarcoFalke:
ACK 25c57d640992255ed67964a44b17afbfd4bed0cf 🥘
promag:
Code review ACK 25c57d640992255ed67964a44b17afbfd4bed0cf.
Tree-SHA512: 61b6ef856bf6c6016d535fbdd19daf57b9e59fe54a1f30d47282a071b9b9d60b2466b044ee57929e0320cb1bdef52e7a1687cacaa27031bbc43d058ffffe22ba
fa55159b9ede4a915f8ef9e5b90e3e99eadedf91 net: Log to net debug in MaybeDiscourageAndDisconnect except for noban and manual peers (MarcoFalke)
Pull request description:
The goal is to avoid local peers (e.g. untrusted peers on the local network or inbound onion peers via a local onion proxy) filling the debug log (and thus the disk).
ACKs for top commit:
practicalswift:
ACK fa55159b9ede4a915f8ef9e5b90e3e99eadedf91
vasild:
ACK fa55159b9ede4a915f8ef9e5b90e3e99eadedf91
Tree-SHA512: de233bf57334580f9b91f369fafd131d71c5ae25db25b09cc8fa8cbf34c0648f083c52260a6a912238751467e3c3c5f5d2309c145710753058d44a0003f88f4f
8f9644890a167a093d95ecef1f12a20dce1bc581 qt: Remove Transactionview Edit Label Action (Jarol Rodriguez)
Pull request description:
This PR removes the `Edit Label` action from the `transactionview` context menu. Since the `Edit Label` action will no longer be utilized in the `transactionview`, the `Edit Label` function logic is also removed.
| Master | PR |
| ----------- | ----------- |
|<img width="248" alt="Screen Shot 2021-02-17 at 8 34 34 PM" src="https://user-images.githubusercontent.com/23396902/108292189-9b86c800-7161-11eb-9e80-6238523bc27e.png">|<img width="248" alt="Screen Shot 2021-02-17 at 8 35 10 PM" src="https://user-images.githubusercontent.com/23396902/108292204-a17ca900-7161-11eb-8582-7f33d3e2ba8f.png">|
Among the context menu actions for each transaction in the `transactionview` is the `Edit Label` action.
While all other actions apply directly to the selected transaction, the `Edit Label` action applies to the selected transaction's address. As documented in issue #209 and [#1168](https://github.com/bitcoin/bitcoin/issues/1168) , this is an "unfortunate" placement for such an action. The current placement creates a confusing UX scenario where the outcome of the action is ambiguous.
**Example of Ambiguous Behavior:**
The context menu gives the wrong impression that the `Edit Label` action will edit a `Label` for the specific transaction that has been right-clicked on. This impression can be because all other actions in this menu will relate to the specific transaction and the misconception between `Comment` and `Label`.
<img width="1062" alt="editlabel-start" src="https://user-images.githubusercontent.com/23396902/108296385-6da48200-7167-11eb-89f0-b21ccc58f6f4.png">
Let's say I wanted to give the transaction selected in the screenshot above a comment of "2-17[17:43]". Given all the context clues, it will be reasonable to assume that the `Edit Label` function will give a label to this transaction. Instead, it edits the `Label` for the address behind this transaction. Thus, changing the `Label` for all transactions associated with this address.
<img width="971" alt="editlabel-end" src="https://user-images.githubusercontent.com/23396902/108297179-e35d1d80-7168-11eb-86a9-0d2796c51829.png">
**Maintaining `Edit Label` Functionality:**
The action of Editing a Label should instead be reserved for the respective address tables of the `Send` and `Receive` tabs. As documented in this [comment](https://github.com/bitcoin-core/gui/issues/209#issuecomment-780922101), `Edit Label` is currently implemented in the `Send` tab and is missing in the `Receive` tab. A follow-up PR can add the `Edit Label` functionality to the `Receive` tab.
ACKs for top commit:
MarcoFalke:
review ACK 8f9644890a167a093d95ecef1f12a20dce1bc581
Talkless:
tACK 8f9644890a167a093d95ecef1f12a20dce1bc581, tested on Debian Sid.
Tree-SHA512: 70bbcc8be3364b0d4f476a9760aa14ad1ad1f53b0b130ce0ffe75190d76c386e6e26c530c0a55d1742402fe2b45c68a2af6dbfaf58ee9909ad93b06f0b6559d4
142807af8b82e2372a03df893c50df4f4a96aca4 gui: display BIP152 high bandwidth relay in peer details (Jon Atack)
9476886353dffb730dcb75799f2bd5e143425795 gui: display fRelayTxes in peer details (Jon Atack)
Pull request description:
This pull adds two fields to the peer details, "Wants Tx Relay" (fRelayTxes) and "High Bandwidth" (bip152_highbandwidth to/from). See the added tooltips for more info.
ACKs for top commit:
MarcoFalke:
review ACK 142807af8b82e2372a03df893c50df4f4a96aca4
jarolrod:
ACK 142807af8b82e2372a03df893c50df4f4a96aca4
Tree-SHA512: 956c7fa54c9c2ea76ee879d370711be0bed4af05484a17d35a1dd77713ed34ff441ed3957d0ef3a7ca7cf59a2f5d898be49b12af609a16b3e3cbfc4a1ba8f54e
3913d1e8c1f604bdd622d5e81e5077ef52b30466 qt: Drop buggy TableViewLastColumnResizingFixer class (Hennadii Stepanov)
Pull request description:
In Qt 5 the last column resizing with dragging its left edge works out-of-the-box.
The current `TableViewLastColumnResizingFixer` implementation could put the last column content out of the view port and confuse a user:
Historical context:
- https://github.com/bitcoin/bitcoin/pull/2862
- https://github.com/bitcoin/bitcoin/pull/3626
- https://github.com/bitcoin/bitcoin/pull/3738
- https://github.com/bitcoin/bitcoin/pull/3920#205 is a nice addition.
ACKs for top commit:
jarolrod:
ACK 3913d1e8c1f604bdd622d5e81e5077ef52b30466, tested on macOS 11.1 Qt 5.15.2
Talkless:
tACK 3913d1e8c1f604bdd622d5e81e5077ef52b30466, tested on Debian Sid. Can confirm that behavior in previous commit does not produce scroll bar, last column gets "hidden". This PR makes clear that there's more to see in the view.
promag:
Tested ACK 3913d1e8c1f604bdd622d5e81e5077ef52b30466 on macos.
Tree-SHA512: 12582dfce54bb1db3d9934ae092e305d32e9760cc99b0265322e161fa7f54b7d6fb6cefedf700783f767d5c3a56a8545c8d2f5ade66596c4e67b8a5287063e8a
8353e8cecc3e34a8699b53849df0adab622c1c14 peers-tab: bug fix right panel toggle (randymcmillan)
Pull request description:
Initial Presentation:
When node row selected - panel is presented:
When network disabled - right panel is hidden:
ACKs for top commit:
jarolrod:
ACK 8353e8cecc3e34a8699b53849df0adab622c1c14
jonatack:
ACK 8353e8cecc3e34a8699b53849df0adab622c1c14 tested rebased on current master. Behavior is initially a bit surprising but this would allow more columns to be added to the peers tab window. Verified that selecting more than one peer, clicking on a column header, or running `disconnectnode "" <currently-selected-peer-id>` in the console (or on the CLI with the `-server` startup option) returns the window to its full size. If this is merged, it might be nice to have an obvious way to close the details area like a clickable "close this" icon in the upper left corner of the area.
Talkless:
tACK 8353e8cecc3e34a8699b53849df0adab622c1c14, tested on Debian Sid. Made `bitcoind` connect to `bitcoin-qt` with the PR changes, and after I quit the `bitcoind` instance, right panel do disappear, compared to the previous commit where it didn't.
Tree-SHA512: 8fc156f40bdd61e3ba8db333c729a2a07fd5f0fd1eed56f2fd2aa5ae5864756f8ab6fad74ae2fb0552ee7518b6d489f5800709e6c80c6f31f61fd8ce21cece5f
be4cf4832f117ab5f97e1367f7bdcb5361de0dae gui: update to "Direction/Type" peer details name/tooltip (Jon Atack)
151888383a772fd5be626b6ed25af183f0395a41 gui: add "Type" column to Peers main window (Jon Atack)
6fc72bd6f030c8b49e8b9f68188413766a239d73 gui: allow ConnectionTypeToQString to prepend direction optionally (Jon Atack)
Pull request description:
This pull:
- adds a sortable `Type` column to the GUI Peers tab window
- updates the peer details row to `Direction/Type`, so the `Type` column without a direction makes sense (the tooltip is also updated)
ACKs for top commit:
jarolrod:
ACK be4cf4832f117ab5f97e1367f7bdcb5361de0dae
leonardojobim:
Tested ACK be4cf4832f on Ubuntu 20.04 on VMWare.
Tree-SHA512: 6c6d1dbe7d6bdb616acff0aaf8f4223546f1d2524566e9cd6e5b1b3bed2be1e9b20b1bc52ed3b627df53ba1f2fe0bc76f036cf16ad934d8a446b515d9bece3b1
If a user is only interested in building for Linux, this saves
downloading the macOS compiler and additional dependencies.
This will result in a few additional `make` invocations, for the Linux
hosts, however this is quite low overhead.
Co-authored-by: Carl Dong <contact@carldong.me>
