[cfe-dev] 经过一些思考,我想,如果clang和llvm能提供多语言支持的话,必定会扩大其影响力.使计算机程序和代码世界变得更多彩更丰富和更多可能性./After some reflection, I think that if clang and llvm can provide multi-language support, it will certainly expand its influence to make computer programs and code the world more colorful and more possibilities

[Renato Golin via cfe-dev]

On 20 October 2016 at 09:31, nk1988 <kingff13 at gmail.com> wrote:
> 1, for each programming language can add a custom interface
> characters, my idea is because I understand that llvm have their own
> assembly, which is the middle code? Bytecode?

Right, so this is case 2) of my suggestions: translate C++.

Formally, if we were going to do this, we'd need the C++ standard's
blessing, and probably some formal description of the process and
ABIs.

But you can start doing this on your own like Daniel said:

Solution 1: Develop a script that does the translation "before" calling Clang.

$ translate-cpp chinese.cpp > temp.cpp
$ clang temp.cpp

This only works if you use "Chinese like English" and if you get used
to the format of the new code. The problems you'll face with this
approach are:

1. If you stray from the strictly accepted Chinese symbols, you may
have leaked Chinese into "temp.cpp", which will confuse Clang.
2. The C++ error messages will be all in English

Fixing 2 above can be done if "translate-cpp" is a wrapper for Clang,
which decodes Chinese to English, calls Clang, then decodes English
error messages into Chinese, and present to the user.

Fixing 1 will need syntax checking on your wrapper program, which can
be hard to do.


Solution 2: Change Clang to accept multiple languages for the identifiers.

This will involve changing Clang to read from different language
files, which can be chosen via a command line "--language=chinese".
Given that most identifiers don't make it out in the object output,
this could work well. The problems you're likely to face are:

1. Debug information (example, type names) will be in Chinese.
Non-Chinese users of your libraries will have problems debugging it.
2. Calling standard library functions (like malloc/free) will either
have to remain in English or be translated in Clang.

Fixing 1 and 2 above is a matter of always loading the English
language, in addition to the international one, then falling back to
English what is either non-existent or problematic.

Most error messages are in string files, so it shouldn't be too hard
to create other language files for error messages and use them when
"--language=" is used.


> 2, to provide official documents of the multi-language version. That
> is, llvm detailed instructions. As long as the developer llvm ontology
> have enough understanding and awareness, it will not create redundant
> errors that is the emergence of non-standard code.

This is the easiest step. You just need people that speak both
languages well and are interested in doing the translation. I'm sure
any patch in that respect will be well accepted.

Thanks,
--renato