Results loaded. Found 1637 matches.

Microsoft Developer Community

Your open channel to Microsoft engineering teams
Error loading VS Status: 'Request failed with status code 500'

Search existing Azure Load Testing feedback

1,637 items
Implement C++23 Standard features in MSVC
On Roadmap25
126Votes
- Reported Oct 28, 2024 3:51 AM

This suggestion ticket is used to track and measure the C++ and MSVC communities’ interest in the C++23 Standard implementation. Please add your vote and let us know (in the comments below) what specific features are of most interest to you.

Please note, MSVC has already shipped the majority of C++23 Standard’s library features, which were contributed to the STL GitHub repo. Please see STL C++23 Features (github.com) for the full list of implemented and remaining features.

For the language features, here’s the current implementation status: Compiler support for C++23 - cppreference.com

* Edit: We are planning to implement the entire C++23 Standard in MSVC. The question above about specific features is to help us prioritize the order of implementation.

Implement C++26 Standard features in MSVC
Under Review12
49Votes
- Reported Oct 28, 2024 3:55 AM

This suggestion ticket is used to track and measure the C++ and MSVC communities’ interest in the C++26 Standard implementation. Please add your vote and let us know (in the comments below) what specific features are of most interest to you.

MSVC has shipped a few C++26 Standard’s library features, which were contributed to the STL GitHub repo. Please see STL C++26 Features - github.com for the full list of implemented and remaining features.

For the language features, here’s the current implementation status: Compiler support for C++26 - cppreference.com

Please note, C++26 Standard still hasn’t been finalized (at the time this is posted), so we’re tracking against the working paper.

NAN is no longer compile-time constant in Windows 11 SDK 10.0.26100.0
Under Investigation014
45Votes
- Reported Jun 23, 2024 7:40 PM

[severity:I’m unable to use this version]
In the latest Windows SDK 10.0.26100.0, the definition of NAN from “corecrt_math.h” is changed to #define _UCRT_NAN (__ucrt_int_to_float(0x7FC00000)) for C (i.e. __cplusplus not defined). This expands to an inline function

inline float __ucrt_int_to_float(int i)
{
    union {
        int i;
        float f;
    } __my_int_to_float;

    __my_int_to_float.i = i;
    return __my_int_to_float.f;
}

This is not a compile-time constant. Therefore, a valid program like below no longer compile.

// test.c

#include <math.h>

static float n = NAN;

For reference, this is the definition in the previous SDK 10.0.22621.0:

// Keep this for backwards compatibility
#define NAN        ((float)(INFINITY * 0.0F))
cWindows 10.0.26100.0Go to details and discussion >
EnableClServerMode: Build and compiler freezes: error MSB8084: Invalid structured output from 'CL.exe'
Closed - Fixed19
42Votes
- Reported Mar 07, 2024 9:11 AM

[severity:It’s more difficult to complete my work]
To reproduce in the attached sample of the next post:

  1. Close all instances of Visual Studio. Set the environment variable EnableClServerMode with the value true in your operating system. The value is only the four letters of the word true. (you may also set EnforceProcessCountAcrossBuilds and UseMultiToolTask to true)
  2. Open solution in Visual Studio.
  3. Try to Rebuild the whole project.
  4. The compiler cl.exe freezes. (If not reproducible, read further below)
  5. There are many error messages as expected.
  6. However, the last error messages are similar to the following: 1>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(588,5): error MSB8084: Invalid structured output from 'CL.exe': Cannot parse JsonRpc notification: ''C' is an invalid start of a value. LineNumber: 0 | BytePositionInLine: 0.'. 1>C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(588,5): error MSB8084: Invalid structured output from 'CL.exe': Unexpected header '"startColumn":17}}}]}}}{"jsonrpc":"2.0","method":"OnSarifResult","params":{"result":{"ruleId":"C2144","level":"error","message":{"text":"syntax error: 'void' should be preceded by ';'"},"analysisTarget":{"uri":"file:///C:/structwarn2/structwarn2/1 - Copy (11).cpp"},"locations":[{"physicalLocation":{"artifactLocation":{"uri":"file:///C:/structwarn2/structwarn2/second.h"},"region":{"startLine":12,"startColumn":17}}}]}}}Content-Length: 466'.
  7. Open Task manager and “End process tree” “msbuild.exe” to also close all frozen cl.exe processes.
  8. In case you did not get the freeze and specific error message, simply also “End process tree” “msbuild.exe” and retry (it seems starting it up makes it more reproducible). You may also want to increase system CPU load during the test, as the error seems to be also timing relevant sometimes. Also CPU count may matter, as I tried to have more cpp files than CPUs.
  9. Close all instances of Visual Studio. Change the environment variable EnableClServerMode to false again, Rebuild the project and now cl.exe does not freeze and only the expected normal error messages get printed.

This is reproducible in 17.9.2 as well as 17.10 preview 1
This is also reproducible with 17.8.6
This may or may not be related to https://developercommunity.visualstudio.com/t/With-EnableClServerMode-is-true-and-prec/10502285
Hopefully this is not again a setup problem where the wrong dlls were installed and the data gets serialized differently!

Fixed in: Visual Studio 2022 version 17.10Fixed in: Visual Studio 2022 version 17.10 Preview 3webFixed in Visual Studio 2022 version 17.10Fixed InGo to details and discussion >
False positive warnings C6397 & C6398 The address-of operator/a field cannot return null pointer in well-defined code.
Closed - Fixed16
37Votes
- Reported Mar 07, 2024 9:16 AM

[severity:It bothers me. A fix would be nice]
To reproduce in the attached sample of the next post:

  1. Open solution in Visual Studio.
  2. Rebuild the whole project.
  3. You will see the following warnings:
CaWarnings2.cpp(16): warning C6397: The address-of operator cannot return null pointer in well-defined code.
CaWarnings2.cpp(21): warning C6398: The address-of a field cannot be null in well-defined code.

Explanation: In this well-defined sample code the dynamic_cast returns a null pointer as expected. The warning should not occur in such cases. Be aware that this is only one example and there may be other cases.

This is reproducible in 17.10 preview 1
This is not reproducible in 17.9.2

The source code from the attached sample, but you have to activate the code analysis warnings C6397 & C6398 to reproduce it:

#include <iostream>
struct Base
{
  virtual ~Base() = default;
};
struct Derived : public Base
{
};
struct Field
{
  Base m_base;
};
int main()
{
  Base base;
  if (dynamic_cast<const Derived*>(&base) == nullptr) //warning C6397: The address-of operator cannot return null pointer in well-defined code.
  {
    std::cout << "Hello World!\n";
  }
  Field field;
  if (dynamic_cast<const Derived*>(&field.m_base) == nullptr) //warning C6398: The address-of a field cannot be null in well-defined code.
  {
    std::cout << "Hello World!\n";
  }
}
Fixed in: Visual Studio 2022 version 17.10Fixed in: Visual Studio 2022 version 17.10 Preview 3webFixed in Visual Studio 2022 version 17.10Fixed InGo to details and discussion >
False positive lifetime code analysis warning C26847: Don't return an invalid pointer (lifetime.4).
Fixed - Pending Release05
36Votes
- Reported Aug 27, 2024 12:22 PM

