Open whoabuddy opened 1 year ago
Expanding on this a bit:
ccd006-city-mining.clar
and ccd007-city-stacking.clar
we're using the filter annotation on private functions. This is working with callee_filter = true
set.is-dao-or-extension
), or guarded functions that check is-self-or-extension
first. In those cases we'd like to indicate that the input should be trusted.trusted_sender
and trusted_callee
does not remedy the majority of them as expected. It's also difficult to see what changed given the number of warnings, and the fact the diffs don't match up well using clarinet check > filename
:
Example of git diff --no-index
between both text files above:
Shouldn't the files be created in the same order each time? Is there a better way to help visualize the diff here?
From there we still have some edge cases but so far the warnings are slowly getting cleaned up!
Shouldn't the files be created in the same order each time? Is there a better way to help visualize the diff here?
hey @whoabuddy! thanks for raising this issue. I noticed this issue, it is pretty annoying, specially in the context of deployments plans - dependencies get re-ordered, creating useless differences. I'll try to address this issue soon.
Ordering issue should be addressed with https://github.com/hirosystems/clarinet/pull/716/commits/cf8140e6534bfc1a2f01c09addcae3a45d85d290
We were experimenting with
callee_filter = true
in the CityCoins protocol (being updated here on this branch).This produced varying results with a public function that checks data through private functions.
The
mine
public function incontracts/extensions/ccd006-city-mining.clar
folds overmine-block
with response data, which calls a few other read-only/private functions to complete mining, including the private functionset-mining-data
.Adding the
callee_filter = true
required us to add filters to each private function, but they are designed to unwrap a value successfully or return an error.It would be great if we had a way to mark that a function will only accept clean data.
It also seems like
trusted_sender = true
andtrusted_caller = true
didn't have the intended effects on functions within the xDAO model, including:is-dao-or-extension
incontracts/base-dao.clar
is-self-or-extension
incontracts/extensions/*
We're working to reduce some of the check checker errors in the branch linked above so we can dig into the more meaty ones!