Grinder does not accept mangrove logs

Examining the source code shows that the grinder doesn't include a case for mangrove logs despite accepting all the other vanilla logs. I presume this was just forgotten for the 1.19 upgrade. (cf. https://github.com/ICY105/Mechanization/blob/42050ba1f55d95c519dca97387393b6edc603f02/data/mechanization/functions/machines/machines/grinder/input.mcfunction#L59 )

Fixed in v4.1.0


users manager

Can manage server users, database users and  users database ACL?

Hello @proidit,
Please provide information about your request using our issue templates.

There has been no update for a long time.
If the issue is still actual, feel free to reopen it.


adding attributes implementation on "Components" decoder

Pull Request Test Coverage Report for Build 733054095

7 of 12 (58.33%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 93.701%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

decoder.go
7
12
58.33%

Totals

Change from base Build 729684940:
-0.1%

Covered Lines:
3734

Relevant Lines:
3985

💛  - Coveralls


NETOBSERV-291 - NetFlow table needs pagination

This PR is a base of discussion following comments about table performances when we render a lot of columns + rows (ie all columns + 1k rows currently makes your browser really slow)
A quick solution would be to implement pagination and only show a subset of flows.
Sort function still needs to be refactored:

it sould sort on all flows (here it only sort current page content)
should apply on flow refresh
column + direction should be kept in URL
Also vertical scrollbar should not show in some cases.

Here is an example with 1k flows in query limit and 10 flows per page:

I put the pager in the top toolbar but it could be also with summary at bottom of the page:

Both https://github.com/netobserv/network-observability-console-plugin/pull/122 about conditional rendering and this PR can be merged to improve performances

@andrew-ronaldson @stleerh what are your thoughts about that approach ?

Here is an example with 1k flows in query limit and 10 flows per page:

What does this look like on a smaller screen? I prefer it at the top with the other actions but space can be limited. More of a case for my consolidated table settings modal.
I go back and forth on pagination because of the refresh rate. If the data refreshes do you automatically go back to page 1 with new data?

Following our discussions:

Pagination will be enabled by default
Options are 100 / 500 / 1000 items per page without performance issues since https://github.com/netobserv/network-observability-console-plugin/pull/122
Default is 100
Pager is integrated at the bottom with summary

I'm taking this one for testing
But a quick comment already, looking at the initial description:

it sould sort on all flows (here it only sort current page content)
should apply on flow refresh

is that something already sorted out since the initial push? Because, compared to the current behaviour without pagination, if we loose that it's a regression, I'd prefer to have that fixed in this PR (especially as we want to release soon)

/hold

If there is no filter, the max number of flows is the limit set in Query Options.  However, if I enter a filter such as "openshift" for Common Namespace, then it exceeds that.  At limit 100, I can get 181 flows.  At limit 500, I can get 681 flows.  At limit 1000, I can get 1671 flows.  What is the rule?
If the table limit is somewhere around 1671 when the limit is set to 1000, then pagination is not very useful because even at 1000 per page, there can be at most 2 pages.
With pagination and a page size limit, does there need to be a table limit?

What is the rule?

API has been refactored to run multiple loki queries in parallel and now limit represent a single query limit.
Limit for internal backend queries. Depending on the matching and filter settings, several queries can be performed under the cover, each with this limit set, resulting in more results after aggregation.
Check https://github.com/netobserv/network-observability-console-plugin/pull/105 & https://github.com/netobserv/network-observability-console-plugin/pull/136

With pagination and a page size limit, does there need to be a table limit?

Loki will always need a limit unless we edit the API to fetch recursively but this can be really slow. We also need to refactor sorting if we go that way since it's done on client side for now and could become huge without limits.
@jotak

Closing that PR since it's quite old. Follow up will be in https://issues.redhat.com/browse/NETOBSERV-291


deploy module should grant invoke permission to code deploy hooks

The deploy module has a var for before_allow_traffic_hook_arn and after_allow_traffic_hook_arn where you can set the arn of a Lambda function for CodeDeploy to call during the deployment. However, the role created by create_codedeploy_role doesn't grant permission for CodeDeploy to invoke the before or after hooks.
The role should add the InvokeFunction permissions for the hooks if they are set and create_codedeploy_role is true.

Hi! Could you please make a PR and show it in code (it is much easier and faster for me to understand)?


Update Nugets and fixes first issues after updates

can you remove the fixes on warnings? We should handle those in another pr

can you remove the fixes on warnings? We should handle those in another pr

This fixes after update Nugets Libraries. I can fixes CI in other PR

solve the conflicts to get the new workflow and pass dotnet-format

already done in #163

ah no my bad, reopened.


Simplify comparison processes (and add date_difference)

This is a proposal to simplify the comparison processes. The discussions in #394 lead me to the conclusion that we may not want to handle date/times in so many processes specifically so that issues can be solved in some central places rather than spreading them into so many processes. Also, the old implementation was a bit suboptimal in that you had to parse the inputs first to detect whether the values are temporal values, potentially making the comparisons slower than needed. Most use-cases can likely be solved with a new process such as date_difference..
This includes a breaking change for the comparison processes. The impact is assumed to be low as most date/time values would usually come from labels in timeseries, but label support seems very limited in back-ends right now. For between back-ends can choose to still support the old behavior.
Looking for feedback.

makes sense.
as already noted: I don't think this will have practical impact at the moment.
Also note that we already could introduce the new date_difference process in the 1.x branch and do the breaking 2.0 changes later

@soxofaan True, but 1.3 and 2.0 are pretty much 2.0 now, I don't think we'll get to an intermediate 1.3 release honestly, but instead directly start with 2.0-beta/rc.

I don't think this will have practical impact at the moment.

Can confirm this for our backend as our process implementation (for those) didn't support date formats from the beginning.


Split LabelsSelect into multiple selects with too many options

Update dropdown for selecting Fingerprint (LabelsSelector): when it contains more than 16 elements in total it should be displayed as a dropdown for each label. As some of the labels are selected the options for other labels should be filtered to only those applicable (ignoring non-existent combinations) and auto-selected if there's only one valid option.

Implemented in #198


chore: upgrade charts

updated chart jxgh/vault-instance from 1.0.21 to 1.0.22

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To complete the pull request process, please assign hferentschik
You can assign the PR to them by writing /assign @hferentschik in a comment when ready.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@jenkins-x-bot-test: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

tls
f0e091a849e0bd8426ee66319859b2c2aeeb5fe7
link
/test tls

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the jenkins-x/lighthouse repository. I understand the commands that are listed here.

already upgraded


How to generate from custom polygon?

Hi,
I have the stage in my game:

I have a custom polygon form and i need generate random positions inside this polygon where my obstacles have custom size and can't collide inside it. Always in random position.
This is my current algorithm (but not poison implementation):

How can i do it? Is possible with your code? The most different thing is that every placed object have their custom size too.
Thanks.

You would have to do it in several passes. So maybe you could generate the large object positions first, and then use those to "clip" the smaller positions. I don't think the Poisson distribution methods are well-suited for "multiple radii" scattering problems out-of-the-box.
I will close this, since it is not really a question about the code itself.


Host details page UI issues

Rancher Version: v1.2.0-pre2-rc2
Steps to Reproduce:

[x] Remove Icons

[x] ~Tabs need to touch table~

[x] ~Title text running into other and Name is on single line (width 1045 px)~

Version - master 10/6
None of this is fixed.  Mistakenly marked resolved

Version - master 11/06
Verified fixed


Contributing documentation

We need a REAMDE file with documentation of how to contribute.

Will add more info about the technical side as soon as I've figured out Statinamic myself. :+1:

Yeah, we need a section as well for code guidelines.

https://github.com/postcss/postcss.com/blob/master/CONTRIBUTING.md

Code guidelines and issues label sections is left over to do.

@marcustisater will you document the issue labels, seeing as you created them?

my 2 cents for labels https://github.com/MoOx/setup/blob/1b712c1f9cb2495585d47c4db6acba0c9558a0ab/dotfiles/zshrc#L234-L235

Yeah, I need to structure those. Thanks @MoOx

I updated the labels with some of your's, will document them in the markdown file as well.

Code guidelines left to do.

These depend on the solution for #29, will do soon.


/std:c++latest not preserved when transferring compile command

InterpolatingCompilationDatabase will translate clang --driver-mode=cl /std:c++latest foo.cpp into clang --driver-mode=cl foo.hpp.
This is because we expect the value after "/std:" to name a language version, but in MSVC-compat mode it's a hardcoded table in the driver instead.

I figured out a similar issue with msvc 16.11.3 for the source file it is called correctly, but when clangd is parsing the header file, it omits it.

This is still an issue as of clangd 14.0.5 and msvc 17.3.4. We use clang-cl, our CompilationDatabase / compiler_commands.json specify -std:c++latest and the clangd invocation (via vscode-clangd) output omits the argument unless we redundantly configure our .clangd config file like:
CompileFlags:
Add: [
"-std:c++latest"
]
CompilationDatabase: "C:/path/to/cmake/out/folder/with/compiler_commands"
For recent language standards, msvc does name a language version in a way that seems 1:1 mappable to my eye.
/std:c++14
/std:c++17
/std:c++20
/std:c++latest

c++latest is the outlier, as it is a moving target.
However, cmake (3.22.2), has a mapping for 23 (and soon 26) to the best msvc match: c++latest. Those mapping choices are certainly debatable but are overridable in a defined way via CMAKE_CXX23_STANDARD_COMPILE_OPTION, so if clangd would accept the -std argument verbatim from compiler_commands.json when it's present, I think that would be more intuitive than the current behavior.

Unfortunately, even the Add : '-std:c++latest' workaround doesn't work all the time (at least for me).
If I open a header file in my code editor, everything works just fine, but if I open a .cpp file and navigate to some header file from it, then I get a bunch of wrong-cpp-version errors

@sigasigasiga please post verbose clangd logs to help figure out what's going on

Unfortunately, even the Add: '-std:c++latest' workaround doesn't work all the time (at least for me).

It never worked, since std:c++latest is not propagated / the maximum supported c++ standard is never determined and propagated. What works is Add: '-std:c++23'

@HighCommander4 I've recorded a video that demonstrates the issue with this workaround (link), the project that I used in the video can be found here clangd-bug.zip

Verbose log
[START][2024-04-26 14:47:51] LSP logging initiated
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:51.643] clangd version 18.1.4\r\nI[14:47:51.644] Features: windows\r\nI[14:47:51.644] PID: 13100\r\nI[14:47:51.644] Working directory: C:\\dev\\clangd-bug\r\nI[14:47:51.644] argv[0]: C:\\Program Files\\LLVM\\bin\\clangd.exe\r\nI[14:47:51.644] argv[1]: --fallback-style=none\r\nI[14:47:51.644] argv[2]: --log=verbose\r\nV[14:47:51.647] User config file is C:\\Users\\egorbychin\\AppData\\Local\\clangd\\config.yaml\r\nI[14:47:51.647] Starting LSP over stdin/stdout\r\nV[14:47:51.647] <<< {"id":1,"jsonrpc":"2.0","method":"initialize","params":{"capabilities":{"offsetEncoding":["utf-8","utf-16"],"textDocument":{"callHierarchy":{"dynamicRegistration":false},"codeAction":{"codeActionLiteralSupport":{"codeActionKind":{"valueSet":["","quickfix","refactor","refactor.extract","refactor.inline","refactor.rewrite","source","source.organizeImports"]}},"dataSupport":true,"dynamicRegistration":false,"isPreferredSupport":true,"resolveSupport":{"properties":["edit"]}},"completion":{"completionItem":{"commitCharactersSupport":false,"deprecatedSupport":false,"documentationFormat":["markdown","plaintext"],"preselectSupport":false,"snippetSupport":false},"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]},"contextSupport":false,"dynamicRegistration":false,"editsNearCursor":true},"declaration":{"linkSupport":true},"definition":{"linkSupport":true},"documentHighlight":{"dynamicRegistration":false},"documentSymbol":{"dynamicRegistration":false,"hierarchicalDocumentSymbolSupport":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]}},"hover":{"contentFormat":["markdown","plaintext"],"dynamicRegistration":false},"implementation":{"linkSupport":true},"publishDiagnostics":{"relatedInformation":true,"tagSupport":{"valueSet":[1,2]}},"references":{"dynamicRegistration":false},"rename":{"dynamicRegistration":false,"prepareSupport":true},"semanticTokens":{"augmentsSyntaxTokens":true,"dynamicRegistration":false,"formats":["relative"],"multilineTokenSupport":false,"overlappingTokenSupport":true,"requests":{"full":{"delta":true},"range":false},"serverCancelSupport":false,"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":{"dynamicRegistration":false,"signatureInformation":{"activeParameterSupport":true,"documentationFormat":["markdown","plaintext"],"parameterInformation":{"labelOffsetSupport":true}}},"synchronization":{"didSave":true,"dynamicRegistration":false,"willSave":true,"willSaveWaitUntil":true},"typeDefinition":{"linkSupport":true}},"window":{"showDocument":{"support":true},"showMessage":{"messageActionItem":{"additionalPropertiesSupport":false}},"workDoneProgress":true},"workspace":{"applyEdit":true,"configuration":true,"didChangeWatchedFiles":{"dynamicRegistration":false,"relativePatternSupport":true},"semanticTokens":{"refreshSupport":true},"symbol":{"dynamicRegistration":false,"hierarchicalWorkspaceSymbolSupport":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]}},"workspaceEdit":{"resourceOperations":["rename","create","delete"]},"workspaceFolders":true}},"clientInfo":{"name":"Neovim","version":"0.9.4"},"initializationOptions":{},"processId":17644,"rootPath":"C:\\\\dev\\\\clangd-bug","rootUri":"file:///C:/dev/clangd-bug","trace":"off","workspaceFolders":[{"name":"C:/dev/clangd-bug","uri":"file:///C:/dev/clangd-bug"}]}}\r\n\r\nI[14:47:51.647] <-- initialize(1)\r\nI[14:47:51.649] --> reply:initialize(1) 1 ms\r\nV[14:47:51.649] >>> {"id":1,"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},"offsetEncoding":"utf-8","serverInfo":{"name":"clangd","version":"clangd version 18.1.4 windows x86_64-pc-windows-msvc"}}}\r\n\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.650] <<< {"jsonrpc":"2.0","method":"initialized","params":{}}\r\n\r\nI[14:47:51.650] <-- initialized\r\nV[14:47:51.650] <<< {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"cpp","text":"#pragma once\\r\\n\\r\\n#include <expected>\\r\\n\\r\\ninline std::expected<int, int> global1;\\r\\n\\r\\nvoid defined_in_main1();\\r\\n","uri":"file:///C:/dev/clangd-bug/header1.hpp","version":0}}}\r\n\r\nI[14:47:51.650] <-- textDocument/didOpen\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.651] config note at C:\\dev\\clangd-bug\\.clangd:1:0: Parsing config fragment\r\nV[14:47:51.651] config note at C:\\dev\\clangd-bug\\.clangd:1:0: Parsed 1 fragments from file\r\nV[14:47:51.651] Config fragment: compiling C:\\dev\\clangd-bug\\.clangd:1 -> 0x0000027203030CD0 (trusted=false)\r\nI[14:47:51.651] --> textDocument/publishDiagnostics\r\nV[14:47:51.651] >>> {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[],"uri":"file:///C:/dev/clangd-bug/.clangd"}}\r\n\r\nI[14:47:51.651] Loaded compilation database from C:\\dev\\clangd-bug\\compile_commands.json\r\nV[14:47:51.651] Broadcasting compilation database from C:\\dev\\clangd-bug\r\nI[14:47:51.651] --> window/workDoneProgress/create(0)\r\nV[14:47:51.651] >>> {"id":0,"jsonrpc":"2.0","method":"window/workDoneProgress/create","params":{"token":"backgroundIndexProgress"}}\r\n\r\nI[14:47:51.651] Enqueueing 1 commands for indexing\r\nI[14:47:51.652] ASTWorker building file C:\\dev\\clangd-bug\\header1.hpp version 0 with command inferred from cpp.cpp\r\n[C:\\dev\\clangd-bug]\r\n"C:\\\\Program Files\\\\LLVM\\\\bin\\\\clang-cl.exe" --driver-mode=cl /std:c++latest "-resource-dir=C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18" -- "C:\\\\dev\\\\clangd-bug\\\\header1.hpp"\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.654] <<< {"id":2,"jsonrpc":"2.0","method":"textDocument/semanticTokens/full","params":{"textDocument":{"uri":"file:///C:/dev/clangd-bug/header1.hpp"}}}\r\n\r\nI[14:47:51.654] <-- textDocument/semanticTokens/full(2)\r\nV[14:47:51.654] <<< {"id":0,"jsonrpc":"2.0","result":null}\r\n\r\nI[14:47:51.654] <-- reply(0)\r\nI[14:47:51.654] --> $/progress\r\nV[14:47:51.654] >>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundIndexProgress","value":{"kind":"begin","percentage":0,"title":"indexing"}}}\r\n\r\nI[14:47:51.654] --> $/progress\r\nV[14:47:51.654] >>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundIndexProgress","value":{"kind":"report","message":"0/1","percentage":0}}}\r\n\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.661] Driver produced command: cc1 -cc1 -triple x86_64-pc-windows-msvc19.39.33519 -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name header1.hpp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -fms-volatile -funwind-tables=2 -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -tune-cpu generic -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames -stack-protector 2 -fdiagnostics-format msvc "-fdebug-compilation-dir=C:\\\\dev\\\\clangd-bug" "-fcoverage-compilation-dir=C:\\\\dev\\\\clangd-bug" -resource-dir "C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18" -internal-isystem "C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18\\\\include" -internal-isystem "C:\\\\Program Files\\\\Microsoft Visual Studio\\\\2022\\\\Community\\\\VC\\\\Tools\\\\MSVC\\\\14.39.33519\\\\include" -internal-isystem "C:\\\\Program Files\\\\Microsoft Visual Studio\\\\2022\\\\Community\\\\VC\\\\Tools\\\\MSVC\\\\14.39.33519\\\\atlmfc\\\\include" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\ucrt" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\shared" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\um" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\winrt" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\cppwinrt" -fdeprecated-macro -ferror-limit 19 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.39.33519 -std=c++26 -fno-implicit-modules -fskip-odr-check-in-gmf -no-round-trip-args -faddrsig -x c++-header "C:\\\\dev\\\\clangd-bug\\\\header1.hpp"\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:51.661] Building first preamble for C:\\dev\\clangd-bug\\header1.hpp version 0\r\n"
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:51.669] BackgroundIndex: building version 1 after loading index from disk\r\n"
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:51.680] BackgroundIndex: serving version 1 (3808111 bytes)\r\n"
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:51.684] --> $/progress\r\n"
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.684] >>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundIndexProgress","value":{"kind":"report","message":"0/1","percentage":0}}}\r\n\r\nI[14:47:51.684] --> $/progress\r\nV[14:47:51.684] >>> {"jsonrpc":"2.0","method":"$/progress","params":{"token":"backgroundIndexProgress","value":{"kind":"end"}}}\r\n\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:51.783] Built preamble of size 3456420 for file C:\\dev\\clangd-bug\\header1.hpp version 0 in 0.12 seconds\r\n"
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:51.784] --> workspace/semanticTokens/refresh(1)\r\nV[14:47:51.784] >>> {"id":1,"jsonrpc":"2.0","method":"workspace/semanticTokens/refresh","params":null}\r\n\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.784] <<< {"jsonrpc":"2.0","method":"$/cancelRequest","params":{"id":2}}\r\n\r\nI[14:47:51.784] <-- $/cancelRequest\r\nV[14:47:51.784] <<< {"id":3,"jsonrpc":"2.0","method":"textDocument/semanticTokens/full","params":{"textDocument":{"uri":"file:///C:/dev/clangd-bug/header1.hpp"}}}\r\n\r\nI[14:47:51.784] <-- textDocument/semanticTokens/full(3)\r\nI[14:47:51.784] Indexing c++23 standard library in the context of C:\\dev\\clangd-bug\\header1.hpp\r\nV[14:47:51.784] <<< {"id":1,"jsonrpc":"2.0","result":null}\r\n\r\nI[14:47:51.784] <-- reply(1)\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.811] indexed file AST for C:\\dev\\clangd-bug\\header1.hpp version 0:\r\n  symbol slab: 2 symbols, 4688 bytes\r\n  ref slab: 4 symbols, 4 refs, 4328 bytes\r\n  relations slab: 0 relations, 24 bytes\r\nV[14:47:51.811] Build dynamic index for main-file symbols with estimated memory usage of 12168 bytes\r\nI[14:47:51.811] --> textDocument/publishDiagnostics\r\nV[14:47:51.811] >>> {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[],"uri":"file:///C:/dev/clangd-bug/header1.hpp","version":0}}\r\n\r\nI[14:47:51.811] --> reply:textDocument/semanticTokens/full(2) 156 ms, error: Task was cancelled.\r\nV[14:47:51.811] >>> {"error":{"code":-32800,"message":"Request cancelled"},"id":2,"jsonrpc":"2.0"}\r\n\r\nV[14:47:51.811] ASTWorker running SemanticHighlights on version 0 of C:\\dev\\clangd-bug\\header1.hpp\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:51.811] --> reply:textDocument/semanticTokens/full(3) 27 ms\r\nV[14:47:51.811] >>> {"id":3,"jsonrpc":"2.0","result":{"data":[4,7,3,15,131584,0,5,8,8,131584,0,8,1,22,0,0,9,1,22,0,0,2,7,0,131075,2,5,16,3,131073],"resultId":"1"}}\r\n\r\n'
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:51.812] indexed preamble AST for C:\\dev\\clangd-bug\\header1.hpp version 0:\r\n  symbol slab: 4369 symbols, 1165288 bytes\r\n  ref slab: 0 symbols, 0 refs, 136 bytes\r\n  relations slab: 142 relations, 3611 bytes\r\n"
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:51.825] Build dynamic index for header symbols with estimated memory usage of 2942364 bytes\r\n"
[ERROR][2024-04-26 14:47:51] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:51.925] <<< {"id":4,"jsonrpc":"2.0","method":"textDocument/documentHighlight","params":{"position":{"character":0,"line":0},"textDocument":{"uri":"file:///C:/dev/clangd-bug/header1.hpp"}}}\r\n\r\nI[14:47:51.925] <-- textDocument/documentHighlight(4)\r\nV[14:47:51.925] ASTWorker running Highlights on version 0 of C:\\dev\\clangd-bug\\header1.hpp\r\nI[14:47:51.925] --> reply:textDocument/documentHighlight(4) 0 ms\r\nV[14:47:51.925] >>> {"id":4,"jsonrpc":"2.0","result":[]}\r\n\r\n'
[ERROR][2024-04-26 14:47:53] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:53.242] Ignored diagnostic. C:\\Program Files\\Microsoft Visual Studio\\2022\\Community\\VC\\Tools\\MSVC\\14.39.33519\\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.\r\n"
[ERROR][2024-04-26 14:47:53] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:53.435] Indexed c++23 standard library (incomplete due to errors): 15846 symbols, 7672 filtered\r\n"
[ERROR][2024-04-26 14:47:53] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:53.479] Build dynamic index for header symbols with estimated memory usage of 8497284 bytes\r\n"
[ERROR][2024-04-26 14:47:53] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:53.732] <<< {"id":5,"jsonrpc":"2.0","method":"textDocument/documentHighlight","params":{"position":{"character":0,"line":5},"textDocument":{"uri":"file:///C:/dev/clangd-bug/header1.hpp"}}}\r\n\r\nI[14:47:53.732] <-- textDocument/documentHighlight(5)\r\n'
[ERROR][2024-04-26 14:47:53] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:53.732] ASTWorker running Highlights on version 0 of C:\\dev\\clangd-bug\\header1.hpp\r\nI[14:47:53.732] --> reply:textDocument/documentHighlight(5) 0 ms\r\nV[14:47:53.732] >>> {"id":5,"jsonrpc":"2.0","result":[]}\r\n\r\n'
[ERROR][2024-04-26 14:47:54] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:54.094] <<< {"id":6,"jsonrpc":"2.0","method":"textDocument/documentHighlight","params":{"position":{"character":0,"line":6},"textDocument":{"uri":"file:///C:/dev/clangd-bug/header1.hpp"}}}\r\n\r\nI[14:47:54.094] <-- textDocument/documentHighlight(6)\r\n'
[ERROR][2024-04-26 14:47:54] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:54.094] ASTWorker running Highlights on version 0 of C:\\dev\\clangd-bug\\header1.hpp\r\n"
[ERROR][2024-04-26 14:47:54] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:54.094] --> reply:textDocument/documentHighlight(6) 0 ms\r\nV[14:47:54.094] >>> {"id":6,"jsonrpc":"2.0","result":[]}\r\n\r\n'
[ERROR][2024-04-26 14:47:54] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:54.503] <<< {"id":7,"jsonrpc":"2.0","method":"textDocument/documentHighlight","params":{"position":{"character":5,"line":6},"textDocument":{"uri":"file:///C:/dev/clangd-bug/header1.hpp"}}}\r\n\r\n'
[ERROR][2024-04-26 14:47:54] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:54.504] <-- textDocument/documentHighlight(7)\r\nV[14:47:54.504] ASTWorker running Highlights on version 0 of C:\\dev\\clangd-bug\\header1.hpp\r\n"
[ERROR][2024-04-26 14:47:54] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:54.504] --> reply:textDocument/documentHighlight(7) 0 ms\r\nV[14:47:54.504] >>> {"id":7,"jsonrpc":"2.0","result":[{"kind":1,"range":{"end":{"character":21,"line":6},"start":{"character":5,"line":6}}}]}\r\n\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.228] <<< {"id":8,"jsonrpc":"2.0","method":"textDocument/definition","params":{"position":{"character":5,"line":6},"textDocument":{"uri":"file:///C:/dev/clangd-bug/header1.hpp"}}}\r\n\r\nI[14:47:55.228] <-- textDocument/definition(8)\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:55.229] ASTWorker running Definitions on version 0 of C:\\dev\\clangd-bug\\header1.hpp\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:55.229] --> reply:textDocument/definition(8) 0 ms\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.229] >>> {"id":8,"jsonrpc":"2.0","result":[{"range":{"end":{"character":21,"line":3},"start":{"character":5,"line":3}},"uri":"file:///C:/dev/clangd-bug/cpp.cpp"}]}\r\n\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.245] <<< {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"cpp","text":"#include \\"header1.hpp\\"\\r\\n#include \\"header2.hpp\\"\\r\\n\\r\\nvoid defined_in_main1() {\\r\\n\\r\\n}\\r\\n\\r\\nvoid defined_in_main2() {\\r\\n\\r\\n}\\r\\n\\r\\nint main() {\\r\\n    std::expected<int, int> e;\\r\\n}\\r\\n","uri":"file:///C:/dev/clangd-bug/cpp.cpp","version":0}}}\r\n\r\nI[14:47:55.245] <-- textDocument/didOpen\r\nI[14:47:55.246] ASTWorker building file C:\\dev\\clangd-bug\\cpp.cpp version 0 with command \r\n[C:\\dev\\clangd-bug]\r\n"C:\\\\Program Files\\\\LLVM\\\\bin\\\\clang-cl.exe" --driver-mode=cl /std:c++latest /std:c++latest "-resource-dir=C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18" -- "C:\\\\dev\\\\clangd-bug\\\\cpp.cpp"\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.247] <<< {"id":9,"jsonrpc":"2.0","method":"textDocument/semanticTokens/full","params":{"textDocument":{"uri":"file:///C:/dev/clangd-bug/cpp.cpp"}}}\r\n\r\nI[14:47:55.247] <-- textDocument/semanticTokens/full(9)\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.250] Driver produced command: cc1 -cc1 -triple x86_64-pc-windows-msvc19.39.33519 -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name cpp.cpp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -fms-volatile -funwind-tables=2 -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -tune-cpu generic -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames -stack-protector 2 -fdiagnostics-format msvc "-fdebug-compilation-dir=C:\\\\dev\\\\clangd-bug" "-fcoverage-compilation-dir=C:\\\\dev\\\\clangd-bug" -resource-dir "C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18" -internal-isystem "C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18\\\\include" -internal-isystem "C:\\\\Program Files\\\\Microsoft Visual Studio\\\\2022\\\\Community\\\\VC\\\\Tools\\\\MSVC\\\\14.39.33519\\\\include" -internal-isystem "C:\\\\Program Files\\\\Microsoft Visual Studio\\\\2022\\\\Community\\\\VC\\\\Tools\\\\MSVC\\\\14.39.33519\\\\atlmfc\\\\include" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\ucrt" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\shared" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\um" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\winrt" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\cppwinrt" -fdeprecated-macro -ferror-limit 19 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.39.33519 -std=c++26 -fno-implicit-modules -fskip-odr-check-in-gmf -no-round-trip-args -faddrsig -x c++ "C:\\\\dev\\\\clangd-bug\\\\cpp.cpp"\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:55.250] Building first preamble for C:\\dev\\clangd-bug\\cpp.cpp version 0\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:55.370] Built preamble of size 3492912 for file C:\\dev\\clangd-bug\\cpp.cpp version 0 in 0.12 seconds\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:55.370] --> workspace/semanticTokens/refresh(2)\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.370] >>> {"id":2,"jsonrpc":"2.0","method":"workspace/semanticTokens/refresh","params":null}\r\n\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.370] <<< {"jsonrpc":"2.0","method":"$/cancelRequest","params":{"id":9}}\r\n\r\nI[14:47:55.370] <-- $/cancelRequest\r\nV[14:47:55.370] <<< {"id":10,"jsonrpc":"2.0","method":"textDocument/semanticTokens/full","params":{"textDocument":{"uri":"file:///C:/dev/clangd-bug/cpp.cpp"}}}\r\n\r\nI[14:47:55.370] <-- textDocument/semanticTokens/full(10)\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.370] <<< {"id":2,"jsonrpc":"2.0","result":null}\r\n\r\nI[14:47:55.370] <-- reply(2)\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:55.399] indexed preamble AST for C:\\dev\\clangd-bug\\cpp.cpp version 0:\r\n  symbol slab: 4373 symbols, 1166216 bytes\r\n  ref slab: 0 symbols, 0 refs, 136 bytes\r\n  relations slab: 142 relations, 3611 bytes\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:55.423] indexed file AST for C:\\dev\\clangd-bug\\cpp.cpp version 0:\r\n  symbol slab: 3 symbols, 4920 bytes\r\n  ref slab: 5 symbols, 5 refs, 4376 bytes\r\n  relations slab: 0 relations, 24 bytes\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.423] Build dynamic index for main-file symbols with estimated memory usage of 22088 bytes\r\nI[14:47:55.423] --> textDocument/publishDiagnostics\r\nV[14:47:55.423] >>> {"jsonrpc":"2.0","method":"textDocument/publishDiagnostics","params":{"diagnostics":[],"uri":"file:///C:/dev/clangd-bug/cpp.cpp","version":0}}\r\n\r\nI[14:47:55.423] --> reply:textDocument/semanticTokens/full(9) 176 ms, error: Task was cancelled.\r\nV[14:47:55.423] >>> {"error":{"code":-32800,"message":"Request cancelled"},"id":9,"jsonrpc":"2.0"}\r\n\r\nV[14:47:55.423] ASTWorker running SemanticHighlights on version 0 of C:\\dev\\clangd-bug\\cpp.cpp\r\nI[14:47:55.423] --> reply:textDocument/semanticTokens/full(10) 52 ms\r\nV[14:47:55.423] >>> {"id":10,"jsonrpc":"2.0","result":{"data":[3,5,16,3,131075,4,5,16,3,131075,4,4,4,3,131075,1,4,3,15,131584,0,5,8,8,131584,0,8,1,22,0,0,9,1,22,0,0,2,1,1,16387],"resultId":"1"}}\r\n\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:55.429] Build dynamic index for header symbols with estimated memory usage of 8470500 bytes\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.507] <<< {"id":11,"jsonrpc":"2.0","method":"textDocument/documentHighlight","params":{"position":{"character":5,"line":3},"textDocument":{"uri":"file:///C:/dev/clangd-bug/cpp.cpp"}}}\r\n\r\n'
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:55.507] <-- textDocument/documentHighlight(11)\r\nV[14:47:55.507] ASTWorker running Highlights on version 0 of C:\\dev\\clangd-bug\\cpp.cpp\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:55.507] --> reply:textDocument/documentHighlight(11) 0 ms\r\n"
[ERROR][2024-04-26 14:47:55] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:55.507] >>> {"id":11,"jsonrpc":"2.0","result":[{"kind":1,"range":{"end":{"character":21,"line":3},"start":{"character":5,"line":3}}}]}\r\n\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:56.708] <<< {"id":12,"jsonrpc":"2.0","method":"textDocument/documentHighlight","params":{"position":{"character":5,"line":1},"textDocument":{"uri":"file:///C:/dev/clangd-bug/cpp.cpp"}}}\r\n\r\nI[14:47:56.708] <-- textDocument/documentHighlight(12)\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:56.711] ASTWorker running Highlights on version 0 of C:\\dev\\clangd-bug\\cpp.cpp\r\nI[14:47:56.711] --> reply:textDocument/documentHighlight(12) 3 ms\r\nV[14:47:56.711] >>> {"id":12,"jsonrpc":"2.0","result":[]}\r\n\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:56.973] <<< {"id":13,"jsonrpc":"2.0","method":"textDocument/definition","params":{"position":{"character":5,"line":1},"textDocument":{"uri":"file:///C:/dev/clangd-bug/cpp.cpp"}}}\r\n\r\nI[14:47:56.973] <-- textDocument/definition(13)\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:56.974] ASTWorker running Definitions on version 0 of C:\\dev\\clangd-bug\\cpp.cpp\r\nI[14:47:56.974] --> reply:textDocument/definition(13) 0 ms\r\nV[14:47:56.974] >>> {"id":13,"jsonrpc":"2.0","result":[{"range":{"end":{"character":0,"line":0},"start":{"character":0,"line":0}},"uri":"file:///C:/dev/clangd-bug/header2.hpp"}]}\r\n\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:56.988] <<< {"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"languageId":"cpp","text":"#pragma once\\r\\n\\r\\n#include \\"header1.hpp\\"\\r\\n\\r\\ninline std::expected<int, int> global2;\\r\\n\\r\\nextern void defined_in_main2();\\r\\n","uri":"file:///C:/dev/clangd-bug/header2.hpp","version":0}}}\r\n\r\nI[14:47:56.988] <-- textDocument/didOpen\r\nI[14:47:56.989] ASTWorker building file C:\\dev\\clangd-bug\\header2.hpp version 0 with command inferred from cpp.cpp\r\n[C:\\dev\\clangd-bug]\r\n"C:\\\\Program Files\\\\LLVM\\\\bin\\\\clang-cl.exe" --driver-mode=cl "-resource-dir=C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18" -- "C:\\\\dev\\\\clangd-bug\\\\header2.hpp"\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:56.990] <<< {"id":14,"jsonrpc":"2.0","method":"textDocument/semanticTokens/full","params":{"textDocument":{"uri":"file:///C:/dev/clangd-bug/header2.hpp"}}}\r\n\r\nI[14:47:56.990] <-- textDocument/semanticTokens/full(14)\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:56.993] Driver produced command: cc1 -cc1 -triple x86_64-pc-windows-msvc19.39.33519 -fsyntax-only -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name header2.hpp -mrelocation-model pic -pic-level 2 -mframe-pointer=none -relaxed-aliasing -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -fms-volatile -funwind-tables=2 -target-cpu x86-64 -mllvm -x86-asm-syntax=intel -tune-cpu generic -D_MT -flto-visibility-public-std --dependent-lib=libcmt --dependent-lib=oldnames -stack-protector 2 -fdiagnostics-format msvc "-fdebug-compilation-dir=C:\\\\dev\\\\clangd-bug" "-fcoverage-compilation-dir=C:\\\\dev\\\\clangd-bug" -resource-dir "C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18" -internal-isystem "C:\\\\Program Files\\\\LLVM\\\\lib\\\\clang\\\\18\\\\include" -internal-isystem "C:\\\\Program Files\\\\Microsoft Visual Studio\\\\2022\\\\Community\\\\VC\\\\Tools\\\\MSVC\\\\14.39.33519\\\\include" -internal-isystem "C:\\\\Program Files\\\\Microsoft Visual Studio\\\\2022\\\\Community\\\\VC\\\\Tools\\\\MSVC\\\\14.39.33519\\\\atlmfc\\\\include" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\ucrt" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\shared" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\um" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\winrt" -internal-isystem "C:\\\\Program Files (x86)\\\\Windows Kits\\\\10\\\\Include\\\\10.0.22621.0\\\\cppwinrt" -fdeprecated-macro -ferror-limit 19 -fno-use-cxa-atexit -fms-extensions -fms-compatibility -fms-compatibility-version=19.39.33519 -std=c++14 -fskip-odr-check-in-gmf -fdelayed-template-parsing -no-round-trip-args -faddrsig -x c++-header "C:\\\\dev\\\\clangd-bug\\\\header2.hpp"\r\n'
[ERROR][2024-04-26 14:47:56] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:56.993] Building first preamble for C:\\dev\\clangd-bug\\header2.hpp version 0\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:57.009] Dropped diagnostic: C:\\dev\\clangd-bug\\header1.hpp: inline variables are a C++17 extension\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"I[14:47:57.010] Built preamble of size 555936 for file C:\\dev\\clangd-bug\\header2.hpp version 0 in 0.02 seconds\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:57.010] --> workspace/semanticTokens/refresh(3)\r\nV[14:47:57.010] >>> {"id":3,"jsonrpc":"2.0","method":"workspace/semanticTokens/refresh","params":null}\r\n\r\n'
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:57.010] <<< {"jsonrpc":"2.0","method":"$/cancelRequest","params":{"id":14}}\r\n\r\nI[14:47:57.010] <-- $/cancelRequest\r\nV[14:47:57.010] <<< {"id":15,"jsonrpc":"2.0","method":"textDocument/semanticTokens/full","params":{"textDocument":{"uri":"file:///C:/dev/clangd-bug/header2.hpp"}}}\r\n\r\n'
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:57.010] <-- textDocument/semanticTokens/full(15)\r\nV[14:47:57.010] <<< {"id":3,"jsonrpc":"2.0","result":null}\r\n\r\nI[14:47:57.010] <-- reply(3)\r\n'
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:57.017] indexed preamble AST for C:\\dev\\clangd-bug\\header2.hpp version 0:\r\n  symbol slab: 1673 symbols, 445608 bytes\r\n  ref slab: 0 symbols, 0 refs, 136 bytes\r\n  relations slab: 0 relations, 24 bytes\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:57.020] Trying to fix unresolved name "expected" in scopes: [std::]\r\n'
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:57.020] Dex query tree: (LIMIT 10000 (& T=xpe T=pec T=cte T=ted T=ect T=exp S=std:: ?=Restricted For Code Completion))\r\nV[14:47:57.021] Dex query tree: (LIMIT 10000 (& T=ted T=xpe T=pec T=cte T=ect T=exp S=std:: ?=Restricted For Code Completion))\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:57.021] indexed file AST for C:\\dev\\clangd-bug\\header2.hpp version 0:\r\n  symbol slab: 2 symbols, 4688 bytes\r\n  ref slab: 2 symbols, 2 refs, 4280 bytes\r\n  relations slab: 0 relations, 24 bytes\r\nV[14:47:57.021] Build dynamic index for main-file symbols with estimated memory usage of 31352 bytes\r\nI[14:47:57.021] --> textDocument/publishDiagnostics\r\nV[14:47:57.021] >>> {\"jsonrpc\":\"2.0\",\"method\":\"textDocument/publishDiagnostics\",\"params\":{\"diagnostics\":[{\"code\":\"no_member_template\",\"message\":\"In included file: no template named 'expected' in namespace 'std'\",\"range\":{\"end\":{\"character\":22,\"line\":2},\"start\":{\"character\":9,\"line\":2}},\"relatedInformation\":[{\"location\":{\"range\":{\"end\":{\"character\":20,\"line\":4},\"start\":{\"character\":12,\"line\":4}},\"uri\":\"file:///C:/dev/clangd-bug/header1.hpp\"},\"message\":\"Error occurred here\"}],\"severity\":1,\"source\":\"clang\"},{\"code\":\"no_member_template\",\"message\":\"No template named 'expected' in namespace 'std' (fix available)\",\"range\":{\"end\":{\"character\":20,\"line\":4},\"start\":{\"character\":12,\"line\":4}},\"relatedInformation\":[],\"severity\":1,\"source\":\"clang\"},{\"code\":\"-Wc++17-extensions\",\"message\":\"Inline variables are a C++17 extension\",\"range\":{\"end\":{\"character\":6,\"line\":4},\"start\":{\"character\":0,\"line\":4}},\"relatedInformation\":[],\"severity\":2,\"source\":\"clang\"},{\"code\":\"unused-includes\",\"codeDescription\":{\"href\":\"https://clangd.llvm.org/guides/include-cleaner\"},\"message\":\"Included header header1.hpp is not used directly (fix available)\",\"range\":{\"end\":{\"character\":22,\"line\":2},\"start\":{\"character\":0,\"line\":2}},\"relatedInformation\":[],\"severity\":2,\"source\":\"clangd\",\"tags\":[1]}],\"uri\":\"file:///C:/dev/clangd-bug/header2.hpp\",\"version\":0}}\r\n\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:57.021] --> reply:textDocument/semanticTokens/full(14) 31 ms, error: Task was cancelled.\r\nV[14:47:57.021] >>> {"error":{"code":-32800,"message":"Request cancelled"},"id":14,"jsonrpc":"2.0"}\r\n\r\nV[14:47:57.021] ASTWorker running SemanticHighlights on version 0 of C:\\dev\\clangd-bug\\header2.hpp\r\nI[14:47:57.021] --> reply:textDocument/semanticTokens/full(15) 11 ms\r\nV[14:47:57.021] >>> {"id":15,"jsonrpc":"2.0","result":{"data":[4,31,7,0,131075,2,12,16,3,131073],"resultId":"1"}}\r\n\r\n'
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:57.045] Build dynamic index for header symbols with estimated memory usage of 8418780 bytes\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:57.248] <<< {"id":16,"jsonrpc":"2.0","method":"textDocument/documentHighlight","params":{"position":{"character":0,"line":0},"textDocument":{"uri":"file:///C:/dev/clangd-bug/header2.hpp"}}}\r\n\r\nI[14:47:57.248] <-- textDocument/documentHighlight(16)\r\n'
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	"V[14:47:57.248] ASTWorker running Highlights on version 0 of C:\\dev\\clangd-bug\\header2.hpp\r\n"
[ERROR][2024-04-26 14:47:57] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'I[14:47:57.249] --> reply:textDocument/documentHighlight(16) 0 ms\r\nV[14:47:57.249] >>> {"id":16,"jsonrpc":"2.0","result":[]}\r\n\r\n'
[ERROR][2024-04-26 14:47:59] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:59.510] <<< {"id":17,"jsonrpc":"2.0","method":"shutdown"}\r\n\r\nI[14:47:59.510] <-- shutdown(17)\r\nI[14:47:59.510] --> reply:shutdown(17) 0 ms\r\nV[14:47:59.510] >>> {"id":17,"jsonrpc":"2.0","result":null}\r\n\r\n'
[ERROR][2024-04-26 14:47:59] .../vim/lsp/rpc.lua:734	"rpc"	"C:\\Program Files\\LLVM\\bin\\clangd.EXE"	"stderr"	'V[14:47:59.518] <<< {"jsonrpc":"2.0","method":"exit"}\r\n\r\nI[14:47:59.518] <-- exit\r\nI[14:47:59.518] LSP finished, exiting with status 0\r\n'