[severity:It’s more difficult to complete my work]
Only in x86, not in x64! Be aware when trying to reproduce!

Tested with Visual Studio 17.11.0 and C++ Core Check Lifetime Rules.

Sample project attached in next post!

In the code making a ref cast creates this warning, which does not make sense. Without cast there is no warning.

struct base
{
};
struct asdf : public base 
{
  base& GetOk()
  {
    return *this;
  }
  base& GetProblem()
  {
    return static_cast<base&>(*this); //warning
  }
};
Currently known issues with IntelliSense for C++20 modules
Under Consideration017
35Votes
- Reported Sep 04, 2024 6:05 PM

Bucket to collect all known issues with C++20 modules support in Intellisense.

Issue symptoms
When importing C++20 modules or header units in C++ source:
You may not see IntelliSense completions or colorization.
You may see red squiggles that don’t match the compiler.

Known issues:
Visual Studio 2022 IntelliSense issue with modules and circular dependency
Intellisense incorrectly reporting incomplete type
IntelliSense error E3344

False positive lifetime code analysis warning C26849: Don't dereference an invalid pointer: (lifetime.1).
Fixed - Pending Release06
35Votes
- Reported Aug 27, 2024 12:16 PM

[severity:It’s more difficult to complete my work]

Tested with Visual Studio 17.11.0 and C++ Core Check Lifetime Rules.

Sample project attached in next post!

In the code assigning to const reference variable through ternary operator creates warning when accessing member afterwards.

struct Points
{
  int p;
};

Points GetPoint()
{
  return {};
}

int main()
{
  Points point1;
  const Points& pointsvar = true ?
    GetPoint() :
    point1;

return pointsvar.p == 0; //warning
}
Allow C++23 (or higher) under C++/CLI
Under Review3
29Votes
- Reported Oct 14, 2024 1:32 PM

This is a complementary request to the previous one regarding C++20/CLI:
https://developercommunity.visualstudio.com/t/Allow-C20-or-higher-under-CCLI/10173878

So the request is the same:
Allow /std:c++23 (or higher) in a future update to VS2022 (or whatever comes next).

Generate warning/error on /verbose:unusedlibs
Under Review3
27Votes
- Reported Nov 22, 2024 9:57 PM

We use /verbose:unusedlibs and then we need to parse the logs to break the build if unused libraries exists for a project. This allows us to minimize the build time and express clear dependencies between the projects. However this adds a lot of complexity in maintaining custom msbuild loggers and it would be nice if the linker would have a new flag to generate a new warning if unused libraries are reported for a C++ project.

/d1trimfile does not work with precompiled headers containing headers that use #pragma once
Under Review5
27Votes
- Reported Apr 24, 2024 4:20 AM

We want the result of /d1trimfile to be used for file identification when doing #pragma once. This would make it possible to make pch portable and prevent the same include from being included by both pch and outside pch. Right now it is not possible to move a pch to another machine with different root paths for include because the headers included in the pch will not match the same headers on the new machine (since they use absolute paths)

Pause all feature work for at least 2 quarters (ideally more) and focus on performance and bugfixing
Under Review2
25Votes
- Reported Oct 06, 2024 6:12 PM

Title. I mean this sincerely as a daily professional user of Visual Studio (C++) for well over a decade (nearly two). Recent releases have made updating the opposite of a value-add, and my hope is that this feedback encourages decision-makers on the team to reevaluate priorities.

I can’t speak for all Visual Studio users, but even before AI took off like a rocket, Visual Studio already had a killer feature set. It needed to do three things well: edit code, navigate code, and debug code. Arguably, everything else was noise or bells and whistles, but those three things were the pillars that made VS the no-brainer choice for C++ and C# development for a time.

These days, VS does not edit or navigate code well. Every keystroke, window drag, widget dock, panel resize, or other mundane UI interaction feels like such a chore, that as a user, I can viscerally feel the editor “thinking” when doing what used to be instantaneous tasks. Layouts are not properly persisted, so project reloads often result in yet another exercise in window-dragging. Ctrl-tab navigation from file to file incurs a noticeable delay. The “omni-search” feature is a strict downgrade from the simple search we used before, and I am finding myself resorting to Ctrl-Shift-F to just search the codebase by text more and more. In the time it takes VS to perform certain navigation or search operations, I can literally find the needed file with Everything.exe, open it in a different editor, and finish what I need to do. This isn’t a matter of “settings” and “options” either. I have tried everything (including looking for the missing “disable Omnisearch” toggle), and perused countless threads mentioning similar issues on this very forum.

I’m not operating on a cheap machine. This dev machine and others I’ve used are builds north of 4000 USD. Every machine I use VS on has at least 64 GB of RAM, and top-of-the-line processors. To say this isn’t acceptable, is an understatement.

I understand business incentives to prioritize features and trends to ensure VS stays “ahead” of the curve. I also understand that placing items on the roadmap is nuanced, and that not all resources that work on a given project are fungible. My assumption is that the VS team does not have real data to show the degree to which basic functionality (editor + navigation) has significantly regressed. If that is indeed the case, hopefully, this comment is a useful data point. I wish nothing but success for the VS team, but I and many others I work with are at the point where the moment a competitor comes along without these usability deficiencies and a decent debugger, VS will be out of the picture.

editorC++DebuggerEditorSolutionGo to details and discussion >
Regression in 17.12.0: Substitution Failure Is An Error C3699 when compiling with /CLR
Fixed - Pending Release29
25Votes
- Reported Nov 18, 2024 8:31 AM

[severity:I’m unable to use this version]
When compiling the following code with “cl -clr -c -std:c++20 sfinae.cpp”:

#include <optional>

ref class X {};

extern X^ get_an_x();

extern X^ convert(std::optional<int> opt);
extern std::optional<int> convert(X^ x);

auto opt = convert(get_an_x());

the compiler throws an error:

Microsoft (R) C/C++ Optimizing Compiler Version 19.42.34433
for Microsoft (R) .NET Framework version 4.08.9282.0
Copyright (C) Microsoft Corporation.  All rights reserved.

sfinae.cpp
predefined C++ types (compiler internal)(23): error C3699: '&&': cannot use this indirection on type '_T'
        with
        [
            _T=X ^
        ]
