Skip to content

Commit ee5e2eb

Browse files
TylerMSFTTylerMSFT
TylerMSFT
authored and
TylerMSFT
committed
add 17.10 conformance changes
1 parent 6ae1d4c commit ee5e2eb

File tree

1 file changed

+147
-0
lines changed

1 file changed

+147
-0
lines changed

‎docs/overview/cpp-conformance-improvements.md

Lines changed: 147 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -21,9 +21,156 @@ Visual Studio 2022 version 17.10 contains the following conformance improvements
2121

2222
For a broader summary of changes made to the Standard Template Library, see [STL Changelog VS 2022 17.10](https://github.com/microsoft/STL/wiki/Changelog#vs-2022-1710).
2323

24+
---------------------- TW
25+
### Conversion operator specialization with explicitly specified return type
2426

27+
This is a source code breaking change. The compiler used to specialize these conversion operators incorrectly in some cases which can lead to mismatched return type. These invalid specializations no longer happen.
2528

29+
#### Example (before/after)
30+
31+
```cpp
32+
// Example 1
33+
struct S
34+
{
35+
template<typename T> operator const T*();
36+
};
37+
38+
void test()
39+
{
40+
S{}.operator int*(); // this is invalid now
41+
S{}.operator const int*(); // this is valid
42+
}
43+
```
44+
45+
```cpp
46+
// Example 2
47+
// In some cases, the overload resolution result may change
48+
struct S
49+
{
50+
template <typename T> operator T*(); // overload 1
51+
template <typename T> operator const T*(); // overload 2
52+
};
53+
54+
void test() {
55+
S{}.operator int*(); // this used to call overload 2, now it calls overload 1
56+
}
57+
```
58+
59+
### Added Support for `#elifdef` and `#elifndef`
60+
61+
Support added for WG21 p2334r1 (C++23) and WG14 n2645 (C23) which introduced the `#elifdef` and `#elifndef` preprocessor directives.
62+
Requires `/std:clatest` or `/std:c++latest`.
63+
64+
#### Example (before/after)
65+
66+
Before:
67+
68+
```cpp
69+
#ifdef __cplusplus
70+
#include <atomic>
71+
#elif !defined(__STDC_NO_ATOMICS__)
72+
#include <stdatomic.h>
73+
#else
74+
#include <custom_atomics_library.h>
75+
#endif
76+
```
77+
78+
After:
79+
80+
```cpp
81+
#ifdef __cplusplus
82+
#include <atomic>
83+
#elifndef __STDC_NO_ATOMICS__
84+
#include <stdatomic.h>
85+
#else
86+
#include <custom_atomics_library.h>
87+
#endif
88+
```
89+
90+
# Application of `_Alignas` on a structured type in C (also added to 17.9) <!-- Sound-bite description of the change -->
91+
92+
<!-- Metadata -->
93+
| Source/Binary Breaking Change? | Compiler mode | Backward compatible? | EDG Behavior | Commit |
94+
| ------------------------------ | ------------- | -------------------- | ------------ | ------ |
95+
| Yes | C (C17 and later) | No | Unchanged | fe_20231031.02|
96+
97+
### Description/Rationale
98+
In versions of Visual C++ before Visual Studio 2022 version 17.9, when the `_Alignas` specifier appeared adjacent to a structured type in a declaration, it was not applied correctly according to the ISO-C Standard.
99+
100+
### Example
101+
```
102+
// compile with /std:c17
103+
#include <stddef.h>
104+
struct Outer {
105+
_Alignas(32) struct Inner { int i; } member1;
106+
struct Inner member2;
107+
};
108+
static_assert(offsetof(struct Outer, member2)==4, "incorrect alignment");
109+
```
110+
111+
According to the ISO-C Standard, this code should compile without the 'static_assert' emitting a diagnostic. The '_Alignas' directive applies only to the member variable 'member1'. It must not change the alignment of 'struct Inner'. However, before release 17.9.1 of Visual Studio, the diagnostic "incorrect alignment" would be emitted. The compiler would align 'member2' to an offset of 32 bytes within the 'struct Outer' type.
112+
113+
Since fixing this bug is a binary breaking change, a warning is now emitted when this change takes effect. Warning C5274 is now emitted at warning level 1 for the code above:
114+
```
115+
warning C5274: behavior change: _Alignas no longer applies to the type 'Inner' (only applies to declared data objects)
116+
```
117+
A second fix was made to _Alignof in this release. In previous versions of Visual Studio, when the _Alignas specifier appeared adjacent to an anonymous type declaration, it was ignored.
118+
###Example
119+
```
120+
// compile with /std:c17
121+
#include <stddef.h>
122+
struct S {
123+
_Alignas(32) struct { int anon_member; };
124+
int k;
125+
};
126+
static_assert(offsetof(struct S, k)==4, "incorrect offsetof");
127+
static_assert(sizeof(struct S)==32, "incorrect size");
128+
```
129+
Previously, both `static_assert` statements would fail when this code was compiled. Now the code will compile, but with the following level 1 warnings emitted:
130+
```
131+
warning C5274: behavior change: _Alignas no longer applies to the type '<unnamed-tag>' (only applies to declared data objects)
132+
warning C5273: behavior change: _Alignas on anonymous type no longer ignored (promoted members will align)
133+
```
134+
The previous behavior can be achieved by replacing uses of `_Alignas(N)` with `__declspec(align(N))`. This declspec is a documented feature of Visual C and C++ for many releases. Unlike `_Alignas`, use of `declspec(align)` will apply to the type.
135+
136+
# Improved Warning C4706
137+
138+
<!-- Metadata -->
139+
| Source/Binary Breaking Change? | Compiler mode | Backward compatible? | EDG Behavior | Commit |
140+
| ------------------------------ | ------------- | -------------------- | ------------ | ------ |
141+
| Yes | All | Yes | N/A | fe_20240221.03 |
142+
143+
### Description/Rationale
144+
145+
Previously this warning was emitted by the optimizer, c2.dll: one side-effect of this was that the compiler could not detect the convention for suppressing the warning: i.e., wrapping the assignment in parentheses (if an assignment really was intended). By moving the warning from the optimizer to the parser, c1.dll or c1xx.dll, the compiler can now detect the parentheses and hence suppress the warning in these cases.
146+
147+
When the warning was in the optimizer it would only check functions that were, in some way, referenced and hence passed to the optimizer to process. If a function was not referenced, then the optimizer would never see it and the warning would not be emitted.
148+
149+
Now that the warning is in the parser it will be emitted for all functions regardless of whether they are referenced or not.
150+
151+
### Example
152+
```
153+
#pragma warning(error: 4706)
154+
155+
struct S {
156+
auto mf() {
157+
if (value = 9)
158+
return value + 4;
159+
else
160+
return value;
161+
}
162+
163+
int value = 9;
164+
};
165+
```
166+
Previously, as 'mf' is an inline function that is never referenced, it would not be passed to the optimizer and hence warning C4706 would not be emitted for this code: but now that the parser is being used to detect this situation the warning is emitted.
167+
```
168+
t.cpp(5): error C4706: assignment used as a condition
169+
t.cpp(5): note: if an assignment is intended you can enclose it in parentheses, '(e1 = e2)', to silence this warning
170+
```
171+
The fix is to either switch to an equality operator, 'value == 9', if this is what was intended, or to wrap the assignment in parentheses, '(value = 9)', if an assignment really was intended. Or, as the function is unreferenced, it can be removed.
26172

173+
---------------------- /TW
27174

28175
## <a name="improvements_179"></a> Conformance improvements in Visual Studio 2022 version 17.9
29176

0 commit comments

Comments
 (0)