The same log as a file can be found here buggy-lsp-log.txt
The log was recorded with the following scenario:

I opened header1.hpp, the C++ version was set correctly
I opened cpp.cpp file, the C++ version was set correctly
I opened header2.hpp, the C++ version was set incorrectly

@Febbe unfortunately, the Add: -std:c++23 workaround doesn't work at all, whereas Add: -std:c++latest works at least partially

@Febbe unfortunately, the Add: -std:c++23 workaround doesn't work at all, whereas Add: -std:c++latest works at least partially

For me it works, when clang and clangd support c++23 maybe std:c++2b or std=c++23 works?

@Febbe I've tried a lot of configurations (including the ones you suggested) but none of them work.
Which version of clangd do you use?
Is your compile_commands.json file generated for the Microsoft's cl.exe compiler?

@Febbe I've tried a lot of configurations (including the ones you suggested) but none of them work.
Which version of clangd do you use?
Is your compile_commands.json file generated for the Microsoft's cl.exe compiler?

I recently switched to clang-cl for licensing reasons, but previously I generated it for cl.exe instead of clang-cl.exe.
Maybe it works for me, since I always force the generation of a corresponding source file for every lonely header file through cmake 🤔.

The same log as a file can be found here buggy-lsp-log.txt
The log was recorded with the following scenario:

