Deprecate experimental coroutine headers #5804
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Drop the undocumented `_SILENCE_CLANG_COROUTINE_MESSAGE` escape hatch. Emit a numbered STL1009 `static_assert` instead of using preprocessor `#error`. Mention C++23 `<generator>`. Add the block to `<experimental/generator>`, which doesn't necessarily drag in `<experimental/coroutine>`. (`<experimental/generator>` might actually work for Clang, but I don't want to increase our support burden.)
`__cpp_impl_coroutine` indicates that modern coroutines are available, so don't waste time explaining how the experimental headers worked. Instead, explain to the user why they're in modern mode (clearly distinguishing C++20 which has modern support by default, from C++14/17 explicitly opting into Future Technology with /await:strict). Then tell them to include the Standard header, and not to include the experimental headers.
…ator>`. Explain how compiler support for either legacy coroutines or standard C++20 coroutines is needed, but then guide the user towards including C++23 `<generator>`.
Make the warning for /await sound more dire by saying that `<coroutine>` is "incompatible" instead of merely "not available". Emphasize that it is "the deprecated /await compiler option", making it clear that it should be removed. Don't say "or use /await:strict for standard coroutines". If the user is in C++20 or later mode, removing deprecated /await is sufficient. If they're in C++14/17 mode, warning STL4038 immediately below will tell them about /await:strict. Don't tell users to use `<experimental/coroutine>`. Slightly clarify warning STL4038, explaining that /await:strict is for C++14/17.
Follow `<experimental/filesystem>` phrasing by adding "by Microsoft" and "superseded" language. We don't need to shout "BUT YOU HAVE BEEN WARNED" a second time, but an ominous "for now" will do.
davidmrdavid
approved these changes
Oct 27, 2025
Member
davidmrdavid
left a comment
davidmrdavid
left a comment
There was a problem hiding this comment.
I'll miss the "YOU HAVE BEEN WARNED" message, but agreed it's probably best without it.
"[...] FOR NOW" 😈
LGTM.
Member
Author
|
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
|
One reason we're still on the experimental generator header is DevCom-10920618 (apparently the MSVC equivalent of llvm/llvm-project#56507) - using the new implementation is blocked on 32-bit x86 MSVC with /guard:cf. It'd be appreciated if its final removal from STL would be gated on this compiler bug being fixed. |
Member
Author
|
Thanks, I've marked that bug as "STL-requested" and commented internally. A couple of back-end devs were analyzing it earlier this month, but I haven't seen a PR yet. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In the MSVC Build Tools 14.50 shipping in VS 2026 18.0, the
/awaitcompiler option was officially deprecated and emits a driver warning. However, driver warnings don't terminate builds, even with/WX:To turn up the heat, I want to "hard deprecate" the experimental coroutine headers, matching what we did with
<experimental/filesystem>,<hash_map>, and<hash_set>. This means adding an impossible-to-miss compiler error, with an escape hatch. This will ship in MSVC Build Tools 14.51, making MSVC Build Tools 14.52 the earliest we could completely remove the headers (it remains to be seen whether we can/will be that aggressive).I am also improving our various warning and error messages to guide users towards the modern Standard ways.