Disallow deployment of deprecated _sol_alloc_free syscall #24986
Conversation
jackcmay
added
the
feature-gate
jackcmay
force-pushed
the
no-new-alloc-free-dependencies
branch
3 times, most recently
from
9c9afc1 to
70c0532
Compare
cli/src/program.rs
Outdated
| @@ -176,6 +178,13 @@ impl ProgramSubCommands for App<'_, '_> { | |||
| .long("allow-excessive-deploy-account-balance") | |||
| .takes_value(false) | |||
| .help("Use the designated program id even if the account already holds a large balance of SOL") | |||
| ) | |||
| .arg( | |||
| Arg::with_name("enable_sol_alloc_free") | |||
There was a problem hiding this comment.
@CriesofCarrots, @jstarry By default after these changes are released, the cli will no longer deploy programs that depend on sol_alloc_free syscall unless the caller specifies this hidden flag. This should be no issue for rust developers because rust programs haven't used this syscall for a long time. C programs that explicitly call alloc/free will fail to deploy unless they pick up the latest SDK. What do you think about this behavior, think we should instead default to allowing it for now?
There was a problem hiding this comment.
My opinion is that the earlier we prevent clients from hitting code paths that will soon be feature gated off, the better. So I'm of the opinion that we don't need to have any flag at all. But if there's some use-case that you're thinking of, a hidden flag to enable seems fine. Definitely in favor of defaulting to disallow here.
There was a problem hiding this comment.
I agree with Justin, and also lean toward no flag at all.
If you do feel the hidden flag is necessary, can we add some documentation about when it will no longer work, and when it can be removed?
There was a problem hiding this comment.
The only reason we would need the flag is if someone is building with an older tool chain but deploying it with this version and doing so before the alloc_free disable feature gate is activated
jackcmay
force-pushed
the
no-new-alloc-free-dependencies
branch
2 times, most recently
from
ea8d115 to
519ce6a
Compare
jackcmay
force-pushed
the
no-new-alloc-free-dependencies
branch
from
519ce6a to
71faf4a
Compare
jackcmay
force-pushed
the
no-new-alloc-free-dependencies
branch
from
71faf4a to
623f7bf
Compare
jackcmay
added
the
automerge
Codecov Report
@@ Coverage Diff @@
## master #24986 +/- ##
=========================================
Coverage 82.0% 82.1%
=========================================
Files 598 610 +12
Lines 165882 167804 +1922
=========================================
+ Hits 136125 137853 +1728
- Misses 29757 29951 +194 |
…lana-labs#24986)" This reverts commit 8f1d4c1.
…lana-labs#24986)" This reverts commit 8f1d4c1.
…lana-labs#24986)" This reverts commit 8f1d4c1.
…lana-labs#24986)" This reverts commit 8f1d4c1.
…lana-labs#24986)" This reverts commit 8f1d4c1.
Problem
Programs are now built with an in-program and customizable heap implementation. There is no more need for the built-in bump allocator syscall. To end-of-life that syscall, future deployments depending on it should fail.
Summary of Changes
_sol_alloc_freeFixes #
Feature Gate Issue: #24985