I opened header1.hpp, the C++ version was set correctly
I opened cpp.cpp file, the C++ version was set correctly
I opened header2.hpp, the C++ version was set incorrectly

The log is showing something quite interesting (emphasis mine):

ASTWorker building file C:\dev\clangd-bug\header1.hpp version 0 with command inferred from cpp.cpp
[C:\dev\clangd-bug]
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" --driver-mode=cl /std:c++latest "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\18" -- "C:\\dev\\clangd-bug\\header1.hpp"
...
ASTWorker building file C:\dev\clangd-bug\cpp.cpp version 0 with command
[C:\dev\clangd-bug]
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" --driver-mode=cl /std:c++latest /std:c++latest "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\18" -- "C:\\dev\\clangd-bug\\cpp.cpp"
...
ASTWorker building file C:\dev\clangd-bug\header2.hpp version 0 with command inferred from cpp.cpp
[C:\dev\clangd-bug]
"C:\\Program Files\\LLVM\\bin\\clang-cl.exe" --driver-mode=cl "-resource-dir=C:\\Program Files\\LLVM\\lib\\clang\\18" -- "C:\\dev\\clangd-bug\\header2.hpp"\r\n'

The command for cpp.cpp contains the flag /std:c++latest twice

explanation: one copy is coming from compile_commands.json, and the second from .clangd

