From 61b19489f1ba35934d9114c034b24eb5bff149e7 Mon Sep 17 00:00:00 2001
From: ocornut <omarcornut@gmail.com>
Date: Fri, 12 Feb 2021 16:34:22 +0100
Subject: [PATCH] Made a change to CalcWindowSizeAfterConstraint() which MSVC
 optimizer seems to trip on. (read on)

We seldomly modify a local ImVec2 passed as parameter. This should be perfectly legal but libigl stumbled on a what may be a MSVC optimizer bug?
Only seven function in the codebase modify as 'ImVec2 parameter' but this is the only static one (and fairly small that is) which may tempt optimizer to perform optimizations over caller-callee boundaries?
While we can't explain it fully yet and I assume it may haunt us back someday. Might also be chain reaction from some unobvious UB but can't see it right now...
Link: https://github.com/libigl/libigl/issues/1669
---
 imgui.cpp | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/imgui.cpp b/imgui.cpp
index 0e401332..efc322aa 100644
--- a/imgui.cpp
+++ b/imgui.cpp
@@ -5097,9 +5097,10 @@ static ImGuiWindow* CreateNewWindow(const char* name, ImGuiWindowFlags flags)
     return window;
 }
 
-static ImVec2 CalcWindowSizeAfterConstraint(ImGuiWindow* window, ImVec2 new_size)
+static ImVec2 CalcWindowSizeAfterConstraint(ImGuiWindow* window, const ImVec2& size_desired)
 {
     ImGuiContext& g = *GImGui;
+    ImVec2 new_size = size_desired;
     if (g.NextWindowData.Flags & ImGuiNextWindowDataFlags_HasSizeConstraint)
     {
         // Using -1,-1 on either X/Y axis to preserve the current size.