predefined C++ types (compiler internal)(23): note: the template instantiation context (the oldest one first) is
sfinae.cpp(10): note: while compiling class template member function 'std::optional<int>::optional(_Ty2 &&) noexcept(<expr>)'
sfinae.cpp(10): note: while processing the default template argument of 'std::optional<int>::optional(_Ty2 &&) noexcept(<expr>)'
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\optional(245): note: see reference to alias template instantiation 'std::optional<_Ty>::_AllowDirectConversion<X^>' being compiled
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\optional(240): note: see reference to variable template 'const bool conjunction_v<std::negation<std::is_same<X ^,std::optional<int> > >,std::negation<std::is_same<X ^,std::in_place_t> >,std::negation<std::conjunction<std::is_same<int,bool>,std::_Is_specialization<X ^,std::optional> > >,std::is_constructible<int,X ^> >' being compiled
C:\Program Files\Microsoft Visual Studio\2022\Professional\VC\Tools\MSVC\14.42.34433\include\optional(240): note: see reference to class template instantiation 'std::is_constructible<int,X ^>' being compiled
predefined C++ types (compiler internal)(26): note: see reference to class template instantiation '<add_rvalue_reference><X ^>' being compiled

The code compiles correctly with versions <= 19.41.

C++ MSVC Toolset ABI Break : Next Stable ABI Release Epoch
Under Review4
25Votes
- Reported Oct 15, 2024 5:12 PM

This Feature Request is tracking interest in moving forward to the next stable ABI for the C++ MSVC Toolset. This scenario encapsulates the C++ ABI strategy in historical VS releases prior to (and including) Visual Studio 2015, where no C++ ABI compatibility was guaranteed between major releases and each release included a separately-names set of runtime libraries (e.g., VS 2013’s “msvcr120.dll” versus VS 2015’s “vcruntime140.dll”).

Under this scenario, a new stable ABI will be established based upon a prioritized list of breaking changes. Once established, this will become the next major epoch for ABI stability for the C++ MSVC Toolset, expected to last for a number of years and across Visual Studio releases. For further details on binary compatibility, please see C++ binary compatibility 2015-2022 | Microsoft Learn for information about the binary compatibility guarantees provided in the current epoch.

Binaries that expose the C++ v14.* (v14x) ABI as exports, will not be compatible with this new C++ ABI and adoption would require a coordinated effort to rebuild all application code and dependencies using a supported toolset in the “vNext” release epoch. Of course, C and COM-based interface compatibility would be maintained and could enable code sharing/re-use if C++ ABI details are not leaked via those interface(s).

If you’re interested in MSVC Toolset future ABI changes, but the set of restrictions in this Feature Request aren’t right for your use cases, please see the following related tickets:
Support for breaking the STL ABI
C++ MSVC Toolset ABI Break : Build from Source
• Or please leave a comment with more details of your scenario requirements if none of the Feature Requests matches your needs.

Constexpr evaluation of constructor creates copy of string literal
Closed - Fixed24
25Votes
- Reported Feb 17, 2024 11:13 AM

[severity:I’m unable to use this version]
In the below code example msvc creates a additional copy of the string literal “gConstant1” while evaluating the ezStringView constructor in a constexpr context. This leads to the ezStringView instance gConstant1 to be incorrectly initialized. Instead of m_pStart and m_pEnd both pointing to the same block of memory, they instead point to different blocks of memory. Both GCC and Clang handle this case correctly.

repro.cpp:

#include <stdio.h>

using ezUInt32 = unsigned int;

struct ezStringView
{
  constexpr ezStringView();

  /// \brief Creates a string view for the range from pStart to pStart + uiLength.
  constexpr ezStringView(const char* pStart, ezUInt32 uiLength);

  ezUInt32 GetElementCount() const { return (ezUInt32)(m_pEnd - m_pStart); }

private:
  const char* m_pStart = nullptr;
  const char* m_pEnd = nullptr;
};

constexpr ezStringView::ezStringView() = default;

constexpr ezStringView::ezStringView(const char* pStart, ezUInt32 uiLength)
  : m_pStart(pStart)
  , m_pEnd(pStart + uiLength)
{
}

constexpr ezStringView operator"" _ezsv(const char* pString, size_t uiLen)
{
  return ezStringView(pString, static_cast<ezUInt32>(uiLen));
}

const ezStringView gConstant1 = "gConstant1"_ezsv;

int main()
{
    printf("is: %d, should: 10\n", gConstant1.GetElementCount());
    return 0;
}

See https://godbolt.org/z/36svah184 for a comparison between mscv, clang and gcc.

The generated code for msvc looks like this:

ezStringView const gConstant1 DQ FLAT:$SG5289      ; gConstant1
        DQ      FLAT:$SG5290+10
$SG5289 DB        'gConstant1', 00H
        ORG $+5
$SG5290 DB        'gConstant1', 00H
        ORG $+5

As you can see the string literal has been duplicated into SG5289 and SG5290 and gConstant1 references both SG5289 and SG5290 instead of just referencing SG5289 once with and once without offset.

Both clang and gcc behave correctly.

Clang:

gConstant1:
        .quad   .L.str.1
        .quad   .L.str.1+10

.L.str.1:
        .asciz  "gConstant1"

GCC:

.LC0:
        .string "gConstant1"
gConstant1:
        .quad   .LC0
        .quad   .LC0+10

Version of cl.exe used:

Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33519 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

Command line to compile:

cl repro.cpp
Fixed in: Visual Studio 2022 version 17.11Fixed In: Visual Studio 2022 version 17.11 GAFixed InGo to details and discussion >
Internal Compiler Error: compiler file 'D:\a\_work\1\s\src\vctools\Compiler\Utc\src\p2\main.c', line 235
Closed - Fixed16
25Votes
- Reported Feb 26, 2024 10:38 AM

[severity:I’m unable to use this version]
After upgrading to Visual Studio 2022 17.9.0 our code no longer compiles with optimizations enabled.

Repro case SpaceManager.cpp:

#include <xmmintrin.h>
#include <cstdint>
#include <memory>
#include <optional>

typedef uint64_t XrFlags64;

typedef XrFlags64 XrSpaceVelocityFlags;
typedef XrFlags64 XrSpaceLocationFlags;

typedef struct XrVector3f {
	float    x;
	float    y;
	float    z;
} XrVector3f;

typedef struct XrQuaternionf {
	float    x;
	float    y;
	float    z;
	float    w;
} XrQuaternionf;

typedef struct XrPosef {
	XrQuaternionf    orientation;
	XrVector3f       position;
} XrPosef;

namespace DirectX
{
	struct XMMATRIX;

typedef XMMATRIX FXMMATRIX;

struct XMMATRIX
	{
	};

struct XMFLOAT3
	{
		float x;
		float y;
		float z;
	};

void XMStoreFloat3(XMFLOAT3* pDestination) 
	{
		__m128 z;
		_mm_store_ss(&pDestination->z, z);
	}

bool XMMatrixDecompose();
}

namespace xr::math {
	namespace detail {
		template <typename X, typename Y>
		X& implement_math_cast(Y& value) {
			return reinterpret_cast<X&>(value);
		}
	}

void StoreXrVector3(XrVector3f* outVec) {
		XMStoreFloat3(&detail::implement_math_cast<DirectX::XMFLOAT3>(*outVec));
	}

bool StoreXrPose(XrPosef* out, DirectX::FXMMATRIX) {
		if (DirectX::XMMatrixDecompose())         StoreXrVector3(&out->position);
		return true;
	}
}

