Hi,
Just out of curiosity has the possibility of brining in C# support (minus .Net) to clang/LLVM been discussed?
Here’s and interesting project: http://blog.prabir.me/post/LLVM-e28093-Native-C-Compiler.aspx
Thoughts?
Juan
While a C# → LLVM compiler is an interesting project (though hard - there’s a lot of runtime library stuff that you would have to reimplement if you forsake existing .Net implementations), Clang has nothing to do with it. C# is sufficiently different from the core C family that there’s really no point in trying to reuse Clang.
Sebastian
I agree that extending Clang to parse C# is unlikely to be a natural fit;
C# is a very distant cousin of the C language family, and there are enough
significant differences that a separate compiler would probably be cleaner.
However, if we wanted a C# compiler to be part of the LLVM project, it
might make sense to make available certain parts of clang for its use (such
as the source manager, diagnostics system, and driver infrastructure, and
possibly the lexer). Most of these are components which could also be
beneficially shared with other LLVM subprojects (lld, for instance).
I don’t think Apple is happy to pour money on C#, for hybrid family, java hold a higher priority.
The idea is good
Java already has open source javac, which produces bytecode which can be than compiled to native by J3. The same should be possible for C# bytecode produced by Mono compiler.
Right. I completely agree.
I think a C# frontend should just use llvm::SourceMgr, which is currently being used by things like filecheck, tblgen, the .ll parser, etc.
Comparing clang::SourceManager to llvm::SourceMgr, the former is really just a super-complicated form made neccesary by C macros (which doesn’t apply to C#). Likewise, I’d rather see the llvm::SMDiagnostic stuff get better (clang does still have some nice features it doesn’t, like fixits) and to have Clang’s diagnostics properly layered on top of it.
-Chris
Oh, I guess the other difference is that llvm::SourceMgr hasn't been tuned. SMLoc is sizeof(pointer), which makes them use twice the memory on 64-bit hosts. This should be easy to fix, but no-one has bothered yet.
-Chris