Code highlighting for C++23

Hello!
The clangd in the VSCode doesn't highlight C++20/23 features and marks them as errors on Windows when using C++23 standard.
I use clangd 17.0.6 with the clang-cl compiler 17.0.6 installed manually from llvm-project releases, but I have the same problem with compilers installed through the Visual Studio installer. Also, when I switch the compiler to Microsoft's cl or clang GNU CLI, it works as expected.
There is a code to reproduce the problem:
# CMakeLists.txt
cmake_minimum_required(VERSION 3.27)
project(sample_project)
add_executable(sample_project main.cpp)
set_target_properties(sample_project PROPERTIES CXX_STANDARD 23)

compile_commands.json
[
{
  "directory": "D:/Projects/cxx/build/release",
  "command": "C:\\PROGRA~1\\LLVM\\bin\\clang-cl.exe  /nologo -TP /DWIN32 /D_WINDOWS /EHsc /O2 /Ob2 /DNDEBUG -std:c++latest -MD /FoCMakeFiles\\sample_project.dir\\main.cpp.obj /FdTARGET_COMPILE_PDB -c -- D:\\Projects\\cxx\\main.cpp",
  "file": "D:\\Projects\\cxx\\main.cpp",
  "output": "CMakeFiles\\sample_project.dir\\main.cpp.obj"
}
]

(just a sample from the c++ docs)
// main.cpp
#include <string>
#include <cstddef>
#include <concepts>
template<typename T>
concept Hashable = requires(T a)
{
    { std::hash<T>{}(a) } -> std::convertible_to<std::size_t>;
};
struct meow {};
template<Hashable T>
void f(T) {}
int main()
{
    using std::operator""s;
    f("abc"s);    // OK, std::string satisfies Hashable
    // f(meow{}); // Error: meow does not satisfy Hashable
}

Btw, switching to the C++20 standard fixes the problem for the sample above but it obviously will not work for C++23 library features like <print> and other.
Below the clangd extension output:
I[23:46:53.223] <-- textDocument/codeAction(14)
I[23:46:53.224] --> reply:textDocument/codeAction(14) 0 ms
I[23:46:53.224] --> textDocument/clangd.fileStatus
I[23:46:55.363] <-- shutdown(15)
I[23:46:55.363] --> reply:shutdown(15) 0 ms
I[23:46:55.369] <-- exit
I[23:46:55.369] LSP finished, exiting with status 0
I[23:46:55.390] clangd version 17.0.6
I[23:46:55.391] Features: windows
I[23:46:55.391] PID: 23276
I[23:46:55.391] Working directory: d:\Projects\cxx
I[23:46:55.391] argv[0]: C:/Program Files/LLVM/bin/clangd.exe
I[23:46:55.398] Starting LSP over stdin/stdout
I[23:46:55.398] <-- initialize(0)
I[23:46:55.400] --> reply:initialize(0) 2 ms
I[23:46:55.401] <-- initialized
I[23:46:55.404] <-- textDocument/didOpen
I[23:46:55.405] Loaded compilation database from d:\Projects\cxx\compile_commands.json
I[23:46:55.406] ASTWorker building file d:\Projects\cxx\main.cpp version 151 with command
[D:/Projects/cxx/build/release]
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" --driver-mode=cl /nologo /DWIN32 /D_WINDOWS /EHsc /O2 /Ob2 /DNDEBUG -MD /FdTARGET_COMPILE_PDB -c "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\17" -- "d:\\Projects\\cxx\\main.cpp"
I[23:46:55.406] --> window/workDoneProgress/create(0)
I[23:46:55.406] Enqueueing 1 commands for indexing
I[23:46:55.408] --> textDocument/clangd.fileStatus
I[23:46:55.408] <-- textDocument/didOpen
I[23:46:55.410] <-- textDocument/didOpen
I[23:46:55.410] <-- reply(0)
I[23:46:55.410] --> $/progress
I[23:46:55.410] --> $/progress
I[23:46:55.410] <-- textDocument/documentSymbol(1)
I[23:46:55.411] <-- textDocument/codeAction(2)
I[23:46:55.413] Failed to find compilation database for c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\yvals_core.h
I[23:46:55.413] Failed to find compilation database for c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\ranges
I[23:46:55.413] ASTWorker building file c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\yvals_core.h version 1 with command clangd fallback
[c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include]
"C:\\Program Files\\LLVM\\bin\\clang" -xobjective-c++-header "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\17" -- "c:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\include\\yvals_core.h"
I[23:46:55.413] ASTWorker building file c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\ranges version 1 with command clangd fallback
[c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include]
"C:\\Program Files\\LLVM\\bin\\clang" -xobjective-c++-header "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\17" -- "c:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\include\\ranges"
I[23:46:55.415] --> textDocument/clangd.fileStatus
I[23:46:55.416] --> textDocument/clangd.fileStatus
I[23:46:55.416] <-- textDocument/documentLink(3)
I[23:46:55.419] <-- textDocument/inlayHint(4)
I[23:46:55.425] Indexed D:\Projects\cxx\main.cpp (9 symbols, 1475 refs, 10 files)
I[23:46:55.425] Failed to compile D:\Projects\cxx\main.cpp, index may be incomplete
I[23:46:55.428] Built preamble of size 471064 for file d:\Projects\cxx\main.cpp version 151 in 0.02 seconds
I[23:46:55.428] --> workspace/semanticTokens/refresh(1)
I[23:46:55.429] --> textDocument/clangd.fileStatus
I[23:46:55.429] Indexing c++14 standard library in the context of d:\Projects\cxx\main.cpp
I[23:46:55.429] <-- reply(1)
I[23:46:55.432] Built preamble of size 499040 for file c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\yvals_core.h version 1 in 0.02 seconds
I[23:46:55.432] --> workspace/semanticTokens/refresh(2)
I[23:46:55.432] Built preamble of size 472872 for file c:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\ranges version 1 in 0.02 seconds
I[23:46:55.432] --> workspace/semanticTokens/refresh(3)
I[23:46:55.433] <-- reply(2)
I[23:46:55.433] <-- reply(3)
I[23:46:55.443] --> textDocument/publishDiagnostics
I[23:46:55.443] --> textDocument/inactiveRegions
I[23:46:55.443] --> reply:textDocument/documentSymbol(1) 32 ms
I[23:46:55.443] --> reply:textDocument/codeAction(2) 32 ms
I[23:46:55.443] --> reply:textDocument/documentLink(3) 27 ms
I[23:46:55.443] --> reply:textDocument/inlayHint(4) 24 ms
I[23:46:55.443] --> textDocument/clangd.fileStatus
I[23:46:55.452] <-- textDocument/semanticTokens/full(5)
I[23:46:55.452] --> reply:textDocument/semanticTokens/full(5) 0 ms
I[23:46:55.452] --> textDocument/clangd.fileStatus
I[23:46:55.464] --> $/progress
I[23:46:55.688] --> textDocument/publishDiagnostics
I[23:46:55.691] --> textDocument/inactiveRegions
I[23:46:55.691] --> textDocument/clangd.fileStatus
I[23:46:55.710] <-- textDocument/documentSymbol(6)
I[23:46:55.710] --> reply:textDocument/documentSymbol(6) 0 ms
I[23:46:55.710] --> textDocument/clangd.fileStatus
I[23:46:55.715] <-- textDocument/foldingRange(7)
I[23:46:55.715] --> reply:textDocument/foldingRange(7) 0 ms
I[23:46:55.716] <-- textDocument/codeAction(8)
I[23:46:55.716] --> reply:textDocument/codeAction(8) 0 ms
I[23:46:55.716] --> textDocument/clangd.fileStatus
I[23:46:55.740] --> textDocument/publishDiagnostics
I[23:46:55.740] --> textDocument/inactiveRegions
I[23:46:55.740] --> textDocument/clangd.fileStatus
I[23:46:56.244] Indexed c++14 standard library (incomplete due to errors): 12104 symbols, 1167 filtered

I notice the compile command contains -std:c++latest, I suspect that may be the issue, as clangd doesn't support "latest" as a standard version name (https://github.com/clangd/clangd/issues/527).
Can you try explicitly specifying -std=c++23 (either arrange for CMake to add it to compile_commands.json, or via the config file), and see if that fixes it?

@HighCommander4 unfortunately it doesn't help. I have already tried both methods.

Hm... I found out that it doesn't even compile either with -std=c++23 or -std:c++23 only with -std:c++latest

Looks like there is no flag с++23 and с++26 for msvc so the clang-cl hasn't them too, and c++latest is just an alias for the c++26.

Note that at this pre-release stage, clang's flag name for what is expected to be C++26 is c++2c (and more importantly, of course not all C++26 features are implemented yet). You can have a look at https://clang.llvm.org/cxx_status for a table showing which features are available in which clang versions.

Hm... I found out that it doesn't even compile either with -std=c++23 or -std:c++23 only with -std:c++latest

