chore: remove knowledge of aztec function types from compiler #4975
Conversation
|
I'm assuming that all the contract artifacts get fed through the AVM transpiler so perhaps this could parse the custom attributes and set the function type, etc (although this could just be done on the fly). |
There was a problem hiding this comment.
Looks good, thanks @TomAFrench! I just left a question to double check, but if it's fine, I'll merge with my PR. Next step (which I can tackle) would be to tweak yarn-project/types/src/abi/contract_artifact.ts#loadContractArtifact to understand the attributes for populating the fields we expect in ts-land.
| match ty { | ||
| "Private" => func.def.return_distinctness = Distinctness::Distinct, | ||
| "Public" => func.def.is_open = true, | ||
| "Public" => func.def.is_unconstrained = true, |
There was a problem hiding this comment.
For compilation purposes (ie emitting ACIR or Brillig or AVM bytecode), is it equivalent to flag the function as unconstrained instead of open? @TomAFrench @Maddiaa0 @sirasistant
There was a problem hiding this comment.
"open" implies AVM, no? We should compile to brillig in this case so we should tell the Noir compiler that it should compile the function as if it were unconstrained.
There was a problem hiding this comment.
We don't output AVM bytecode so we can only output ACIR or brillig.
This PR removes the concept of a function being internal or "open" from the Noir compiler as these are now concepts which are aztec specific. We instead attach all of a contract functions custom attributes to it in the build artifact so aztec can parse these to determine whether a function is open or secret, etc. @spalladino This follows on from #4967 but I've made this as a separate PR into yours as I don't want to hijack it.
This PR removes the concept of a function being internal or "open" from the Noir compiler as these are now concepts which are aztec specific. We instead attach all of a contract functions custom attributes to it in the build artifact so aztec can parse these to determine whether a function is open or secret, etc. @spalladino This follows on from #4967 but I've made this as a separate PR into yours as I don't want to hijack it.
This PR removes the concept of a function being internal or "open" from the Noir compiler as these are now concepts which are aztec specific. We instead attach all of a contract functions custom attributes to it in the build artifact so aztec can parse these to determine whether a function is open or secret, etc. @spalladino This follows on from #4967 but I've made this as a separate PR into yours as I don't want to hijack it.
This PR removes the concept of a function being internal or "open" from the Noir compiler as these are now concepts which are aztec specific. We instead attach all of a contract functions custom attributes to it in the build artifact so aztec can parse these to determine whether a function is open or secret, etc. @spalladino This follows on from #4967 but I've made this as a separate PR into yours as I don't want to hijack it.
This PR removes the concept of a function being internal or "open" from the Noir compiler as these are now concepts which are aztec specific. We instead attach all of a contract functions custom attributes to it in the build artifact so aztec can parse these to determine whether a function is open or secret, etc. @spalladino This follows on from #4967 but I've made this as a separate PR into yours as I don't want to hijack it.
This PR removes the concept of a function being internal or "open" from the Noir compiler as these are now concepts which are aztec specific. We instead attach all of a contract functions custom attributes to it in the build artifact so aztec can parse these to determine whether a function is open or secret, etc.
@spalladino This follows on from #4967 but I've made this as a separate PR into yours as I don't want to hijack it.