fix: Replace quote! with quote_spanned! in #[program] macro

[AvhiMaz]

Replaces all uses of quote!{} with quote_spanned! in the program macro
code generation to ensure generated code corresponds to correct source
code locations. This enables the Rust compiler to report error messages
at the actual problematic code instead of the macro invocation.

Changes:

• Applied quote_spanned! to all 9 codegen files
• Added spanned variants of helper functions
• Proper span extraction at instruction, program, and module levels

This addresses the requirements from issue #4015.

[vercel]

@AvhiMaz is attempting to deploy a commit to the Solana Foundation Team on Vercel.

A member of the Team first needs to authorize it.

[jamie-osec]

Please note that quote_spanned is not the correct solution in every case; it adds noise to the code so it should be used when it will improve developer UX - in particular consider when user code/identifiers (with potential errors) will be reflected in macro output and should be highlighted in error messages, or when a generated function will appear in a backtrace.

[AvhiMaz]

Please note that quote_spanned is not the correct solution in every case; it adds noise to the code so it should be used when it will improve developer UX - in particular consider when user code/identifiers (with potential errors) will be reflected in macro output and should be highlighted in error messages, or when a generated function will appear in a backtrace.

yaa true, i actually put quote_spanned in every file so I have gone through files and kept quote_spanned where it actually helps:

• instruction definitions and their trait impls - users need to see errors there
• handler wrappers and cpi methods - these show up in backtraces
• dispatch and entry functions - they're in the execution stack
• user's fallback handler - it's their code

removed it from the scaffolding stuff:

• module wrappers (accounts, cpi modules)
• idl dispatch (that's anchor internals)
• generated helper code with no user identifiers

should fix the issue now.

[0x4ka5h]

could you please make changes for cli's saftey checks?

• can you keep this issue (#3915) in mind so that changes should solve that issue too?
• can you also implement some tests to showcase the working? also I would recommend to add a CI workflow constrains to prove the changes are working as needed.

[AvhiMaz]

hi @0x4ka5h added fix for issue #3915 - safety checks now show struct names and correct line numbers. tests added and ci configured to validate it works. can you review it ? thanks

[Otter-0x4ka5h]

instead of pointing out to both#[program] and issue line, cant we just directly poke to the line where incident happens?
for eg:
instead

error: custom attribute panicked
 --> programs/account-info/src/lib.rs:5:1
  |
5 | #[program]
  | ^^^^^^^^^^
  |
  = help: message: Safety checks failed: 
                  /Users/0x4ka5h/Documents/intern/osec/development/anchor/tests/safety-checks/programs/account-info/src/lib.rs:21:0
                  Struct "Initialize1" field "unchecked" is unsafe, but is not documented.
                  Please add a `/// CHECK:` doc comment explaining why no checks through types are necessary.
                  Alternatively, for reasons like quick prototyping, you may disable the safety checks
                  by using the `skip-lint` option.
                  See https://www.anchor-lang.com/docs/the-accounts-struct#safety-checks for more information.
                              

vs

error: custom attribute panicked
 --> programs/account-info/src/lib.rs:21:0
     |
21 |  unchecked: AccountInfo<'info>,
     | ^^^^^^^^^^^^^^^^^^^^^^^^
     |
  = help: message: Safety checks failed: 
                  /Users/0x4ka5h/Documents/intern/osec/development/anchor/tests/safety-checks/programs/account-info/src/lib.rs:21:0
                  Struct "Initialize1" field "unchecked" is unsafe, but is not documented.
                  Please add a `/// CHECK:` doc comment explaining why no checks through types are necessary.
                  Alternatively, for reasons like quick prototyping, you may disable the safety checks
                  by using the `skip-lint` option.
                  See https://www.anchor-lang.com/docs/the-accounts-struct#safety-checks for more information.

[Otter-0x4ka5h]

Closes #3915 as well

[AvhiMaz]

instead of pointing out to both#[program] and issue line, cant we just directly poke to the line where incident happens? for eg: instead

error: custom attribute panicked
 --> programs/account-info/src/lib.rs:5:1
  |
5 | #[program]
  | ^^^^^^^^^^
  |
  = help: message: Safety checks failed: 
                  /Users/0x4ka5h/Documents/intern/osec/development/anchor/tests/safety-checks/programs/account-info/src/lib.rs:21:0
                  Struct "Initialize1" field "unchecked" is unsafe, but is not documented.
                  Please add a `/// CHECK:` doc comment explaining why no checks through types are necessary.
                  Alternatively, for reasons like quick prototyping, you may disable the safety checks
                  by using the `skip-lint` option.
                  See https://www.anchor-lang.com/docs/the-accounts-struct#safety-checks for more information.
                              

vs

error: custom attribute panicked
 --> programs/account-info/src/lib.rs:21:0
     |
21 |  unchecked: AccountInfo<'info>,
     | ^^^^^^^^^^^^^^^^^^^^^^^^
     |
  = help: message: Safety checks failed: 
                  /Users/0x4ka5h/Documents/intern/osec/development/anchor/tests/safety-checks/programs/account-info/src/lib.rs:21:0
                  Struct "Initialize1" field "unchecked" is unsafe, but is not documented.
                  Please add a `/// CHECK:` doc comment explaining why no checks through types are necessary.
                  Alternatively, for reasons like quick prototyping, you may disable the safety checks
                  by using the `skip-lint` option.
                  See https://www.anchor-lang.com/docs/the-accounts-struct#safety-checks for more information.

make sense, gotcha! i will update the implementation to point directly to the problematic field instead.

[jamie-osec]

While you're making changes, please address the earlier issues I raised with program_mod.span and Span::call_site

[Otter-0x4ka5h]

lgtm

[jamie-osec]

Also LGTM - would you mind squashing your changes into one commit so git history is a little cleaner? Thank you!

[AvhiMaz]

Also LGTM - would you mind squashing your changes into one commit so git history is a little cleaner? Thank you!

done!

[Otter-0x4ka5h]

@AvhiMaz can you makesure all tests should be passed

[AvhiMaz]

@AvhiMaz can you makesure all tests should be passed

yaa checking

[AvhiMaz]

hi @Otter-0x4ka5h, can you please trigger the CI again? hopefully, all test cases pass this time.

[AvhiMaz]

done, thanks !

[0x4ka5h]

lgtm @jamie-osec but i'm not sure by using Span::call_site()

[AvhiMaz]

lgtm @jamie-osec but i'm not sure by using Span::call_site()

I used Span::call_site() here because this is a macro-time error that occurs during the #[program] macro expansion. It points the user to the exact place where the macro was invoked, making it easier to debug. Am I wrong here?

what i thought if we use mixed_site() or def_site() would point inside the macro definition, which wouldn't be as helpful for end users, lmk if you'd prefer a different approach

[jamie-osec]

If you can address the latest comment and fix the merge conflicts this should be good to land

[AvhiMaz]

If you can address the latest comment and fix the merge conflicts this should be good to land

done