Naoya Hatta

I created a PR to add translation submodule to rust-lang/rust. If this PR is accepted, translation can be added without merging cost of the original maintainers. https://github.com/rust-lang/rust/pull/133562

https://github.com/rust-lang/rust/pull/133562 was rejected. So I'll consider about auto-merging approach again.

I'll close this PR. This is because it seems to be better that managing translation resources at external repository considering merging cost. Now I'm woriking on https://rust-lang-translations.org/.

I can merge the first commit [dec2a56](https://github.com/veryl-lang/veryl/pull/1487/commits/dec2a56a2e4bbd42ca1c6f1d8cb5faf714c5f01a). Or do you plan to change this PR to implementation of bit witdh check?

> You can merge as is, the width check will come later. OK. so could you revert other changes except dec2a56a2e4bbd42ca1c6f1d8cb5faf714c5f01a ? If I merge this PR as is, unexpected...

`;` at the end of case expression is not a part of expression. The `;` shows the end of statement. ```systemverilog // the following `;`s are same meaning let a:...

But the above case introduces statement without `;`. If so, the following case should be allowed? ``` module ModuleA { let a: logic = 1 // single statement without `;`...

Instead of `generic_for`, `generic for` may be more extensible like `generic if`, `generic case`.

> "generic for" is just expand generics, but "generic if" must evaluate the condition statements at veryl side. I thought that are there any implementation issues? Yes. So all operands...

@daohainam Hi, I started a new project to host translated documents of Rust. https://rust-lang-translations.org/ This project uses [mdbook-i18n-helpers](https://github.com/google/mdbook-i18n-helpers) to support continuous translation of documentation. Even if the original documentation is...