Why is my function returning early unless I return `nullptr`? - visual-c++

Question

I'm currently in the process of writing a function that tries to parse a .fbx file (the library used is a .c and .h pair that I compile together with my code, called ufbx) and I am puzzled by some behavior I'm seeing while debugging. The code looks like this, imagine there's a breakpoint on ufbx_free_scene at the end:
std::shared_ptr<geometry::Mesh> AssetManager::LoadFbxMesh(const std::string& fullFilePath)
{
ufbx_load_opts opts = { 0 }; // Optional, pass NULL for defaults
ufbx_error error; // Optional, pass NULL if you don't care about errors
ufbx_scene* scene = ufbx_load_file(fullFilePath.c_str(), &opts, &error);
if (!scene)
{
throw std::runtime_error("Failed to load fbx file: " + fullFilePath + ": " + std::string(error.description.data));
}
bool meshFound = false;
auto newMesh = std::make_shared<geometry::Mesh>();
for (size_t ni = 0; ni < scene->nodes.count; ni++)
{
ufbx_node* node = scene->nodes.data[ni];
if (node->is_root)
{
continue;
}
if (node->mesh)
{
if (meshFound)
{
throw std::runtime_error("Only fbx files with a single mesh are supported.");
}
meshFound = true;
auto fbxMesh = node->mesh;
for (size_t i = 0; i < fbxMesh->vertices.count; ++i)
{
auto pos = fbxMesh->vertices.data[i];
}
}
}
ufbx_free_scene(scene);
return nullptr;
}
If I run the code as-is, the breakpoint is hit, it runs as expected. However, if I replace nullptr with the newMesh defined above, the breakpoint is never hit. Instead it jumps straight to the return, completely ignoring the for loop and the call to ufbx_free_scene.
I tried to look at the disassembly and it seems it introduces an early return right after it creates the new shared ptr? Why would it do that? The disassembly for the non-nullptr case looks like I'd expect (no early return).
I'm invoking msvc via SCons, if it helps this is the full command it ran (where only AssetManager was changed i.e. the class that contains my function):
scons: done reading SConscript files.
scons: Building targets ...
cl /FoduskEngine\asset\AssetManager.obj /c duskEngine\asset\AssetManager.cpp /TP /nologo /Od /std:c++20 /MD /EHsc /DEBUG /Zi /DTRACY_ENABLE /IduskEngine /IC:\Users\myuser\code\thirdparty\duskengine\glfw-3.3.7\include /IC:\Users\myuser\code\thirdparty\duskengine\glad\include /IC:\Users\myuser\code\thirdparty\duskengine\glm /IC:\Users\myuser\code\thirdparty\duskengine\boost_1_79_0 /IC:\Users\myuser\code\thirdparty\duskengine\tracy\public
AssetManager.cpp
link /nologo /DEBUG /OUT:a.exe /LIBPATH:. ./../thirdparty/duskengine/glfw-3.3.7/lib/glfw3.lib ./../thirdparty/duskengine/boost_1_79_0/stage/lib/libboost_container-vc143-mt-x64-1_79.lib ./../thirdparty/duskengine/boost_1_79_0/stage/lib/libboost_json-vc143-mt-x64-1_79.lib opengl32.lib kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib duskEngine\DuskMisc.obj duskEngine\main.obj duskEngine\asset\AssetManager.obj duskEngine\asset\Texture.obj duskEngine\asset\third_party\stb_image_impl.obj duskEngine\camera\Camera.obj duskEngine\editor\CameraController.obj duskEngine\editor\Editor.obj duskEngine\editor\EditorGUI.obj duskEngine\editor\InputManager.obj duskEngine\editor\gizmos\EditorGizmos.obj duskEngine\editor\gizmos\TransformHandles.obj duskEngine\editor\gui_subpanes\AssetBrowserGUI.obj duskEngine\editor\gui_subpanes\EntityListEditorGUI.obj duskEngine\editor\gui_subpanes\EntityPropertiesGUI.obj duskEngine\editor\gui_subpanes\ScenePropertiesGUI.obj duskEngine\imgui\imgui.obj duskEngine\imgui\ImGuizmo.obj duskEngine\imgui\imgui_demo.obj duskEngine\imgui\imgui_draw.obj duskEngine\imgui\imgui_impl_glfw.obj duskEngine\imgui\imgui_impl_opengl3.obj duskEngine\imgui\imgui_stdlib.obj duskEngine\imgui\imgui_tables.obj duskEngine\imgui\imgui_widgets.obj duskEngine\math\Math.obj duskEngine\projects\ProjectLoader.obj duskEngine\rendering\shaderset.obj duskEngine\rendering\opengl\GLModelRenderable.obj duskEngine\rendering\opengl\GLRenderer.obj duskEngine\scene\Scene.obj duskEngine\scene\SceneLoading.obj duskEngine\glad.obj duskEngine\asset\third_party\ufbx\ufbx.obj C:\Users\myuser\code\thirdparty\duskengine\tracy\public\TracyClient.obj
LINK : a.exe not found or not built by the last incremental link; performing full link
scons: done building targets.
Shouldn't /Od disable such optimizations? Assuming it's an optimization (but then, why not return nullptr early?)

Answer 1

MSVC has enabled named returned value optimization (NRVO) when built with /std:c++20 even in debug builds:
Visual Studio 2022 version 17.4 increases the number of places where the compiler does optional copy or move elisions under /Zc:nrvo, whether enabled explicitly, or automatically by using the /O2, /permissive-, or /std:c++20 or later options.
It can be explicitly disabled with /Zc:nrvo- compiler option.
Note, nameless return value optimization (RVO) is required by the standard since C++17 and will always be performed regardless of /Zc:nrvo:
When the nameless temporary is the operand of a return statement, this variant of copy elision is known as RVO, "return value optimization".
(until C++17)
Return value optimization is mandatory and no longer considered as copy elision; see above. (since C++17)