[cfe-dev] Introduction and a few questions

[Eli Friedman]

On Tue, Aug 3, 2010 at 8:50 AM, Michael Price
<michael.b.price.dev at gmail.com> wrote:
> 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:
> clang: error: unable to execute command: program not executable
> clang: error: assembler (via gcc) command failed due to signal 1 (use -v to
> see invocation)
> But, if I compile it with 'clang.exe clangtest.cpp -fsyntax-only', the
> compilation succeeds.  Any ideas what is screwed up with my environment?

clang requires an assembler (for the moment) and linker, can't use the
MSVC assembler, and doesn't know how to use the MSVC linker.  The
workaround is to download mingw and put it in your path.  There's work
in progress which will allow everything to just work without gcc
installed, but it's not stable yet.

> 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.

If you can find a mingw gcc 4.2, the headers should be usable if you
get the include paths configured correctly.  You can hack up
lib/Frontend/InitHeaderSearch.cpp to change the default include paths.

> 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.

Initialization code on the trunk is stable; feel free to submit any changes.

> 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).
>
> 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.

Cool.

-Eli