fix(proc macros): don't use params as name

[niklasad1]

Because jsonrpsee's internal proc macro code was using params as internal variable name it could conflict and with params in the user's API in such case it may try to overwrite the "wrong" variable.

In this PR I have renamed this internal variable to something much weirder which should be quite unlikely that anyone will use and panic if those collide to make it easier to debug.

Close #1362

[niklasad1]

@CodiumAI-Agent /review

[CodiumAI-Agent]

PR Review

⏱️ Estimated effort to review [1-5]	3, because the changes involve understanding the context of macro usage and ensuring that the renaming and error handling logic are correctly implemented without introducing new issues.
🧪 Relevant tests	No
🔍 Possible issues	Possible Bug: The code checks for conflicts with the ILLEGAL_PARAM_NAME by comparing against the string representation, but it should compare against the Ident representation directly. This might not catch all potential conflicts.
🔒 Security concerns	No

Code feedback:

---

relevant file	proc-macros/src/render_client.rs
suggestion	Consider using a more robust method for generating a unique identifier rather than a fixed string. This could involve using a UUID or a similarly unique generator to minimize the risk of name collisions further. [important]
relevant line	const ILLEGAL_PARAM_NAME: &str = "__________________params";

---

relevant file	proc-macros/src/render_client.rs
suggestion	Instead of panicking directly when a name collision is detected, it might be better to return an error from the function. This would allow the caller to handle the error more gracefully. [important]
relevant line	panic!("Cannot use `{}` as a parameter name", ILLEGAL_PARAM_NAME);

---

relevant file	proc-macros/src/render_client.rs
suggestion	To ensure that the identifier comparison is accurate, compare Ident directly rather than converting both to a string. This avoids issues with different representations leading to false negatives. [important]
relevant line	if param_names.iter().any(|name| name == ILLEGAL_PARAM_NAME) {

---

relevant file	proc-macros/src/render_client.rs
suggestion	Add a unit test to verify that the new logic correctly handles scenarios where the user's API might use the ILLEGAL_PARAM_NAME. This is crucial to ensure that the panic behavior works as expected. [important]
relevant line	if param_names.iter().any(|name| name == ILLEGAL_PARAM_NAME) {

---

---

✨ Review tool usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.

The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

• When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

• With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

See the review usage page for a comprehensive guide on using this tool.

[jsdw]

The only wee thing is that this might provoke some sort of clippy warning about _ being used in front of a variable that's in use, but perhaps not an issue (and you could call it eg jsonrpsee__params or whatever if it was) :)

[niklasad1]

I double checked and async trait ignores the let _x = .. warning but I also changed this to camelCase which will be a warning if someone is using it in their API.

I also ignore's to the related lints this to be on the safe-side.