For crds_gossip_pull, we want to parallelize build_crds_filters, which
requires concurrent writes to bloom filters.
This commit implements a variant of the bloom filter which uses atomics
for its bits vector and so is thread-safe.
(cherry picked from commit bb183938d9)
Co-authored-by: behzad nouri <behzadnouri@gmail.com>
* Record invoked instructions and store in transaction meta
* Enable cpi recording if transaction sender is some
* Rename invoked to innerInstructions
(cherry picked from commit 6601ec8f26)
Co-authored-by: Justin Starry <justin@solana.com>
* Implement keccak-secp256k1 instruction
Verifies eth addreses with ecrecover function
* Move secp256k1 test
Co-authored-by: sakridge <sakridge@gmail.com>
* Cache re-usable work performed by the loader (#12135)
(cherry picked from commit 3278d78f08)
# Conflicts:
# programs/bpf/Cargo.toml
# programs/bpf/tests/programs.rs
# programs/bpf_loader/Cargo.toml
* resolve conflicts
Co-authored-by: Jack May <jack@solana.com>
* Switch programs activation to whole-set based gating (#11750)
* Implement Debug for MessageProcessor
* Switch from delta-based gating to whole-set gating
* Remove dbg!
* Fix clippy
* Clippy
* Add test
* add loader to stable operating mode at proper epoch
* refresh_programs_and_inflation after ancestor setup
* Callback via snapshot; avoid account re-add; Debug
* Fix test
* Fix test and fix the past history
* Make callback management stricter and cleaner
* Fix test
* Test overwrite and frozen for native programs
* Test epoch callback with genesis-programs
* Add assertions for parent bank
* Add tests and some minor cleaning
* Remove unsteady assertion...
* Fix test...
* Fix DOS
* Skip ensuring account by dual (whole/delta) gating
* Fix frozen abi implementation...
* Move compute budget constatnt init back into bank
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
(cherry picked from commit db4bbb3569)
# Conflicts:
# genesis-programs/src/lib.rs
* Fix conflicts
Co-authored-by: Jack May <jack@solana.com>
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
* sdk: Make PubKey::create_program_address available in program unit tests (#11745)
* sdk: Make PubKey::create_program_address available in program unit tests
This finishes the work started in #11604 to have
`create_program_address` available when `target_arch` is not `bpf` and
`program` is enabled. Otherwise, there is an undefined reference error
to `sol_create_program_address`, which is only defined in `bpf`.
A small test to simply call the function has been added in order to catch
the problem in the future.
The default dependency to `solana-sdk/default` doesn't cause a problem with
existing programs since `build.sh` always specifies
`--no-default-features`, and programs in `solana-program-library` all
use it too.
* Add `default-features = false` for inter-program dependencies
Fix the build error found during CI. The `--no-default-features` flag
only applies to the top-level package, and not to dependencies. A program that
depends on another program, i.e. `128bit` which depends on `128bit_dep`,
must specify `default-features = false` when including that package,
otherwise the `bpf` build will try to pull in default packages, which
includes `std`.
(cherry picked from commit 9a366281d3)
# Conflicts:
# programs/bpf/rust/128bit/Cargo.toml
# programs/bpf/rust/invoke/Cargo.toml
# programs/bpf/rust/many_args/Cargo.toml
# programs/bpf/rust/param_passing/Cargo.toml
* resolve conflicts
Co-authored-by: Jon Cinque <jon.cinque@gmail.com>
Co-authored-by: Jack May <jack@solana.com>
* The constraints on compute power a program can consume is limited only to its instruction count (#11717)
(cherry picked from commit 8d362f682b)
# Conflicts:
# programs/bpf/Cargo.toml
# programs/bpf_loader/Cargo.toml
# programs/bpf_loader/src/lib.rs
# programs/bpf_loader/src/syscalls.rs
# runtime/src/bank.rs
# sdk/src/instruction.rs
* Resolve conflicts
* nudge
Co-authored-by: Jack May <jack@solana.com>
* Add failing test for decoding ShortU16 alias values
(cherry picked from commit 338f66f9aa)
* Factor out ShortU16 deser vistor logic to helper
(cherry picked from commit 6222fbcc66)
* Reimplement decode_len() with ShortU16 vistor helper
(cherry picked from commit 30dbe257cf)
Co-authored-by: Trent Nelson <trent@solana.com>
* Fix bad rent in Bank::deposit as if since epoch 0
* Remove redundant predicate
* Rename
* Start to add tests with some cleanup
* Forgot to add refactor code...
* Enchance test
* Really fix rent timing in deposit with robust test
* Simplify new behavior by disabling rent altogether
(cherry picked from commit 6c242f3fec)
Co-authored-by: Ryo Onodera <ryoqun@gmail.com>
The `declare_program!` and `declare_loader!` macros both expand to
new macro definitions (based on the `$name` argument). These 'inner'
macros make use of the special `$crate` metavariable to access items in
the crate where the 'inner' macros is defined.
However, this only works due to a bug in rustc. When a macro is
expanded, all `$crate` tokens in its output are 'marked' as being
resolved in the defining crate of that macro. An inner macro (including
the body of its arms) is 'just' another set of tokens that appears in
the body of the outer macro, so any `$crate` identifiers used there are
resolved relative to the 'outer' macro.
For example, consider the following code:
```rust
macro_rules! outer {
() => {
macro_rules! inner {
() => {
$crate::Foo
}
}
}
}
```
The path `$crate::Foo` will be resolved relative to the crate that defines `outer`,
**not** the crate which defines `inner`.
However, rustc currently loses this extra resolution information
(referred to as 'hygiene' information) when a crate is serialized.
In the above example, this means that the macro `inner` (which gets
defined in whatever crate invokes `outer!`) will behave differently
depending on which crate it is invoked from:
When `inner` is invoked from the same crate in which it is defined,
the hygiene information will still be available,
which will cause `$crate::Foo` to be resolved in the crate which defines 'outer'.
When `inner` is invoked from a different crate, it will be loaded from
the metadata of the crate which defines 'inner'. Since the hygiene
information is currently lost, rust will 'forget' that `$crate::Foo` is
supposed to be resolved in the context of 'outer'. Instead, it will be
resolved relative to the crate which defines 'inner', which can cause
incorrect code to compile.
This bug will soon be fixed in rust (see https://github.com/rust-lang/rust/pull/72121),
which will break `declare_program!` and `declare_loader!`. Fortunately,
it's possible to obtain the desired behavior (`$crate` resolving in the
context of the 'inner' macro) by use of a procedural macro.
This commit adds a `respan!` proc-macro to the `sdk/macro` crate.
Using the newly-stabilized (on Nightly) `Span::resolved_at` method,
the `$crate` identifier can be made to be resolved in the context of the
proper crate.
Since `Span::resolved_at` is only stable on the latest nightly,
referencing it on an earlier version of Rust will cause a compilation error.
This requires the `rustversion` crate to be used, which allows conditionally
compiling code epending on the Rust compiler version in use. Since this method is already
stabilized in the latest nightly, there will never be a situation where
the hygiene bug is fixed (e.g. https://github.com/rust-lang/rust/pull/72121)
is merged but we are unable to call `Span::resolved_at`.
