2019-12-03 20:55:18 -05:00
|
|
|
//! Convenience macro to declare a static public key and functions to interact with it
|
|
|
|
//!
|
|
|
|
//! Input: a single literal base58 string representation of a program's id
|
|
|
|
|
|
|
|
extern crate proc_macro;
|
|
|
|
|
|
|
|
use proc_macro::TokenStream;
|
Fix hygiene issues in `declare_program!` and `declare_loader!`
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`.
2020-06-20 01:42:11 -04:00
|
|
|
use proc_macro2::{Delimiter, Span, TokenTree};
|
2019-12-03 20:55:18 -05:00
|
|
|
use quote::{quote, ToTokens};
|
|
|
|
use std::convert::TryFrom;
|
|
|
|
use syn::{
|
2020-05-09 12:05:29 -06:00
|
|
|
bracketed,
|
2019-12-03 20:55:18 -05:00
|
|
|
parse::{Parse, ParseStream, Result},
|
2020-05-09 12:05:29 -06:00
|
|
|
parse_macro_input,
|
|
|
|
punctuated::Punctuated,
|
|
|
|
token::Bracket,
|
Fix hygiene issues in `declare_program!` and `declare_loader!`
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`.
2020-06-20 01:42:11 -04:00
|
|
|
Expr, Ident, LitByte, LitStr, Path, Token,
|
2019-12-03 20:55:18 -05:00
|
|
|
};
|
|
|
|
|
|
|
|
struct Id(proc_macro2::TokenStream);
|
|
|
|
impl Parse for Id {
|
|
|
|
fn parse(input: ParseStream) -> Result<Self> {
|
|
|
|
let token_stream = if input.peek(syn::LitStr) {
|
|
|
|
let id_literal: LitStr = input.parse()?;
|
2020-05-09 12:05:29 -06:00
|
|
|
parse_pubkey(&id_literal)?
|
2019-12-03 20:55:18 -05:00
|
|
|
} else {
|
|
|
|
let expr: Expr = input.parse()?;
|
|
|
|
quote! { #expr }
|
|
|
|
};
|
|
|
|
|
|
|
|
if !input.is_empty() {
|
|
|
|
let stream: proc_macro2::TokenStream = input.parse()?;
|
|
|
|
return Err(syn::Error::new_spanned(stream, "unexpected token"));
|
|
|
|
}
|
|
|
|
|
|
|
|
Ok(Id(token_stream))
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ToTokens for Id {
|
|
|
|
fn to_tokens(&self, tokens: &mut proc_macro2::TokenStream) {
|
|
|
|
let id = &self.0;
|
|
|
|
tokens.extend(quote! {
|
2020-06-17 19:57:23 -06:00
|
|
|
/// The static program ID
|
2019-12-03 20:55:18 -05:00
|
|
|
pub static ID: ::solana_sdk::pubkey::Pubkey = #id;
|
|
|
|
|
2020-06-17 19:57:23 -06:00
|
|
|
/// Confirms that a given pubkey is equivalent to the program ID
|
2019-12-03 20:55:18 -05:00
|
|
|
pub fn check_id(id: &::solana_sdk::pubkey::Pubkey) -> bool {
|
|
|
|
id == &ID
|
|
|
|
}
|
|
|
|
|
2020-06-17 19:57:23 -06:00
|
|
|
/// Returns the program ID
|
2019-12-03 20:55:18 -05:00
|
|
|
pub fn id() -> ::solana_sdk::pubkey::Pubkey {
|
|
|
|
ID
|
|
|
|
}
|
|
|
|
|
|
|
|
#[cfg(test)]
|
|
|
|
#[test]
|
|
|
|
fn test_id() {
|
|
|
|
assert!(check_id(&id()));
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Fix hygiene issues in `declare_program!` and `declare_loader!`
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`.
2020-06-20 01:42:11 -04:00
|
|
|
#[allow(dead_code)] // `respan` may be compiled out
|
|
|
|
struct RespanInput {
|
|
|
|
to_respan: Path,
|
|
|
|
respan_using: Span,
|
|
|
|
}
|
|
|
|
|
|
|
|
impl Parse for RespanInput {
|
|
|
|
fn parse(input: ParseStream) -> Result<Self> {
|
|
|
|
let to_respan: Path = input.parse()?;
|
|
|
|
let _comma: Token![,] = input.parse()?;
|
|
|
|
let respan_tree: TokenTree = input.parse()?;
|
|
|
|
match respan_tree {
|
|
|
|
TokenTree::Group(g) if g.delimiter() == Delimiter::None => {
|
|
|
|
let ident: Ident = syn::parse2(g.stream())?;
|
|
|
|
Ok(RespanInput {
|
|
|
|
to_respan,
|
|
|
|
respan_using: ident.span(),
|
|
|
|
})
|
|
|
|
}
|
2020-07-13 21:16:57 -04:00
|
|
|
val => Err(syn::Error::new_spanned(
|
Fix hygiene issues in `declare_program!` and `declare_loader!`
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`.
2020-06-20 01:42:11 -04:00
|
|
|
val,
|
|
|
|
"expected None-delimited group",
|
|
|
|
)),
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A proc-macro which respans the tokens in its first argument (a `Path`)
|
|
|
|
/// to be resolved at the tokens of its second argument.
|
|
|
|
/// For internal use only.
|
|
|
|
///
|
|
|
|
/// There must be exactly one comma in the input,
|
|
|
|
/// which is used to separate the two arguments.
|
|
|
|
/// The second argument should be exactly one token.
|
|
|
|
///
|
|
|
|
/// For example, `respan!($crate::foo, with_span)`
|
|
|
|
/// produces the tokens `$crate::foo`, but resolved
|
|
|
|
/// at the span of `with_span`.
|
|
|
|
///
|
|
|
|
/// The input to this function should be very short -
|
|
|
|
/// its only purpose is to override the span of a token
|
|
|
|
/// sequence containing `$crate`. For all other purposes,
|
|
|
|
/// a more general proc-macro should be used.
|
|
|
|
#[rustversion::since(1.46.0)] // `Span::resolved_at` is stable in 1.46.0 and above
|
|
|
|
#[proc_macro]
|
|
|
|
pub fn respan(input: TokenStream) -> TokenStream {
|
|
|
|
// Obtain the `Path` we are going to respan, and the ident
|
|
|
|
// whose span we will be using.
|
|
|
|
let RespanInput {
|
|
|
|
to_respan,
|
|
|
|
respan_using,
|
|
|
|
} = parse_macro_input!(input as RespanInput);
|
|
|
|
// Respan all of the tokens in the `Path`
|
|
|
|
let to_respan: proc_macro2::TokenStream = to_respan
|
|
|
|
.into_token_stream()
|
|
|
|
.into_iter()
|
|
|
|
.map(|mut t| {
|
|
|
|
// Combine the location of the token with the resolution behavior of `respan_using`
|
|
|
|
// Note: `proc_macro2::Span::resolved_at` is currently gated with cfg(procmacro2_semver_exempt)
|
|
|
|
// Once this gate is removed, we will no longer need to use 'unwrap()' to call
|
|
|
|
// the underling `proc_macro::Span::resolved_at` method.
|
|
|
|
let new_span: Span = t.span().unwrap().resolved_at(respan_using.unwrap()).into();
|
|
|
|
t.set_span(new_span);
|
|
|
|
t
|
|
|
|
})
|
|
|
|
.collect();
|
2020-07-13 21:16:57 -04:00
|
|
|
TokenStream::from(to_respan)
|
Fix hygiene issues in `declare_program!` and `declare_loader!`
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`.
2020-06-20 01:42:11 -04:00
|
|
|
}
|
|
|
|
|
2019-12-03 20:55:18 -05:00
|
|
|
#[proc_macro]
|
|
|
|
pub fn declare_id(input: TokenStream) -> TokenStream {
|
|
|
|
let id = parse_macro_input!(input as Id);
|
|
|
|
TokenStream::from(quote! {#id})
|
|
|
|
}
|
2020-05-09 12:05:29 -06:00
|
|
|
|
|
|
|
fn parse_pubkey(id_literal: &LitStr) -> Result<proc_macro2::TokenStream> {
|
|
|
|
let id_vec = bs58::decode(id_literal.value())
|
|
|
|
.into_vec()
|
|
|
|
.map_err(|_| syn::Error::new_spanned(&id_literal, "failed to decode base58 string"))?;
|
|
|
|
let id_array = <[u8; 32]>::try_from(<&[u8]>::clone(&&id_vec[..])).map_err(|_| {
|
|
|
|
syn::Error::new_spanned(
|
|
|
|
&id_literal,
|
|
|
|
format!("pubkey array is not 32 bytes long: len={}", id_vec.len()),
|
|
|
|
)
|
|
|
|
})?;
|
|
|
|
let bytes = id_array.iter().map(|b| LitByte::new(*b, Span::call_site()));
|
|
|
|
Ok(quote! {
|
|
|
|
::solana_sdk::pubkey::Pubkey::new_from_array(
|
|
|
|
[#(#bytes,)*]
|
|
|
|
)
|
|
|
|
})
|
|
|
|
}
|
|
|
|
|
|
|
|
struct Pubkeys {
|
|
|
|
method: Ident,
|
|
|
|
num: usize,
|
|
|
|
pubkeys: proc_macro2::TokenStream,
|
|
|
|
}
|
|
|
|
impl Parse for Pubkeys {
|
|
|
|
fn parse(input: ParseStream) -> Result<Self> {
|
|
|
|
let method = input.parse()?;
|
|
|
|
let _comma: Token![,] = input.parse()?;
|
|
|
|
let (num, pubkeys) = if input.peek(syn::LitStr) {
|
|
|
|
let id_literal: LitStr = input.parse()?;
|
|
|
|
(1, parse_pubkey(&id_literal)?)
|
|
|
|
} else if input.peek(Bracket) {
|
|
|
|
let pubkey_strings;
|
|
|
|
bracketed!(pubkey_strings in input);
|
|
|
|
let punctuated: Punctuated<LitStr, Token![,]> =
|
|
|
|
Punctuated::parse_terminated(&pubkey_strings)?;
|
|
|
|
let mut pubkeys: Punctuated<proc_macro2::TokenStream, Token![,]> = Punctuated::new();
|
|
|
|
for string in punctuated.iter() {
|
|
|
|
pubkeys.push(parse_pubkey(string)?);
|
|
|
|
}
|
|
|
|
(pubkeys.len(), quote! {#pubkeys})
|
|
|
|
} else {
|
|
|
|
let stream: proc_macro2::TokenStream = input.parse()?;
|
|
|
|
return Err(syn::Error::new_spanned(stream, "unexpected token"));
|
|
|
|
};
|
|
|
|
|
|
|
|
Ok(Pubkeys {
|
|
|
|
method,
|
|
|
|
num,
|
|
|
|
pubkeys,
|
|
|
|
})
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl ToTokens for Pubkeys {
|
|
|
|
fn to_tokens(&self, tokens: &mut proc_macro2::TokenStream) {
|
|
|
|
let Pubkeys {
|
|
|
|
method,
|
|
|
|
num,
|
|
|
|
pubkeys,
|
|
|
|
} = self;
|
|
|
|
if *num == 1 {
|
|
|
|
tokens.extend(quote! {
|
|
|
|
pub fn #method() -> ::solana_sdk::pubkey::Pubkey {
|
|
|
|
#pubkeys
|
|
|
|
}
|
|
|
|
});
|
|
|
|
} else {
|
|
|
|
tokens.extend(quote! {
|
|
|
|
pub fn #method() -> ::std::vec::Vec<::solana_sdk::pubkey::Pubkey> {
|
|
|
|
vec![#pubkeys]
|
|
|
|
}
|
|
|
|
});
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#[proc_macro]
|
|
|
|
pub fn pubkeys(input: TokenStream) -> TokenStream {
|
|
|
|
let pubkeys = parse_macro_input!(input as Pubkeys);
|
|
|
|
TokenStream::from(quote! {#pubkeys})
|
|
|
|
}
|