Fixes for windows version

Hi,

when I updated the sources today there were several small problems that stopped the windows version from compiling, here are the patches

m.

win32patches.txt (6.83 KB)

Morten,

I've applied these patches. Thanks for the updates!

Reid.

I have some patches of my own:

* An improvement on Morten's fix to Signals.cpp.

* Undo the breakage to system.vcproj (Signals.cpp was being built twice
  as a result).

* Fix a class/struct inconsistency.

* Remove unneeded #includes from win32 fSystem files.

I've also determined why VC++ complains about deprecated destructors
when using hash_map. Because it's not ANSI (yet), Microsoft decided to
move it from the std namespace to the stdext namespace. Use of
std::hash_map is therefore deprecated. Similar shenanigans have been
committed by gcc from one version to another. I see where this is
handled (llvm/ADT/hash_map), but it isn't clear how to add support for
VC++ to the auto config magic.

I'll soon thoroughly go through the llvm_test results for FreeBSD to
identify all platform dependencies that cause failures. I'm getting far
more failures than I have in the past, though it's apparent many tests
have also been added. Perhaps they never passed?

diff.out (6.42 KB)

Jeff,

I have some patches of my own:

* An improvement on Morten's fix to Signals.cpp.

* Undo the breakage to system.vcproj (Signals.cpp was being built twice
  as a result).

* Fix a class/struct inconsistency.

* Remove unneeded #includes from win32 fSystem files.

Thanks for the excellent patches. All commited.

I've also determined why VC++ complains about deprecated destructors
when using hash_map. Because it's not ANSI (yet), Microsoft decided to
move it from the std namespace to the stdext namespace. Use of
std::hash_map is therefore deprecated. Similar shenanigans have been
committed by gcc from one version to another. I see where this is
handled (llvm/ADT/hash_map), but it isn't clear how to add support for
VC++ to the auto config magic.

Yeah, there's tests in autoconf/m4/cxx_hash_map to dictate which naming
style needs to be used. You'll have to haxor it in there if you're not
using the configure script.

I'll soon thoroughly go through the llvm_test results for FreeBSD to
identify all platform dependencies that cause failures. I'm getting far
more failures than I have in the past, though it's apparent many tests
have also been added. Perhaps they never passed?

There's only a handful (8-10) that don't pass at this point. See the
nightly test results for other platforms for the details:

http://llvm.cs.uiuc.edu/testresults/

Reid.

I've also determined why VC++ complains about deprecated destructors
when using hash_map. Because it's not ANSI (yet), Microsoft decided to
move it from the std namespace to the stdext namespace. Use of
std::hash_map is therefore deprecated. Similar shenanigans have been
committed by gcc from one version to another. I see where this is
handled (llvm/ADT/hash_map), but it isn't clear how to add support for
VC++ to the auto config magic.

Yeah, there's tests in autoconf/m4/cxx_hash_map to dictate which naming
style needs to be used. You'll have to haxor it in there if you're not
using the configure script.

I created a special configure project in the Visual Studio solution which uses sed to directly enter the correct configuration values for the Visual Studio build. It seems quite unnecessary to have all the auto detection stuff work on windows since it's a fairly homogenous build environment :wink: But in fact I use the stdext:: namespace and I still get deprecation warning, I think it is because the hash function for pointers is deprecated (although it still works) - I'm actually generating code now with LLVM and it works fine, so I'm not too worried about these warnings (as they are not showing up when you use the libs+header files)

And thanks a lot for the fixes, Jeff - also thanks to Reid and Chris for swift response when I submit patches!

m.

Well.. I cannot see where stdext was being used, but with your pointer
to where this is setup I was able to start using stdext and fix the
problem. Patch attached.

diff.out (1.62 KB)

Jeff Cohen wrote:

Well.. I cannot see where stdext was being used, but with your pointer
to where this is setup I was able to start using stdext and fix the
problem. Patch attached.

Right, my mistake -- I did it right first, when I was not using the config system at all I had a -DHASH_NAMESPACE=stdext on the command line but then I must have forgotten when I made the configure system... sorry, and thanks for the fix!

m.