struct XrSpaceLocationInternal {
	XrSpaceLocationFlags locationFlags;
	XrSpaceVelocityFlags velocityFlags;
	XrPosef pose;
};
namespace msxr {
	struct IXrSpaceManager {
		virtual std::optional<XrSpaceLocationInternal> Locate() const;

};
}
namespace msxr::spaces {
	XrSpaceVelocityFlags XrSpaceVelocityFlags_Valid;
}
namespace {
	using namespace msxr;
	using namespace xr::math;
	using namespace DirectX;

class XrSpaceManager : IXrSpaceManager {
	public:
		std::optional<XrSpaceLocationInternal> Locate() const {
			XrSpaceLocationInternal spaceRelation{};
			spaceRelation.velocityFlags = spaces::XrSpaceVelocityFlags_Valid;

XMMATRIX trackedSpaceToTracker;

StoreXrPose(&spaceRelation.pose, trackedSpaceToTracker);

return spaceRelation;
		}
	};
}

namespace msxr {
	std::unique_ptr<IXrSpaceManager> CreateSpaceManager()
	{
		std::make_unique<XrSpaceManager>();
		return nullptr;
	}
}
  

Compiler output:

SpaceManager.cpp(53) : fatal error C1001: Internal compiler error.
(compiler file 'D:\a\_work\1\s\src\vctools\Compiler\Utc\src\p2\main.c', line 235)
 To work around this problem, try simplifying or changing the program near the locations listed above.
If possible please provide a repro here: https://developercommunity.visualstudio.com
Please choose the Technical Support command on the Visual C++
 Help menu, or open the Technical Support help file for more information
  cl!RaiseException()+0x6c
  cl!RaiseException()+0x6c
  cl!InvokeCompilerPassW()+0xa5e5b
  cl!InvokeCompilerPassW()+0xf298f
  

Command line used:

cl /c /FoSpaceManager.obj /std:c++20 /EHsc /O2 SpaceManager.cpp
  

Compiler version used:

Microsoft (R) C/C++ Optimizing Compiler Version 19.39.33519 for x64
  
Fixed in: Visual Studio 2022 version 17.9.2webC++Fixed InGo to details and discussion >
After updating to VS 17.10 the size of .ilk files has increased considerably, leading to fatal error LNK1210
Closed - Fixed27
24Votes
- Reported May 23, 2024 11:59 AM

[severity:It’s more difficult to complete my work]
After updating to VS 17.10 the .ilk files generated for our projects at work are about 4+ times larger than they were when I worked with VS 17.9.6. One project fails to compile with the error LINK : fatal error LNK1210: exceeded internal ILK size limit; link with /INCREMENTAL:NO (even though the .ilk file size created when compiling with older VS 17.8.3 was only about 400MB).

I tried compiling a simple solution with 5 .cpp files
Incremental-link-test.zip
and even there the .ilk file generated by VS 17.10 was more than 50% larger than it was when compiled by VS 17.9.6.

Fixed In: Visual Studio 2022 version 17.10.4Fixed in: Visual Studio 2022 version 17.11 Preview 3Fixed In: Visual Studio 2022 version 17.8.13webFixed InGo to details and discussion >
local namespace alias not visible in requires clause of nested template lambda
Closed - Fixed13
23Votes
- Reported Apr 22, 2024 1:54 PM

[severity:It’s more difficult to complete my work]
The following code should compile but doesn’t (on msvc v19.38):

namespace my_namespace
{
  constexpr static bool always_true = true;
}

int main()
{
  namespace alias = my_namespace;

  auto f = [&](auto t) {
    return [&]<class U>
      requires alias::always_true
    (U u) -> int
    {
      return 0; 
    }(t);
  };

  return f(17);
}