The command for header1.hpp contains it once

explanation: the first copy is dropped when transferring the compile command (this bug), this is why the second copy is needed as a workaround

The command for header2.hpp contains is zero times

this I don't understand why, will require additional investigation

The command for header2.hpp contains it zero times

this I don't understand why, will require additional investigation

I have a theory for why: the "transfer compile command" code can run twice as described in (the first half of) this comment. The second time happens after the Add: has been processed and unfortunately drop that copy of the flag too.
So I think fixing the "transfer compile command" code (i.e. this bug) should fix this scenario as well.

I confirm that I have same issue of @sigasigasiga.
My project compile_command.json is generated from CMake using ninja. I use the same workaround with the .clangd Add: ['-std:c++latest']. It works well if i open direcly header or cpp files.
But If I open my cpp file, and then use a go to definition to go to the header file. I got c++23 symbols not recogognised.
Here is my clangd logs :
clangd_issue.log
Here is my compile_commands.json:
compile_commands.json
What I see from my logs is clangd convert well to c++23 (even c++26 on one command 🫨 ).
But when I go to header file, clangd inferred configuration and roll back to c++14.

@Febbe I've tried a lot of configurations (including the ones you suggested) but none of them work. Which version of clangd do you use? Is your compile_commands.json file generated for the Microsoft's cl.exe compiler?

