[cfe-dev] unknown type name __thiscall

[Douglas Gregor]

On Mar 16, 2010, at 3:54 PM, Stefan Seefeld wrote:

> On 03/16/2010 05:48 PM, Douglas Gregor wrote:
>> On Mar 16, 2010, at 2:28 PM, Stephen Deken wrote:
>> 
>> 
>>> Hello list,
>>> 
>>> I'm getting strange errors emitted by clang++ on Windows 7 (built
>>> using Visual Studio 9 from trunk) when attempting to compile C++ code
>>> that includes the VC9 headers:
>>> 
>>> cfetest.cpp:
>>> 
>>> 	#include<iostream>
>>> 	using namespace std;
>>> 	int main( int, char** ) {
>>> 		cout<<"hello world!"<<endl;
>>> 		return 0;
>>> 	}
>>> 
>>> This emits 122 errors.  Some are about __thiscall, which clang/clang++
>>> apparently doesn't define,
>>> 
>> No, we don't define that. We could (and probably should).
>> 
> 
> Pardon me for jumping in here, but this brings up a high-level design 
> question I have:
> 
> With the Synopsis parsers I used the approach of emulating external 
> (real) compilers, by scanning for them, and using heuristics to figure 
> out what symbols they would expect and emit, as well as where they store 
> system headers.
> 
> Thus, my parser wouldn't need to do any of this.
> 
> How does this work with CLang ? Does it know anything about specific 
> platforms ? What do I need to feed in to get an environment similar to, 
> say, GCC ?


Clang does know about specific compilers, platforms, targets, and system headers. It does not scan for them at all.

For specific compilers, there are extension flags, e.g., -fms-extensions (Visual C++), -std=gnu99 (C99 w/ GNU extensions), etc. These are stored in LangOptions and are used for keywords, parsing, semantic analysis, etc.

For specific platforms and targets, we have TargetInfo.

For header search paths, we have InitHeaderSearch.cpp, which is a mess based on the target triple.

IMO, only the last of those is really amenable to scanning the system compiler, although I guess we could have some kind of top-level flag to "emulate compiler Foo as best you can".

	- Doug