(https://godbolt.org/z/7ozbqjT8d)

The local namespace alias is not visible from within the requires clause of the nested lambda. This only happens if all the following are satisfied:

This would only be a minor nuisance, if not for the fact that mixing this up with overload resolution can get code that compiles but produces unexpected results. The following compiles and returns 2, but it should return 1: https://godbolt.org/z/aYoPjv6z1. Unfortunately, this was a silent bug in our codebase for a good while.

Fixed in: Visual Studio 2022 version 17.11Fixed In: Visual Studio 2022 version 17.11 GAwebFixed InGo to details and discussion >
VS2022 17.9.1: generates incorrect code in x64 release build if inline expansion is not disabled
Closed - Fixed313
20Votes
- Reported Feb 22, 2024 7:23 PM

[severity:It’s more difficult to complete my work]
VS2022 17.9.1 generates incorrect code in x64 release build if inline expansion is not disabled
Issue is reproducible with VS2022 17.9.0 too (and probably with earlier versions)
Code which reproduces the issue is in the attachment
Project1.zip

Fixed in: Visual Studio 2022 version 17.11Fixed in: Visual Studio 2022 version 17.11 Preview 1Fixed In: Visual Studio 2022 version 17.11 GAwebFixed InGo to details and discussion >
`std::stacktrace` has multiple issues due to its underlying API problems
Under Review6
19Votes
- Reported Jun 27, 2024 6:58 AM

[severity:I’m unable to use this version]
I’m the contributor of MSVC STL std::stacktrace feature. This C++23 feature provides symbolized call stacks.

And I’m aware it has bugs that cannot be fixed by me as an open-source contributor, because of lack of decent public API to properly implement the feature.

There are the following bugs:

  1. Thread unsafety. Relevant DbgHelp functions have warnings that they are single threaded:

All DbgHelp functions, such as this one, are single threaded. Therefore, calls from more than one thread to this function will likely result in unexpected behavior or memory corruption. To avoid this, you must synchronize all concurrent calls from more than one thread to this function.

That’s why MSVC STL implementation resorted to DbgEng. Which causes other problems though, see below. And doesn’t even certainly resolve thread safety issues – despite the lack of such warning, DbgEng appears to be implemented on top of DbgHelp, so I wouldn’t trust concurrent DbgEng and DbgHelp sages.

  1. Inability to symbolize when an executable module and its .pdb has a different absolute path. See issue 4726 and issue 4746, /PDBALTPATH:%_PDB% is not a solution for any case. This problem is applicable to DbgEng only, DbgHelp has a way to bypass strict path expectations, but we don’t use that for thread safety reasons.

  2. Hang when trying to use from within DllMain. See issue 4675. This was resolved as invalid, since nothing is safe from within DllMain. But I would still expect that a debug facility would work, or, at least, fail gracefully (so that stacktrace impl may return an empty string).

  3. CaptureStackBackTrace failing sopradically. See Issue 3889. Note that automatic retry is not possible, because there’s no reliable way to detect such sporadic failure.

  4. Suboptimal CaptureStackBackTrace interface. It doesn’t have a way to continue stack frames enumeration from the place where it stopped, or a way to pass an allocation function to it, so the caller needs to start with maximum allocation. See issue 3859


As a soultion I see either fixing existing APIs, or providing new ones, if the current are unfixable.

I understand that the existing APIs were originally created for limited debugging scenarios, so they weren’t good for std::stacktrace-like scenario, but now as std::stacktrace is a part of C++, you’ll have to support that if you claim to support C++.

Build speed slows down dramatically when using the build option "Inline Expansion"
Under Investigation111
19Votes
- Reported Jun 03, 2024 10:00 AM

In the most recent version 17.10.1 of visual studio, using the build option “Inline Expansion-Ob2” causes the building speed to slow down to a crawl.

inline expansion.zip

The following test code is used to recreate the slow down using minimum requirements. When building our own code using our develop environment, the slowdown effect is amplified with the large amounts of code getting built.
When building some of our files containing the Inline functions, each file takes about 10 minutes to build making the current version unusable for our project.

The test code takes about 6 seconds to build, but when the commented code is used instead, the build time shortens to below 1 second.

Incremental linking get stuck
Under Investigation012
18Votes
- Reported Mar 05, 2024 11:07 PM

[severity:It’s more difficult to complete my work]
We noticed that in some cases, when incremental linking is used, and there is a big change in the compiled files it links, the link.exe process gets stuck for a ridiculously long time.
I will attach logs and relevant outputs in a followup comment.
In the procmon recording, it can be seen that between 18:12:52 and 18:19:30 the process seem to do nothing. It has a total runtime of 10 minutes, while in a clean build scenario the linking takes less than 1 minute.

cl : command line error D8000: UNKNOWN COMMAND-LINE ERROR
Under Investigation130
16Votes
- Reported Oct 14, 2024 9:54 PM

[severity:I’m unable to use this version]
This is happening regularly yet somewhat randomly for my project, and it’s happening on at least 2 separate computers, both when compiled out of visual studio and from the command line using msbuild:

Microsoft ® C/C++ Optimizing Compiler Version 19.42.34321.1 for x64

cl : command line error D8000: UNKNOWN COMMAND-LINE ERROR [c:\develop\source\src\shared\shared.vcxproj]
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information
cl : command line error D8000: UNKNOWN COMMAND-LINE ERROR [c:\develop\source\src\shared\shared.vcxproj]
Please choose the Technical Support command on the Visual C++
Help menu, or open the Technical Support help file for more information

cl : command line error D8040: error creating or communicating with child process [c:\develop\source\src\shared\shared
.vcxproj]

From what i can tell it’s happening to different source files, not a particular one, and somewhat randomly, so not sure how to go about creating a repro.

Visual Studio Debugger can't display values in 'Locals' window
Closed - Fixed18
16Votes
- Reported Nov 22, 2024 12:30 PM

[severity:It’s more difficult to complete my work]
I have a solution which contains 2 projects. The first project in a solution is a command line C++ application. The second project in a solution is a Windows dynamic library (.dll). There are no 3rd party dependencies. C++ standard is set to C++20.

The command line application takes one argument - a path to a .dll file which it then loads, searches for a function in it and calls that function. The code for application is as follows (I’ve omitted error checking for the sake of brevity. Library loads correctly and debugger correctly jumps into library’s code.)

//sdk.hpp
#pragma once

extern "C" __declspec(dllexport) int entry_point(int argc, char** argv);

namespace cli {
    __declspec(dllexport)  int main(int argc, char** argv);
}

// ------------------------------------------------------------------------------

// main.cpp of console application project
#define WIN32_LEAN_AND_MEAN
#include <Windows.h>
#include <filesystem>
#include <iostream>
#include <string>
#include "sdk.hpp"

int main (int argc, char** argv) {
    //Application checks that there is only one argument, the path to that argument isn't a directory and it exists.
    // Omitted for brevity.
    std::filesystem::path p{argv[1]};
    
HANDLE handle = LoadLibraryW(p.wstring().c_str());
    
FARPROC proc_address = GetProcAddress(handle, "entry_point");
    
auto function_ptr = reinterpret_cast<decltype(&entry_point)>(proc_address);
    function_ptr(argc, argv);

return 0;
}
  

Once the debugger is in dynamic library, I’ve noticed two things:

1.) Hovering over a variable to read its value works if and only if a function in which the debugger is currently, has extern "C" linkage.

2.) For every function which doesn’t have extern "C" linkage, hovering over any variable in it doesn’t work. Additionally “Autos” window in debugger doesn’t work for those functions - it doesn’t show any values.

3.) “Locals” window in debugger can’t display values of objects (object in a sense of ‘an instance of a class’). It just displays an error.

Code to reproduce this:

// sdk.cpp, this is a part of a second project - dynamic library
#include "pch.h"
#include "sdk.hpp"

#include <iostream>

namespace cli {

struct wrapped_double_t {
        double d1;
    };

constexpr static const wrapped_double_t global_wrapped_doubles[] = {
        12.9001, 84.55
    };

__declspec(dllexport) int main(int argc, char** argv) {
        constexpr wrapped_double_t local_wrapped_doubles[] = { 14.0, 15.0 };

const auto& g = global_wrapped_doubles[0];
        const auto& l = local_wrapped_doubles[0];

std::cout << "The wrapped value of a global is: " << g.d1 << '\n';
        std::cout << "The wrapped value of a local is: " << l.d1 << '\n';
        return 0;
    }
}

__declspec(dllexport) int entry_point(int argc, char** argv) {
    return cli::main(argc, argv);
}
  

The program correctly outputs “The wrapped value of a global is: 12.9001” and “The wrapped value of a local is: 14” on the standard output. Debugger can’t see this:

Snimka zaslona 2024-11-22 132501.png

Attempting to re-evaluate these values in “Locals” window doesn’t work:

Snimka zaslona 2024-11-22 132525.png

This is an example project to reproduce this error. On a real project my company works on, the issue described in number 3 crashes the debugger completely. Error output is that “msvsmon.exe” has stopped working.

Info on what I’m currently using:

Microsoft Visual Studio Professional 2022
Version 17.11.5
VisualStudio.17.Release/17.11.5+35327.3
Microsoft .NET Framework
Version 4.8.09032

Installed Version: Professional

Visual C++ 2022 00476-80000-00000-AA595
Microsoft Visual C++ 2022

ASP.NET and Web Tools 17.11.231.19466
ASP.NET and Web Tools

Azure App Service Tools v3.0.0 17.11.231.19466
Azure App Service Tools v3.0.0

C# Tools 4.11.0-3.24460.3+5649376e0e5f5db3743a94a62b073f2cce4be5d9
C# components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Linux Core Dump Debugging 1.0.9.35103
Enables debugging of Linux core dumps.

Microsoft JVM Debugger 1.0
Provides support for connecting the Visual Studio debugger to JDWP compatible Java Virtual Machines

NuGet Package Manager 6.11.1
NuGet Package Manager in Visual Studio. For more information about NuGet, visit https://docs.nuget.org/

Test Adapter for Boost.Test 1.0
Enables Visual Studio’s testing tools with unit tests written for Boost.Test. The use terms and Third Party Notices are available in the extension installation directory.

Test Adapter for Google Test 1.0
Enables Visual Studio’s testing tools with unit tests written for Google Test. The use terms and Third Party Notices are available in the extension installation directory.

