docs: rename RedundantAssignEliminator to UnusedAssignEliminator + other small corrections

[minaminao]

In #12310 , RedundantAssignEliminator was renamed to UnusedAssignEliminator , but the documentation wasn't updated, so I fixed it.
FYI, the current implementation is here: https://github.com/ethereum/solidity/blob/29041c8101d13a5e4372e9c2b94e83a5e254d66e/libyul/optimiser/Suite.cpp#L313

Also, fixed several typos.

[github-actions]

Thank you for your contribution to the Solidity compiler! A team member will follow up shortly.

If you haven't read our contributing guidelines and our review checklist before, please do it now, this makes the reviewing process and accepting your contribution smoother.

If you have any questions or need our help, feel free to post them in the PR or talk to us directly on the #solidity-dev channel on Matrix.

[r0qs]

Thanks @minaminao, just have some comments :)

[r0qs]

The comment in the paragraph above and code-block in question with the version 0.5.4 was only meant as an example of a specific docker image tag. I believe we don't plan to keep bumping this information on every release, so I don't really see need to update it. But I'm fine with the change if you think it makes it more clear. The typo For example, You... should be fixed indeed.

[minaminao]

I believe we don't plan to keep bumping this information on every release

Yes, I agree with you! But do you think the version 0.5.4 is a too old?

Btw, I saw the following tweet about the Vyper bug.

https://twitter.com/WuBlockchain/status/1685827572033363968

Vyper official documentation recommendation is actually a faulty version. A bug in the smart contract language layer means that almost all protocols using Vyper are affected. Fortunately most protocols such as Uniswap use Solidity instead of the less popular Vyper. According to Slowmist

This tweet is wrong. It's clear from the Vyper's documentation that the 0.2.15 version is just an example version, and they don't recommend the 0.2.15 version.
But when I see this kind of misunderstanding, I think the version should be updated once in a while.

[r0qs]

I believe we don't plan to keep bumping this information on every release

Yes, I agree with you! But do you think the version 0.5.4 is a too old?

Yes it is, but as it is mean as an example, I don't really expect that anyone would think that we are recommending such version, because we are not. However, I'm fine with the change, but this version will become obsolete in the next release anyway.

[cameel]

Like @r0qs said, this was not meant to be kept up to date and will go out of date again soon. But you do have a point. Some users could copy it without making sure it's a recent version, especially if they're new to Solidity and don't know that 0.5.x is ancient by now. We should replace it with a tag pointing at the latest version and just mention in the surrounding text that tags for specific versions are available too. Then an out of date version would not be such a problem because people would get the latest one by default.

Suggested change

	docker run ethereum/solc:0.8.21 --help
	docker run ethereum/solc:stable --help

[cameel]

Also, this currently sits in a commit described as fix: typo. Something like this should really get a separate commit.

[minaminao]

@cameel Thanks for your comment.
The current documentation already describes a command using stable as follows, and changing the specific version to stable seems unnatural to me.

As an alternative, I think using 0.x.y is good: docker run ethereum/solc:0.x.y --help.
0.x.y is used at the beginning of this page and on other pages, so users can understand it.

You're right about the commit issue, so I split it into separate commits!

[cameel]

Ah, true :) I did not notice that we already have stable above.

In that case I don't think this bit with a specific version is even needed. I mean, with a concrete version it did make some sense, but if you replace it with x.y.z, I think we're better off only mentioning that as a part of the surrounding text like I suggested.

BTW, I'd use x.y.z instead of 0.x.z. That bit you screenshotted specifically refers to major release 0 so it's relevant there, but in the rest of the docs, we don't have to assume we're at 0. The number will go up some day and the less we'll have to update then the better :)

[r0qs]

In that case I don't think this bit with a specific version is even needed. I mean, with a concrete version it did make some sense, but if you replace it with x.y.z, I think we're better off only mentioning that as a part of the surrounding text like I suggested.

Yeah, maybe it is better indeed to do what @cameel suggested and only mention the use with tags for specific version in the surrounding text, removing it from the example. @minaminao if you do that, we can already merge it :)

[minaminao]

@r0qs
used colons and squashed the commit!

[cameel]

Thanks for the corrections!

I'd be fine with merging it already, but it would be best to change the docker tag to stable first as I suggested in comments below.

[cameel]

Like @r0qs said, this was not meant to be kept up to date and will go out of date again soon. But you do have a point. Some users could copy it without making sure it's a recent version, especially if they're new to Solidity and don't know that 0.5.x is ancient by now. We should replace it with a tag pointing at the latest version and just mention in the surrounding text that tags for specific versions are available too. Then an out of date version would not be such a problem because people would get the latest one by default.

Suggested change

	docker run ethereum/solc:0.8.21 --help
	docker run ethereum/solc:stable --help

[cameel]

Also, this currently sits in a commit described as fix: typo. Something like this should really get a separate commit.

[mehtavishwa30]

Thank you for your contribution. I will make a small change to accommodate @cameel's comment regarding changing the docker tag to stable and clarifying that version tags are available in surrounding text. This is to ensure users get the latest version by default and avoid an out-of-date version.

Will commit the change and merge once all checks pass. :)

[r0qs]

Looks good to me. Just one last comment ;)