premake-core: Using `C++2a` as a `cppdialect` triggers the Default dialect (C++14)

What seems to be the problem? I wanted to use C++20 Draft version as C++ dialect in my project (the latest C++ available), and I specified C++2a as the cppdialect for the project, following this documentation that states it’s the value to use for that.

However, once I generated the project in Visual Studio 2019, I found that the language is the default Default (ISO C++14 Standard). This might be the default version triggered, so I initially thought it was something I was doing wrong, but just changing the cppdialect to C++latest actually works and enables the C++20 Draft.

I also checked the GitHub documentation for this to see if there was something wrong, and apparently it looks like it’s still under construction.

I made a screenshot to illustrate the problem:

The current configuration I have in the premake is the next one:

workspace "WksName"
	... [some specifications here]...

project "ProjectName"
	kind "ConsoleApp"
	language "C++"
	cppdialect "C++2a"
	staticruntime "on"
	... [more specifications here]...

The ...[more specifications here]... is just stuff that I’m configuring and removing here for clarity (they work properly always). Using the latest label will work fine for me now, but I think this might still be worth flagging.

What did you expect to happen? C++2a triggers usage of C++20 Draft.

What have you tried so far? Using C++2a triggers Deafult (C++14), using C++latest triggers C++20 Draft (actually shown as Preview - Features from the Latest C++ Working Draft (/std:c++latest).

How can we reproduce this? By specifying C++2a as a cppdialect and generating the project (for me it’s Visual Studio 2019, not sure about other IDEs or versions), then checking the C++ version used.

Visual Studio 2019 (vs2019)

What version of Premake are you using? 5.0.0-beta2

About this issue

Original URL
State: open
Created a year ago
Comments: 18 (13 by maintainers)

Most upvoted comments

Indeed, I miss m.languageStandard, so just doc to update, and warning later when supported. (A simple print would seem enough for me).

Jarod42 on Feb 1, 2023

@nickclark2016: It is there modules/vstudio/vs2010_vcxproj.lua#L1634.

Ideally, I think exporters should warn about unsupported fields. (pretty sure we will disagree on that 😉 )

At minima, documentation should be updated.

Jarod42 on Feb 1, 2023

I think the initial thought on the cppdialect flag was that we’d only support the language versions explicitly called out by the toolchain and C++latest, so we didn’t support the GNU and C++ draft versions in VS. As it currently stands, I don’t see this as a bug, but a documentation deficiency.

nickclark2016 on Jan 31, 2023