TypeScript Tools 17.0.30715.2002
TypeScript Tools for Microsoft Visual Studio

Visual Basic Tools 4.11.0-3.24460.3+5649376e0e5f5db3743a94a62b073f2cce4be5d9
Visual Basic components used in the IDE. Depending on your project type and settings, a different version of the compiler may be used.

Visual C++ for Linux Development 1.0.9.35103
Visual C++ for Linux Development

Visual Studio IntelliCode 2.2
AI-assisted development for Visual Studio.

Fixed In: Visual Studio 2022 version 17.12.4Fixed In: Visual Studio 2022 version 17.10.10Fixed In: Visual Studio 2022 version 17.8.17Fixed in: Visual Studio 2022 version 17.13 Preview 3webC++TypescriptDebuggerEditorcrashtesting-toolsFixed InGo to details and discussion >
Please resolve the severe build speed degradation issue (decreased by hundreds of times).
Closed - Duplicate14
15Votes
- Reported Jun 27, 2024 12:49 AM

[severity:I’m unable to use this version]
https://developercommunity.visualstudio.com/t/Build-speed-slows-down-dramatically-when/10673986

The issue described in the link above is a very serious problem for our company’s program. As a result, we have rolled back to version 17.9.7 on our build server from 17.10.x and have notified our internal development team not to update.

This is an extremely critical issue, and we earnestly hope that it will be prioritized and resolved in version 17.10.4 so that we can update.

_free_dbg always locks the __acrt_heap_lock before early out on nullptr
Under Investigation09
14Votes
- Reported Feb 21, 2024 9:32 PM

[severity:It’s more difficult to complete my work]
Any call to delete or free in a debug mod calls _free_dbg, before checking if the pointer is null and early outing the function takes a global lock on the __acrt_heap_lock.

It should first check for null and early out and only then once it knows it has a pointer which actually needs deletion should it take the lock.

Currently any usage of owning pointers be they raw or in a container causes a global lock across threads which in heavily parallel code produces a lot of slow down. In fact since the implemtnation of snprintf internally have a unique_ptr this means that things like formatting into a fixed buffer will always take an allocation lock blocking other threads.

This early out is already applied to freeing an over aligned allocation in _aligned_free_dbg. The same should apply to the normal free.

VS2022 17.10.0 Preview 7: Internal compiler error
Closed - Fixed15
14Votes
- Reported May 14, 2024 10:42 AM

[severity:It’s more difficult to complete my work]
This code causes crash. Empty project with 1 cpp, Debug/Release, standard is set to C++17.
VS2022 Version 17.10.0 Preview 7.0

#include <array>

struct A
{
  constexpr A(double i0, double i1)
    : a{ i0, i1 }
  {}

  double a[2];
};

namespace {
  void f1([[maybe_unused]] const std::array<A, 1>& i_uv = { A{ 0.0, 0.0 } }) {}
}
void f2()
{
  f1();
}
Build started at 12:37 PM...
1>------ Build started: Project: ICE_vs2022_update_10, Configuration: Debug x64 ------
1>FileName.cpp
1>C:\Users\mklymov\source\repos\ICE_vs2022_update_10\ICE_vs2022_update_10\FileName.cpp(17,5): error C1001: Internal compiler error.
1>C:\Users\mklymov\source\repos\ICE_vs2022_update_10\ICE_vs2022_update_10\FileName.cpp(17,5): error C1001: (compiler file 'D:\a\_work\1\s\src\vctools\Compiler\CxxFE\sl\p1\c\toil.c', line 4114)
1>C:\Users\mklymov\source\repos\ICE_vs2022_update_10\ICE_vs2022_update_10\FileName.cpp(17,5): error C1001:  To work around this problem, try simplifying or changing the program near the locations listed above.
1>C:\Users\mklymov\source\repos\ICE_vs2022_update_10\ICE_vs2022_update_10\FileName.cpp(17,5): error C1001: If possible please provide a repro here: https://developercommunity.visualstudio.com 
1>C:\Users\mklymov\source\repos\ICE_vs2022_update_10\ICE_vs2022_update_10\FileName.cpp(17,5): error C1001: Please choose the Technical Support command on the Visual C++ 
1>C:\Users\mklymov\source\repos\ICE_vs2022_update_10\ICE_vs2022_update_10\FileName.cpp(17,5): error C1001:  Help menu, or open the Technical Support help file for more information
1>Done building project "ICE_vs2022_update_10.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 12:37 PM and took 00.610 seconds ==========
Fixed in: Visual Studio 2022 version 17.12 Preview 1Fixed In: Visual Studio 2022 version 17.12webFixed InGo to details and discussion >
C++ Syntax Error after upgrading to Visual Studio 17.11.0
Closed - Fixed18
14Votes
- Reported Aug 16, 2024 9:10 AM

[severity:It bothers me. A fix would be nice]
Hello!

The following code does not compile any more after the upgrade:

#include <string>
struct IModel {
  virtual IModel& Initialize(const std::string&) = 0;
};

template<class T>struct Observable {
  virtual ~Observable() = default;
};

struct Model : public Observable<IModel>, public IModel
{
  Model& Initialize(const std::string&) override {
    return *this;
  }
};
  

It results in this error

c:\Development>cl bug.cpp
Microsoft (R) C/C++ Optimizing Compiler Version 19.41.34120 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

bug.cpp
bug.cpp(13): error C2146: syntax error: missing '>' before identifier '__A0'
bug.cpp(13): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
bug.cpp(13): error C2144: syntax error: 'unknown-type' should be preceded by ')'
bug.cpp(13): error C2144: syntax error: 'unknown-type' should be preceded by ';'
bug.cpp(13): error C2761: 'Initialize': redeclaration of member is not allowed
bug.cpp(13): error C2059: syntax error: ')'
bug.cpp(13): error C2059: syntax error: '{'
bug.cpp(13): error C2143: syntax error: missing ';' before '{'
bug.cpp(13): error C2447: '{': missing function header (old-style formal list?)
  

It compiles for clang, gcc and MSVC prior to 17.11.0
https://godbolt.org/z/ETEqeaG5f

Changing the order of the class derivation list of the Model class, it compiles again.

Fixed In: Visual Studio 2022 version 17.11.5Fixed in: Visual Studio 2022 version 17.12 Preview 3Fixed In: Visual Studio 2022 version 17.12webC++setupEditorFixed InGo to details and discussion >
Add support for the C++23 extended floating-point types
Under Review3
13Votes
- Reported Jul 19, 2024 8:29 AM

I think it’d be important to at least partially support (by adding types that have no native similarity: std::float16_t, std::bfloat16_t and std::float128_t) the C++23 extended floating-point types defined in P1467 to have a more complete set over the types defined at the standard IEEE754 and a better CPU <-> GPU native interoperability thanks to having a direct representation (std::float16_t) of the floating-point half-precision types present in shading languages.

C++ MSVC Toolset ABI Break : Build from Source Scenario
Under Review3
13Votes
- Reported Oct 15, 2024 5:07 PM

