[Windows] MSVC Compilation Error: C2001 and C2143 in multiple source files (e.g., routing_lp_scheduling.cc)

[sxfbug]

What version of OR-Tools and what language are you using?
Version: v9.14
Language: C++

Which solver are you using (e.g. CP-SAT, Routing Solver, GLOP, BOP, Gurobi)
CMake v4.1.1
Git v2.51.0.windows.1
Visual Studio Community 2022 v17.14.13
x64 Native Tools Command Prompt for VS 2022

What operating system (Linux, Windows, ...) and version?
OS: Windows11 Family Chinese

What did you do?
Steps to reproduce the behavior:

1. I follow the instruction in https://developers.google.com/optimization/install/cpp/source_windows?hl=zh-cn
2. After get the code from Git and build CMake, I use command (as same as in the website)
   cmake --build build --config Release --target ALL_BUILD -j -v
   to compile the program
3. After finishing compile, I scroll down to the bottom of x64 Native Tools Command Prompt for VS 2022
4. So that I see 17 warnings and 10 errors, in the following files(line numbers might vary slightly)

info_of_errors.txt

The following 2 parts is concluded by Deepseek. I talk to him about the problems I met. He help me to generate these parts when I told him that I want to create a issue.

Steps to Reproduce

1. git clone -b stable https://github.com/google/or-tools.git
2. cd or-tools
3. cmake -S . -B build -DBUILD_DEPS=ON
4. cmake --build build --config Release --target ALL_BUILD -j -v

What I've Tried

• Ensured core.autocrlf is set to false and performed multiple clean clones.
• Verified that the line endings (LF) and file encoding (UTF-8 without BOM) of the problematic files are correct using VS Code.
• Manually re-typing the offending string literals and saving the files.
• The fact that the error persists in a clean environment suggests it might be an issue with the source code in the repository itself, not a local configuration.

[lperron]

we did compile it for the release :-)

[sxfbug]

we did compile it for the release :-)

could you please share the exact versions of the toolchain you used for that successful compilation?

[sxfbug]

we did compile it for the release :-)

I tried main branch instead of stable branch, as same as before. I don't know how to do

[Mizux]

https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2001?view=msvc-170

https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/compiler-error-c2143?view=msvc-170

[sxfbug]

Thanks for confirming and adding it to the milestone! I'll keep an eye on this thread for updates.

[sxfbug]

Thank you for your previous response. I'm writing to provide a significant update that successfully identifies the root cause of the C2001 and C2143 errors.

After a exhaustive investigation on a fresh Windows installation (clean C drive) using the v9.10.4067 source code, I can conclusively state that the issue is not related to file encoding, line endings, or general environment corruption.

The root cause is a parsing bug in the MSVC compiler when it encounters specific Unicode mathematical symbols within string literals in the source code.

Key Evidence:

All C2001 errors occurred exclusively on lines containing the infinity symbol (∞ U+221E) or the empty set symbol (∅ U+2205).

ostr << "(-∞"; (in routing_lp_scheduling.cc)

... + "]-∞" + ... (in linear_solver.cc)

... + "+∞[" + ... (in linear_solver.cc)

Diagnostic Proof: Replacing these Unicode symbols with their ASCII equivalents (e.g., ∞ -> Infinity, ∅ -> {}) in the source code immediately resolved the compilation errors for those files, allowing a full successful build.

The compiler is the latest version available from the Visual Studio 2022 installer as of today. The fresh OS install eliminates any possibility of pre-existing configuration issues.

This appears to be a specific regression or edge-case bug in the MSVC compiler's lexer/parser. I hope this detailed analysis helps you reproduce the issue on your end. The workaround for now is to avoid using these specific Unicode characters directly in string literals for MSVC builds.

Thank you for your attention to this matter.

[lperron]

Thanks. We will fix those. MSVC is so brittle. Laurent Perron | Operations Research | ***@***.*** | (33) 1 42 68 53 00 Le sam. 6 sept. 2025 à 08:05, sxfbug ***@***.***> a écrit :

…

*sxfbug* left a comment (google/or-tools#4772) <#4772 (comment)> Thank you for your previous response. I'm writing to provide a significant update that successfully identifies the root cause of the C2001 and C2143 errors. After a exhaustive investigation on a fresh Windows installation (clean C drive) using the v9.10.4067 source code, I can conclusively state that the issue is not related to file encoding, line endings, or general environment corruption. The root cause is a parsing bug in the MSVC compiler when it encounters specific Unicode mathematical symbols within string literals in the source code. Key Evidence: All C2001 errors occurred exclusively on lines containing the infinity symbol (∞ U+221E) or the empty set symbol (∅ U+2205). ostr << "(-∞"; (in routing_lp_scheduling.cc) ... + "]-∞" + ... (in linear_solver.cc) ... + "+∞[" + ... (in linear_solver.cc) Diagnostic Proof: Replacing these Unicode symbols with their ASCII equivalents (e.g., ∞ -> Infinity, ∅ -> {}) in the source code immediately resolved the compilation errors for those files, allowing a full successful build. The compiler is the latest version available from the Visual Studio 2022 installer as of today. The fresh OS install eliminates any possibility of pre-existing configuration issues. This appears to be a specific regression or edge-case bug in the MSVC compiler's lexer/parser. I hope this detailed analysis helps you reproduce the issue on your end. The workaround for now is to avoid using these specific Unicode characters directly in string literals for MSVC builds. Thank you for your attention to this matter. — Reply to this email directly, view it on GitHub <#4772 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUPL3OICREYYOKH4M32CRT3RJ2SDAVCNFSM6AAAAACFUTTHTCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTENRRGE3TGNRZGE> . You are receiving this because you commented.Message ID: ***@***.***>

[sxfbug]

Thanks. We will fix those. MSVC is so brittle. Laurent Perron | Operations Research | @.*** | (33) 1 42 68 53 00 Le sam. 6 sept. 2025 à 08:05, sxfbug @.***> a écrit :

Thank you for the confirmation and your response! I'm glad I could help. I'll keep an eye on the future releases.