Are you still referring to the code example in the bug description, or something else?
That example does not appear to use anything newer than C++20, and compiles fine for me with either -std=c++20 or -std=c++23 (though I'm testing on Linux, not Windows).

Are you still referring to the code example in the bug description, or something else?

Yes, I do. As I described earlier, it is still not possible to use C++23 features. If you try to add something like std::println it will be highlighted as an error. And the reason I believe that it is a bug that I can actually compile this code with the flag -std:c++latest, but highlighting is not working.

If you try to add something like std::println it will be highlighted as an error.

Could you post a specific code example where you get the error, and associated clangd logs, for further investigation?

Sure. There is another one example.
cmake_minimum_required(VERSION 3.27)
project(sample_project)
add_executable(sample_project main.cpp)
set_target_properties(sample_project PROPERTIES CXX_STANDARD 23)

[
{
  "directory": "D:/Projects/cxx/build/release",
  "command": "C:\\PROGRA~1\\LLVM\\bin\\clang-cl.exe  /nologo -TP /DWIN32 /D_WINDOWS /EHsc /O2 /Ob2 /DNDEBUG -std:c++latest -MD /FoCMakeFiles\\sample_project.dir\\main.cpp.obj /FdTARGET_COMPILE_PDB -c -- D:\\Projects\\cxx\\main.cpp",
  "file": "D:\\Projects\\cxx\\main.cpp",
  "output": "CMakeFiles\\sample_project.dir\\main.cpp.obj"
}
]

#include <print>
int main()
{
    std::println("{}", 123);
    return 0;
}

I[10:53:55.805] <-- shutdown(25)
I[10:53:55.805] --> reply:shutdown(25) 0 ms
I[10:53:55.811] <-- exit
I[10:53:55.811] LSP finished, exiting with status 0
I[10:53:55.831] clangd version 17.0.6
I[10:53:55.832] Features: windows
I[10:53:55.832] PID: 10672
I[10:53:55.832] Working directory: d:\Projects\cxx
I[10:53:55.832] argv[0]: C:/Program Files/LLVM/bin/clangd.exe
I[10:53:55.839] Starting LSP over stdin/stdout
I[10:53:55.840] <-- initialize(0)
I[10:53:55.841] --> reply:initialize(0) 1 ms
I[10:53:55.842] <-- initialized
I[10:53:55.845] <-- textDocument/didOpen
I[10:53:55.846] Loaded compilation database from d:\Projects\cxx\compile_commands.json
I[10:53:55.846] --> window/workDoneProgress/create(0)
I[10:53:55.846] ASTWorker building file d:\Projects\cxx\main.cpp version 14 with command
[D:/Projects/cxx/build/release]
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" --driver-mode=cl /nologo /DWIN32 /D_WINDOWS /EHsc /O2 /Ob2 /DNDEBUG -MD /FdTARGET_COMPILE_PDB -c "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\17" -- "d:\\Projects\\cxx\\main.cpp"
I[10:53:55.846] Enqueueing 1 commands for indexing
I[10:53:55.847] <-- reply(0)
I[10:53:55.847] --> $/progress
I[10:53:55.847] --> $/progress
I[10:53:55.848] --> $/progress
I[10:53:55.848] --> $/progress
I[10:53:55.848] --> $/progress
I[10:53:55.849] --> textDocument/clangd.fileStatus
I[10:53:55.850] <-- textDocument/documentSymbol(1)
I[10:53:55.850] <-- textDocument/codeAction(2)
I[10:53:55.858] <-- textDocument/documentLink(3)
I[10:53:55.862] <-- textDocument/inlayHint(4)
I[10:53:55.865] Built preamble of size 470040 for file d:\Projects\cxx\main.cpp version 14 in 0.02 seconds
I[10:53:55.866] --> workspace/semanticTokens/refresh(1)
I[10:53:55.866] --> textDocument/clangd.fileStatus
I[10:53:55.866] Indexing c++14 standard library in the context of d:\Projects\cxx\main.cpp
I[10:53:55.866] <-- reply(1)
I[10:53:55.874] <-- textDocument/semanticTokens/full(5)
I[10:53:55.914] Indexed D:\Projects\cxx\main.cpp (6 symbols, 1469 refs, 9 files)
I[10:53:55.914] Failed to compile D:\Projects\cxx\main.cpp, index may be incomplete
I[10:53:55.919] --> textDocument/publishDiagnostics
I[10:53:55.919] --> textDocument/inactiveRegions
I[10:53:55.919] --> reply:textDocument/documentSymbol(1) 69 ms
I[10:53:55.919] --> reply:textDocument/codeAction(2) 69 ms
I[10:53:55.919] --> reply:textDocument/documentLink(3) 61 ms
I[10:53:55.919] --> reply:textDocument/inlayHint(4) 57 ms
I[10:53:55.919] --> reply:textDocument/semanticTokens/full(5) 45 ms
I[10:53:55.919] --> textDocument/clangd.fileStatus
I[10:53:55.940] --> $/progress
I[10:53:56.159] <-- textDocument/documentSymbol(6)
I[10:53:56.159] --> reply:textDocument/documentSymbol(6) 0 ms
I[10:53:56.159] --> textDocument/clangd.fileStatus
I[10:53:56.160] <-- textDocument/foldingRange(7)
I[10:53:56.160] --> reply:textDocument/foldingRange(7) 0 ms
I[10:53:56.180] <-- textDocument/codeAction(8)
I[10:53:56.180] --> reply:textDocument/codeAction(8) 0 ms
I[10:53:56.180] --> textDocument/clangd.fileStatus
I[10:53:56.696] Indexed c++14 standard library (incomplete due to errors): 12104 symbols, 1167 filtered

(though I'm testing on Linux, not Windows)
I think this problem is clang-cl specific, because it works fine with GNU CLI version of the clang which has corresponding flags (I mean c++23 and c++26). Btw, it also works fine with the cl compiler and -std:c++latest flag. So I think there should be a possible fix.

In your example, you still have -std:c++latest in the compile_commands.json.

This is the relevant part of the log:
I[10:53:55.846] ASTWorker building file d:\Projects\cxx\main.cpp version 14 with command
[D:/Projects/cxx/build/release]
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" --driver-mode=cl /nologo /DWIN32 /D_WINDOWS /EHsc /O2 /Ob2 /DNDEBUG -MD /FdTARGET_COMPILE_PDB -c "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\17" -- "d:\\Projects\\cxx\\main.cpp"

There is no std flag here because latest wasn't recognized. For the example to work, an std flag should appear in this line of the log.

I think this problem is clang-cl specific

This is just a guess, but the flag format might be /std:c++23 for clang-cl?

Well, there is no another options... With other flags such as -std:c++23, -std=c++23 and /std:c++23 it still doesn't work and moreover it will not compile if I specify it explicitly through CMAKE_CXX_FLAGS.

With other flags such as -std:c++23, -std=c++23 and /std:c++23 it still doesn't work and moreover it will not compile if I specify it explicitly through CMAKE_CXX_FLAGS.

Can you try with
CompileFlags:
 Add: [/std=c++23]

and show verbose logs (to make the logs verbose, add --log=verbose to "clangd.arguments".

V[11:23:11.081] <<< {"id":9,"jsonrpc":"2.0","method":"shutdown"}

I[11:23:11.081] <-- shutdown(9)
I[11:23:11.081] --> reply:shutdown(9) 0 ms
V[11:23:11.081] >>> {"id":9,"jsonrpc":"2.0","result":null}

V[11:23:11.088] <<< {"jsonrpc":"2.0","method":"exit"}

I[11:23:11.088] <-- exit
I[11:23:11.088] LSP finished, exiting with status 0
I[11:23:11.108] clangd version 17.0.6
I[11:23:11.109] Features: windows
I[11:23:11.109] PID: 19656
I[11:23:11.109] Working directory: d:\Projects\cxx
I[11:23:11.109] argv[0]: C:/Program Files/LLVM/bin/clangd.exe
I[11:23:11.109] argv[1]: --log=verbose
V[11:23:11.115] User config file is C:\Users\kozin\AppData\Local\clangd\config.yaml
I[11:23:11.115] Starting LSP over stdin/stdout
V[11:23:11.116] <<< {"id":0,"jsonrpc":"2.0","method":"initialize","params":{"capabilities":{"general":{"markdown":{"parser":"marked","version":"1.1.0"},"positionEncodings":["utf-16"],"regularExpressions":{"engine":"ECMAScript","version":"ES2020"},"staleRequestSupport":{"cancel":true,"retryOnContentModified":["textDocument/semanticTokens/full","textDocument/semanticTokens/range","textDocument/semanticTokens/full/delta"]}},"notebookDocument":{"synchronization":{"dynamicRegistration":true,"executionSummarySupport":true}},"textDocument":{"callHierarchy":{"dynamicRegistration":true},"codeAction":{"codeActionLiteralSupport":{"codeActionKind":{"valueSet":["","quickfix","refactor","refactor.extract","refactor.inline","refactor.rewrite","source","source.organizeImports"]}},"dataSupport":true,"disabledSupport":true,"dynamicRegistration":true,"honorsChangeAnnotations":false,"isPreferredSupport":true,"resolveSupport":{"properties":["edit"]}},"codeLens":{"dynamicRegistration":true},"colorProvider":{"dynamicRegistration":true},"completion":{"completionItem":{"commitCharactersSupport":true,"deprecatedSupport":true,"documentationFormat":["markdown","plaintext"],"insertReplaceSupport":true,"insertTextModeSupport":{"valueSet":[1,2]},"labelDetailsSupport":true,"preselectSupport":true,"resolveSupport":{"properties":["documentation","detail","additionalTextEdits"]},"snippetSupport":true,"tagSupport":{"valueSet":[1]}},"completionItemKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25]},"completionList":{"itemDefaults":["commitCharacters","editRange","insertTextFormat","insertTextMode"]},"contextSupport":true,"dynamicRegistration":true,"editsNearCursor":true,"insertTextMode":2},"declaration":{"dynamicRegistration":true,"linkSupport":true},"definition":{"dynamicRegistration":true,"linkSupport":true},"diagnostic":{"dynamicRegistration":true,"relatedDocumentSupport":false},"documentHighlight":{"dynamicRegistration":true},"documentLink":{"dynamicRegistration":true,"tooltipSupport":true},"documentSymbol":{"dynamicRegistration":true,"hierarchicalDocumentSymbolSupport":true,"labelSupport":true,"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]},"tagSupport":{"valueSet":[1]}},"foldingRange":{"dynamicRegistration":true,"foldingRange":{"collapsedText":false},"foldingRangeKind":{"valueSet":["comment","imports","region"]},"lineFoldingOnly":true,"rangeLimit":5000},"formatting":{"dynamicRegistration":true},"hover":{"contentFormat":["markdown","plaintext"],"dynamicRegistration":true},"implementation":{"dynamicRegistration":true,"linkSupport":true},"inactiveRegionsCapabilities":{"inactiveRegions":true},"inlayHint":{"dynamicRegistration":true,"resolveSupport":{"properties":["tooltip","textEdits","label.tooltip","label.location","label.command"]}},"inlineValue":{"dynamicRegistration":true},"linkedEditingRange":{"dynamicRegistration":true},"onTypeFormatting":{"dynamicRegistration":true},"publishDiagnostics":{"codeDescriptionSupport":true,"dataSupport":true,"relatedInformation":true,"tagSupport":{"valueSet":[1,2]},"versionSupport":false},"rangeFormatting":{"dynamicRegistration":true},"references":{"dynamicRegistration":true},"rename":{"dynamicRegistration":true,"honorsChangeAnnotations":true,"prepareSupport":true,"prepareSupportDefaultBehavior":1},"selectionRange":{"dynamicRegistration":true},"semanticTokens":{"augmentsSyntaxTokens":true,"dynamicRegistration":true,"formats":["relative"],"multilineTokenSupport":false,"overlappingTokenSupport":false,"requests":{"full":{"delta":true},"range":true},"serverCancelSupport":true,"tokenModifiers":["declaration","definition","readonly","static","deprecated","abstract","async","modification","documentation","defaultLibrary"],"tokenTypes":["namespace","type","class","enum","interface","struct","typeParameter","parameter","variable","property","enumMember","event","function","method","macro","keyword","modifier","comment","string","number","regexp","operator","decorator"]},"signatureHelp":{"contextSupport":true,"dynamicRegistration":true,"signatureInformation":{"activeParameterSupport":true,"documentationFormat":["markdown","plaintext"],"parameterInformation":{"labelOffsetSupport":true}}},"synchronization":{"didSave":true,"dynamicRegistration":true,"willSave":true,"willSaveWaitUntil":true},"typeDefinition":{"dynamicRegistration":true,"linkSupport":true},"typeHierarchy":{"dynamicRegistration":true}},"window":{"showDocument":{"support":true},"showMessage":{"messageActionItem":{"additionalPropertiesSupport":true}},"workDoneProgress":true},"workspace":{"applyEdit":true,"codeLens":{"refreshSupport":true},"configuration":true,"diagnostics":{"refreshSupport":true},"didChangeConfiguration":{"dynamicRegistration":true},"didChangeWatchedFiles":{"dynamicRegistration":true,"relativePatternSupport":true},"executeCommand":{"dynamicRegistration":true},"fileOperations":{"didCreate":true,"didDelete":true,"didRename":true,"dynamicRegistration":true,"willCreate":true,"willDelete":true,"willRename":true},"inlayHint":{"refreshSupport":true},"inlineValue":{"refreshSupport":true},"semanticTokens":{"refreshSupport":true},"symbol":{"dynamicRegistration":true,"resolveSupport":{"properties":["location.range"]},"symbolKind":{"valueSet":[1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26]},"tagSupport":{"valueSet":[1]}},"workspaceEdit":{"changeAnnotationSupport":{"groupsOnLabel":true},"documentChanges":true,"failureHandling":"textOnlyTransactional","normalizesLineEndings":true,"resourceOperations":["create","rename","delete"]},"workspaceFolders":true}},"clientInfo":{"name":"Visual Studio Code","version":"1.84.2"},"initializationOptions":{"clangdFileStatus":true,"fallbackFlags":[]},"locale":"en","processId":2928,"rootPath":"d:\\Projects\\cxx","rootUri":"file:///d%3A/Projects/cxx","trace":"off","workspaceFolders":[{"name":"cxx","uri":"file:///d%3A/Projects/cxx"}]}}

I[11:23:11.116] <-- initialize(0)
I[11:23:11.118] --> reply:initialize(0) 1 ms
V[11:23:11.118] >>> {"id":0,"jsonrpc":"2.0","result":{"capabilities":{"astProvider":true,"callHierarchyProvider":true,"clangdInlayHintsProvider":true,"codeActionProvider":{"codeActionKinds":["quickfix","refactor","info"]},"compilationDatabase":{"automaticReload":true},"completionProvider":{"resolveProvider":false,"triggerCharacters":[".","<",">",":","\"","/","*"]},"declarationProvider":true,"definitionProvider":true,"documentFormattingProvider":true,"documentHighlightProvider":true,"documentLinkProvider":{"resolveProvider":false},"documentOnTypeFormattingProvider":{"firstTriggerCharacter":"\n","moreTriggerCharacter":[]},"documentRangeFormattingProvider":true,"documentSymbolProvider":true,"executeCommandProvider":{"commands":["clangd.applyFix","clangd.applyTweak"]},"foldingRangeProvider":true,"hoverProvider":true,"implementationProvider":true,"inactiveRegionsProvider":true,"inlayHintProvider":true,"memoryUsageProvider":true,"referencesProvider":true,"renameProvider":{"prepareProvider":true},"selectionRangeProvider":true,"semanticTokensProvider":{"full":{"delta":true},"legend":{"tokenModifiers":["declaration","definition","deprecated","deduced","readonly","static","abstract","virtual","dependentName","defaultLibrary","usedAsMutableReference","usedAsMutablePointer","constructorOrDestructor","userDefined","functionScope","classScope","fileScope","globalScope"],"tokenTypes":["variable","variable","parameter","function","method","function","property","variable","class","interface","enum","enumMember","type","type","unknown","namespace","typeParameter","concept","type","macro","modifier","operator","bracket","label","comment"]},"range":false},"signatureHelpProvider":{"triggerCharacters":["(",")","{","}","<",">",","]},"standardTypeHierarchyProvider":true,"textDocumentSync":{"change":2,"openClose":true,"save":true},"typeDefinitionProvider":true,"typeHierarchyProvider":true,"workspaceSymbolProvider":true},"serverInfo":{"name":"clangd","version":"clangd version 17.0.6 windows x86_64-pc-windows-msvc"}}}

V[11:23:11.118] <<< {"jsonrpc":"2.0","method":"initialized","params":{}}

I[11:23:11.118] <-- initialized
V[11:23:11.120] <<< {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"cpp","text":"#include <print>\r\nint main()\r\n{\r\n    std::println(\"{}\", 123);\r\n    return 0;\r\n}","uri":"file:///d%3A/Projects/cxx/main.cpp","version":14}}}

