This change appears to have broken the Windows MLIR bot (I suspect others Windows builders).
https://lab.llvm.org/buildbot/#/builders/13/builds/32862/steps/6/logs/stdio

This appears to have broken the Windows buildbot. https://lab.llvm.org/buildbot/#/builders/13/builds/30769/steps/6/logs/stdio

The valueByDim() switch in InferIntRangeInterfaceImpls.cpp appears to have broken the Windows buildbot (https://lab.llvm.org/buildbot/#/builders/13/builds/30180/steps/6/logs/stdio).

This change appears to have broken the Windows buildbot. https://lab.llvm.org/buildbot/#/builders/13/builds/28002/steps/6/logs/stdio

C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\SparseTensor\Transforms\CodegenUtils.cpp(227): error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\SparseTensor\Transforms\CodegenUtils.cpp(227): warning C4804: '<=': unsafe use of type 'bool' in operation

This change has broken the Windows buildbot, in an unfortunately opaque way. https://lab.llvm.org/buildbot/#/builders/13/builds/27291

In D135505#3856160, @sanjoy wrote:

How do we usually address these? I believe that switch covers all enums so this looks like a false positive to me.

There is also a failure in the MLIR Windows bot. https://lab.llvm.org/buildbot/#/builders/13/builds/27028

This appears to have broken the C interface. I suppose the corresponding rename will be required there. https://lab.llvm.org/buildbot/#/builders/13/builds/26975/steps/6/logs/stdio

It looks like the File.cpp fix was reverted due to producing a different warning, reintroducing the MSVC one here: https://github.com/llvm/llvm-project/commit/e898be2f6edbb886af2f6b23e2f5db5210535620.

LGTM

In D127457#3592625, @christopherbate wrote:

Thanks, I can push a 1-line change to fix.

This has caused a break in the Windows MLIR bot:

614.601 [639/64/2749] Building CXX object tools\mlir\lib\Dialect\NVGPU\Transforms\CMakeFiles\obj.MLIRNVGPUTransforms.dir\OptimizeSharedMemory.cpp.obj
FAILED: tools/mlir/lib/Dialect/NVGPU/Transforms/CMakeFiles/obj.MLIRNVGPUTransforms.dir/OptimizeSharedMemory.cpp.obj ... 
C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\NVGPU\Transforms\OptimizeSharedMemory.cpp(194): error C2220: the following warning is treated as an error
C:\buildbot\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\NVGPU\Transforms\OptimizeSharedMemory.cpp(194): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)

Removing the default: on the switch in isSingleCondition broke the Windows bot, but unfortunately it was down so there was no timely notification. Sorry about that!
https://lab.llvm.org/buildbot/#/builders/13/builds/21881

Fix merge base

Add comment for RULE_LAUNCH_COMPILE on Windows

clang-format

Fixed reference, I'm not clear why this isn't const, since unlike other pybind exceptions cast_error doesn't appear to be handled by Python.

I posted this on the commit, sorry! Meant to do it here.
This appears to have broken a number of tests on the Windows buildbot: https://lab.llvm.org/buildbot/#/builders/13/builds/19731

LLVM ERROR: TypeID::get<`anonymous-namespace'::ClonePass>(): Using TypeID on a class with an anonymous namespace requires an explicit TypeID definition. The implicit fallback uses string name, which does not guarantee uniqueness in anonymous contexts. Define an explicit TypeID instantiation for this type using `MLIR_DECLARE_EXPLICIT_TYPE_ID`/`MLIR_DEFINE_EXPLICIT_TYPE_ID` or `DEFINE_EXPLICIT_PRIVATE_INLINE_TYPE_ID`.

This appears to have broken a number of tests on the Windows buildbot: https://lab.llvm.org/buildbot/#/builders/13/builds/19731

LLVM ERROR: TypeID::get<`anonymous-namespace'::ClonePass>(): Using TypeID on a class with an anonymous namespace requires an explicit TypeID definition. The implicit fallback uses string name, which does not guarantee uniqueness in anonymous contexts. Define an explicit TypeID instantiation for this type using `MLIR_DECLARE_EXPLICIT_TYPE_ID`/`MLIR_DEFINE_EXPLICIT_TYPE_ID` or `DEFINE_EXPLICIT_PRIVATE_INLINE_TYPE_ID`.

This is causing failures on the Windows builbot: https://lab.llvm.org/buildbot/#/builders/13/builds/19626/steps/6/logs/stdio
I believe you simply need #include <string> to make MSVC happy.

I believe this change produces a comparison warning with clang:

In D102827#2771837, @mehdi_amini wrote:

That seems fairly ad-hoc as a fix: what are the conditions where this is a problem more precisely?

I believe this change causes the assert on the attribute SmallVector (for size >256) to hit when the size isn't specified on Windows debug builds.

Yes, the fix works! Thanks again.

Hi Lang,

