feat: clang format & tidy + CI#393
Conversation
998cad7 to
107ece1
Compare
9d1365d to
369494f
Compare
| auto keccak_hash = ethash_keccak256(reinterpret_cast<uint8_t const*>(func_sig_cstr), strlen(func_sig_cstr)); | ||
| // get a pointer to the start of the hash bytes | ||
| uint8_t const* hash_bytes = reinterpret_cast<uint8_t const*>(&keccak_hash.word64s[0]); | ||
| auto const* hash_bytes = reinterpret_cast<uint8_t const*>(&keccak_hash.word64s[0]); |
There was a problem hiding this comment.
Not sure I like that this is being changed from uint8_t to auto, but I can live with it.
There was a problem hiding this comment.
Consistent approach throughout, which I got used to, ove the 160 files :D
There was a problem hiding this comment.
It seems to only switch to auto when the type is obvious. And that is what I say to do in our standard.
|
|
||
| Contract<NCT>(std::string const& contract_name) | ||
| : contract_name(contract_name) | ||
| explicit Contract<NCT>(std::string const& contract_name) : contract_name(contract_name) |
There was a problem hiding this comment.
This seems to be the only explicit constructor. I wonder why it chose to make this one explicit (and others not)?
There was a problem hiding this comment.
Hm, not sure why it didn't change others too.... I can look into it.
| static std::vector<Note> UTXO_SLOAD(UTXOSetStateVar<Composer, Note>* utxo_set_state_var, | ||
| size_t const& num_notes, | ||
| typename Note::NotePreimage const& advice); | ||
| template <typename Note> static std::vector<Note> UTXO_SLOAD(UTXOSetStateVar<Composer, Note>* utxo_set_state_var, |
There was a problem hiding this comment.
Might be more legible if we always put template <...> on a line before the function declaration. Not worth pauding this PR, though.
There was a problem hiding this comment.
We can choose to do have it always on its own line, sometimes on its own line, or just let people use their best judgement. What do you think?
|
|
||
| const NT::address msg_sender = NT::fr(1); | ||
| const NT::address tx_origin = msg_sender; | ||
| const NT::address& tx_origin = msg_sender; |
There was a problem hiding this comment.
Should this be a reference? If msg_sender changes, we don't want tx_origin to change...
Maybe it's ok in this particular case, because tx_origin is probably only used below to initialise structs... and I think (???) it will always create a copy of the value of tx_origin, rather than passing a reference. Makes me nervous, though.
There was a problem hiding this comment.
It shouldn't be a problem here because they are both const I believe. But yes you make a good point about it adding & in general. I'll look through and see if there are any sketchy spots where it did this.
| template <typename KernelInput> | ||
| void propagate_valid_state_transitions(KernelInput const& public_kernel_inputs, | ||
| KernelCircuitPublicInputs<NT>& circuit_outputs) | ||
| template <typename KernelInput> void propagate_valid_state_transitions(KernelInput const& public_kernel_inputs, |
There was a problem hiding this comment.
Again, not sure I like this moving down to be on same line as function declaration. Seems like in some files it does this, in some files it leaves it.
There was a problem hiding this comment.
That doesn't seem right. Maybe I have the settings different for functions/structs/enums/classes. I'll look into it.
iAmMichaelConnor
left a comment
There was a problem hiding this comment.
A few comments, but none of those need stop merging
Description
This PR does the following:
.clang-format.clangdsettings to provide more VSCode warnings for bad code./scripts/tidy.sh fixwould change code.clang-tidy).clang-format)Checklist: