Git for Windows comes with its own installation of a bunch of them, and llvm's lit does pick them up automatically if they aren't available in PATH: https://github.com/llvm/llvm-project/blob/main/llvm/utils/lit/lit/llvm/config.py#L31-L35

Yes the test had passed since then, so all OK.

Addressing comment in https://reviews.llvm.org/D108085

Address https://bugs.llvm.org/show_bug.cgi?id=51643

Thanks for all the comments!

The x64 windows pre-check bot is failing on this test, see:

Upload lal local commits to include all local changes

Address comments

Trying yet again to fix the diff

Trying to fix the diff

Fix typo

add all commits

I completely agree, the Getting Started document should be modernized considering a current Visual Studio 2019 installation bundles tools and that GnuWin32 is antique. I will create revision for your review.

https://bugs.llvm.org/show_bug.cgi?id=45978

already fixed in https://github.com/llvm/llvm-project/commit/ffe58de39319b42b46319473263b59bd68ceee67

passes tests

https://reviews.llvm.org/D107544

Switched to Linux repo

opened by mistake

Support both Windows llvm-lit.py and Linux llvm-lit command name

looking into Linux failures

Added test in r305213.

OK

Raphael , do you have commit access? should I commit this?

LGTM

Please move the =new out of the PP.AddPragmaHandler calls.
While at it, this code still (as the original) leaks the PragmaHandlers. These should be deleted after RemovePragmaHandler or instead, simply use std::unique_ptr.

reverted in r300497

Adding Mateusz and Reid.

Added attribute test.

Thanks, I'll make a test.

r299207

No intention of any major work intended... just moved the code (locally) to Release and regression tests were still passing.

Most other module flags are added at CodeGenModule::Release(). For consistency, could this code be in CodeGenModule::Release() as well?

Could use dumpDeclContext() to test?

OK.

If something is broken now we don't break it even more.
__float128 remain be fixed to be compatible, not only some poor developer would have to fix the missing headers bug one day, he will have to re-fix limits.h the right way and undo this "fix".
There is a problems with limits.h, fix limits.h. Don't make all headers that happens to be in the same directory as limits.h disappear.

These directories are "mostly" equivalent, with some headers existing is mings gcc dir but missing in clang resource dir and thus will break compilation.
For example, the most popular (37089 download this week) https://sourceforge.net/projects/mingw-w64 distribuion for Windows had elected to place the includes

omp.h, quadmath.h, openacc.h

at

c:\mingw32\lib\gcc\i686-w64-mingw32\5.4.0\include\

with the corresponding libraries at

c:\mingw32\lib\gcc\i686-w64-mingw32\5.4.0\

I had verified this still holds true for the latest i686-6.3.0-release-posix-dwarf-rt_v5-rev1.7z package.
Removing the include dir will make clang less useful for mingw users using these includes, since they will not be found anymore.
Furthermore, It makes no sense to make such intrusive wide-ranging change where the original problem was with limits.h is actually due to:

/* The system's limits.h may, in turn, try to #include_next GCC's limits.h.
 Avert this #include_next madness. */
#if defined __GNUC__ && !defined _GCC_LIMITS_H_
#define _GCC_LIMITS_H_
#endif

so the solution may be as simple as

#if defined __GNUC__ && !defined _GCC_LIMITS_H_ && !defined __MINGW32__
#define _GCC_LIMITS_H_
#endif

What about omp.h and openacc.h ? many programs are using OpenMP.

The gcc include dirs in mingw contains headers not available esewhere and thus can't be removed.
Notable examples,

Hiding these two include dirs removes many headers. Most has clang equivalents but not all of them.
For example quadmath.h is only there, and without the include path programs using it will fail to compile.

This code is actually used with Windows as well as Linux (with the exception of line 218), see the comment blocks above for detailed include dirs from all platforms from which it was derived.

LGTM, matches the code in libstdc++ stdarg,h.
You can remove the 'hack' comment in line 46, __GNUC_VA_LIST is just a standard include guard for the typedef.

In D28399#642458, @v.g.vassilev wrote:

@yaron.keren, it seems that http://llvm.org/pr30994 concerns friend function declarations. My current patch focuses on friend class templates. Perhaps we should open another review item for a fix of http://llvm.org/pr30994.

While at it, http://llvm.org/pr30994

LGTM after fixing the inline comment

PR28749 was created with trunk clang on Ubuntu x64.
It reproduced reliably but is very fragile, changing just about anything in the code makes the problem disappear.

I added a small reproducer for what is probably the same problem in

You mean
Some target platforms do not support -fsanitize=address.

result of r269402, LGTM

Ah, OK, I am using regular svn and thus did not counter this problem.
Could you detail this exactly, the problem happens when using git-svn with core.autocrlf config=true but not with svn?
LGTM with this addition.

AFAIK the eol type is decided by svn based the svn:eol-style property, so as long the files were checked in correctly and you do not override it specifically while svn checkout, it just works.
Did you encounter problems with eol ?

Would be nice to have CodeGenAction::TheModule redirect to CodeGeneratorImpl::M if possible, but that's for another patch. LGTM.

It certainly makes sense to redirect the module request to its owner instead of duplicating it in a local copy.

We have tried to keep one copy of DataLayout around
http://reviews.llvm.org/D11103
Can it share the Module->getDataLayout() ?

The instantiated does get a new collection of ParmVarDecls while getting
the pattern Type which points to the pattern ParmVarDecls. So the
ParmVarDecls pointed in the instantiated are not the same as those pointed
by its Type.

#define NOGDI
is also useful.

+1 all general-purpose Windows stuff should move to WindowsSupport.h. I'm surprised we got away without so far.
We have NOMINMAX at lib/Driver/MSVCToolChain.cpp before Windows.h which should probably switched to use WindowsSupport.h.