[RASAPI32] Add stub for RasGetConnectionStatistics #12
Conversation
This file contains 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
learn-more
requested changes
Oct 4, 2017
ThFabba
approved these changes
Oct 4, 2017
|
@learn-more that's my real name, I already commited (sent patches) with it. See: https://github.com/reactos/reactos/search?utf8=%E2%9C%93&q=Stas%27M&type=Commits |
|
@binarymaster : the commit lists as author: 'From: binarymaster redacted@gmail.com' |
|
UPD: just noticed, there was nickname instead of name in commit author field, thanks! |
binarymaster
force-pushed
the
rasapi
branch
2 times, most recently
from
580002d
to
2d73025
Compare
|
Fixed author field, and rebased with latest changes. |
learn-more
approved these changes
Oct 4, 2017
|
This shouldn't be merged here. This is a Winesynced DLL. You should propose upstream (either Wine or Wine-Staging). |
Could you do this? The patch is pretty simple. I found it a bit complicated (still cloning wine repo, about a hour). |
|
UPD: filed a patch to Wine-Staging: https://dev.wine-staging.com/patches/203/ Hope I've done it right. |
|
Got accepted \o/ |
@binarymaster you can clone big repos with the It's very useful for quick patches in big repositories. Diff history will be ommited in your local clone, so you won't be able to view the changes a file has gotten beyond the depth you specify. In case you ever need/want to finish downloading the remaining history, you can use |
|
@AmineKhaldi: Shall we still apply the patch, or import the related wine-staging instead? |
|
@tkreuzer I'd prefer picking this up from the Wine Staging side if that's okay, otherwise we would for example need to go over the sync commits (that list of changes you see in the commit log of each module sync) with a fine tooth comb to eliminate all the commits that we already merged outside the syncs. |
|
Along with this commit 5048dc8 the patch resolves the issue!
|
|
In that case we can close this PR? |
|
@learn-more see my last comment in CORE-10426, without this patch service fails to start. |
|
Commit 5048dc8 only allows to pass the install without errors. |
|
Yes but this exact commit comes from the staging side, so we do not need this PR anymore. |
|
Well, it would be better to sync this first, then close the PR. 🙄 @AmineKhaldi can you do it? |
AmineKhaldi
added
the
3rd party sync
|
Is this done? |
|
Awaits to be synced. |
binarymaster
force-pushed
the
rasapi
branch
2 times, most recently
from
45c55d8
to
a9d5eaf
Compare
See CORE-10426
|
https://source.winehq.org/git/wine.git/commit/290aec59aa18e0bdd481c9ae36e24a75e1254bc8 My patch just got into Wine! |
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Apr 12, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Apr 12, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Apr 14, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
May 7, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Jul 2, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
archeYR
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Jul 2, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Aug 13, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Aug 14, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
DarkFire01
pushed a commit
to Ring-0-Productions/reactos
that referenced
this pull request
Sep 13, 2022
# This is the 1st commit message: [SPEC2DEF] Implement generating export patch information Now spec2def uses the version annotations in spec files to generate a table, which will be used to dynamically patch the export table based on the current process' appcompat settings, when a dll is initialized, allowing to export the appropriate functions for each version. This feature is still disabled in config.cmake with the variable DISABLE_EXPORT_VERSIONING. # This is the commit message #2: [NTDLL] Add mechanism to patch the export table at runtime The loader checks for a ros-compat-descriptor, and if one is found, parses it's entries. Each entry corresponds to an export and provides a bitmask that specifies on what Windows version the export exists. If the bit for the process' appcompat version (default is still Windows 2003) is set, the export will be kept, otherwise the export will be moved into a second (private) export table. If a module has a ros-compat-descritor, it is still allowed to import these hidden exports. # This is the commit message #3: [ROSCOMPAT_APITEST] Add initial test for export rewriting # This is the commit message #4: [COMCTL32] Include roscompat descriptor # This is the commit message #5: [WINHTTP] Include roscompat descriptor, so that winhttp can use nt6+ apis # This is the commit message reactos#6: [REACTOS] Make sure xxx_vista is linked to before xxx This is required, because with dynamically patched export tables we will export all vista functions from the main dll, and you can link to them at compile time, but they will not be resolved at runtime, unless the importer has a roscompat-descriptor. Linking the vista version first will resolve the imports from the vista dll. # This is the commit message reactos#7: [NTDLL] Don't derive appcompat version from manifest # This is the commit message reactos#8: [KERNEL32] Export more Vista APIs Create kernel32_vista_static library and link both kernel32_vista and kernel32 to it. Export some vista functions from kernel32. # This is the commit message reactos#9: [NTDLL] Link rtl_vista and export some vista functions # This is the commit message reactos#10: [APISETS] Improve/fix up some exports # This is the commit message reactos#11: [MSVCRT] Export _vcwprintf # This is the commit message reactos#12: [KERNEL32_APITEST] Hack the loader test The test is mapping ntdll using MapViewOfFile, bypassing the loader, then enumerates it's exports, and then passes the names to GetProcAddress, which is hiding some of the original exports. At this point we do not support this scenario. # This is the commit message reactos#13: [SDK] Enable export patching # This is the commit message reactos#14: [MSVCRT][CPPRT] Adjust Cxxhandler3 # This is the commit message reactos#15: oops
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
That's my patch from CORE-10426.