I work with clang-cl.exe in combination with the MSVC-STL, I never use /std:c++latest only /std:c++23


created korean file

added the Korean file and copied down the original English version of README.mediawiki file

Great to the paper is going to be translated in Korean ! Thanks a lot for your help.

Thank you Veronique  - see you in the Ambassador git!


Merge pull request #1599 from Azure/master

Update smoke-test

Docs Build status updates of commit 32c8eb0:
:warning: Validation status: warnings
For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 32c8eb0:
:warning: Validation status: warnings
For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 9cfe6bc:
:warning: Validation status: warnings
For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit 9cfe6bc:
:warning: Validation status: warnings
For more details, please refer to the build report.
If you see build warnings/errors with permission issues, it might be due to single sign-on (SSO) enabled on Microsoft's GitHub organizations. Please follow instructions here to re-authorize your GitHub account to Docs Build.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
Note: Your PR may contain errors or warnings unrelated to the files you changed. This happens when external dependencies like GitHub alias, Microsoft alias, cross repo links are updated. Please use these instructions to resolve them.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit e0ff72e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-mapping/reference-unified.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

Docs Build status updates of commit e0ff72e:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-mapping/reference-unified.yml
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel

@v-alje -- Do we still need this PR or can we close it?

@danieljurek This can be closed.


ubuntu no icon