I[11:23:11.121] <-- textDocument/didOpen
V[11:23:11.121] config note at d:\Projects\cxx\.clangd:1:0: Parsing config fragment
V[11:23:11.121] config note at d:\Projects\cxx\.clangd:1:0: Parsed 1 fragments from file
V[11:23:11.121] Config fragment: compiling d:\Projects\cxx\.clangd:1 -> 0x000002A42B10CB30 (trusted=false)
I[11:23:11.121] --> textDocument/publishDiagnostics
V[11:23:11.121] >>> {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[],"uri":"file:///d:/Projects/cxx/.clangd"}}

I[11:23:11.122] Loaded compilation database from d:\Projects\cxx\compile_commands.json
V[11:23:11.122] Broadcasting compilation database from d:\Projects\cxx
I[11:23:11.122] ASTWorker building file d:\Projects\cxx\main.cpp version 14 with command
[D:/Projects/cxx/build/release]
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" --driver-mode=cl /nologo /DWIN32 /D_WINDOWS /EHsc /O2 /Ob2 /DNDEBUG -MD /FdTARGET_COMPILE_PDB -c /std=c++23 "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\17" -- "d:\\Projects\\cxx\\main.cpp"
V[11:23:11.122] config note at D:\Projects\cxx\.clangd:1:0: Parsing config fragment
V[11:23:11.122] config note at D:\Projects\cxx\.clangd:1:0: Parsed 1 fragments from file
V[11:23:11.122] Config fragment: compiling D:\Projects\cxx\.clangd:1 -> 0x000002A42B10CB80 (trusted=false)
I[11:23:11.122] --> textDocument/publishDiagnostics
V[11:23:11.122] <<< {"id":1,"jsonrpc":"2.0","method":"textDocument/documentSymbol","params":{"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

V[11:23:11.122] >>> {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[],"uri":"file:///D:/Projects/cxx/.clangd"}}

I[11:23:11.122] <-- textDocument/documentSymbol(1)
I[11:23:11.122] --> window/workDoneProgress/create(0)
V[11:23:11.122] >>> {"id":0,"jsonrpc":"2.0","method":"window/workDoneProgress/create","params":{"token":"backgroundIndexProgress"}}

I[11:23:11.122] Enqueueing 1 commands for indexing
V[11:23:11.123] Failed to load shard: D:\Projects\cxx\main.cpp
V[11:23:11.123] Ignored diagnostic. /std=c++23: 'linker' input unused
V[11:23:11.123] <<< {"id":2,"jsonrpc":"2.0","method":"textDocument/codeAction","params":{"context":{"diagnostics":[],"triggerKind":2},"range":{"end":{"character":1,"line":5},"start":{"character":1,"line":5}},"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

I[11:23:11.124] <-- textDocument/codeAction(2)
V[11:23:11.124] Driver produced command: cc1 -cc1 -triple x86_64-pc-windows-msvc19.38.33130 -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name main.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -tune-cpu generic -D_MT -D_DLL --dependent-lib=msvcrt --dependent-lib=oldnames -stack-protector 2 -fcxx-exceptions -fexceptions -fexternc-nounwind -fms-volatile -fdiagnostics-format msvc -ffunction-sections -fcoverage-compilation-dir=D:/Projects/cxx/build/release -resource-dir "C:\\Program Files\\LLVM\\lib\\clang\\17" -D WIN32 -D _WINDOWS -D NDEBUG -internal-isystem "C:\\Program Files\\LLVM\\lib\\clang\\17\\include" -internal-isystem "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\include" -internal-isystem "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\ATLMFC\\include" -internal-isystem "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Auxiliary\\VS\\include" -internal-isystem "D:\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\um" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\shared" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\winrt" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\cppwinrt" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\NETFXSDK\\4.8\\include\\um" -internal-isystem "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\include" -internal-isystem "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.38.33130\\ATLMFC\\include" -internal-isystem "C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Auxiliary\\VS\\include" -internal-isystem "D:\\Windows Kits\\10\\include\\10.0.19041.0\\ucrt" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\um" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\shared" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\winrt" -internal-isystem "D:\\Windows Kits\\10\\\\include\\10.0.19041.0\\\\cppwinrt" -internal-isystem "C:\\Program Files (x86)\\Windows Kits\\NETFXSDK\\4.8\\include\\um" -O2 -fdeprecated-macro -fdebug-compilation-dir=D:/Projects/cxx/build/release -ferror-limit 19 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.38.33130 -std=c++14 -fdelayed-template-parsing -finline-functions -vectorize-loops -vectorize-slp -no-round-trip-args -faddrsig -x c++ "d:\\Projects\\cxx\\main.cpp"
I[11:23:11.124] --> textDocument/clangd.fileStatus
V[11:23:11.124] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"parsing includes, running Update","uri":"file:///d:/Projects/cxx/main.cpp"}}

V[11:23:11.124] Building first preamble for d:\Projects\cxx\main.cpp version 14
V[11:23:11.124] Indexing D:\Projects\cxx\main.cpp (digest:=EA2CFF289303FEF4)
V[11:23:11.125] <<< {"id":0,"jsonrpc":"2.0","result":null}

I[11:23:11.125] <-- reply(0)
I[11:23:11.125] --> $/progress
V[11:23:11.125] >>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundIndexProgress","value":{"kind":"begin","percentage":0,"title":"indexing"}}}

I[11:23:11.125] --> $/progress
V[11:23:11.125] >>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundIndexProgress","value":{"kind":"report","message":"1/2","percentage":50}}}

V[11:23:11.126] Ignored diagnostic. /std=c++23: 'linker' input unused
V[11:23:11.129] <<< {"id":3,"jsonrpc":"2.0","method":"textDocument/documentLink","params":{"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

I[11:23:11.129] <-- textDocument/documentLink(3)
V[11:23:11.129] <<< {"id":4,"jsonrpc":"2.0","method":"textDocument/inlayHint","params":{"range":{"end":{"character":1,"line":5},"start":{"character":0,"line":0}},"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

I[11:23:11.129] <-- textDocument/inlayHint(4)
V[11:23:11.135] Ignored diagnostic. D:\Projects\cxx\main.cpp:4:5:use of undeclared identifier 'std'
I[11:23:11.136] Indexed D:\Projects\cxx\main.cpp (6 symbols, 1469 refs, 9 files)
I[11:23:11.136] Failed to compile D:\Projects\cxx\main.cpp, index may be incomplete
I[11:23:11.141] Built preamble of size 470040 for file d:\Projects\cxx\main.cpp version 14 in 0.02 seconds
I[11:23:11.142] --> workspace/semanticTokens/refresh(1)
V[11:23:11.142] >>> {"id":1,"jsonrpc":"2.0","method":"workspace/semanticTokens/refresh","params":null}

I[11:23:11.142] --> textDocument/clangd.fileStatus
V[11:23:11.142] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"parsing includes, running Build AST","uri":"file:///d:/Projects/cxx/main.cpp"}}

I[11:23:11.142] Indexing c++14 standard library in the context of d:\Projects\cxx\main.cpp
V[11:23:11.142] <<< {"id":1,"jsonrpc":"2.0","result":null}

I[11:23:11.142] <-- reply(1)
V[11:23:11.147] <<< {"id":5,"jsonrpc":"2.0","method":"textDocument/semanticTokens/full","params":{"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

I[11:23:11.147] <-- textDocument/semanticTokens/full(5)
V[11:23:11.147] indexed preamble AST for d:\Projects\cxx\main.cpp version 14:
  symbol slab: 1330 symbols, 341456 bytes
  ref slab: 0 symbols, 0 refs, 136 bytes
  relations slab: 0 relations, 24 bytes
V[11:23:11.152] indexed file AST for d:\Projects\cxx\main.cpp version 14:
  symbol slab: 1 symbols, 4456 bytes
  ref slab: 1 symbols, 1 refs, 4256 bytes
  relations slab: 0 relations, 24 bytes
V[11:23:11.152] Build dynamic index for main-file symbols with estimated memory usage of 11536 bytes
I[11:23:11.152] --> textDocument/publishDiagnostics
V[11:23:11.152] >>> {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[{"code":"undeclared_var_use","message":"Use of undeclared identifier 'std'","range":{"end":{"character":7,"line":3},"start":{"character":4,"line":3}},"relatedInformation":[],"severity":1,"source":"clang"}],"uri":"file:///d:/Projects/cxx/main.cpp","version":14}}

I[11:23:11.152] --> textDocument/inactiveRegions
V[11:23:11.152] >>> {"jsonrpc":"2.0","method":"textDocument/inactiveRegions","params":{"regions":[],"textDocument":{"uri":"file:///d:/Projects/cxx/main.cpp"}}}

V[11:23:11.152] ASTWorker running DocumentSymbols on version 14 of d:\Projects\cxx\main.cpp
I[11:23:11.152] --> reply:textDocument/documentSymbol(1) 30 ms
V[11:23:11.152] >>> {"id":1,"jsonrpc":"2.0","result":[{"detail":"int ()","kind":12,"name":"main","range":{"end":{"character":1,"line":5},"start":{"character":0,"line":1}},"selectionRange":{"end":{"character":8,"line":1},"start":{"character":4,"line":1}}}]}

V[11:23:11.152] ASTWorker running codeAction on version 14 of d:\Projects\cxx\main.cpp
I[11:23:11.152] --> reply:textDocument/codeAction(2) 28 ms
V[11:23:11.152] >>> {"id":2,"jsonrpc":"2.0","result":[]}

V[11:23:11.152] ASTWorker running DocumentLinks on version 14 of d:\Projects\cxx\main.cpp
I[11:23:11.152] --> reply:textDocument/documentLink(3) 23 ms
V[11:23:11.152] >>> {"id":3,"jsonrpc":"2.0","result":[{"range":{"end":{"character":16,"line":0},"start":{"character":9,"line":0}},"target":"file:///C:/Program%20Files/Microsoft%20Visual%20Studio/2022/Community/VC/Tools/MSVC/14.38.33130/include/print"}]}

V[11:23:11.152] ASTWorker running InlayHints on version 14 of d:\Projects\cxx\main.cpp
I[11:23:11.152] --> reply:textDocument/inlayHint(4) 23 ms
V[11:23:11.152] >>> {"id":4,"jsonrpc":"2.0","result":[]}

V[11:23:11.152] ASTWorker running SemanticHighlights on version 14 of d:\Projects\cxx\main.cpp
I[11:23:11.153] --> reply:textDocument/semanticTokens/full(5) 5 ms
V[11:23:11.153] >>> {"id":5,"jsonrpc":"2.0","result":{"data":[1,4,4,3,131075],"resultId":"1"}}

I[11:23:11.153] --> textDocument/clangd.fileStatus
V[11:23:11.153] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///d:/Projects/cxx/main.cpp"}}

V[11:23:11.156] Build dynamic index for header symbols with estimated memory usage of 1120920 bytes
V[11:23:11.165] BackgroundIndex: building version 1 when background indexer is idle
V[11:23:11.165] BackgroundIndex: serving version 1 (233736 bytes)
I[11:23:11.165] --> $/progress
V[11:23:11.165] >>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundIndexProgress","value":{"kind":"end"}}}

V[11:23:11.429] <<< {"id":6,"jsonrpc":"2.0","method":"textDocument/codeAction","params":{"context":{"diagnostics":[],"triggerKind":2},"range":{"end":{"character":1,"line":5},"start":{"character":1,"line":5}},"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

I[11:23:11.429] <-- textDocument/codeAction(6)
V[11:23:11.429] ASTWorker running codeAction on version 14 of d:\Projects\cxx\main.cpp
I[11:23:11.429] --> reply:textDocument/codeAction(6) 0 ms
V[11:23:11.429] >>> {"id":6,"jsonrpc":"2.0","result":[]}

I[11:23:11.429] --> textDocument/clangd.fileStatus
V[11:23:11.429] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///d:/Projects/cxx/main.cpp"}}

V[11:23:11.429] <<< {"id":7,"jsonrpc":"2.0","method":"textDocument/documentSymbol","params":{"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

I[11:23:11.429] <-- textDocument/documentSymbol(7)
V[11:23:11.429] ASTWorker running DocumentSymbols on version 14 of d:\Projects\cxx\main.cpp
I[11:23:11.430] --> reply:textDocument/documentSymbol(7) 0 ms
V[11:23:11.430] >>> {"id":7,"jsonrpc":"2.0","result":[{"detail":"int ()","kind":12,"name":"main","range":{"end":{"character":1,"line":5},"start":{"character":0,"line":1}},"selectionRange":{"end":{"character":8,"line":1},"start":{"character":4,"line":1}}}]}

I[11:23:11.430] --> textDocument/clangd.fileStatus
V[11:23:11.430] >>> {"jsonrpc":"2.0","method":"textDocument/clangd.fileStatus","params":{"state":"idle","uri":"file:///d:/Projects/cxx/main.cpp"}}

V[11:23:11.430] <<< {"id":8,"jsonrpc":"2.0","method":"textDocument/foldingRange","params":{"textDocument":{"uri":"file:///d%3A/Projects/cxx/main.cpp"}}}

I[11:23:11.430] <-- textDocument/foldingRange(8)
I[11:23:11.430] --> reply:textDocument/foldingRange(8) 0 ms
V[11:23:11.430] >>> {"id":8,"jsonrpc":"2.0","result":[{"endLine":4,"kind":"region","startCharacter":1,"startLine":2}]}

V[11:23:11.549] Ignored diagnostic. C:\Program Files\LLVM\lib\clang\17\include\stdatomic.h:81:6:conflicting types for 'atomic_thread_fence'
V[11:23:11.549] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\atomic:334:36:previous definition is here
V[11:23:11.549] Ignored diagnostic. C:\Program Files\LLVM\lib\clang\17\include\stdatomic.h:82:6:conflicting types for 'atomic_signal_fence'
V[11:23:11.549] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\atomic:338:36:previous definition is here
V[11:23:11.617] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\pplinterface.h:248:4:expected parameter declarator
V[11:23:11.617] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\pplinterface.h:248:4:expected ')'
V[11:23:11.617] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\pplinterface.h:248:4:to match this '('
V[11:23:11.624] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\pplcancellation_token.h:481:48:no matching function for call to '__c11_atomic_exchange'
V[11:23:11.624] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\pplinterface.h:248:4:candidate function template not viable: requires 2 arguments, but 3 were provided
V[11:23:11.636] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\ppltasks.h:793:17:no matching function for call to '__c11_atomic_exchange'
V[11:23:11.636] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\pplinterface.h:248:4:candidate function template not viable: requires 2 arguments, but 3 were provided
V[11:23:11.764] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\experimental/filesystem:27:2:The <experimental/filesystem> header providing std::experimental::filesystem is deprecated by Microsoft and will be REMOVED. It is superseded by the C++17 <filesystem> header providing std::filesystem. You can define _SILENCE_EXPERIMENTAL_FILESYSTEM_DEPRECATION_WARNING to suppress this error.
V[11:23:11.864] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\ppltasks.h:2548:13:no matching function for call to '__c11_atomic_exchange'
V[11:23:11.864] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\ppltasks.h:2758:22:in instantiation of member function 'Concurrency::task_completion_event<unsigned char>::_ClearStoredException' requested here
V[11:23:11.864] Ignored diagnostic. C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.38.33130\include\pplinterface.h:248:4:candidate function template not viable: requires 2 arguments, but 3 were provided
I[11:23:11.945] Indexed c++14 standard library (incomplete due to errors): 12104 symbols, 1167 filtered
V[11:23:11.985] Build dynamic index for header symbols with estimated memory usage of 6755724 bytes

This line in the log:

V[11:23:11.123] Ignored diagnostic. /std=c++23: 'linker' input unused

Suggests /std=c++23 is not recognized. I believe it needs to be /std:c++23.
(My mistake, I did originally writen /std=c++23 in my previous comment before editing it.)

Oh, whoops, we have to smuggle the : past the YAML syntax of the config file.
Single quotes seems to do it:
CompileFlags:
  Add: ['/std:c++23']

Nah, unsuccessful.

V[11:44:26.713] Ignored diagnostic. argument unused during compilation: '/std:c++23'

Hmm, then I'm afraid I'm out of ideas for now.
Anyways, there are two steps to solving this:

Figure out what command-line flags need to be passed to clang-cl to get it to compile C++23 code
Make sure clangd is passing those flags

Step 1 is not really specific to clangd, maybe you can ask about it in a more general clang forum like this one.

clang-cl can compile it with flag -std:c++latest 😄 Another flags are not supported as I mentioned earlier.

Looks like there is no flag с++23 and с++26 for msvc so the clang-cl hasn't them too, and c++latest is just an alias for the c++26.

But is there any reason why it works with cl -std:c++latest and doesn't work with clang-cl -std:c++latest?

Btw, it also works fine with the cl compiler and -std:c++latest flag.

clang-cl can compile it with flag -std:c++latest 😄 Another flags are not supported as I mentioned earlier.

My apologies, I misunderstood.
So it is a clangd problem then, that it drops the -std:c++latest from the compile command.
But you should be able to work around it with .clangd:
CompileFlags:
  Add: ['-std:c++latest']

In my local testing, this one is not dropped.

This workaround works fine, thank you very much! Should I close this issue or it is a bug after all?

Let's keep it open. It might be a duplicate of #527, but I'm not sure since the description of #527 talks about transferring compile commands specifically (the operation that happens when a file is opened which is not in compile_commands.json, and a command from another file is transferred over to it), while I'm observing -std:c++latest being dropped even in cases where a file in compile_commands.json is opened directly.

I seem to be getting something similar even after apply -std=c++latest. I'm running on a mac with Clangd 17.0.6
Homebrew clangd version 17.0.6
Features: mac+xpc
Platform: arm64-apple-darwin22.5.0

I created the following main file
#include <iostream>
#include <bit>

int main(int argc, char** argv) {
  uint32_t sample = 0x42;

  auto result = std::byteswap(sample);
  std::cout << "Result = " << result << std::endl;
}

with the following .clangd
CompileFlags:
  Add: ['-std=c++latest']

with the Following CMakeLists.txt
cmake_minimum_required(VERSION 3.25)
project(clangdIssue CXX)

add_executable(clangdIssue main.cpp)
target_compile_features(clangdIssue PRIVATE cxx_std_23)

and the following preset
{
  "version": 4,
  "configurePresets": [
    {
      "name": "default",
      "displayName": "default",
      "generator": "Unix Makefiles",
      "binaryDir": "${sourceDir}/build",
      "cacheVariables": {
        "CMAKE_BUILD_TYPE": {
          "type": "String",
          "value": "Debug"
        },
        "CMAKE_EXPORT_COMPILE_COMMANDS": "ON"
      }
    }
  ],
  "buildPresets": [
    {
      "name": "default",
      "displayName": "default",
      "configurePreset": "default"
    }
  ]
}

and I'm getting following result

Even if I do what the warning points to and replace with gnu++2c or gnu++26 it doesn't seem to pick up the c++23 byteswap function. Should I be adding more to my clangd config ?

@KartikAiyer c++latest is a Windows thing (it's an MSVC compiler flag which clang's MSVC-compatibility driver, clang-cl, also supports). It's not applicable to other platforms like Mac.
The most likely issue in your case is that you're using the headers of an older standard library version which doesn't implement byteswap yet.
Which standard library (libstdc++ or libc++) are you using, and what version? If unsure, do go-to-definition on <bit> and share the full path of the opened header.

Thank you very much for the response. If I go to the definition of the <bit> it is comming from
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/bit and I can't find a definition of byteswap in it which makes sense. However, I'm able to compile the code and it is byteswapping so I'm guessing this is because the LSP is pointing to a different library than what is being compiled.
I don't specify anything in the CMakeLists.txt file to select the standard library so I'm assuming its using the system default which I thought was libc++.
This is the explicit compile step
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++   -g -std=gnu++2b -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Dev
eloper/SDKs/MacOSX13.3.sdk -MD -MT CMakeFiles/clangdIssue.dir/main.cpp.o -MF CMakeFiles/clangdIssue.dir/main.cpp.o.d -o CMakeFiles/clangdIssue.dir/main.cpp.o -c /Users/kartikaiyer/tmp/clangdIssue/main.cpp

If I go to the definition of the <bit> it is comming from /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1/bit

Ok, so this is libc++. (The version cannot be determined from the path in this case.)

This is the explicit compile step
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++   -g -std=gnu++2b -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Dev
eloper/SDKs/MacOSX13.3.sdk -MD -MT CMakeFiles/clangdIssue.dir/main.cpp.o -MF CMakeFiles/clangdIssue.dir/main.cpp.o.d -o CMakeFiles/clangdIssue.dir/main.cpp.o -c /Users/kartikaiyer/tmp/clangdIssue/main.cpp

Can you run the following command and paste the output?
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk -E -v -x c++ /dev/null

So the discrepancy is between this libc++ installation used during actual compilation, which seems to be newer and supports byteswap:

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1

and this one used by clangd, which seems to be older and does not support byteswap:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1

In situations like this, you can use the query-driver flag to get clangd to query the compiler for its standard library include paths.
So in this case, you could add --query-driver=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ to clangd's command line arguments and that should pick up the same library headers as the compiler.

Yes, so the compiler invocation printed 5 include directories after  "#include <...> search starts here:":

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/14.0.3/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/System/Library/Frameworks

Of these, only the first one is the libc++ directory (which always ends in c++/v1). The others are directories containing C headers, Mac system headers, and stuff like that.
So, that told me that the correct libc++ directory we want is /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.3.sdk/usr/include/c++/v1.
The one that clangd was actually using, /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include/c++/v1, I got from the path of the <bit> header that you said clangd actually opened.
As for how clangd chose that directory originally, I believe that in the absence of --query-driver it finds the directory using heuristics based on the compiler's path.

I'm also having this (the original) issue with clangd not respecting clang-cl /std:c++latest (required to compile C++23) in the compile_commands.json unless I add the workaround to .clangd:
CompileFlags:
  Add: ['-std:c++latest']

I think the workaround isn't really acceptable, though, because adding this to .clangd then makes clangd not work on other platforms, so I need to generate different .clangd files depending on platform, which is the problem compile_commands.json is supposed to solve for me in the first place.

clangd's LSP can't handle right C++ 23 features...😞

clangd's LSP can't handle right C++ 23 features...😞

Please file a new issue with details (code examples + clangd logs), as it's not clear whether you're running into the same problem as the reporter of this issue (which is a Windows-specific configuration problem) or an actual piece of missing language support.

clangd's LSP can't handle right C++ 23 features...😞

Please file a new issue with details (code example + clangd logs), as it's not clear whether you're running into the same problem as the reporter of this issue (which is a Windows-specific configuration problem) or an actual piece of missing language support.

Yes, I'm on Windows 10, unfortunately, and it clang doesn't support , ,  and other c++20 & 23 features on VS Code nor on Neovim ☹. The only solution I found is only for VS Code to set Clang: Cxxflags to -std=c++23 and Clangd: Fallback Flags to -std=c++23...

I fiddled with the same issue with clang-cl cmake project on Windows 10 as well. And here's what sort-of worked for me:
CompileFlags:
    Add: ['-std:c++20', '-std:c++latest']

The issue I faced was that with inferred commands ASTWorker building file <xxx.h> version 17 with command inferred from <xxx.cpp>, the std:c++latest flag was completely gone.
What I guess happened was that during parsing of TransferableCommand, with tryParseStdArg,
https://github.com/llvm/llvm-project/blob/be10070f91b86a6f126d2451852242bfcb2cd366/clang/lib/Tooling/InterpolatingCompilationDatabase.cpp#L193-L197
it tries to parse with LangStandard::getLangKind, which is derived from clang/Basic/LangStandards.def
https://github.com/llvm/llvm-project/blob/db2fb3d96b217f0d2e139e7816c98d9f95974f25/clang/lib/Basic/LangStandards.cpp#L66-L72
And in LangStandards.def does not have latest defined. So try parse return lang_unspecified instaed
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Basic/LangStandards.def
and during transferTo. There's no latest to write and caused the issue.
https://github.com/llvm/llvm-project/blob/be10070f91b86a6f126d2451852242bfcb2cd366/clang/lib/Tooling/InterpolatingCompilationDatabase.cpp#L239-L243
I guess what my .clangd did was adding a c++20 definition before latest, so during command transfer, it would take that c++20 and generate back -std:c++20 instead of -std:c++latest. Now my header files would works 90% of the time, except some c++23 sections.
Would it make sense to add c++latest support to TransferableCommand in clang-cl mode?

@HighCommander4, here's something that may help investigate this problem.
I've noticed that this happens all the time on my PC laptop, while on my Parallels Windows VM on Mac clangd has no problems recognizing the c++latest.
I'm using a different compiler (MSVC), and my compile_commands.json seems to be different from the OP's, so let me know if I should open a separate issue or leave it here.
Anyway, here's the simple CMakeLists.txt file:
cmake_minimum_required(VERSION 3.5)

project(OptionalSample)

set(CMAKE_CXX_STANDARD 23)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_executable(main main.cpp)

The build command line:
cmake -DCMAKE_BUILD_TYPE=Debug -G "Ninja" -DCMAKE_EXPORT_COMPILE_COMMANDS=1 -S. -Bbuild

And the resulting compile_commands.json:
[
{
  "directory": "C:/Users/luke/Developer/optional/build",
  "command": "C:\\PROGRA~1\\MICROS~1\\2022\\COMMUN~1\\VC\\Tools\\MSVC\\1439~1.335\\bin\\Hostx64\\x64\\cl.exe  /nologo /TP /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 -std:c++latest /FoCMakeFiles\\main.dir\\main.cpp.obj /FdTARGET_COMPILE_PDB /FS -c C:\\Users\\luke\\Developer\\optional\\main.cpp",
  "file": "C:\\Users\\luke\\Developer\\optional\\main.cpp",
  "output": "CMakeFiles\\main.dir\\main.cpp.obj"
}
]

This works perfectly well, the LSP server does not complain about any modern C++ features (the OP code shows no errors too).
However, after updating MSVC on the VM (which also updated CMake I think; I don't remember the previous version unfortunately) and rebuilding the project, the errors started to appear. The same code, the same CMakeLists.txt, the same build command... but the generated compile_commands.json looks different:
[
{
  "directory": "C:/Users/luke/Developer/optional/build",
  "command": "C:\\PROGRA~1\\MICROS~1\\2022\\COMMUN~1\\VC\\Tools\\MSVC\\1439~1.335\\bin\\Hostx64\\x64\\cl.exe  /nologo /TP /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 -std:c++latest @CMakeFiles\\main.dir\\main.cpp.obj.modmap /FoCMakeFiles\\main.dir\\main.cpp.obj /FdTARGET_COMPILE_PDB /FS -c C:\\Users\\luke\\Developer\\optional\\main.cpp",
  "file": "C:\\Users\\luke\\Developer\\optional\\main.cpp",
  "output": "CMakeFiles\\main.dir\\main.cpp.obj"
}
]

The added @CMakeFiles\\main.dir\\main.cpp.obj.modmap part seems to be the problem -- removing it fixes the errors.
I don't know what it is (something related to C++23 modules, I guess?), but it does seem to confuse clangd, so I think it's worth investigating.
The -std:c++latest does not seem to be a problem, at least in my case.

The added @CMakeFiles\\main.dir\\main.cpp.obj.modmap part seems to be the problem -- removing it fixes the errors.
I don't know what it is (something related to C++23 modules, I guess?), but it does seem to confuse clangd, so I think it's worth investigating.

That sounds like a different issue. Note that modules support in clangd is known to be incomplete (see https://github.com/clangd/clangd/issues/1293), so I think it's expected that some things don't work.

The added @CMakeFiles\\main.dir\\main.cpp.obj.modmap part seems to be the problem -- removing it fixes the errors.
I don't know what it is (something related to C++23 modules, I guess?), but it does seem to confuse clangd, so I think it's worth investigating.

That sounds like a different issue. Note that modules support in clangd is known to be incomplete (see #1293), so I think it's expected that some things don't work.

The problem is not so much that the modules don't work as that the introduction of @CMakeFiles\\main.dir\\main.cpp.obj.modmap argument completely breaks clangd's ability to detect modern C++ features, including simple stuff like std::optional.
I'll report a separate issue.

Hey clangd developer, I'm seeing this problem when using vscode on mac but ssh into a linux machine. Tried different workaround mentioned above, but I still have those annoying warnings in my header files :(

Nested namespace definition is a C++17 extension; define each namespace separately (fix available)clang(-Wc++17-extensions)

Is there any suggestion for my case?

Is there any suggestion for my case?

Please share clangd logs, preferably in a new issue.

Sure. IIUC, I need to add --log=verbose to Clangd: Arguments in my vscode setting, and then get the log from vscode's OUTPUT.
This is what I can get
I[00:24:33.074] <-- textDocument/codeAction(103)
V[00:24:33.074] ASTWorker running codeAction on version 1 of /home/yxia/repo/util.h
I[00:24:33.075] --> reply:textDocument/codeAction(103) 0 ms
V[00:24:33.075] >>> {
  "id": 103,
  "jsonrpc": "2.0",
  "result": [
    {
      "diagnostics": [
        {
          "code": "-Wc++17-extensions",
          "message": "Nested namespace definition is a C++17 extension; define each namespace separately (fix available)",
          "range": {
            "end": {
              "character": 23,
              "line": 8
            },
            "start": {
              "character": 14,
              "line": 8
            }
          },
          "severity": 1,
          "source": "clang"
        }
      ],
      "edit": {
        "documentChanges": [
          {
            "edits": [
              {
                "newText": " { namespace my_ns",
                "range": {
                  "end": {
                    "character": 23,
                    "line": 8
                  },
                  "start": {
                    "character": 14,
                    "line": 8
                  }
                }
              },
              {
                "newText": "} ",
                "range": {
                  "end": {
                    "character": 0,
                    "line": 276
                  },
                  "start": {
                    "character": 0,
                    "line": 276
                  }
                }
              }
            ],
            "textDocument": {
              "uri": "file:///home/yxia/repo/util.h",
              "version": 1
            }
          }
        ]
      },
      "isPreferred": true,
      "kind": "quickfix",
      "title": "nested namespace definition is a C++17 extension; define each namespace separately"
    }
  ]
}

Please show the entire log from clangd startup.
And please post it in a new issue. The reporter of this issue is on Windows and is experiencing a Windows-specific issue; given that you are not on Windows, your issue is unlikely to be related.

(I edited the title of this issue to clarify that it's about a Windows issue, and more specifically one affecting clang-cl.)


Accept CDK constructs in on_* methods.

It would be great if we could pass a CDK construct in the on_* methods, instead of passing all the ARN parts. The boilerplate feels unnecessary.

It's a nice idea but I don't see a viable solution.
How would floyd know if a construct has an ARN and what is the properties name without manually implementing every available CDK construct?
Manually implementing every single construct seems to be a huge amount of work and the benefit is rather small, because passing an ARN is pretty straight forward, e.g. for a Lambda function: .on(fn.functionArn).

It would require to implement ARN getters for all constructs that you provide on_* methods, yes, but this seems easier than the work that's already been done with all of those methods already.


upgraded sbtpgp plugin

Can we not just remove this plugin?

that makes everyone import it to their own project, not sure how useful that would be...
we can release this plugin in a new version and let people gradually upgrade.

Why do they need to import this plugin?

On 24 Feb 2015, at 17:36, Nuno Marques<EMAIL_ADDRESS>wrote:
that makes everyone import it to their own project, not sure how useful that would be...
we can release this plugin in a new version and let people gradually upgrade.
—
Reply to this email directly or view it on GitHub.

oh, you meant the sbt-utils one rather than the gpg one...
I thought it would help with the publishing (in general not just sonatype), but I've not dig too much into this, I can try and check if I can get the simple-reactivemongo working without it...

there seems to be a bunch of default build settings that are imported via this plugin, not sure if removing this plugin (given that lots of projects use it) doesn't not create more work than fixing this problem

Is the reference to the sbt-pgp plugin needed in this repo? If not then let's delete it from /plugins/plugins.sbt rather than upgrade it

if we move the plugin to a global configuration then we don't need it neither here nor anywhere, but then we make our lives harder if we need to upgrade because that leads to a big-bang upgrade.
we can't delete it from here because this plugin needs it for its own publishing, as this is an open sourced project.

I don't agree but happy to be told otherwise. Lets talk


Fixes for validation lookupCode method

Fixes https://github.com/hapifhir/hapi-fhir/issues/5512
Address here:
(1) NullPointerException when processing CodeSystem designation in RemoteTerminologyServiceValidationSupport
(2) Inconsistency between input and output type  vs.  for property parameter across the board for IValidationSupport
(3) Fix most of the warnings in the updated classes.
(4) Code review changes
The same changes were added and reviewed here: https://github.com/hapifhir/hapi-fhir/pull/5519
I needed to create another pull request due to an issue with a bad merge from master.

Approved pending answer to question above.
Also, have you ran related tests locally in CDR?

Yes. There are just 3 tests which reference lookupCode method in CDR and all pass.


Error while trying to load model's weights for fine-tuning (transfer learning)

System information
Have I written custom code (as opposed to using a stock example script provided in TensorFlow): NO
OS Platform and Distribution (e.g., Linux Ubuntu 16.04): Windows 10
TensorFlow installed from (source or binary): binary (no errors during installation)
TensorFlow version: 2.3.1 (with GPU support)
Python version: 3.7.5
CUDA/cuDNN version: 10.1
GPU model and memory: RTX 1660 Ti 6.00GB
Describe the current behavior
I reproduce my issue on oversimplified code.
I'm trying to train model for one dataset (say, on MNIST) and then fine-tune it on another (with different number of classes, say 5).
After I have created model for '5 classes task' I'm trying to load the weights from original model using
model.load_weights(path, by_name=True, skip_mismatch=True)
But I got an error:
ValueError: Shapes (5,) and (10,) are incompatible
I hoped that setting the params by_name=True, skip_mismatch=True will be enough to handle differences between the models.
How to correct load weights for slightly different model?
Standalone code to reproduce the issue
Oversimplified script to recreate the trouble
import tensorflow as tf
import numpy as np
import os

mnist = tf.keras.datasets.mnist
(x_train, y_train), (x_test, y_test) = mnist.load_data()
x_train, x_test = x_train / 255.0, x_test / 255.0
y_train = tf.keras.utils.to_categorical(y_train, 10)
y_test = tf.keras.utils.to_categorical(y_test, 10)
x_train = np.expand_dims(x_train, -1)
x_test = np.expand_dims(x_test, -1)

model = tf.keras.models.Sequential([
    tf.keras.layers.Input(shape=(28, 28, 1)),
    tf.keras.layers.Conv2D(32, 3, activation='relu', padding='same'),
    tf.keras.layers.AveragePooling2D(),
    tf.keras.layers.Conv2D(64, 3, activation='relu', padding='same'),
    tf.keras.layers.AveragePooling2D(),
    tf.keras.layers.Conv2D(128, 3, activation='relu', padding='same'),
    tf.keras.layers.AveragePooling2D(),
    tf.keras.layers.Flatten(),
    tf.keras.layers.Dense(10, activation='softmax')])

model.compile(loss=tf.keras.losses.CategoricalCrossentropy(), optimizer=tf.keras.optimizers.Adam())

batch_size = 128
epochs = 3
model.fit(x_train, y_train, batch_size, epochs, validation_data=(x_test, y_test))

ver = 0
path = os.path.join(os.getcwd(), str(ver))
model.save_weights(path)

different_model = tf.keras.models.Sequential([
    tf.keras.layers.Input(shape=(28, 28, 1)),
    tf.keras.layers.Conv2D(32, 3, activation='relu', padding='same'),
    tf.keras.layers.AveragePooling2D(),
    tf.keras.layers.Conv2D(64, 3, activation='relu', padding='same'),
    tf.keras.layers.AveragePooling2D(),
    tf.keras.layers.Conv2D(128, 3, activation='relu', padding='same'),
    tf.keras.layers.AveragePooling2D(),
    tf.keras.layers.Flatten(),
    tf.keras.layers.Dense(5, activation='softmax')]) # say, we change the number of classes here for further fine-tuning

# here I got an error!!!!!!! isn't by_name=True, skip_mismatch=True not enough?
different_model.load_weights(path, by_name=True, skip_mismatch=True)

# fine-tuning/transfer learning is supposed here for some application where we classify 5 cls

print('loaded!')

It's a serious and urgent problem for my project!
Any help is appreciated!!!

I think this is a project specific support request not a bug. Please close this and post on our Stackoverflow channel

@bhack I wouldn't say it's project specific. The issue described entirely in term of MNIST and simple 'standard' CNN (in fact, you can use just 'one-conv-layer-followed-by-dense-classifier' network to reproduce it)
Found work-around loading weights before adding layers which may cause shape mismatch. More about loading checkpoints in TF's docs here https://www.tensorflow.org/guide/checkpoint#loading_mechanics

(in fact, you can use just 'one-conv-layer-followed-by-dense-classifier' network to reproduce it)

Yes it is what I meant, but in you case was a code snippet, and I also I meant that it is not bug as you have used a bug template for this issue.
It could be a bug if you are confused by the error message and you want to improve it.
But seems to me a support request on your code example and it is why I suggest you to use our Stackoverflow channel.

Also if you use h5ext filename format in your save and load path it will run fine as is


[Bug]: Puppeteer isn't clicking a button despite it being on the page.

Bug expectation
I expected the 'Join Now' button to be clicked on the Google Meet page after the 'Dismiss' button has been clicked.
Any help would be greatly appreciated.
Here is the dom node I am trying to click:
<button
  class="VfPpkd-LgbsSe VfPpkd-LgbsSe-OWXEXe-k8QpJ VfPpkd-LgbsSe-OWXEXe-dgl2Hf nCP5yc AjY5Oe DuMIQc LQeN7 jEvJdc QJgqC"
  jscontroller="soHxf"
  jsaction="click:cOuCgd; mousedown:UX7yZ; mouseup:lbsD7e; mouseenter:tfO1Yc; mouseleave:JywGue; touchstart:p6p2H; touchmove:FwuNnf; touchend:yfqBxc; touchcancel:JMtRjd; focus:AHmuwe; blur:O22p3e; contextmenu:mg9Pef;mlnRJb:fLiPzd;"
  data-idom-class="nCP5yc AjY5Oe DuMIQc LQeN7 jEvJdc QJgqC"
  jsname="Qx7uuf"
>

  Join now
</button>

The puppeteer code is in the example section.
I have also tried grabbing the node by text, using text/Join Now however I receive the following error:
Error: Query set to use "text", but no query handler of that name was found
    at Object.getQueryHandlerAndSelector

Bug behavior

[x] Flaky
[ ] PDF

Minimal, reproducible example
const joinMeeting = async (page) => {
    console.log(logYellow, '📺 Joining meeting...');
    await page.goto('https://meet.google.com/');
    await page.waitForSelector('.mobgod', { visible: true });
    await page.click('.mobgod');
    await page.waitForSelector('.VfPpkd-vQzf8d');
    await page.click('.VfPpkd-vQzf8d'); // Click dismiss buttong
    await page.waitForSelector('.VfPpkd-LgbsSe');
    await page.click('.VfPpkd-LgbsSe'); // Click join button
    console.log(logGreen, '✅ Joined meeting!');
}

Error string
No error. Just hangs at the section where I need it to click the button.
Puppeteer configuration
No response
Puppeteer version
10.4.0
Node version
18.16.0
Package manager
pnpm
Package manager version
8.6.1
Operating system
macOS

All I needed to do was select all the buttons on the page, and then select the button using it's index.


Upgrade to RN 0.67

Description
Add/verify support for the React Native 0.67 release:

[x] Check (and migrate) Detox test app on developer env
[ ] Upgrade demo apps (demo-react-native, then check demo-react-native-jest and detox-react-native-detox-instruments)
[ ] Upgrade associated CI job config to always use 0.67
[x] Update support table in main README.md

Is the current version compatible with 0.67?

@gabrielmoncea almost there 😄 Be sure to track this issue


ProjectSettings.load_resource_pack() Can Not Override Files

Godot version
3.4.stable.official [206ba70f4]
System information
Windows 10
Issue description
I am importing different vehicles to my game via .pck files during runtime (by user input).
When a user imports a vehicle for the first time, it works great. I can load the pck and make an instance of one of the scenes in the pck.
When the user imports a second pck, the same vehicle shows up on the screen.
I am using seperate pck files for each vehicle and all the pck files have a scene named vehicle.tscn which is the instanced scene for the vehicle. I am using this to change the player vehicle, not to add multiple vehicles to the game.
Steps to reproduce
Here is the code responsible for instancing a new vehicle and deleting the old one.
var vehicle_node

func initiate_new_vehicle(file_name):
	if vehicle_node:
		vehicle_node.queue_free()
	vehicle_node = null

	var imported_vehicle_scene : PackedScene
	print(ProjectSettings.load_resource_pack("./vehicles/" + file_name + ".pck", true))
	imported_vehicle_scene = ResourceLoader.load("res://vehicles/vehicle.tscn","",true)

	vehicle_node = imported_vehicle_scene.instance()
	add_child(vehicle_node)

It adds the selected vehicle without a problem for the first time, but if I run this function with a different "file_name" parameter, the same vehicle shows up, not the one the "file_name" points to.
(I've checked if the file_name is correct or not and it looks ok)
Minimal reproduction project
No response

You're loading "res://vehicles/vehicle.tscn" every time, are you sure this name doesn't change between resource loads? Or maybe you need to wait or force refresh something?

I am using one seperate project to create both of the .pck files.
To test this, I created a pck file with that project, and then I changed the color of something and created another pck file. So both of the pck files have exactly same files/folders in the same order (except one color info).
Is there any way to force refresh? In the "ResourceLoader.load()" function, the last parameter supposed to force NOT using the cache and in the "ProjectSettings.load_resource_pack()" function, the last parameter supposed to force override if the file names are same.

@starcin Please upload a minimal reproduction project to make this easier to troubleshoot.

I've tried with an extremely small project but it worked but not with a complicated scene. I will dig into this and post here. Sorry for the inconvenience.

Apparantly the small project also had the same problem but it was harder to see. So I've prepared a minimal project.
Th minimal_pck_project is responsible for creating different pck files. The minimal_game is the game which loads those pck files.
It looks like, when I load the pck files, everything directly in the tree works ok, including: the scene tree, existence of nodes, visibility of nodes, color parameter of ColorRect.
But it looks like anything that is an external resource doesn't get updated, including scripts.

In the minimal project, the red button loads a pck file with a red ColorRect in it. The green button loads one with a green ColorRect.

The script in the red.pck file, prints the hardcoded strings "red", "root red", and the color value of the rectangle (by directly reading from the ColorRect's color property).

The script in the green.pck file, prints the hardcoded strings "green", "root green", and the color value of the rectangle (by directly reading from the ColorRect's color property).

When you press the buttons, the first one works perfectly. When you press the other button after the first, the color changes (the tree is loaded OK), but the printouts are weird. It prints the previous strings but the new color value (hardcoded values are wrong but reading properties is OK)
I think since the "queue_free" works only after the frame and resources like scripts are locked until then, overwrite can't function properly. I've tested this by seperating "queue_free" and "load_resource_pack" functions by 5 frames (by checking simple counters).
I am not sure if this is a bug or not. It is just not very visible since the scene tree is overwrritten but not the scripts.
Minimal Load Pck Project.zip
.

Apparantly the small project also had the same problem but it was harder to see. So I'am uploding the small project.
Th minimal_pck_project is responsible for creating different pck files. The minimal_game is the game which loads those pck files.
It looks like, when I load the pck files, everything directly in the tree works ok, including: the scene tree, existence of nodes, visibility of nodes, color parameter of ColorRect. But it looks like anything that is an external resource doesn't get updated, including scripts.

In the minimal project, the red button loads a pck file with a red ColorRect in it. The green button loads one with a green ColorRect.
The script in the red.pck file, prints the hardcoded strings "red", "root red", and the color value of the rectangle (by directly reading from the ColorRect's color property).
The script in the green.pck file, prints the hardcoded strings "green", "root green", and the color value of the rectangle (by directly reading from the ColorRect's color property).

When you press the buttons, the first one works perfectly. When you press the other button after the first, the color changes (the tree is loaded OK), but the printouts are weird. It prints the previous strings but the new color value (hardcoded values are wrong but reading properties is OK)
I think since the "queue_free" works only after the frame and resources like scripts are locked until then, overwrite can't function properly. I've tested this by seperating "queue_free" and "load_resource_pack" functions by 5 frames (by checking simple counters).
I am not sure if this is a bug or not. It is just not very visible since the scene tree is overwrritten but not the scripts.
Minimal Load Pck Project.zip .

you just need to instance the scene or  at next frame. It cant be  load_resource_pack(PCK) and load(resource) at the same frame.

@Atem1995
Is there a way to wait for 1 frame (without hacky solutions)?

@starcin
var success = ProjectSettings.load_resource_pack("res://mods/subScene.pck", true)
if success:
get_node("subScene").queue_free()
	print("try to get new!")

	###yield(get_tree().create_timer(0.001), "timeout")### I try this way and it works.
	var imported_scene:PackedScene = load("res://subScene.tscn")
	self.add_child(imported_scene.instance())
	$Label.text = "Now we got a subScene from subScene PCK."
else:
	$Label.text = "There is no SubScene PCK found!"
pass

Looks like using yield() with a timer works.
My lines were like this:
1- queue_free the object
2- set the node to "null" to be sure
3- yield a timer
4- load_resource_pack
5- load scene
Thank you @Atem1995

I am not sure if I should close this issue since the load_resource_pack() really can not override files even the flag is set. This may not be a bug but maybe it should be documented better.


Remove gulp dependecy

WARNING: This is not meant to be merged, but rather to open discussion about necessity of gulp dependency in este and webpack projects in general. In este project is gulp used in a way that it's duplicating npm scripts functionality. Beside duplicity it's hard to find out what is actually happening behind each task. So I have tried to remove gulp dependency to solve these issues.
I had to do these changes to make it work without gulp

drop es6 imports in some of the scripts as babel-node is terribly slow
remove from src/server/index.js NODE_ENV check as for development it is not set
add rctapp dependecy which contain clear-react-packager-cache task
replace mochaRunCreator.js with mocha

I believe that these changes make project bit more readable and also reducing amount of code written for este which is one of the goals.
Let me know what do you think.

Gulp is unfortunately needed, blame Windows. To have Este cross platform we need to script things without crazy helpers. Also, I really don't like having complicated scipting stuff written in npm string. As I see it, npm scripts are just aliases. Feel free to argue, maybe there is a way to bypass gulp, but for now I think we have other priorities.

Well in my opinion is Gulp what make it hard to reason about project, as you have to go thru each task and look what code is executed there, in the another hand with npm scripts you have whole devstack in few lines without any extra logic just executed commands / scripts no extra api which has to be tailored, tested and documented.
Also npm scripts are in this minimal setup cross platform ( see http://blog.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/#thewindowsproblem ) , so in case you have some issues run any of these task please let me know and I will fix it.
I understand that there are many many other parts of the project which needs your attention, this is just POC to consider.
Let me know.

Thank you very much anyway. Once I will have a time, I will rethink gulpless approach and your PR will be very helpfull.

I'm glad I had chance to put my two cents.
Cheers

@elmariofredo How is looking at shell code in package.json any easier than reading javascript code in a gulpfile? You also lose: sourcemaps, performance, ability to run cross-platform, easy configurability.

+1

Hi @contra, first of all I’m really glad to have this discussion directly with you as creator of gulp. I had actually few talks around this topic, so I’m wondering how my argumentation will work for you.
To make it clear I have to say that I was using Grunt and and I was really happy to migrate to Gulp, at that time it was big step forward and I'm glad that you saved us from Grunt configuration hell.
But things has changed since these times. If one mean front end development seriously they use Webpack as build system (there are others but let's put that aside), same as este. So with Webpack you don't need another build system as Gulp, it feels to me same way as if somebody would suggest to use Gulp with Grunt when Gulp popularity was raising :smile: it just don't feel right as it's not necessary. I have create this PR to prove that it's possible and it will mainly improve readability among other things.
If you don't mind I would take each of your pro arguments and explain why I don't think it is relevant these days specially in context of this particular PR.

readability In this PR I have removed 118 lines which is not much but still it's some code one has to read and mainly maintain which is the thing which no team does and they end up in awful state with their devstack.
You can easily compare by yourself these few lines of package.json file

"lint": "eslint 'src/**/*.js' 'webpack/*.js'",
"test": "npm run lint && mocha --require test/mochaSetup.js --reporter spec --compilers js:babel-core/register 'src/**/*.spec.js'",
"test:watch": "npm test -- -w",
"build": "node webpack/build.js",
"postinstall": "npm run build",
"server-node": "node src/server",
"server-hot": "node webpack/server",
"server-nodemon": "nodemon src/server",
"start": "npm run server-hot & npm run server-nodemon",
"start-production": "npm run --production build && npm run --production server-node",
"start-native": "node_modules/react-native/packager/packager.sh",
"clean-native": "rctapp clean cache"

with gulpfile.js and accompanied with mochaRunCreator.js where there is no doubt about readability, you don't have to be command line pro to understand what is happening in package.json file. With Gulp you have to study each plugin what exactly is doing and how.

sourcemaps these are completely handled by Webpack and Gulp doesn't play any part in this
performance actually best perfomance is with using my favorite make but that's not unfortunately multiplatform solution, anyway Gulp performance is in question specially running thru Babel compiler, I haven't done any measurement, but I doubt that Gulp will outperform npm which is just executing command, no plugins, no logic. You are probably addressing one of the biggest Gulp feature which is use of streams. That was great idea, but it's not working that great these days with current devstack requirements. You can read great article from @joliss https://www.solitr.com/blog/2014/02/broccoli-first-release/ where she is comparing her Broccoli tool with other tools such as Gulp ( search for  "Comparison With Other Build Tools" specially part about gulp-less streams workaround ), also you can spot just one usage of streams in este gulpfile.js which is not enough to advocate use of Gulp.
cross-platform my PR is actually cross platform without Gulp, but I admit that it can bring some issues, but I would prefer single purpose library with minimal dependencies, than using Gulp which use plugin which in fact use library which does the job.
easy configurability I don't see anything easy about using yargs or process.env in comparison to npm config which can be overridden by user without any hassle see https://docs.npmjs.com/misc/config
wild plugins This one is mine :wink:, as this is really common issue with any sort of plugin system that plugin maintainer wont update dependent library as you or your coworkers needs, or even worse when depended library get upgraded thanks to semver issue and your devstack will stop working properly, so you have to shrinkwrap your project which also straight way to hell.

To summarize it, my main reason why I'm trying to get rid of Gulp is to simplify devstack as tools as Webpack has all functionality for which Gulp was created. Not to mention that with gulpfile.js various teams or single developers get really creative. One of the positive side effect of using npm scripts is that we are guiding developers to use existing well tested libraries instead of own code hidden in gulpfile.js or even other required files.
I hope that I haven't bore you to death :smile:, but I want to make sure to give you proper view on each of your arguments for using Gulp these days. Please feel free to tear my arguments apart, as npm scripts movement is raising I want to be sure that we haven't missed anything.

@elmariofredo That sounds reasonable, thanks for your comparison. My own experience with Este in the beginning was that I felt the gulpfile was rather opaque and "one more tool to learn"-barrier in order to fully understand what it does (nowdays with Webpack quite little).

@contra I understand that you have been busy with Gulp 4, also christmas holidays didn't help either ;). Just can you summarize where I'm wrong with my logic. I really would like to hear your opinion and don't want to have this discussion forgotten and lost.
Thanks!

for instance here is example of "similar" project which is using solely npm scripts https://github.com/coryhouse/react-slingshot

@elmariofredo The thing is, we need Gulp at least for little helpers like https://github.com/este/este/blob/master/gulpfile.babel.js#L90 Gulp is cross-platform, without Gulp, we would use various helpers like parallelshell anyway. Let's wait for webpack 2, maybe we can rethink Este approach.

@steida well IMHO these little helpers should be separate utils as they can help others ;)
and yes you would need to install and use parallelshell or other util in order to run webpack and backend server simultaneously, but it's same as you have to install and use gulp-bg but in less lines. Also you could consider instead of starting two express servers, just start single backend server and mount webpack middleware for development mode.
Sure I understand that such changes should be done carefully and agree that e.g. webpack upgrade could be suitable time this change.


First Two Scenarios Identical (mistake?) but have different recommendations

The first two bullet points/scenarios under the "Understand where you're starting from" heading have practically the same description but different recommendations.  One basically implies "follow the steps in this document", the second implies "don't follow this document but contact CSS instead".  Which is it?

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 9f56d653-f3ed-88a3-c307-1ba6eec6cbc2
Version Independent ID: 5f5b1c72-7b2a-a7cf-aea7-39cf84b11005
Content
Content Source
Service: unspecified

@cbailiss I have clarified this and it should be live later today, thank you for your feedback.


add $LOCAL on Kujira and Terra.

If you can set it up it would be of great help. At this point I'm not sure
what the correct JSON is for each $LOCAL token.
Here's a list of the Token Addresses:
Original LOCAL on Terra
Classic: terra1vchw83qt25j89zqwdpmdzj722sqxthnckqzxxp
whLOCAL on Terra2 - (LOCAL moved from Terra Classic to Terra2 via Wormhole)
terra1xzkel96e5e8vfmqw7valzdzzv9hqasfyslclvnmvxdejvpda3xwsskxzus
whLOCAL on KUJIRA - (LOCAL moved from Terra Classic to Terra2 via Wormhole,
and from Terra2 to KUJIRA via IBC)
ibc/DE92DB84EA7E8CB5EC76BC395CF634D6483B67414AD28BEF3F71EBFD6A780D36
https://finder.kujira.network/kaiyo-1/token/ibc%2FDE92DB84EA7E8CB5EC76BC395CF634D6483B67414AD28BEF3F71EBFD6A780D36
New, native LOCAL on KUJIRA
factory/kujira1swkuyt08z74n5jl7zr6hx0ru5sa2yev5v896p6/local
https://finder.kujira.network/kaiyo-1/token/factory%2Fkujira1swkuyt08z74n5jl7zr6hx0ru5sa2yev5v896p6%2Flocal
whLOCAL:LOCAL Swap contract, (in case you need or curious about it:
https://finder.kujira.network/kaiyo-1/address/kujira1hf84x7k4nkmult2daw65fe8yujr4yetvsv2zs2y33h2lq0smxu4sun5mmh
)
Really appreciate it.
On Wed, Nov 1, 2023 at 6:22 PM JeremyParish69 @.***>
wrote:

@.**** commented on this pull request.
In terra2/assetlist.json
https://github.com/cosmos/chain-registry/pull/3102#discussion_r1379423628
:

     "denom": "cw20:terra1xzkel96e5e8vfmqw7valzdzzv9hqasfyslclvnmvxdejvpda3xwsskxzus",

     "exponent": 0

   },

   {

     "denom": "whLOCAL",

     "exponent": 6

   }

 ],

 "base": "cw20:terra1xzkel96e5e8vfmqw7valzdzzv9hqasfyslclvnmvxdejvpda3xwsskxzus",

 "name": "whLOCAL",

 "display": "whLOCAL",

 "symbol": "whLOCAL",

 "logo_URIs": {

   "png": "https://raw.githubusercontent.com/cosmos/chain-registry/master/terra2/images/local.png"

 },

 "coingecko_id": "local-money",

In this case, I would say we should define the Terra2 to Kujira
ibc-transferred $LOCAL, as well (with its trace origin pointing to Terra2,
using type 'ibc'), and then this Kujira LOCAL that you already drafted
would have a trace origin to the ibc Kujira LOCAL, using type 'wrapped'.
I hope that makes sense? If needed, I could try to define some of it for
you
—
Reply to this email directly, view it on GitHub
https://github.com/cosmos/chain-registry/pull/3102#discussion_r1379423628,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAEJWR6LANPST4A5CCP6RATYCLKTTAVCNFSM6AAAAAA6YIUSB6VHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTOMBZGIYTMNBQGA
.
You are receiving this because you authored the thread.Message ID:
@.***>

Will there still be effort to register this?


Add serviceaccount of nfs-provisioner was created succeed logs to readme.

The latest nfs provisioner's deployment include kind of ServiceAccount and need to print log

My CLA signature fully registered

/lgtm
thank you

/approve


Lead part doesn't need calibration step

IF I create a song and go to record the lead part I'm asked to go through the audio calibration, but there's no need for the lead part because there's nothing to offset against i.e. offset should be 0 for the lead part.

Good point! Will amend :)


KMP iOS Support

Already supports iOS in KMP

Hi @halysongoncalves
Since no additional details or steps are provided regarding the issue, we're closing it. Feel free to reopen or create a new one if you encounter any specific issues and provide the necessary details.
Thanks!

@halysongoncalves iOS publishing pipeline wasn't setup, I did put some initial work in the last couple of days to setup SPM and cocoapods publishing, it is still WIP and would need more work

is this published on SPM? thanks!


List the PackageIdentifier of the package to be added to automation
XunLei.xunlei
Details about the application
https://down.sandai.net/thunder11/XunLeiSetup<IP_ADDRESS>0.exe

@spectershell can you please find API for this and the other package (https://github.com/vedantmgoyal2009/winget-pkgs-automation/issues/280) 😃

@SpecterShell, does this software have any API?

I got one but it is 404. 🤔


Crowspairses

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.2 out of 9 committers have signed the CLA.:white_check_mark: janEbert:white_check_mark: thnkinbtfly:x: rrutmann:x: ghstgs:x: KlaudiaTH:x: jjbuschhoff:x: malteos:x: katrinklug:x: nmowmitanmowmita seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.


Change syntax highlighting to javascript

For a better display in gitbook

Does it support JSX now? I think I went back and forth for a bit because it made it look like syntax errors. Let's give it a try.

I think it would be correct.


[chip-test] chip_sw_alert_handler_lpg_reset_toggle

Test point name
chip_sw_alert_handler_lpg_reset_toggle
Host side component
None Required
OpenTitanTool infrastructure implemented
No response
Contact person
@msfschaffner
Checklist
Please fill out this checklist as items are completed. Link to PRs and issues as appropriate.

[ ] Check if existing test covers most or all of this testpoint (if so, either extend said test to cover all points, or skip the next 3 checkboxes)
[ ] Device-side (C) component developed
[ ] Bazel build rules developed
[ ] Host-side component developed
[ ] HJSON test plan updated with test name (so it shows up in the dashboard)
[ ] Test added to dvsim nightly regression (and passing at time of checking)

Yes in that case we can close this.


Add EncodeURL function

This adds EncodeUrl functionality. The description of the function is described in this document.
The expected values on the test files are from PowerApps' EncodeUrl result and the test is checking if they are providing the identical result.

✅ No public API change.

✅ No public API change.

✅ No public API change.

✅ No public API change.


Use @DynamicPropertySource instead of ApplicationContextInitializer in Junits

Use @DynamicPropertySource like here instead of ApplicationContextInitializer in Junits when using Containers for setting the value in Junit tests  example
Also use @TestContainers annotation in conjunction with @Container annotation to start the container.
If we need to use the database across all Junits then we need to create ShareContainer like here
Suggest which is better way to handle?
I will submit PR for this

I remember changing it to use @DynamicPropertySource and reverting it back to ApplicationContextInitializer for some reason. Couldn't recollect the reason off top of my head.
Basically, I am aiming for having separate classes for Database/Localstack etc containers so that I can use them separately for specific scenarios, or use them all combined to run integration tests.
For example, if I want to run Spring Data JPA repository tests with @DataJpaTest I would like to use DBContainerInitializer. If I want to run some integration test with @SpringBootTest then I would like to use same DBContainerInitializer and LocalStackContainerInitializer without having to configure DB container for integration tests again separately.
If that can be done with @DynamicPropertiesSource then we can update it.

I will check sharing of containers for multiple tests from different classes

Please go through this link https://rieckpil.de/reuse-containers-with-testcontainers-for-fast-integration-tests/ it helps to use @DynamicProperties

In order to use @DynamicPropertiesSource we need to have a base class with ALL the containers defined. It would become bulky as and when we add more containers. Also, ApplicationContextInitializers play nice when running tests parallelly as opposed to having a base class with static containers.
So, for now, let us continue with current approach.


something wrong when training bevfusion with nuscenes mini

When I tried to train bevfusion with nuscenes mini (v1.0 mini), I firstly prepared the dataset by running "python tools/create_data.py nuscenes --version v1.0-mini --root-path ./data/nuscenes --out-dir ./data/nuscenes --extra-tag nuscenes". Then, I trained the bevfusion and it went wrong with the following bug:"FileNotFoundError: NuscenesDataset: LoadBEVSegmentation: [Errno 2] No such file or directory:' data/nuscenes/maps/expansion/singapore-onenorth.json'". May I ask if I can train bevfusion with the mini dataset? And what's wrong with this bug?

I have encountered the same problem. Have you solved it?

I have encountered the same problem. Have you solved it?

Yes， you can download the map expansion (v1.3), and put them into the "map".


remove --cluster from v8.x

Is your feature request related to a problem? Please describe.
I am trying to troubleshoot a problem that I was having in snakemake 7 where, when I used --cluster "command string here", snakemake would not recognize when target files were present and rules had successfully completed. The same snakemake worked fine when ran without --cluster. I think it is related to https://github.com/snakemake/snakemake/issues/2739 or https://github.com/snakemake/snakemake/issues/2496 . It might be some file latency problem with my SLURM cluster, too.
I switched to snakemake 8 to test my code, and I ran the same command with --cluster. It ran, and I encountered the same issue. I then looked at the documentation for snakemake 8 and realized that --cluster has been replaced with the --executor flag, and the --cluster is no longer supported.
Describe the solution you'd like
I think snakemake 8 should throw an error when --cluster is called and the user should be pointed to the now-supported --executor pattern. If it is deprecated code, maybe that code should also be removed.
Describe alternatives you've considered
The alternative is not doing anything and allowing snakemake to run with the old --cluster instruction. Old scripts may still work, but bug fixes for it would not be supported.

The cli documentation contains several references to --cluster, even though it doesn't exist anymore in 8.25.3.
$ snakemake --version
8.25.3
$ snakemake --cluster
usage: snakemake [-h] [--dry-run] [--profile PROFILE] [--workflow-profile WORKFLOW_PROFILE] [--cache [RULE ...]] [--snakefile FILE] [--cores N] [--jobs N] [--local-cores N]
...
snakemake: error: unrecognized arguments: --cluster


Custom bulk action

If you have a multi-tenant system and know that the queries will always include a filter condition for a given tenant, you might want to instruct Elasticsearch to group the documents for the same tenant on the same shard.
This PR provides a prepareIndexAction method to add metadata to the Bulk action.
Similar to prepare() I added a new interface JeroenG\Explorer\Application\BeIndexed to hold this new behavior.

What I like: ability to add bulk action settings. What I don't like: separate implementations for each setting.
Given that we just recently added a more general approach to query properties I would like to do the same for these settings. I therefore think a slightly different approach from yours is necessary. @blackshadev do you agree?
@fedeisas in any case, thanks for bringing this idea and PR, it certainly can be a good improvement to Explorer!


[Question]: about regex match

Hi, I like Kong very much.  But there are some questions about how to use regex.
I has two route:
Route A: /test_(.+)
Route B: /test_a(.+)

I want to hit the second route on visit /test_a/test.  But they always hit the first one. I set priorities but it doesn't work, right.
I don't know if I'm using it the wrong way.
Kong version: 1.3.0
System version: Centos7

Ok, let me try (this is using next branch):
Create Route A:
$ http put :8001/routes/a paths="/test_(.+)" -f
{
    "created_at":<PHONE_NUMBER>,
    "destinations": null,
    "headers": null,
    "hosts": null,
    "https_redirect_status_code": 426,
    "id": "3847d45f-7e5d-4837-aa34-400eec04188a",
    "methods": null,
    "name": "a",
    "path_handling": "v0",
    "paths": [
        "/test_(.+)"
    ],
    "preserve_host": false,
    "protocols": [
        "http",
        "https"
    ],
    "regex_priority": 0,
    "service": null,
    "snis": null,
    "sources": null,
    "strip_path": true,
    "tags": null,
    "updated_at":<PHONE_NUMBER>
}

Create Route B:
$ http put :8001/routes/b paths="/test_a(.+)" -f
{
    "created_at":<PHONE_NUMBER>,
    "destinations": null,
    "headers": null,
    "hosts": null,
    "https_redirect_status_code": 426,
    "id": "be5a22d9-3027-453f-b76c-d4fd98be2421",
    "methods": null,
    "name": "b",
    "path_handling": "v0",
    "paths": [
        "/test_a(.+)"
    ],
    "preserve_host": false,
    "protocols": [
        "http",
        "https"
    ],
    "regex_priority": 0,
    "service": null,
    "snis": null,
    "sources": null,
    "strip_path": true,
    "tags": null,
    "updated_at":<PHONE_NUMBER>
}

Make request to /test_a/test:
$ http :8000/test_a/test kong-debug:true
Kong-Route-Name: a

Matches a as expected. Now lets prioritize b:
$ http patch :8001/routes/b regex_priority=1 -f
{
    "created_at":<PHONE_NUMBER>,
    "destinations": null,
    "headers": null,
    "hosts": null,
    "https_redirect_status_code": 426,
    "id": "be5a22d9-3027-453f-b76c-d4fd98be2421",
    "methods": null,
    "name": "b",
    "path_handling": "v0",
    "paths": [
        "/test_a(.+)"
    ],
    "preserve_host": false,
    "protocols": [
        "http",
        "https"
    ],
    "regex_priority": 1,
    "service": null,
    "snis": null,
    "sources": null,
    "strip_path": true,
    "tags": null,
    "updated_at":<PHONE_NUMBER>
}

Make request to /test_a/test:
$ http :8000/test_a/test kong-debug:true
Kong-Route-Name: b

Matches b as expected.
Could it be a bug in 1.3.0 that is already fixed.

Sorry, The example is not very appropriate, I will sort out the existing routes and feedback.


feat(app): Implement acknowledgement feature in app

Signed-off-by: Talwinder kaur<EMAIL_ADDRESS>

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Comparison is base (f5616d7) 89.02% compared to head (a99d510) 89.02%.
Report is 2 commits behind head on main.

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #689   +/-   ##
=======================================
  Coverage   89.02%   89.02%
=======================================
  Files         103      103
  Lines        4218     4218
=======================================
  Hits         3755     3755
  Misses        312      312
  Partials      151      151

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.