near_bindgen methods with no self check for attached deposit

[austinabell]

Methods like this will add the codegen assumed when a contract mutates state. A slightly strange pattern we have that defaults to checking this only when the parameter is &mut self even though in any function there can be state changes not tied to the contract state.

Tying the check for attached deposit to whether or not contract state changes is a strange pattern IMO but the band-aid fix is to just remove this check when contract state isn't used. This needs to be done so that these methods can be called with a view operation, otherwise, the runtime will fail when trying to call env::attached_deposit from within a view call.

#[near_bindgen]
pub struct SomeContract;

#[near_bindgen]
impl SomeContract {
    pub fn get_val(s: &String) -> Option<u8> 

    { // ... } 

// ...

Test for this looks like:

#[test]
fn no_self_no_args() {
    let impl_type: Type = syn::parse_str("Hello").unwrap();
    let mut method: ImplItemMethod = syn::parse_str("pub fn method() { }").unwrap();
    let method_info = ImplItemMethodInfo::new(&mut method, impl_type).unwrap();
    let actual = method_info.method_wrapper();
    let expected = quote!(
       #[cfg(target_arch = "wasm32")]
       #[no_mangle]
       pub extern "C" fn method() 

       { near_sdk::env::setup_panic_hook(); Hello::method(); } 

     );
    assert_eq!(expected.to_string(), actual.to_string());
}

which is currently failing because it adds the extra check

[itegulov]

Just to be clear, codegen having a check for the attached deposit is a side effect of such functions being identified as call functions.

_{Also, the markdown is all messed up again, curse you exalate}

[HumbertoTM10]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I have 4 years working in development environments, have encountered several challenges, requests and teams focusing in reusable and efficient code, so that gives me a better understanding of the code and how to solve problems efficiently.

How I plan on tackling this issue

My approach here would be adding checks for env::attached_deposit in NEAR contract methods, the solution involves refining the code generation logic to more accurately distinguish between view methods and state-changing methods.

[PrincesoDan]

I am applying to this issue via OnlyDust platform.

My background and how it can be leveraged

I'm developer working around blockchain

[Krishn1412]

I’d like to help with this.