var iconPath = __dirname + '/app/assets/img/appledisk.png';
function createWindow() {
mainWindow = new BrowserWindow({
width: 1000,
height: 1000,
icon: iconPath
});
when electron start, i see nothing.

See https://github.com/electron-userland/electron-packager/issues/90#issuecomment-225498415 and reply here.

According to the BrowserWindow documentation, the icon argument needs to be a NativeImage, not a path string.
Since this question isn't related to electron-packager, I'm marking it as invalid and closing it.

Use electron-builder to build deb/rpm/etc for Linux — icons will be installed according to https://developer.gnome.org/integration-guide/stable/desktop-files.html.en

Creating a .desktop file shouldn't be necessary for setting an icon - it certainly doesn't for GNOME3. If it's required for Unity, I would be surprised.

I don't understand why a .desktop is necessary now. In pre 1.0 Electron linux icons worked and now they don't. I don't understand what changed and why.


Update user guide

Codecov Report

Merging #198 into master will decrease coverage by 1.32%.
The diff coverage is n/a.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9e57532...1419902. Read the comment docs.


Please add a new "Convert to bound imports" TS refactoring

Suggestion
🔍 Search Terms

unbound named imports
TypeError: Cannot read properties of undefined
convert destructured imports

✅ Viability Checklist

[x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
[x] This wouldn't change the runtime behavior of existing JavaScript code
[x] This could be implemented without emitting different JS based on the types of the expressions
[x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
[x] This feature would agree with the rest of TypeScript's Design Goals.

⭐ Suggestion
It'd be wonderful to support a new refactor action that converts destructed imports (that newly fail under TypeScript 4.4) to an import that avoids unbound function calls:
before
import { addListener, pid } from "process";

addListener("SIGINT", (evt) => {
  console.log(pid + " caught SIGINT", evt);
});

after
import process from "process";

process.addListener("SIGINT", (evt) => {
  console.log(process.pid + " caught SIGINT", evt);
});

📃 Motivating Example
This would greatly reduce the impact from this TypeScript 4.4 change.
💻 Use Cases
See https://github.com/microsoft/TypeScript/issues/46027

I think the biggest issue here is that we don't understand that
import * as process from "process";

process.addListener

is undefined no matter what module target you’re using, because addListener is non-enumerable. But using the default import instead of the namespace import when you have esModuleInterop enabled and the target module is written with as a CJS export = is probably the right thing to do in that refactor regardless... (Of course, the export = here belies what is actually going on under the hood in Node itself... 😐)

This was a refactoring added in TypeScript 3.0, right?
https://devblogs.microsoft.com/typescript/announcing-typescript-3-0/#named-import-refactoring

@andrewbranch @DanielRosenwasser  thanks for replying!
I think we're talking about different things.
I'm trying to deal with the (new) error caused by unbound function calls that I'm seeing with javascript produced by TypeScript 4.4. @andrewbranch  and I discussed it here:  #46027
What I'd like is to either

have a tsconfig option to disable the new TS4.4's generated (0, function)(...args) method invocations, or

add a refactoring action to make converting to bound method import references easier. That's what I'm asking for here.

In the interests of Chesterton's Fence, I'd like to properly understand why y'all made this change, though: Andrew pointed me at meeting notes, but the cure seemed worse than the disease...

@mceachen the error you get with import * as process from "process" is not the same error you get with import { addListener } from "process" and does not share the same root cause. The import * version has nothing to do with the this binding changes in 4.4. Our emit for the import * version is actually correct, because this code does not work in native node ESM:

[alt text]
❯ node --input-type=module -e 'import * as process from "process"; process.addListener("SIGINT", () => {});'
file:///Users/anbranc/Developer/microsoft/eg/[eval1]:1
import * as process from "process"; process.addListener("SIGINT", () => {});
                                            ^

TypeError: process.addListener is not a function
    at file:///Users/anbranc/Developer/microsoft/eg/[eval1]:1:45
    at ModuleJob.run (internal/modules/esm/module_job.js:170:25)
    at async Loader.eval (internal/modules/esm/loader.js:170:24)
    at async internal/process/execution.js:49:24
    at async loadESM (internal/process/esm_loader.js:68:5)

It has always been invalid to write this code in Node, and our CJS emit for this code has exactly the same behavior as Node's ESM behavior—the issue is that we do not prevent you from writing it in any mode. So you’ve turned up two completely separate issues just trying to write this one little piece of code 😄

Syntactically speaking, the refactor we offer you is exactly right, and you end up transforming from one invalid form to another invalid form, neither of which are we capable of noticing is invalid, incredibly. But given that the export we see from process is a CJS export= and you have --esModuleInterop enabled, my hypothesis is that converting to a default import instead of a namespace import is more likely to actually work—we can perhaps have a good chance of taking you from an invalid form to a valid form.

Thanks for the explanation @andrewbranch!
I just found these discussions as well:
https://github.com/evanw/esbuild/issues/1163
https://github.com/microsoft/TypeScript/issues/35420


Icyterm won't start...

I've tried redownloading it and putting it in various locations, and it did work at first, but now when I double click on the executable, nothing happens. .7.6 works fine.

Is there anything in the log file?
help->terminal->open settings dir -> icy_term.log
(Should work with 7.6 to open the log file). The only thing that's changed is that "skypix" got added - can't imagine that this breaks something. However the log may contain the answer.
I've been using 7.7 now several days - seems to work. Which OS are you on?

Windows.
INFO - Starting iCY TERM 0.7.7
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
INFO - shutting down.
INFO - Starting iCY TERM 0.7.7
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
INFO - Starting iCY TERM 0.7.7
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
INFO - shutting down.
INFO - shutting down.
INFO - Starting iCY TERM 0.7.7
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
INFO - Current Locale: [LanguageIdentifier { language: Language(Some("en")), script: None, region: Some(Region("US")), variants: None }]
ERROR - run_update_thread::read_data: Connection aborted
INFO - shutting down.

From: Mike Krüger @.>
Sent: Thursday, May 30, 2024 12:53 AM
To: mkrueger/icy_tools @.>
Cc: martykazmaier @.>; Author @.>
Subject: Re: [mkrueger/icy_tools] Icyterm won't start... (Issue #16)
Is there anything in the log file?
help->terminal->open settings dir -> icy_term.log
(Should work with 7.6 to open the log file). The only thing that's changed is that "skypix" got added - can't imagine that this breaks something. However the log may contain the answer.
I've been using 7.7 now several days - seems to work. Which OS are you on?
—
Reply to this email directly, view it on GitHubhttps://github.com/mkrueger/icy_tools/issues/16#issuecomment-2138806623, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4JLVXS5SXTDDPYCM4UGVD3ZE3EGVAVCNFSM6AAAAABIQGWQXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZYHAYDMNRSGM.
You are receiving this because you authored the thread.Message ID: @.***>

No log entries at all.

From: Mike Krüger @.>
Sent: Thursday, May 30, 2024 6:30 AM
To: mkrueger/icy_tools @.>
Cc: martykazmaier @.>; Author @.>
Subject: Re: [mkrueger/icy_tools] Icyterm won't start... (Issue #16)
Can you try to update the build?
'ERROR - run_update_thread::read_data: Connection aborted…' should've been fixed. Had a bug in the first upload - my local builds used another lib than on the build server.
—
Reply to this email directly, view it on GitHubhttps://github.com/mkrueger/icy_tools/issues/16#issuecomment-2139451299, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4JLVXTB6DYKPUOULKHJVZLZE4LVLAVCNFSM6AAAAABIQGWQXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMZZGQ2TCMRZHE.
You are receiving this because you authored the thread.Message ID: @.***>

tested the 0.7.7 build - not much of an issue.
When you rename or move the settings file (don't delete it) does it work?

I don't see a settings file, what should I look for?

From: Mike Krüger @.>
Sent: Thursday, May 30, 2024 10:13 AM
To: mkrueger/icy_tools @.>
Cc: martykazmaier @.>; Author @.>
Subject: Re: [mkrueger/icy_tools] Icyterm won't start... (Issue #16)
tested the 0.7.7 build - not much of an issue.
When you rename or move the settings file (don't delete it) does it work?
—
Reply to this email directly, view it on GitHubhttps://github.com/mkrueger/icy_tools/issues/16#issuecomment-2140113687, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4JLVXQ5UH5OZOYDR7FMMYDZE5F4PAVCNFSM6AAAAABIQGWQXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQGEYTGNRYG4.
You are receiving this because you authored the thread.Message ID: @.***>

Nevermind, used everything to find icy_term.exe and then checked properties for the location. After renaming the setting file it works!

From: Marty Kazmaier @.>
Sent: Thursday, May 30, 2024 6:05 PM
To: mkrueger/icy_tools @.>
Subject: Re: [mkrueger/icy_tools] Icyterm won't start... (Issue #16)
I don't see a settings file, what should I look for?

From: Mike Krüger @.>
Sent: Thursday, May 30, 2024 10:13 AM
To: mkrueger/icy_tools @.>
Cc: martykazmaier @.>; Author @.>
Subject: Re: [mkrueger/icy_tools] Icyterm won't start... (Issue #16)
tested the 0.7.7 build - not much of an issue.
When you rename or move the settings file (don't delete it) does it work?
—
Reply to this email directly, view it on GitHubhttps://github.com/mkrueger/icy_tools/issues/16#issuecomment-2140113687, or unsubscribehttps://github.com/notifications/unsubscribe-auth/A4JLVXQ5UH5OZOYDR7FMMYDZE5F4PAVCNFSM6AAAAABIQGWQXWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCNBQGEYTGNRYG4.
You are receiving this because you authored the thread.Message ID: @.***>

Then there is something in the settings which caused it. Which is bad :/. I'll review the loading code.

I've reviewed the loading code and made it more stable. That might fix that issue.


examples/dll source type and dependencies

extends https://github.com/webpack/webpack/pull/4749

already merged a while ago


Undefined reference to core::panicking::panic in debug builds

Hi all,
Every time I try to build and Arduino Uno project without the --release flag, my project is unable to link with the panic handler.
error: linking with `avr-gcc` failed: exit code: 1
  |
  = note: "avr-gcc" "-Os" "-mmcu=atmega328p" "-L" "/home/kevlar/.rustup/toolchains/nightly-2021-01-07-x86_64-unknown-linux-gnu/lib/rustlib/avr-atmega328p/lib" "/home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/busted-48e39b52f28b50c4.arduino_uno-aa6bd09237895391.arduino_uno.bng1ym0s-cgu.0.rcgu.o.rcgu.o" "-o" "/home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/busted-48e39b52f28b50c4.elf" "-Wl,--gc-sections" "-L" "/home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps" "-L" "/home/kevlar/Documents/rust-morse/uno/target/debug/deps" "-L" "/home/kevlar/.rustup/toolchains/nightly-2021-01-07-x86_64-unknown-linux-gnu/lib/rustlib/avr-atmega328p/lib" "-Wl,--start-group" "-Wl,--end-group" "-Wl,-Bstatic" "/home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/libcompiler_builtins-22ecd261b63a219e.rlib" "-Wl,-Bdynamic" "-Wl,--gc-sections"
  = note: /home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/libcompiler_builtins-22ecd261b63a219e.rlib(compiler_builtins-22ecd261b63a219e.compiler_builtins.2xqjeibm-cgu.6.rcgu.o): In function `compiler_builtins::int::mul::Mul::mul::hf2ef2c06cb9c88ef':
          /home/kevlar/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.36/src/int/mul.rs:(.text._ZN17compiler_builtins3int3mul3Mul3mul17hf2ef2c06cb9c88efE+0x29e): undefined reference to `core::panicking::panic::h80cbf9e666e18772'
          /home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/libcompiler_builtins-22ecd261b63a219e.rlib(compiler_builtins-22ecd261b63a219e.compiler_builtins.2xqjeibm-cgu.6.rcgu.o): In function `compiler_builtins::int::mul::Mulo::mulo::h1a93e217f9703dd5':
          /home/kevlar/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.36/src/int/mul.rs:(.text._ZN17compiler_builtins3int3mul4Mulo4mulo17h1a93e217f9703dd5E+0x3ac): undefined reference to `core::panicking::panic::h80cbf9e666e18772'
          /home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/libcompiler_builtins-22ecd261b63a219e.rlib(compiler_builtins-22ecd261b63a219e.compiler_builtins.2xqjeibm-cgu.7.rcgu.o): In function `compiler_builtins::int::shift::Ashl::ashl::h1eb3228f4f805c9e':
          /home/kevlar/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.36/src/int/shift.rs:(.text._ZN17compiler_builtins3int5shift4Ashl4ashl17h1eb3228f4f805c9eE+0x150): undefined reference to `core::panicking::panic::h80cbf9e666e18772'
          /home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/libcompiler_builtins-22ecd261b63a219e.rlib(compiler_builtins-22ecd261b63a219e.compiler_builtins.2xqjeibm-cgu.7.rcgu.o): In function `compiler_builtins::int::shift::Ashl::ashl::h828bb5286455f201':
          /home/kevlar/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.36/src/int/shift.rs:(.text._ZN17compiler_builtins3int5shift4Ashl4ashl17h828bb5286455f201E+0x198): undefined reference to `core::panicking::panic::h80cbf9e666e18772'
          /home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/libcompiler_builtins-22ecd261b63a219e.rlib(compiler_builtins-22ecd261b63a219e.compiler_builtins.2xqjeibm-cgu.7.rcgu.o): In function `compiler_builtins::int::shift::Lshr::lshr::h08c3922bd0713bd0':
          /home/kevlar/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.36/src/int/shift.rs:(.text._ZN17compiler_builtins3int5shift4Lshr4lshr17h08c3922bd0713bd0E+0x1f8): undefined reference to `core::panicking::panic::h80cbf9e666e18772'
          /home/kevlar/Documents/rust-morse/uno/target/avr-atmega328p/debug/deps/libcompiler_builtins-22ecd261b63a219e.rlib(compiler_builtins-22ecd261b63a219e.compiler_builtins.2xqjeibm-cgu.1.rcgu.o):/home/kevlar/.cargo/registry/src/github.com-1ecc6299db9ec823/compiler_builtins-0.1.36/src/int/specialized_div_rem/delegate.rs:(.text._ZN17compiler_builtins3int19specialized_div_rem11u64_div_rem17hc28005c952b8fec9E+0x125c): more undefined references to `core::panicking::panic::h80cbf9e666e18772' follow
          collect2: error: ld returned 1 exit status

error: aborting due to previous error; 13 warnings emitted

error: could not compile `busted`

Is this expected behavior? Thank you so much for your help.

Yeah, this is a known behavior, unfortunately.  The problem is that in debug builds, overflow-checks are enabled.  Due to a problem in cargo's build-std, they are not only enabled for your code, but also for the compiler-builtins crate.  This means, the compiler will insert overflow checks into the intrinsics defined in compiler-builtins, which in turn reference the panic handler symbol.  Now due to the way the Rust standard library works, this is not possible (binary object linking order).  That's why you get the errors.
In a non-build-std build, e.g. with a precompiled libcore and compiler-builtins this wouldn't be a problem.
There is a workaround although it isn't really pretty.  To quote a previous comment of mine:

that's a known issue: rust-lang/compiler-builtins#347
There is a dirty workaround to add the following to your Cargo.toml:
[profile.dev.package.compiler_builtins]
overflow-checks = false

cargo will warn about this but it'll still work fine... Alternatively compile in release mode where overflow-checks are always disabled.

One other option would be to disable overflow-checks entirely in debug mode as well (i.e. also for all other crates including your code), but that of course is a dangerous decision.  You'd do this by adding
[profile.dev]
overflow-checks = false

Thank you for your help. I'll use this for now.

Glad I could help!  Let's keep this issue open for visibility until the problem is fixed.


bower_components path is wrong

Started the tutorial v1.3.0-build.2603. The path to bower_components in every index.html is ../bower_components/angular/angular.js. However, bower_components is now installed in the app directory.
hobbit:~/Projects/angular-phonecat% npm -v
1.4.3
hobbit:~/Projects/angular-phonecat% bower -v
1.3.1

I think the paths in the tutorial should be changed. Can I proceed, or did I do something wrong?
EDIT:

also the tests should be updated

@lmorchard morchard it did save me!! Kudos!!


use launch.properties and patches/ from $HOME/.ghidra/

Is your feature request related to a problem? Please describe.
patching ghidra is hard when $GHIDRA_ROOT is read-only
Describe the solution you'd like
when launch.properties and patches/ exist in $HOME/.ghidra/, then use only these files. i hope im missing something and this already works ...?
Describe alternatives you've considered
im building ghidra with nix, so to modify launch.properties and patches/, i have to create a new derivation (by symlinking most files, and patching some files)

What do you need the patches for? I'd argue that this isn't something you should need to do and should be reserved for things like testing fixes without having to rebuild Ghidra.

What do you need the patches for?

for example to increase font size for my hidpi display
-VMARGS_LINUX=-Dsun.java2d.uiScale=1
+VMARGS_LINUX=-Dsun.java2d.uiScale=2

ghidra ignores the env var
VMARGS_LINUX=-Dsun.java2d.uiScale=2 ghidra

What do you need the patches for?

for example to increase font size for my hidpi display
-VMARGS_LINUX=-Dsun.java2d.uiScale=1
+VMARGS_LINUX=-Dsun.java2d.uiScale=2

ghidra ignores the env var
VMARGS_LINUX=-Dsun.java2d.uiScale=2 ghidra

in general, make ghidra more patchable in read-only installs
per FHS, files in /usr should be read-only, and user configs should be in $HOME
for cross-platform paths, see xdg-java

Oh. Looks like I mistook that for the patch folder inside Ghidra. Nevermind.

well ...

use launch.properties and patch/ from $HOME/.ghidra/

so yeah, i also want to override ghidra's patch folder

The team discussed this and we are willing to support a user-specific launch.properties for things like custom display settings, but not a user-specific patch directory which could potentially introduce security concerns.


Add error handling to graph and equations

Part of #338
Description of the changes:

Updates graph control to flag equations if they fail to graph
Updates graph control to flag equations if they successfully graph
Graph control will not try to graph any equations that have previously failed, unless their expression has changed
When graphing an equation that was previously successful, if the graphing fails, we will flag that equation and try graphing again without it
Added UI to indicate that an equation has failed to graph
Some other code tweaks

How changes were validated:

Manual tests

I think you need to also handle the case where the equation is disabled, and then edited.  After it becomes enabled again, it is marked as valid, even if it isn't rendered

/azp run


Switching to a conda interpreter via the kernel switcher fails to install ipykernel if current interpreter is not conda

conda create -n myNewEnv python
Start up an Interactive Window session with a .venv as the selected python interpreter
Via the kernel switcher try to change to myNewEnv
It will ask to install ipykernel into myNewEnv
Choose to install with conda
Result:

The default interactive shell is now zsh.
To update your account to use zsh, please run chsh -s /bin/zsh.
For more details, please visit https://support.apple.com/kb/HT208050.
Ians-MacBook-Pro:DebuggingDemo ianhuff$ source /Users/ianhuff/Documents/DataScience/DebuggingDemo/.debugEnv/bin/activate
(.debugEnv) Ians-MacBook-Pro:DebuggingDemo ianhuff$ /Users/ianhuff/Documents/DataScience/DebuggingDemo/.debugEnv/bin/python /Users/ianhuff/GitHub/vscode-python-ianhu/pythonFiles/pyvsc-run-isolated.py /Users/ianhuff/GitHub/vscode-python-ianhu/pythonFiles/shell_exec.py /Users/ianhuff/opt/miniconda3/bin/conda install --name kernelSwitchEnv4 ipykernel -y /var/folders/q7/cn8fg6s94fgdcl0h7rbxldf00000gn/T/tmp-13674iJ9OcUzhf3Qj.log
Executing command in shell >> /Users/ianhuff/opt/miniconda3/bin/conda install --name kernelSwitchEnv4 ipykernel -y
Traceback (most recent call last):
File "/Users/ianhuff/opt/miniconda3/bin/conda", line 12, in
from conda.cli import main
ModuleNotFoundError: No module named 'conda'
Traceback (most recent call last):
File "/Users/ianhuff/GitHub/vscode-python-ianhu/pythonFiles/shell_exec.py", line 26, in
subprocess.check_call(shell_args, stdout=sys.stdout, stderr=sys.stderr)
File "/Library/Frameworks/Python.framework/Versions/3.7/lib/python3.7/subprocess.py", line 363, in check_call
raise CalledProcessError(retcode, cmd)
subprocess.CalledProcessError: Command '['/Users/ianhuff/opt/miniconda3/bin/conda', 'install', '--name', 'kernelSwitchEnv4', 'ipykernel', '-y']' returned non-zero exit status 1.

In my quick debug into this looked like syncTerminalService.sendCommand was interesting. If you remove the cancel token the install will actually go forward and complete, but it was not able to connect after that.

Tried this as well, and works for me.
I think its a setup issue, looking at the output from our terminal looks like conda isn't setup properly
Executing command in shell >> /Users/ianhuff/opt/miniconda3/bin/conda install --name kernelSwitchEnv4 ipykernel -y
Traceback (most recent call last):
File "/Users/ianhuff/opt/miniconda3/bin/conda", line 12, in
from conda.cli import main
ModuleNotFoundError: No module named 'conda'
Traceback (most recent call last):


Is a bind type of write-only possible?

Hi!
The browser-container-launcher.sh for example mounts Pictures as read-only. But if we are worried about browser bugs leading to exfiltration of data, even read-only is harmful (making the distinction between read-only and full kind of moot).

Hi Oliver,
If you want to hide files from the browser, you should not map them at all. By default none of your home directory is visible in the container, except for the directories you specify to map in.
A "write-only" mapping in theory could make sense if you wanted to let the browser save downloads to some directory without being able to read any of the existing downloads. However, AFAIK there is no such thing as a write-only bind mapping, so I don't think this is something home-container can implement easily.

A "write-only" mapping in theory could make sense if you wanted to let the browser save downloads to some directory without being able to read any of the existing downloads.

This is what I was thinking about.

However, AFAIK there is no such thing as a write-only bind mapping, so I don't think this is something home-container can implement easily.

Thank you for explaining.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


No phar file to upload

hi - i tried to install this plugin by downloading the contents as zip file and uploaded either by individual files to /plugins folder or by the zip file renamed as .phar file in to this directory.
but none works. It doesnt show in the list of plugins in my OSticket admin panel.
How dio i bring in the phar file to this plugins directory?

You need to create a subfolder on your plugins directory, and put the php files on it. Set the permissions accordingly. I had to edit the plugin.php to close the php statement by adding ?> at the end of the file.


Implement Multithreading for speedup in some situations

I've started a fork that aims to take advantage of multiple cores present in modern and higher end computers.
https://github.com/jedbrooke/auto-editor/tree/batch
So far results show a 5% speedup in some cases, to as much as 80% in others.
A more detailed analysis is present in batch.txt

#208


make it possible to run Dialer and Listener on the same UDP socket

Not sure yet how we can make this work, but it'd be a nice feature.

I don't understand what you want to do here and why ^^

This would be useful for protocols that rely on stun for NAT punchthrough.
It would be awesome if this existed, yet it can be done outside of the library if quic framing is deterministic and sessions are easily identifiable with each Write() call.
We already do something simillar in syncthing and kcp where we have a single UDP connection and then filter incoming stun and KCP traffic based on the signatures into virtual connections using something like https://github.com/AudriusButkevicius/pfilter.
net.PacketConn ->

Good news. It looks like with the current new QUIC header format, this will be possible.

Superb! Are there plans to suppprt this feature in this implementation?

Sure, that's what this issue is there for ;)
I don't have a timeline yet though.

It's probably the most complicated issues we currently have.
I've been working on #1324, which is a subset of this issue, and I already spent two complete days refactoring stuff, and it's still a long way to go...

Given the multiplexer is now merged, would it be possible to reuse the multiplexer for mixing server and client sockets?
My idea is have a type exposed:
type Multiplexer interface {
     Accept() (Session, error)
     Dial(...) (Session, error)
     ReadFrom([]byte) (int, net.Addr, error)
}

It would work as follows:

Dial normally registers the connection with the mux, and forward connections to the right session.
Any valid quic packets sent for sessions the mux is not aware of, would go onto an Accept queue, which can be consumer by calling Accept(), at which point they would get registered with the mux. Not sure that everything that is needed for newsession is available at that point.
Any non-quic packets would go on to the backlog channel, which can then be consumer by calling ReadFrom(), this way we can piggyback stun on the same net.PacketConn.

Header parsing is currently a mess, which is blocking this issue. There are just too many different header formats at the moment...
The cool thing is, we won't need any new API for this: You'll just pass the same packet conn to Dial and to Listen, and things will work automatically.
Regarding the additional ReadFrom call you're suggesting, I'm not sure if that's necessary. The IETF QUIC packet header was designed to allow demultiplexing of commonly used UDP based protocols, so in the most cases you can decide just by looking at the first byte of a packet if this is a QUIC packet or not. If you use a preallocated buffer for reading from the connection, this should be very cheap both in terms of allocations as well as packet processing. Or am I missing something?

will work

I am trying to understand what is left to do to support this, as I suspect currently Listen part of the socket might read a packet which is meant to be delivered to a session that was acquired by Dial, essentially causing the packet to be dropped (or being interpreted as a new SYN)

Yes, that's the problem. We currently have a wire.ParseHeaderSentByServer and wire.ParseHeaderSentByClient, and these are required for parsing the gQUIC Public Header. If you want to have a server and a client on a packet conn, obviously you won't know who sent the packet in advance.


Push latest changes from MCH-APN for a 0.2 release

I think it is nice to push our current change in order to make a 0.2 release before the changes from Fabian will come in.

All the changes were approved in the MeteoSwiss-APN forks so I merge it directly.


The response panel hangs indefinitely when using the Repeat on Interval function

Expected Behavior
The response from the api call should be shown in the response panels.
Actual Behavior
The response pane hangs when the request is sent,  the api being tested here typically responds in around 30ms

Reproduction Steps

Create a new GraphQL Request
Enter https://countries.trevorblades.com/ as the POST url
Enter the following graphql as the query body

query ListCountriesInNAFTA {
  countries(filter: { code: { in: ["US", "CA", "MX"] } }) {
    code
    name
    languages {
      name
    }
  }
}

The typical response times for this api are 30ms

Set the Repeat on Interval to 0.15
Press Send

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Additional Information
This is not limited to GraphQL requests. I have a number of private slow json based apis that respond in the 1 - 3 second time range, setting a repeat on interval value between 0.5-0.9 causes the same behaviour with those endpoints.
From examining the console logs, the requests/responses do appear to be proceeding, but the user interface never updates beyond the initial progress spinner and ultimately you need to cancel the requests.
HTTP/2 Preferred and a response timeout of 30000ms is set.
Insomnia Version
8.4.5
What operating system are you using?
Ubuntu
Operating System Version
6.2.0-37-generic # 38~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Thu Nov  2 18:01:13 UTC 2 x86_64 x86_64 x86_64 GNU/Linux
Installation method
deb package
Last Known Working Insomnia version
No response

FYI, from my side, the time interval should start from the previous request response.
Additionally, it's more intuitive to request immediately upon button click.


The software is always in the foreground

Issue Type: Bug
Hi,
I am using the Visual Studio Code insider program.
Once I opened the software, it is working as expected however I can not switch to any other application as it is located on top of all the other windows. It doesn't go to the background.
Details :

It occurs only when launched as an administrator
I can minimize the application and then I am able again to use the rest of the applications
When two or more windows of Visual Studio Code are opened, I can switch between by clicking on them but not with other applications
Minimizing by clicking on the window's taskbar is not working too, only on the icon on top of the window

VS Code version: Code - Insiders 1.43.0-insider (beaf391bc53136912e4f0bbdfb7844ad954247db, 2020-02-07T05:29:40.363Z)
OS version: Windows_NT x64 10.0.19041
Remote OS version: Linux x64 4.19.84-microsoft-standard

System Info

Item
Value

CPUs
Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz (4 x 2400)

GPU Status
2d_canvas: enabledflash_3d: enabledflash_stage3d: enabledflash_stage3d_baseline: enabledgpu_compositing: enabledmultiple_raster_threads: enabled_onoop_rasterization: disabled_offprotected_video_decode: unavailable_offrasterization: enabledskia_renderer: disabled_off_okvideo_decode: enabledviz_display_compositor: enabled_onviz_hit_test_surface_layer: disabled_off_okwebgl: enabledwebgl2: enabled

Load (avg)
undefined

Memory (System)
7.92GB (1.22GB free)

Process Argv

Screen Reader
no

VM
0%

Item
Value

Remote
WSL: Ubuntu

OS
Linux x64 4.19.84-microsoft-standard

CPUs
Intel(R) Core(TM) i5-6200U CPU @ 2.30GHz (4 x 2399)

Memory (System)
6.13GB (4.42GB free)

VM
0%

Extensions (14)

Extension
Author (truncated)
Version

remote-wsl
ms-
0.42.3

vscode-markdownlint
Dav
0.34.0

gitlens
eam
10.2.0

prettier-vscode
esb
3.20.0

vscode-wordcount-cjk
hol
1.3.1

latex-workshop
Jam
8.7.1

python
ms-
2020.3.62366-dev

vscode-yaml
red
0.6.1

markdown-preview-enhanced
shd
0.5.2

code-spell-checker
str
1.7.22

code-spell-checker-french
str
0.1.6

pdf
tom
0.5.1

vscodeintellicode
Vis
1.2.5

markdown-all-in-one
yzh
2.7.0

Is this still an issue with latest insiders https://code.visualstudio.com/insiders ?


Blight Maps pull up the Blight Gems

As the title states, searching a Blight Map pulls up the Blight gem.

I'll add a category check within the next upcoming version. Thanks for reporting.

0.4.2 now has category filter.


Add orbit tokens and universal components

closes #55

Can we use components from universal-component?
In this PR I can see that you use just stylesheet.

Of course we can

I can start replacing other components in next PR


merging from fork

Make sure you have checked all steps below.
Jira

[ ] My PR addresses the following Airflow Jira issues and references them in the PR title. For example, "[AIRFLOW-XXX] My Airflow PR"

https://issues.apache.org/jira/browse/AIRFLOW-XXX
In case you are fixing a typo in the documentation you can prepend your commit with [AIRFLOW-XXX], code changes always need a Jira issue.
In case you are proposing a fundamental code change, you need to create an Airflow Improvement Proposal (AIP).
In case you are adding a dependency, check if the license complies with the ASF 3rd Party License Policy.

Description

[ ] Here are some details about my PR, including screenshots of any UI changes:

Tests

[ ] My PR adds the following unit tests OR does not need testing for this extremely good reason:

Commits

[ ] My commits all reference Jira issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":

Subject is separated from body by a blank line
Subject is limited to 50 characters (not including Jira issue reference)
Subject does not end with a period
Subject uses the imperative mood ("add", not "adding")
Body wraps at 72 characters
Body explains "what" and "why", not "how"

Documentation

[ ] In case of new functionality, my PR adds documentation that describes how to use it.

All the public functions and the classes in the PR contain docstrings that explain what it does
If you implement backwards incompatible changes, please leave a note in the Updating.md so we can assign it to a appropriate release

Codecov Report

Merging #5 into master will decrease coverage by 51.51%.
The diff coverage is 24.98%.

@@             Coverage Diff             @@
##           master       #5       +/-   ##
===========================================
- Coverage   84.08%   32.57%   -51.52%
===========================================
  Files         639      896      +257
  Lines       36900    42790     +5890
===========================================
- Hits        31028    13937    -17091
- Misses       5872    28853    +22981

Impacted Files
Coverage Δ

airflow/contrib/operators/docker_swarm_operator.py
0% <ø> (-96.67%)
:arrow_down:

airflow/contrib/hooks/vertica_hook.py
0% <ø> (-50%)
:arrow_down:

...w/contrib/operators/gcp_speech_to_text_operator.py
0% <ø> (-100%)
:arrow_down:

...irflow/contrib/operators/redis_publish_operator.py
0% <ø> (-100%)
:arrow_down:

airflow/contrib/hooks/qubole_hook.py
0% <ø> (-55.64%)
:arrow_down:

airflow/contrib/operators/awsbatch_operator.py
0% <ø> (-78.41%)
:arrow_down:

...w/contrib/operators/sagemaker_training_operator.py
0% <ø> (-100%)
:arrow_down:

...rflow/contrib/operators/sagemaker_base_operator.py
0% <ø> (-91.67%)
:arrow_down:

airflow/contrib/hooks/salesforce_hook.py
0% <ø> (-91.79%)
:arrow_down:

...irflow/contrib/operators/gcp_container_operator.py
0% <ø> (-100%)
:arrow_down:

... and 1187 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 22da960...42eef38. Read the comment docs.