This Feature Request is tracking interest for an “evergreen ABI” mode for the C++ MSVC Toolset where all C++ code and dependencies are built from source and can be guaranteed to build using the same release of the toolset.

Under this scenario, there are no guarantees around compatibility of the C++ ABI across releases, including at the granularity of patch-level/servicing releases. All servicing/bug fixes would require picking-up and using a new toolset release and rebuilding the entire application stack from source. C and COM-based interface compatibility would be maintained and could enable code sharing/re-use if C++ ABI details are not leaked via those interface(s).

In this mode, C and C++ runtime deployment would be enabled through App Local and Static Linking only; specifically, there would be no VC++ Redistributable.

If you’re interested in MSVC Toolset future ABI changes, but the set of restrictions in this Feature Request aren’t right for your use cases, please see the following related tickets:
Support for breaking the STL ABI
C++ MSVC Toolset ABI Break : Next Stable ABI epoch
• Or please leave a comment with more details of your scenario requirements if none of the Feature Requests matches your needs.

Syntax error when using non-type template parameters in templated class member function
Under Investigation02
13Votes
- Reported Aug 22, 2024 12:06 PM

[severity:It’s more difficult to complete my work]
When using non-type template parameters in templated class member function a syntax error is emmited

https://godbolt.org/z/xsz5oM87T

The error can be fixed when using brackets like this:
Foo<F1{}, S1{}> foo(){}
or when function foo() is a free function

MSVC instantiates constexpr destructors too early when data member initializers are involved
Under Investigation07
13Votes
- Reported Feb 29, 2024 12:15 AM

[severity:It’s more difficult to complete my work]
I work on MSVC’s C++ Standard Library implementation, and we’ve encountered an apparent bug in the MSVC compiler front-end. We’ve reduced it to a library-free test case (thanks to our GitHub contributor frederick-vs-ja).

VS 2022 17.10 Preview 1 rejects this code. We believe that it’s well-formed, and Clang 17.0.3 accepts it. Note that although the Incomplete type is incomplete in this translation unit, the compiler shouldn’t care - in another translation unit, this type can be completed and the constructor and destructor of B can be defined.

C:\Temp>type meow.cpp
template <typename T>
struct UniquePtr {
    UniquePtr() = default;

    UniquePtr(const UniquePtr&)            = delete;
    UniquePtr& operator=(const UniquePtr&) = delete;

    constexpr ~UniquePtr() { // This constexpr destructor is important
        static_assert(sizeof(T) > 0);
    }
};

struct Incomplete;

struct B {
    B();
    ~B();

    UniquePtr<Incomplete> p{}; // This data member initializer is important
};

int main() {
    B b;
}
C:\Temp>cl /EHsc /nologo /W4 /std:c++20 /c meow.cpp
meow.cpp
meow.cpp(9): error C2027: use of undefined type 'Incomplete'
meow.cpp(13): note: see declaration of 'Incomplete'
meow.cpp(9): note: the template instantiation context (the oldest one first) is
meow.cpp(19): note: see reference to class template instantiation 'UniquePtr<Incomplete>' being compiled
meow.cpp(8): note: while compiling class template member function 'UniquePtr<Incomplete>::~UniquePtr(void)'
meow.cpp(9): error C2607: static assertion failed

C:\Temp>clang-cl /EHsc /nologo /W4 /std:c++20 /c meow.cpp

C:\Temp>
testhost.exe hanging indefinitely when running C++ tests
Need More Info010
12Votes
- Reported Dec 19, 2024 9:46 PM

We randomly have testhost.exe processes hanging during our tests, which is blocking our CI/CD infrastructure.

We are running using: vstest.console.exe" *UnitTests.dll /ResultsDirectory:"$UnitTestResultsDir" /Logger:trx /Parallel

The tests will complete, we get the results, but there are testhost.exe processes that fail to shutdown, they just hang and have to be manually killed otherwise that aforementioned command hangs indefinitely.

One thing to note is that if we do kill the long running testhost.exe process, we successfully get our test results file and the tests have all passed, unblocking our CI/CD pipeline.

Two questions:

  • Is there a way to run this command such that there is a time limit for which testhost.exe processes be running for before being killed?
  • What are some trouble shooting steps we can take for this?
Compilation error in lambda expressions in hierarchies with virtual inheritance
Fixed - Pending Release04
12Votes
- Reported Jan 09, 2025 1:26 PM

[severity:It’s more difficult to complete my work]

Starting from the toolset v14.33-17.3, the C++ lambda expressions have received a new compilation bug. As of now, it is still present in the latest (14.42) Visual Studio 2022 toolset.

It reproduces when:
1) There is a “diamond-shaped” hierarchy with virtual inheritance (e.g., FirstMiddle: virtual ns::Base, SecondMiddle: virtual ns::Base, Derived: FirstMiddle, SecondMiddle).
2) The Base class of this hierarchy is in a namespace that is different from the namespace(s) of its child classes (ns in this example).
3) The Derived class contains a lambda expression in one of its member functions, which accepts a pointer to ns::Base and attempts to perform any kind of operations with that pointer.

The compiler mistakes the type of the argument pointer for something strange (Derived::FirstMiddle::Base*) that is completely “unrelated” to ns::Base*, and thus refuses to compile any meaningful operations with it inside the lambda.

A workaround that I’ve found is to refactor the code so that it wouldn’t use lambda expressions at all (replace them with new functions or “functor” classes), but this is not very convenient most of the time.

Here’s an example:

namespace ns {
struct Base {
    virtual ~Base() = default;
};
}

struct FirstMiddle : virtual ns::Base {
};

struct SecondMiddle : virtual ns::Base {
};

struct Derived : FirstMiddle, SecondMiddle {
    void TestLambda() {
        [](ns::Base* ip_base) {
            ns::Base* p_base_local = ip_base;
        };
    }
};

Output:

example.cpp
<source>(16): error C2440: 'initializing': cannot convert from 'Derived::FirstMiddle::Base *' to 'ns::Base *'
<source>(16): note: Types pointed to are unrelated; conversion requires reinterpret_cast, C-style cast or parenthesized function-style cast
Compiler returned: 2

Godbolt link: https://godbolt.org/z/zvYE7Grn7

Here’s a slightly modified example where I attempt to call a virtual function through that pointer:

namespace ns {
struct Base {
    virtual ~Base() = default;
    virtual void Foo() = 0;
};
}

struct FirstMiddle : virtual ns::Base {
    virtual void Foo() override {}
};

struct SecondMiddle : virtual ns::Base {
};

struct Derived : FirstMiddle, SecondMiddle {
    void TestLambda() {
        [](ns::Base* ip_base) {
            ip_base->Foo();
        };
    }
};

Output:

example.cpp
<source>(18): error C2227: left of '->Foo' must point to class/struct/union/generic type
<source>(18): note: type is 'Derived::FirstMiddle::Base *'
Compiler returned: 2

Godbolt link: https://godbolt.org/z/nc5fqTeMs