I believe this change, or one of the subsequent ones (I can't find them on Differential, sorry), broke a test on the Windows Debug build.

This broke the Windows MLIR buildbot, because algorithm is required for std::min in MSVC.
https://lab.llvm.org/buildbot/#/builders/13/builds/6985/steps/6/logs/stdio

It doesn't look like MSVC likes this use of type. Break in the buildbot here: https://lab.llvm.org/buildbot/#/builders/13/builds/5148. Thanks!

Could you please add #include<algorithm> for RunnerUtils.h? MSVC requires it for std::max/min, resulting in this http://lab.llvm.org:8011/#/builders/13/builds/4283/steps/6/logs/stdio failure. Thanks!

This appears to still be failing on VS2017 after the latest GCC5 fix (although builder is having some trouble, so I'll confirm). http://lab.llvm.org:8011/#/builders/13/builds/2128

I think there may be a small remaining issue on the llvmir-intrinsics.mlir test on Windows, as seen here: http://lab.llvm.org:8011/#/builders/82/builds/40/steps/7/logs/stdio

In D83241#2140860, @ergawy wrote:

(No need thanks, I setup a virtual environment)

Unfortunately, this still produces a cryptic error on VS2017:

In D81426#2090919, @antiagainst wrote:

http://lab.llvm.org:8011/builders/mlir-windows/builds/3163 Windows bot is happy now.

In D81426#2088781, @antiagainst wrote:

The Windows failure and GCC failure look the same.

I believe this change may have broken the Windows buildbot, here: http://lab.llvm.org:8011/builders/mlir-windows/builds/3068

I believe this change broke the windows buildbot as well, just as an additional data point. http://lab.llvm.org:8011/builders/mlir-windows/builds/2485

1025.187 [461/64/2346] Building CXX object tools\mlir\lib\Dialect\Linalg\Transforms\CMakeFiles\obj.MLIRLinalgTransforms.dir\Loops.cpp.obj
FAILED: tools/mlir/lib/Dialect/Linalg/Transforms/CMakeFiles/obj.MLIRLinalgTransforms.dir/Loops.cpp.obj 
C:\PROGRA~2\MICROS~1\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\cl.exe  /nologo /TP -DBUILD_EXAMPLES -DGTEST_HAS_RTTI=0 -DMLIR_CUDA_CONVERSIONS_ENABLED=1 -DMLIR_ROCM_CONVERSIONS_ENABLED=1 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\mlir\lib\Dialect\Linalg\Transforms -IE:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\Linalg\Transforms -Iinclude -IE:\build_slave\mlir-x64-windows-ninja\llvm-project\llvm\include -IE:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include -Itools\mlir\include /DWIN32 /D_WINDOWS   /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2    /EHs-c- /GR- -UNDEBUG -std:c++14 /showIncludes /Fotools\mlir\lib\Dialect\Linalg\Transforms\CMakeFiles\obj.MLIRLinalgTransforms.dir\Loops.cpp.obj /Fdtools\mlir\lib\Dialect\Linalg\Transforms\CMakeFiles\obj.MLIRLinalgTransforms.dir\ /FS -c E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\lib\Dialect\Linalg\Transforms\Loops.cpp
E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include\mlir/IR/PatternMatch.h(192): error C2664: 'mlir::LogicalResult mlir::OpRewritePattern<mlir::vector::TransferWriteOp>::match(SourceOp) const': cannot convert argument 1 from 'SourceOp' to 'mlir::Operation *'
        with
        [
            SourceOp=mlir::vector::TransferWriteOp
        ]
E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include\mlir/IR/PatternMatch.h(192): note: use of undefined type 'mlir::vector::TransferWriteOp'
E:\build_slave\mlir-x64-windows-ninja\llvm-project\mlir\include\mlir/Dialect/Linalg/Transforms/Transforms.h(20): note: see declaration of 'mlir::vector::TransferWriteOp'

I believe this change broke the build on the Windows VS2017 buildbot, http://lab.llvm.org:8011/builders/mlir-windows/builds/2042. It's not obvious to me why it would generate deeply nested code. Any thoughts? Thanks!

In D73967#1989932, @erichkeane wrote:

I didn't see that on any of the buildbots, where did you see it?

I believe this change pushes clang\lib\Sema\SemaTemplateDeduction.cpp over the 16-bit COFF section limit for Windows Debug builds. Could you please resolve it or add /bigobj to the CMakeFile file for MSVC (see clang\lib\CodeGen\CMakeLists.txt). ERROR C1128 Thanks!

Hey Brooks, do you have a public buildbot so I can try to fix it? What generator are you using?

This patch resolved the issue for our VS build. Thanks! Unfortunately, I don't have any way to test it for Xcode. Should I still accept the revision?

Should be fixed in 2d723d4ad51c1e369810b543e1ac9ac1dfe0bfc8

That changed the error to following. In cases like this is better to move the discussion to the latest update, or keep it here? Thanks!

I think part of this change may have broken the Windows build. Sorry for not being able to be more specific or catching it sooner. I'll be more on top of this once the buildbot moves over to the loud master.

The mlir-check target passes with MS C++ 19.24.28319 (except for the known failure). If there is another test that would be helpful on Windows let me know.

In D74440#1910791, @rriddle wrote:

Let me know if that fixes it for you.

This appears to break the VisualStudio build for MSVC++ 14.16