Hi List,<div><br></div><div>I've been developing with C++ code for the past 5 years and was introduced to the idea behind clang/llvm late last year.  I've been following C++0x developments since early 2008 however, and I am quite excited about the (hopefully) forthcoming standard.  I decided recently to begin making contributions to open-source C++ compilers to advance the implementation level of the new standard so that it could be more widely adopted.  Seeing how GCC is doing pretty good without any help (and most of the "easy") topics are taken, I figured I'd help out some with clang.  I understand that C++0x will not be a priority until the previous standards are implemented, but it can't hurt to have a head start on C++0x implementation, right?  With that out of the way, here are some questions I have:</div>
<div><br></div><div><br></div><div>I've built llvm/clang on Windows 7 x64 with Visual C++ 2010 Express (using cmake to create a VS solution file).  The build succeeded with no errors.  I have not run the test suite yet, but would like to do that soon as I have some code changes that I'd like to verify with the tests before I submit a patch.  Does anyone have any guidance on running the tests in the environment I've described?</div>
<div><br></div><div><br></div><div>After building, I made a simple program (no #includes, simple main() returning 0).  When I compiled it with the command 'clang.exe clangtest.cpp', clang gave the following error:  </div>
<div>clang: error: unable to execute command: program not executable</div><div>clang: error: assembler (via gcc) command failed due to signal 1 (use -v to see invocation)</div><div><br></div><div>But, if I compile it with 'clang.exe clangtest.cpp -fsyntax-only', the compilation succeeds.  Any ideas what is screwed up with my environment?</div>
<div><br></div><div><br></div><div>Also, if I #include any standard library headers, clang will choke, since the VC++10 headers are implemented with some C++0x support (and some other weird errors occur).  If anyone is interested in helping me with this, I'll post the errors.  Otherwise, some direction on how to get either GCC library or libc++ compiling and working on my environment would be extremely helpful.</div>
<div><br></div><div><br></div><div>For my first contribution, I've decided to work on type deduction via the 'auto' type keyword (as opposed to the 'auto' storage-specifier :) ).  After looking through the code, I've found the first "half" of an implementation, in that the type declaration was already present.  I have some code implemented which will modify the type of the declared variable (similar to how unsized-arrays are done) based on the type of the initializer.  I still need to review the latest standard proposal so that I can verify I've covered all the cases (I doubt I have), or at least know what tests to create so that it can be completed at a later date.  I browsed through the list archive and noticed that Doug was working on an initialization rewrite, but I don't see the results of that anywhere in the revision that I checked out.  I want to make sure I don't step on any toes in there.  After I run the tests, I'll build a patch and send it to the list for comments.</div>
<div><br></div><div><br></div><div>The next thing that I'm considering implementing is the new function declaration syntax (auto func (param1, param2) -> rettype;), as I see it as a building block towards implemented lambdas.  I'd also consider finishing off any work on rvalue-references and move-constructors instead, as those are extremely valuable and important pieces of the new standard library (see unique_ptr).</div>
<div><br></div><div><br></div><div>Hopefully I'll be able to help out just a little and get some degree of C++0x support in place before the C++0x goes through the entire process to become the next standard.</div><div>
<br></div>