Fixed in: Visual Studio 2022 version 17.14 Preview 1webFixed InGo to details and discussion >
Type always prefered over value when using qualified identifiers
Fixed - Pending Release03
12Votes
- Reported Aug 22, 2024 11:14 AM

[severity:It’s more difficult to complete my work]
When a variable has the same name as the type and is defined in a namespace it can not be used as non-type template parameter because the msvc compiler always prefers the type over the value.

See the example on compiler explorer:
https://godbolt.org/z/PYzWKz7s8

Show/Hide debug targets choices are not persisted between sessions
New5
12Votes
- Reported May 29, 2024 7:56 AM

[severity:It’s more difficult to complete my work]
When using cmake integration in VS, the “Standard” toolbar has a “launch debug target” area.
Using cmake, I get a “lot” of unwanted targets there (mostly from dependencies)?

image.png

I rejoiced when I saw that you could “Show/Hide targets” to make the list more useful.
Unfortunately, these choices do not persist between VS launchs making the feature somewhat useless.

Any chance these choices could persist?

Thank you for considering this request 😃
Jean

fatal error C1001: Internal compiler error (backend, 19.39.33522)
Under Investigation13
12Votes
- Reported Mar 14, 2024 1:37 PM

[severity:It’s more difficult to complete my work]
I’ve tried to reduce the code as much as possible. It now doesn’t make sense but leads to compiler crash with /Ox on VS2022. VS2019 processes same code without problems.
cl version: 19.39.33522, x64
/std:c++17 /permissive- /Ox

https://godbolt.org/z/xcKsTh4GK

struct B
{
  unsigned int c = 0;
  unsigned int p = 0;
  unsigned char m_sn[1];
};

struct A
{
  unsigned char* F() const;

  unsigned int s = 0;
  unsigned int bc = 0;
  B** bl = nullptr;
  B& bl0;
};

unsigned char* A::F() const
{
  unsigned char* e = nullptr;
  for (unsigned long long i = 0; i < bc; i++)
  {
    if (bl[i]->c > bl[i]->p)
    {
      for (unsigned long long j = 0; j < bl[i]->c; j++)
      {
        if (bl[i]->m_sn[j])
        {
          return &bl[i]->m_sn[j];
        }
      }
      break;
    }
  }
  const_cast<A*>(this)->s -= bl0.p;
  return e;
}
  

fatal error C1001: Internal compiler error.
1>(compiler file ‘D:\a_work\1\s\src\vctools\Compiler\Utc\src\p2\main.c’, line 235)
1> To work around this problem, try simplifying or changing the program near the locations listed above.
1>If possible please provide a repro here: https://developercommunity.visualstudio.com
1>Please choose the Technical Support command on the Visual C++
1> Help menu, or open the Technical Support help file for more information
1> CL!RaiseException()+0x69
1> CL!RaiseException()+0x69
1> CL!CloseTypeServerPDB()+0x9a5c7
1> CL!CloseTypeServerPDB()+0x14cbbd


Full original source code:
1) download https://github.com/mcneel/opennurbs (tag v8.5.24072.13000)
2) open opennurbs_public.sln, retarget it to latest toolset
3) compile
opennurbs-8.5.24072.13000\opennurbs_lookup.cpp(700): fatal  error C1001: Internal compiler error.
CWinFormsControl ready for .NET 8? Issues with using CWinFormsControl on .NET 8.
New5
11Votes
- Reported Oct 10, 2024 6:55 AM

[severity:It’s more difficult to complete my work]
I experience a couple of issues when trying to use CWinFormsControl in C++/CLI library referencing a Winforms Library with a user control, all on .NET 8:

At first, the compiler fails to include <afxwinforms.h>. The problematic statement in <afxwinforms.h> is

#using <System.Windows.Forms.dll>

which causes a compilation error

 2>D:\dev\samples\dot.net\net8-cppcli\cppcli-mfccontrols-lib\cppcli-mfccontrols-lib.cpp(5,8): error C1107: could not find assembly 'System.Windows.Forms.dll': please specify the assembly search path using /AI or by setting the LIBPATH environment variable

It is possible to fix this by adding <FrameworkReference Include="Microsoft.WindowsDesktop.App.WindowsForms" /> to the project, then searching System.Windows.Forms in external dependencies section of the project, opening properties for this item and copying the full path. Then add this path to Configuration Properties|C/C++|General|Additional #using Directories. But this is more a hack than a solution for productive code, I think 😃

After getting everything compiled, my sample app crashed. The crash was inside CWinFormsControlSite. I had to use a CWinFormsControlSite-derived class to fix this.

All sample code to reproduce this is available at https://github.com/meinig-arts/net8-cppcli.

My final question is: Is CWinFormsControl ready to be used on .NET 8? If not, are there any plans to make it compatible? We are planning to port a large solution from .NET Framework 4.8 to .NET 8. The sample solution (see above) was to check for problems before porting. We use CWinFormsControls to embed WinForms User Controls in an MFC desktop application. Before starting to port we need to have more clarity about this issue.
Thanks for any information about this.

.netwindows formsMFCGo to details and discussion >
Provide the MSVC native toolset as a standalone licensable package for non-C++ environments like Swift to take a dependency on
Under Review2
10Votes
- Reported Dec 18, 2024 9:05 PM

Request: Distribute the VC++ runtime header and import libraries outside of Microsoft Visual Studio, and with a more permissive license, to make the Universal C Runtime usable by non-C++ programming languages. A NuGet package would be ideal.

Problem: Swift natively interoperates with C and C++, and for this purpose the Swift toolchain includes clang. To be interoperable, Swift on Windows builds against the Universal C Runtime from the Windows SDK. However, the UCRT is not self-contained and depends on header files and import libraries that are distributed as part of the Microsoft Visual C++ toolset (%VCToolsInstallDir%\include and %VCToolsInstallDir%\lib). As a result, using Swift on Windows requires an installation of Microsoft Visual Studio, even though none of its tooling is required. This is a large installation size and time burden, and also potentially exposes commercial Swift apps to VS’ license terms.

See this question on the Swift forums.

This may also be an issue for Rust.

Wrong output when compiled in x86 msvc -o2
Under Investigation06
10Votes
- Reported Dec 26, 2024 6:03 AM

[severity:It’s more difficult to complete my work]
We compiled this program in x86 msvc v19 and later, and only got wrong output when compiled with x86 release -o2,
the program output is “fc18000000000000” not “0”
image.png

Godblot

#include <iostream>
#include <vector>
#include <cstdint>

struct FDataConfig {
    int64_t A {};
    int64_t B {};
};

int main()
{
    std::srand(time(nullptr));

    FDataConfig GTBB[2];
    {
        GTBB[0].A = 1000;
        GTBB[0].B = 1000;

        GTBB[1].A = 0;
        GTBB[1].B = 0;
    }

    int i = 0;
    while (i == 0) i = std::rand() & 1;

    int64_t C = -GTBB[i].A;
    std::cout << std::hex << C << std::endl;

    system("Pause");
    return 0;
}