text:
Fix memory leaks in compile webworker

Fixes https://github.com/microsoft/pxt-arcade/issues/3931
This fixes the memory leak in pxtworker that was causing us to crash the tab (and sometimes all of chrome) by running out of memory.
During a compile we annotate the TS ast with a bunch of information for our compiler. To support incremental compilation, we also store references to functions that we can call again when re-emitting the nodes. The closures for these functions were causing a reference to the Binary object to stick around, which in turn was referencing CompileOptions (which contains the entire source of the program) and CompileResult (which includes the text of the emitted binary.js). All together this amounted to many mbs of strings being allocated every time the compiler was invoked.
This PR removes the binary's references to CompileResult and CompileOptions.
I also ended up hoisting some of the recordAction functions because they were causing references to the binary and compile result to stick around. I'm not sure why that is, because they don't appear to be referenced inside the function bodies, but this fixes that issue regardless.

@jwunderl removed! and yeah, we'll see! I'd totally believe there is something else going on too.

🥳

authors: abchatra riknoll

repo: microsoft/pxt


text:
Add github action to docs

Closes #154

Codecov Report

Merging #157 (b3666e4) into main (567b5ad) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##             main     #157   +/-   ##
=======================================
  Coverage   95.66%   95.66%
=======================================
  Files          33       33
  Lines        1868     1868
=======================================
  Hits         1787     1787
  Misses         81       81

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 567b5ad...b3666e4. Read the comment docs.

awaiting changes to github action before approval/merge is completed.

@leestott this is ready for review/merge

source: gharchive/pull-request

authors: chrispyles codecov-commenter leestott

repo: microsoft/pybryt

license: MIT

license_type: permissive

license_source: github-api


text:
Symbol range incorrect for functions and classes

 Environment data

Language Server version: 2021.2.4
OS and version: darwin x64
Python version (and distribution if applicable, e.g. Anaconda):
python.analysis.indexing: undefined
python.analysis.typeCheckingMode: off

 Expected behaviour
When calling documentSymbol.range, I'd expect it to return the exact range of the function, eg

 Actual behaviour
It returns the range of the function and part of the next few lines:

 Logs

Python Language Server Log
[Info  - 4:03:04 PM] Pylance language server 2021.2.4 (pyright a18e6fb4) starting
[Info  - 4:03:04 PM] Server root directory: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist
[Info  - 8:32:05 PM] No configuration file found.
[Info  - 8:32:05 PM] Setting pythonPath for service "pokey_talon": "/usr/local/opt/python@3.9/bin/python3.9"
Search paths found for configured python interpreter:
  /usr/local/Cellar/python@3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9
  /usr/local/Cellar/python@3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/lib-dynload
  /Users/pokey/Library/Python/3.9/lib/python/site-packages
  /usr/local/lib/python3.9/site-packages
  /usr/local/Cellar/protobuf/3.14.0/libexec/lib/python3.9/site-packages
[Info  - 8:32:05 PM] Assuming Python version 3.9
[Info  - 8:32:05 PM] Assuming Python platform Darwin
[Info  - 8:32:05 PM] Searching for source files
[Info  - 8:32:05 PM] Found 82 source files
Background analysis message: setConfigOptions
Background analysis message: setTrackedFiles
Background analysis message: markAllFilesDirty
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/apps/vscode/command_client.py (24ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/builtins.pyi [fs read 1ms] (41ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/builtins.pyi (16ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/apps/vscode/command_client.py (2ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/queue.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/queue.pyi (1ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi [fs read 0ms] (6ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi (1ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/typing.pyi [fs read 2ms] (13ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/typing.pyi (8ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stubs/typing-extensions/typing_extensions.pyi [fs read 0ms] (2ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stubs/typing-extensions/typing_extensions.pyi (1ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/threading.pyi [fs read 0ms] (5ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/threading.pyi (3ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/time.pyi [fs read 0ms] (2ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/time.pyi (1ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/__init__.pyi [fs read 0ms] (19ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/__init__.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/__init__.pyi [fs read 1ms] (2ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/__init__.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/context.pyi [fs read 1ms] (11ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/context.pyi (2ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/module.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/module.pyi (0ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/datetime.pyi [fs read 1ms] (3ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/datetime.pyi (2ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/pathlib.pyi [fs read 1ms] (2ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/pathlib.pyi (1ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/os/__init__.pyi [fs read 1ms] (7ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/os/__init__.pyi (3ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/abc.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/abc.pyi (0ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/json/__init__.pyi [fs read 1ms] (1ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/json/__init__.pyi (2ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/app.pyi [fs read 1ms] (3ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/app.pyi (1ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/enum.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/enum.pyi (0ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/dataclasses.pyi [fs read 0ms] (0ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/dataclasses.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/actions.pyi [fs read 1ms] (2ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/actions.pyi (0ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/json/encoder.pyi [fs read 0ms] (0ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/json/encoder.pyi (0ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/io.pyi [fs read 1ms] (5ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/io.pyi (3ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/types.pyi [fs read 0ms] (4ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/types.pyi (2ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/registry.pyi [fs read 1ms] (2ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/registry.pyi (3ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/dispatch.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/dispatch.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/types.pyi [fs read 0ms] (2ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/types.pyi (1ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/apps/vscode/vscode.py (3ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/apps/vscode/vscode.py (2ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/socket.pyi [fs read 1ms] (6ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/socket.pyi (3ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/scope.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/scope.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/match.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/match.pyi (0ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/code/code.py (3ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/code/code.py (1ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/settings.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/scripting/settings.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/imgui.pyi [fs read 0ms] (5ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/imgui.pyi (2ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/code/parrot.py (0ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/code/parrot.py (1ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/apps/mac/safari.py (0ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/apps/mac/safari.py (0ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/apps/mac/things3.py (2ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/apps/mac/things3.py (0ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/code/tabs.py (0ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/code/tabs.py (0ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/apps/slack/slack.py (0ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/apps/slack/slack.py (0ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/code/todo_list.py (0ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/code/todo_list.py (0ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/code/find_and_replace.py (0ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/code/find_and_replace.py (0ms)
Background analysis message: getSemanticTokens
[BG(1)] parsing: /Users/pokey/src/pokey_talon/code/switcher.py (2ms)
[BG(1)] binding: /Users/pokey/src/pokey_talon/code/switcher.py (2ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/re.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/re.pyi (1ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/os/path.pyi [fs read 0ms] (2ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/os/path.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/ui.pyi [fs read 0ms] (6ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/ui.pyi ...
[BG(1)]   parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/mac/ui.pyi [fs read 0ms] (1ms)
[BG(1)]   binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/mac/ui.pyi (1ms)
[BG(1)]   parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/linux/ui.pyi [fs read 0ms] (2ms)
[BG(1)]   binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/linux/ui.pyi (0ms)
[BG(1)]   parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/windows/ui.pyi [fs read 0ms] (5ms)
[BG(1)]   binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/windows/ui.pyi (0ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/ui.pyi (11ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/fs.pyi [fs read 0ms] (3ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/fs.pyi (0ms)
[BG(1)] parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/system.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/system.pyi (0ms)
[BG(1)] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/posix.pyi [fs read 0ms] (1ms)
[BG(1)] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/posix.pyi (2ms)
Background analysis message: analyze
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/mac/safari.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/apps/mac/safari.py ...
[BG(1)]     parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/ctrl.pyi [fs read 1ms] (7ms)
[BG(1)]     binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/ctrl.pyi ...
[BG(1)]       parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/mac/ctrl.pyi [fs read 1ms] (1ms)
[BG(1)]       binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/mac/ctrl.pyi (0ms)
[BG(1)]       parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/linux/ctrl.pyi [fs read 0ms] (4ms)
[BG(1)]       binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/linux/ctrl.pyi (0ms)
[BG(1)]       parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/windows/ctrl.pyi [fs read 1ms] (2ms)
[BG(1)]       binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/windows/ctrl.pyi (1ms)
[BG(1)]     binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/ctrl.pyi (9ms)
[BG(1)]     parsing: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/clip.pyi [fs read 0ms] (2ms)
[BG(1)]     binding: /Applications/Talon.app/Contents/Resources/python/lib/python3.9/site-packages/talon/clip.pyi (0ms)
[BG(1)]   checking: /Users/pokey/src/pokey_talon/apps/mac/safari.py (19ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/mac/safari.py (19ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/slack/slack.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/apps/slack/slack.py (0ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/slack/slack.py (0ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/vscode/command_client.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/apps/vscode/command_client.py (3ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/vscode/command_client.py (3ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/vscode/vscode.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/apps/vscode/vscode.py (8ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/vscode/vscode.py (8ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/code.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/code/code.py (11ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/code.py (11ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/find_and_replace.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/code/find_and_replace.py (1ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/find_and_replace.py (1ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/parrot.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/code/parrot.py (1ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/parrot.py (1ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/switcher.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/code/switcher.py (10ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/switcher.py (10ms)
Background analysis message: resumeAnalysis
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/tabs.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/code/tabs.py (0ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/tabs.py (0ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/mac/things3.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/apps/mac/things3.py (1ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/apps/mac/things3.py (1ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/todo_list.py ...
[BG(1)]   checking: /Users/pokey/src/pokey_talon/code/todo_list.py (1ms)
[BG(1)] analyzing: /Users/pokey/src/pokey_talon/code/todo_list.py (1ms)
Background analysis message: resumeAnalysis
Background analysis message: getDiagnosticsForRange
Background analysis message: getDiagnosticsForRange
[FG] parsing: /Users/pokey/src/pokey_talon/code/switcher.py (19ms)
[FG] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/builtins.pyi [fs read 0ms] (52ms)
[FG] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/builtins.pyi (17ms)
[FG] binding: /Users/pokey/src/pokey_talon/code/switcher.py (2ms)
[FG] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi [fs read 0ms] (7ms)
[FG] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/_typeshed/__init__.pyi (0ms)
[FG] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/typing.pyi [fs read 0ms] (19ms)
[FG] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/typing.pyi (3ms)
[FG] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stubs/typing-extensions/typing_extensions.pyi [fs read 0ms] (2ms)
[FG] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stubs/typing-extensions/typing_extensions.pyi (0ms)
[FG] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/re.pyi [fs read 0ms] (5ms)
[FG] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/re.pyi (0ms)
[FG] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/abc.pyi [fs read 0ms] (0ms)
[FG] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/abc.pyi (0ms)
[FG] parsing: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/enum.pyi [fs read 0ms] (1ms)
[FG] binding: /Users/pokey/.vscode/extensions/ms-python.vscode-pylance-2021.2.4/dist/typeshed-fallback/stdlib/enum.pyi (1ms)
[FG] parsing: /usr/local/Cellar/python@3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/re.py [fs read 1ms] (16ms)
[FG] binding: /usr/local/Cellar/python@3.9/3.9.1/Frameworks/Python.framework/Versions/3.9/lib/python3.9/re.py (2ms)
Background analysis message: getDiagnosticsForRange
Background analysis message: getDiagnosticsForRange
Background analysis message: getDiagnosticsForRange
Background analysis message: getDiagnosticsForRange
Background analysis message: getDiagnosticsForRange
Background analysis message: getDiagnosticsForRange

 Code Snippet / Additional information

XXX

Out of curiosity, how did you obtain the highlighting like that?

https://marketplace.visualstudio.com/items?itemName=pokey.semantic-movement

Thanks for the bug report and repro steps. This will be fixed in the next release.
Here's the change if you're interested: https://github.com/microsoft/pyright/commit/c575ed0790132eb861cae1680b0e92653a2573e9

Awesome thanks!

We'll leave the bug open until the fix is released.

Well that seems awfully responsible 😄

This issue has been fixed in version 2021.3.1, which we've just released. You can find the changelog here: https://github.com/microsoft/pylance-release/blob/main/CHANGELOG.md#202131-10-march-2021

Confirmed fixed; thanks!

source: gharchive/issue

authors: erictraut jakebailey pokey

repo: microsoft/pylance-release


text:
Cannot "Go to Definition" for files in Python Eggs

Environment data

Language Server version: Every version after 2021.5.4; 2021.5.4 and before work correctly
OS and version: Windows 10
Python version (& distribution if applicable, e.g. Anaconda): Miniconda, Python 3.8.2

Expected behaviour
In PyLance 2021.5.4 and before, when I do the command "Go to Definition" (right click on the function and then the first dropdown link), it works as intended and creates a separate tab in VSCode where the highlighted code is defined.
Actual behaviour
When I do the command "Go to Definition"  for something like
from InternalPackage.utility.log import Log

where package would be in a Python egg
home/acho/miniconda3/envs/env_name/lib/python3.8/site-packages/internal_package-2.1.2.300-py3.8.egg/InternalPackage/utility/log
I would expect this to work, but instead, PyLance throws "No Definition Found".
PyLance does recognize the correct type for imported classes and signature for functions.
Code Snippet / Additional information
So this works correctly in 2021.5.4 and previous version. However, there was a breaking change made in 2021.6.0

If the file is in an egg, there's no file on disk that VS Code can open, so we don't allow navigation there. Allowing navigation causes VS Code to throw an error that the file isn't found.
I'm not sure how this would have been working on versions that predate egg support; necessarily, if this module is in an egg, and we entirely ignored eggs, we wouldn't have been able to resolve the import. The only way that navigation would have been working is if there was another module of the same name that was being resolved (which would actually be the wrong module, given the egg is resolving it now).

Where does go to def go in the older version? Somewhere else?

the def goes to the correct place in the older versions, ie the 2021.6.0 introduced an update that regressed this functionality for me

Is that .egg a file, or a folder? I can only think that you can browse to it previously if it's a folder, in which case it's interesting that it's not a file.

The .egg in the example is a folder
the site-packages contains a bunch of folders and files that represent packages (e.g. flake8, pip, wheel, jupyter)
a .egg can be a file or a folder, but in the example above, it is a folder that contains the package contents

I see; I didn't realize that eggs would be folders (not quite sure of the point of them at that point compared to regularly installed modules, but...).

Eggs being folders is to support Python bindings in C/C++ without compilation, allow for easy import, and allow easy upgrades because it is self-contained

Sure, but one can achieve the same things with packages installed normally in site-packages versus nested in egg folders. (I'm honestly surprised anyone uses eggs these days when wheels have been the standard for a while).
Anyway, it's a bug that we ignore eggs that aren't files.

Oh gotcha. Was not aware of wheels vs eggs.
Thank you for the help!

This should be fixed in the next release.

We typically leave issues open until the fix is released; reopening.

authors: choandrew jakebailey


text:
PyLance does not seem to understand subpackage imports

 Environment data

Language Server version: 2022.10.20
OS and version: win32 x64
Python version (and distribution if applicable, e.g. Anaconda):
python.analysis.indexing: false
python.analysis.typeCheckingMode: off

 Code Snippet
site-packages/kubernetes/__init__.py:
import kubernetes.client

main.py:

import kubernetes

kubernetes.client  # PyLance does not know what `client` is

 Expected behavior
I expect PyRight to understand the implications of the import kubernetes.client imports (client attribute being added to the kubernetes module).
 Actual behavior

Thank you for the information. I've inferred the first workaround and proposed a patch https://github.com/kubernetes-client/python/pull/1935
Just curious: Why is the first form not possible to analyze?
import kubernetes.client

vs.
from . import client

At the first glance the first form seems more predictable: client attribute becomes available on top-level kubernetes module. The module path is rooted. With the second form we are not 100% sure which module paths the client would be added to.


text:
[WIP] Fix import * over local declarations

Fixes #1257.
Cherry picked out of #1429.

WIP until FromImportMultiValues test is fixed.

Test suite passes with that extra commit.

repo: microsoft/python-language-server


text:
API for appending data

❓ Questions and Help
According to the paper, appending data should be super easy using qlib data format.
Is there any documentation about how to use this feature?
BTW:
Is there any api to write dataframes into the data store directly?
We would like to use the data store in a more interactive way, e.g., read some data from the data store, transform it, then write the result back to the data store using a different identifier.
Thanks in advance!

@qiuwei
The data are stored as bytes on the disk
You can update the data by appending bytes directly.
We have an internal version scripts for updating data, but they are not readly enough for opensource.

authors: qiuwei you-n-g

repo: microsoft/qlib


text:
Update target xrefs in Extensions.cs

Problem: Customer reported broken links in the API docs.
Cause: Tags were being resolved to xrefs for topics that hadn't been published yet, and have since had their content moved.
Fix: Update xrefs with location of correct live content.

@Bradben @cgranade Is this PR still needed?

@bettinaheim - yes, this still needs to be merged.

/azp run

authors: Bradben bettinaheim

repo: microsoft/qsharp-compiler


text:
Q# 2.0 Tracking Issue

This issue tracks the tasks we'd like to have done before the release of Q# 2.0.

[ ] #2048
[ ] Deprecate Explicit Namespaces (no issue yet)
[ ] Deprecate use qubit blocks
[ ] Deprecate w/ syntax
[ ] Old UDT syntax
[ ] Deprecate Microsoft.Quantum.* libraries
[ ] remove set keyword (see https://github.com/microsoft/qsharp/issues/1496)
[ ] remove ... syntax from specialization definitions

Process of Upgrading Q# Syntax
For anything breaking, primarily the removal or modification of existing Q# syntax, we want to be in the following state before Q# 2.0:

A lint warning will inform the user that something is deprecated.
The v2-preview-syntax feature flag allows the user to opt-in to v2 syntax, meaning that the aforementioned lints become compile errors.
There needs to be a clearly documented path to go from deprecated syntax to v2 syntax. Ideally, there's also a quick fix attached to the lint to make this even easier.

We should define a minimum deprecation time period such that items are deprecated for at least that long before they are removed. During this period, there should also be new syntax available.

repo: microsoft/qsharp


text:
Don't install boost twice

Please select one of the following

[x] I am removing an existing difference between facebook/react-native and microsoft/react-native-macos :thumbsup:
[ ] I am cherry-picking a change from Facebook's react-native into microsoft/react-native-macos :thumbsup:
[ ] I am making a fix / change for the macOS implementation of react-native
[ ] I am making a change required for Microsoft usage of react-native

Summary
There exists boost and boost-for-react-native, the latter of which was just a copy of boost. RN Core used to use the latter, but stopped doing so with this commit: https://github.com/facebook/react-native/commit/b77948e33bc5e0df422fffca3b4c9253f611d298
We however, kept installing both. We probably shouldn't install boost twice. That should also greatly improve pod install times.
Changelog
[Internal] [Removed] - Removed extra copy of boost
Test Plan
CI should pass.

@ZihanChen-MSFT Would you know why the CXX-Turbomodule podspec is failing to build?

the CI failure seems legit after your boost change

the CI failure seems legit after your boost change

Agreed, thats why I tested the author of the podspec that fails.

This passes now :) , ScreenshotManager.podspec did need boost in the header search path

authors: Saadnajmi harrieshin

repo: microsoft/react-native-macos


text:
Add treatment bar chart

Code refactoring & add treatment bar chart

Areas changed

npm packages changed:

[ ] responsibleai/causality
[x] responsibleai/core-ui
[ ] responsibleai/counterfactuals
[ ] responsibleai/dataset-explorer
[ ] responsibleai/fairness
[ ] responsibleai/interpret
[ ] responsibleai/localization
[ ] responsibleai/mlchartlib
[ ] responsibleai/model-assessment

Python packages changed:

[ ] raiwidgets
[ ] responsibleai
[ ] erroranalysis
[ ] rai_core_flask

Tests

[ ] No new tests required.
[ ] New tests for the added feature are part of this PR.
[ ] I validated the changes manually.

Screenshots (if appropriate):
Documentation:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly.

Codecov Report

Merging #1184 (66c23ba) into main (39a7ff8) will increase coverage by 7.81%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##             main    #1184      +/-   ##
==========================================
+ Coverage   67.76%   75.58%   +7.81%
==========================================
  Files          90       10      -80
  Lines        4291      258    -4033
==========================================
- Hits         2908      195    -2713
+ Misses       1383       63    -1320

Flag
Coverage Δ

unittests
75.58% <ø> (+7.81%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

raiwidgets/raiwidgets/error_analysis_constants.py

...ibleai/_tools/shared/state_directory_management.py

...onsibleai/responsibleai/serialization_utilities.py

raiwidgets/raiwidgets/constants.py

...nsibleai/responsibleai/_managers/causal_manager.py

responsibleai/responsibleai/_config/base_config.py

.../responsibleai/modelanalysis/constants/__init__.py

responsibleai/responsibleai/_internal/__init__.py

erroranalysis/erroranalysis/_internal/constants.py

erroranalysis/erroranalysis/version.py

... and 70 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 39a7ff8...66c23ba. Read the comment docs.

repo: microsoft/responsible-ai-toolbox


text:
Make targets package a dev dependency and fix package supplier trimming

Fixes https://github.com/microsoft/sbom-tool/issues/713
Fixes https://github.com/microsoft/sbom-tool/issues/714

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

Project coverage is 66.72%. Comparing base (7b69133) to head (80a51b8).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #726      +/-   ##
==========================================
- Coverage   70.00%   66.72%   -3.28%
==========================================
  Files         277      277
  Lines        8630     8630
  Branches     1004     1004
==========================================
- Hits         6041     5758     -283
- Misses       2071     2362     +291
+ Partials      518      510       -8

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

authors: codecov-commenter sfoslund

repo: microsoft/sbom-tool


text:
.Net: SK V1 improvements

### Tasks
- [ ] https://github.com/microsoft/semantic-kernel/issues/3686
- [ ] https://github.com/microsoft/semantic-kernel/issues/3687
- [ ] https://github.com/microsoft/semantic-kernel/issues/3688
- [ ] https://github.com/microsoft/semantic-kernel/issues/3689
- [ ] https://github.com/microsoft/semantic-kernel/issues/3690
- [x] (Issure Created)(Mark) Move Kernel.RunAsy(pipeline) extension methods to samples.
- [x] **(WIP)**(Sergey) Remove SKContext argument from all the things, pass it nowhere. Delete SKContext.
- [ ] https://github.com/microsoft/semantic-kernel/issues/3691
- [ ] https://github.com/microsoft/semantic-kernel/issues/3692
- [ ] https://github.com/microsoft/semantic-kernel/issues/3693
- [ ] https://github.com/microsoft/semantic-kernel/issues/3694
- [x] Rename "SK" to "Kernel" and ensure consistency in which types use the prefix. Also Prompt instead of Semantic.
- [ ] https://github.com/microsoft/semantic-kernel/issues/3695
- [ ] https://github.com/microsoft/semantic-kernel/issues/3696
- [x] (PR Open)(Stephen) Remove resiliency stuff from SK
- [ ] https://github.com/microsoft/semantic-kernel/issues/3698
- [ ] https://github.com/microsoft/semantic-kernel/issues/3697
- [x] (Done)(Mark) integrate pre/post hooks into KernelFunction.InvokeAsync
- [ ] https://github.com/microsoft/semantic-kernel/issues/3699
- [x] (WIP)(Roger) Multi Modality Abstractions - https://github.com/microsoft/semantic-kernel/issues/3675

@SergeyMenshykh, this can be closed now, right?

Yep, closing it now.

authors: SergeyMenshykh stephentoub

repo: microsoft/semantic-kernel


text:
.Net: Identify how Autogen handles parallel agents responding to a group chat

According to a customer, Autogen has the ability to have multiple agents respond at the same time. This issue is to investigate how that works (if at all).

Closing as a dupe of #6783


text:
Python: hf sample and generator

Motivation and Context

Adds a parameter to the hugging face text completion class to supply the Pipeline, this allows more customization.
Added a sample that shows how to setup quantization for HF models. Not ready to use because of differences in setup and hardware.
Closes: #6374
Description

Contribution Checklist

[x] The code builds clean without any errors or warnings
[x] The PR follows the SK Contribution Guidelines and the pre-submission formatting script raises no violations
[x] All unit tests pass, and I have added new tests where possible
[x] I didn't break anyone :smile:

Python 3.10 Test Coverage Report • FileStmtsMissCoverMissingsemantic_kernel/connectors/ai/hugging_face/services   hf_text_completion.py431467%92–93, 95, 121–144TOTAL652972789%
Python 3.10 Unit Test Overview

Tests
Skipped
Failures
Errors
Time

1547
1 :zzz:
0 :x:
0 :fire:
24.262s :stopwatch:

@eavanvalkenburg, are you still working on this one? Or should we close it out?

@matthewbolanos still want to add this, just has not been a prio, it adds some additional capabilities to the connector as well as a new sample

Please re-open if/when we want to get this into main.

authors: eavanvalkenburg markwallace-microsoft matthewbolanos moonbox3


text:
Unable to use feature 'default literal' (c# 7.1)

Visual Studio (15.7.2) compile successfully, but msbuild fails
Web1.csproj (LangVersion is 7.1)
[Route("api/[controller]")]
public class ValuesController : Controller
{
    private readonly MyService myService;
    public ValuesController()
    {
        myService = new MyService();
    }
    // GET api/values/5
    [HttpGet("{id}")]
    public int Get(int id)
    {
        return myService.GetDefaultValue();
    }
}

services.csproj (LangVersion is 7.1)
public class MyService
{
    public int GetDefaultValue()
    {
        int value = default;
        return value;
    }
}

msbuild output:
"C:\Temp\testSF\testSF\testSF.sfproj" (Package target) (1) ->
"C:\Temp\testSF\Web1\Web1.csproj" (default target) (2:5) ->
"C:\Temp\testSF\services\services.csproj" (default target) (3:6) ->
(CoreCompile target) ->
MyService.cs(9,25): error CS8107: Feature 'default literal' is not available in C# 7.0. Please use language version 7.1 or greater. [C:\Temp\testSF\services\services.csproj]
added
It is possible to use 'default' in the Web1.csproj, but not in the services.csproj

testSF.zip

What version of msbuild are you running? the one included in VS?

Yes, included in VS

I had the same problem a while back and was able to solve it by editing the .sfproj and packages.config-files in the Service Fabric project.
Per default, the older Msbuild 1.6.2 is required, which doesn't support C# 7.1, but if you change this everywhere to Msbuild 1.6.6, the C# 7.1 features should work.
packages.config:
<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Microsoft.VisualStudio.Azure.Fabric.MSBuild" version="1.6.6" targetFramework="net461" />
</packages>

.sfproj (also do a replace of "1.6.2" with "1.6.6"):
...
<SupportedMSBuildNuGetPackageVersion>1.6.6</SupportedMSBuildNuGetPackageVersion>
...

I am also experiencing something similar to this problem myself.
I am able to build and deploy the solutions locally in Visual Studio, however on my VSTS Build Agent (which should be using exactly the same version of Visual Studio) I get the error above.
Relatively interestingly I don't get this on the Build Solution Step, only on the Build *.sfproj step after it. Below are screen shots of my build step. I have done what was suggested by @jtapolczai but that hasn't helped.
Has anyone else had a similar problem?

Hello,
I have the exact same issue as JamiePed.
If I open the solution and manually package the application using Visual Studio 2017 on the build agent, it works.
But, through VSTS task, it fail.
My packages.config target MSBuild 1.6.7 :
<package id="Microsoft.VisualStudio.Azure.Fabric.MSBuild" version="1.6.7" targetFramework="net471" />
The temporary workaround is ... to not use C# 7.1 features 😞

This can be solved by checking these nodes in project files.
v4.7.1
7.3
netstandard2.0
These properties should be compatible to use C# 7.1 features.
@JamiePed check your erroring project has the lang version specified. And  should be in the first/main  of the project file.

I ran into this issue when targeting a *.proj.  The issue was on VSTS Platform type.  It use to build with the type set to "any cpu", and now if you are targeting a *.proj file you must specify "AnyCPU" (no whitespaces)

You only need to add the <LangVersion>7.3</LangVersion>  tag the projects that fails and everything will work.

Here try this => int value = default(value);
public class MyService
{
    public int GetDefaultValue()
    {
        int value = default(value);
        return value;
    }
}

Why does this not work like in VS where the maximum version is taken by default?

have the problem yesterday in VS 2017, only resolved it by moving to VS 2019...

I think I found a solution for msbuild, and I see that @kensaccord mentioned the same fix, above.  I had the same issue as @JamiePed and @nicolas-garcia, except that the DevOps build task was giving me an error about C# 8, like this: "Error CS8370: Feature '[X]' is not available in C# 7.3. Please use language version 8.0 or greater."  Per this Azure DevOps page on the Visual Studio Build task:

Platform: If you are targeting an MSBuild project (.*proj) file instead of a solution, specify AnyCPU (no whitespace).

So, in the Visual Studio Build task configuration, I changed the Platform setting from "$(BuildPlatform)" to "AnyCPU", and the build succeeded.  (The default value was "Any CPU".)
By the way, for those not using Azure DevOps (or if you want to test locally with msbuild), that setting corresponds with the /p:platform="AnyCPU" parameter in msbuild.exe.

You only need to add the <LangVersion>7.3</LangVersion> tag the projects that fails and everything will work.

Adding for reference, you add this to the unconditional "PropertyGroup" section, for example:
<PropertyGroup>
	<LangVersion>latest</LangVersion>
</PropertyGroup>

For a list of possible values and other documentation, see: https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/configure-language-version

authors: JamiePed KSemenenko SamHard aL3891 cosminsandu25 dbr123 demonguru18 jtapolczai kensaccord mickert nicolas-garcia vitalsap vshaukun

repo: microsoft/service-fabric


text:
Uses the deprecated add-path and set-env command

Hello,
According to GitHub, they have removed the add-path and set-env commands because there was a security issue. More information can be found here: https://github.blog/changelog/2020-10-01-github-actions-deprecating-set-env-and-add-path-commands/
add-path should be replaced with addPath and set-env should be replaced with exportVariable. Apparently, it uses @actions/core version 1.2.6. More information: https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-commands-for-github-actions#environment-files
Because it uses the deprecated add-path and set-env commands, our GitHub Actions workflows which use @microsoft/setup-msbuild fail with an error referencing it.
The affected lines in affected files are found here:
https://github.com/microsoft/setup-msbuild/blob/f25dd68be285e78e89e662c0c6deee7f5065cbb3/dist/index.js#L1200
https://github.com/microsoft/setup-msbuild/blob/f25dd68be285e78e89e662c0c6deee7f5065cbb3/dist/index.js#L1184
And these are the failed workflows in our project:
https://github.com/EoflaOE/Kernel-Simulator/actions/runs/376949373
https://github.com/EoflaOE/Kernel-Simulator/actions/runs/376949371
This is a serious issue for us as it makes workflows that don't have ACTIONS_ALLOW_UNSECURE_COMMANDS environment variable set to true unusable, especially for the project owners who seek for security like us.

Well, looks like 1.0.2 fixed it. We'll use this version from now on. Updating all projects...

Glad you found the fix! -- Yes, this was present in the core GitHub library (that pretty much every Action uses) and not directly called by this action's core code.  Either way, this is updated.

authors: EoflaOE timheuer

repo: microsoft/setup-msbuild


text:
Adding Rust Support

I am trying to bind snmalloc to rust to have a comprehensive malloc-bench (WIP).
Basically, I have already created several bindings: snmalloc,snmalloc-sys, snmallocator.
Yet, there is a issue to provide efficient realloc with alignment. I added one following the code in malloc.h, but I do not know whether it is sound and safe. So I guess I need some guidance here.

Hi @SchrodingerZhu
This is awesome, firstly is there a specification of realloc aligned for Rust that I can read. There are a bunch of things that are done here to meet various C expectations that might not be required. The most efficient version will do no more than necessary.
In particular, the interaction between alignment work and realloc work has many possibilities: What should size = 0, alignment = 16 do?

error
free the object
return a pointer that is aligned to 16.
The order of checks is important to get each of these behaviours.

Second minor point, if you reformat a file it makes code review very hard, if we are to take any changes they must be formated with our Clangformat config, our CI enforces this.

Is it supposed to satisfy the following:
https://doc.rust-lang.org/std/alloc/trait.GlobalAlloc.html#safety-4
How defensive do you want the code to be for undefined behaviour?  The current code checks a lot of properties and returns error codes, but as the property failures are undefined behaviour we could be more efficient here?  So it depends on the performance/usability trade-off for how this is implemented.  I would suggest we turn a lot of stuff into asserts, so the Debug version checks everything and release is fast.

I am so sorry that I am being terribly busy recently. I will back to this work at this weekend. :P

All looks good, so closing this issue. Thanks @snf and @SchrodingerZhu for the hard work.  Perf numbers look pretty good too.

repo: microsoft/snmalloc


text:
Work3

Description
Updated README of homepage.

Codecov Report

Merging #533 into master will not change coverage.
The diff coverage is 91.93%.

@@            Coverage Diff            @@
##             master     #533   +/-   ##
=========================================
  Coverage     55.77%   55.77%
  Complexity      680      680
=========================================
  Files           162      162
  Lines          2969     2969
  Branches        172      172
=========================================
  Hits           1656     1656
  Misses         1193     1193
  Partials        120      120

Impacted Files
Coverage Δ
Complexity Δ

.../spring/cloud/autoconfigure/jms/ServiceBusKey.java
100% <100%> (ø)
4 <4> (ø)
:arrow_down:

...oconfigure/jms/ServiceBusJMSAutoConfiguration.java
100% <100%> (ø)
4 <4> (ø)
:arrow_down:

...ft/azure/spring/cloud/config/ConfigHttpClient.java
80.85% <100%> (ø)
9 <0> (ø)
:arrow_down:

...utoconfigure/jms/AzureServiceBusJMSProperties.java
77.77% <77.77%> (ø)
9 <9> (ø)
:arrow_down:

...ud/autoconfigure/jms/ConnectionStringResolver.java
92.85% <92.85%> (ø)
2 <2> (ø)
:arrow_down:

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 6331d3a...7946a10. Read the comment docs.

authors: codecov-io junjie-x

repo: microsoft/spring-cloud-azure


text:
typo "Prchestration' to "Orchestration"

typo

Hello! We use this particular repo as a course, so we open "Issues" for typos or other corrections, and assign it to the appropriate author so that they maintain control over their work. Feel free to open an Issue, and include the specific page where you find the error. Thanks for reading and submitting!

repo: microsoft/sqlworkshops


text:
Please support -H/--set-home

sudo on Linux has an option -H/--set-home, which sets the home directory to that of the target user. (If this is already the default behavior, then consider accepting and ignoring the option, for compatibility.)

When you say, set the home directory to that of the target user, it sounds in order to enable this we would first have to enable the ability to run commands as different users rather than just elevating as admin: https://github.com/microsoft/sudo/issues/3

(I'm gonna parent this up to #3 officially, because this is basically a no-op in the default "run as this user, but with the admin token" scenario)

@zadjii-msft It'd be helpful to accept and ignore the option as a no-op, for compatibility with other implementations of sudo, even before there's any support for becoming a different user.

authors: joadoumie joshtriplett zadjii-msft

repo: microsoft/sudo


text:
Font features break line drawing

Windows Terminal version
1.15.2003.0
Windows build number
10.0.22000.0
Other Software
No response
Steps to reproduce
Modify the config file as below:

Expected Behavior
Unicode isn't broken.

Actual Behavior

The font can be downloaded from here.

I tried many stylistic sets of Cascadia Code and Delugia, this all repro-ed.
But if Fira Code is used, this won't happen.

Unless I'm testing incorrectly, this issue doesn't seem to occur with AtlasEngine, after #13549.

Well this issue still occurs in the latest release yesterday, but the "gap" is much unnoticeable now.

I'm glad it's much better! Very slight gaps are something I've also noticed myself for fonts that aren't particularly pixel-perfect, but I haven't had time to investigate it further yet. This is the worst that I could produce myself (magnified 400%):

Yours seem to be the exact same kind, which means I can reproduce and thus hopefully fix it.

authors: lhecker registerGen

repo: microsoft/terminal


text:
New window dimension setting

Description of the new feature
how do you set a new windows terminal window to be maximized on launch?
vscode has a "window.newWindowDimensions": "maximized" setting that works but i cannot find the equivalent in windows terminal
source: https://aka.ms/terminal-profiles-schema
Proposed technical implementation details
create the setting in (AppData/Local/Packages/WindowsTerminal/LocalState)/settings.json

From the schema:
https://github.com/microsoft/terminal/blob/56dc9d1f981382da61f745d30600415df24729a5/doc/cascadia/profiles.schema.json#L2496-L2507
In the UI:

Does that work for you/?

thanks

authors: ridhwaans zadjii-msft


text:
Display issue in Cloud Shell with line wrapped long commands

When a Cloud Shell command line is long and wrapped to next line, it cannot be rendered properly when one tries to edit the command by moving the arrow keys

/dup #2267 (even though it says pwsh, this is the same root cause)

authors: DHowett-MSFT ningweinw


text:
Non-cygwin subprocesses are not handling the ANSI escape sequence

This is a follow up to https://github.com/microsoft/terminal/issues/2837 which is already resolved in that the a large set of ANSI is already handled by Windows Terminal.  This seems to propagate properly through any other tools that use the cygwin/msys libraries such as ls
However, it does not appear to handle ANSI escape sequences for processes that do not use Cygwin/MSys in those scenarios the raw escape codes appear.
I am thinking this is likely an External bug, but I wanted to double check since I saw one of the Terminal devs using something called "Libra" to find the process flow to debug something like this.  It could likely be something about setting an envvar or something to trigger a proper call.
Environment
Microsoft Windows [Version 10.0.19041.329]

Windows Terminal version (if applicable):
Version: 1.0.1401.0

Any other software?
git version 2.27.0.windows.1

Steps to reproduce

Set up Git Bash as your shell https://stackoverflow.com/questions/56839307/adding-git-bash-to-the-new-windows-terminal/57369284#57369284
Have a Gradle project or some other program that would spit out ANSI escape sequences that does not use MSys/Cygwin.
Run ./gradlew build

Expected behavior
ANSI escape sequences are parsed and handled like this in the Git Bash shortcut provided by Git for Windows

Actual behavior

ANSI escape sequences are visible and not handled in Windows Terminal's shell

So, here's the deal.
This is, quite firmly, a client application problem. I know, that's not the "right" answer. It is, however, the self-consistent one.
We didn't always ship with support for VT sequences, so a bunch of applications took a dependency on the ability to print raw control characters directly to the screen. I realize that that sounds like insanity. However, because we have to support them (forever!), we leveraged a system we already had:
The Windows Console subsystem has the notion of "modes". Input modes and output modes. Back in Windows 10 TH1 (10.0.10240) we introduced the output mode ENABLE_VIRTUAL_TERMINAL_PROCESSING. It's off by default so that legacy applications continue to work properly.
When that mode is enabled, the console handles escape sequences. When that mode is disabled, it prints the escape character 0x1B directly to the screen as a tiny "left arrow" glyph.
When we added support for ENABLE_VT_PROCESSING, we also added a registry key called VirtualTerminalLevel (DWORD). When it's set to 0x01, ENABLE_VIRTUAL_TERMINAL_PROCESSING is turned on by default.
None of this has changed since Windows 10 10.0.10240.0. The Terminal doesn't impact the console modes*, because it is running on the other side of the console. It's a replacement for the user's eyes seeing the console window, and it does not (cannot!) impact the console mode.
That footnote, though. That footnote haunts me. Terminal doesn't impact the console modes in a way that would make this situation worse. Terminal sets up the console host it talks to in such a way as to always enable ENABLE_VT_PROCESSING by default. There's a one-way one-time change here, and that change is "by default, on startup, the console application WILL BE IN VT MODE".
Any application found to not be in VT mode has explicitly turned it off by calling SetConsoleMode() without ENABLE_VIRTUAL_TERMINAL_PROCESSING.

(The "Git Bash" shortcut does not, by default, use the windows console susbsytem. It is unfortunately invalid to use it for these comparisons. There's a special handshake that happens between mintty and mingw/cygwin that they use to light up special behaviors.)
FWIW: The application that's changing the console mode to turn off VT processing is likely to be java.exe.

And one last note: I think the Libra you're referring to is my personal laptop :smile: I do a lot of terminal engineering on it, though, so it shows up all the time.
If you're talking about what I think you are, though, that's the "debug tap". More info inside the detail region below.

Info about the debug tap
The debug tap lets us see what raw output is coming out of the console translation layer, and what raw input is going into it. If you set the setting debugFeaturesEnabled to true, and then press both Alt keys while opening a new tab (with the menu), you'll get this split-screen view:

FWIW: The application that's changing the console mode to turn off VT processing is likely to be java.exe.

I was thinking something along those lines so that means existing programs that want to render properly in Terminal and is executed behind cygwin needs to be updated then.

Since there's no Terminal-specific magic, it's less about "being inside terminal" and more about being a good windows console subsystem citizen... but, essentially, yes.

I wonder if there's a way for MSys to detect SetConsoleMode() from a subprocess and adjust the calls accordingly.

I'd rather just handle that with #4954, which would isolate all of these processes from eachother. One day, one day.
Closing this one as discussed/external :smile:

Adding a link to a potential solution for apps that have weird issues and how to fix it when setting the VT_PROCESSING does not work https://github.com/starship/starship/pull/2258#issuecomment-771943572 it's a bit of an odd solution though (setting stdin to null)

authors: DHowett trajano


text:
Could you pls add Minimize to Taskbar Status Area

Description of the new feature/enhancement
Terminal is a useful tool, and the frequency of usage is very high. But sometime i don't need it, do not want it appears in the taskbar, because i switch between lots of windows with Alt+Tab. So i think we can add one feature minimize to TSA. If we want to use it again, we can invoke it quickly by hotkey such as Ctrl+~ like in VSCode.
Proposed technical implementation details (optional)
See above.

I think you might be asking for #5727.

I think you might be asking for #5727.

Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #5727 for more discussion.
/dup #5727

Thanks for the suggestion! This is actually already being tracked by another issue on our repo - please refer to #5727 for more discussion.
/dup #5727

authors: j4james scutxd zadjii-msft


text:
Generated reference docs must enumerate interface operations

Looking at the Azure Core reference documentation, I see that the ResourceOperations interface section does not describe the operations that this interface contains:
https://azure.github.io/typespec-azure/docs/libraries/azure-core/reference/interfaces#Azure.Core.ResourceOperations
The list of operations following ResourceOperations are actually the old deprecated signatures that we don't want people to use anymore.
Perhaps we should only describe operations of templated interfaces?

est: 5

authors: daviwil markcowl

repo: microsoft/typespec


text:
llvm build failure

Host Environment

OS: Windows 10 Pro Version 1909 build 18363.778
Compiler: MSVC 19.25.28614 for x64

To Reproduce
Steps to reproduce the behavior:
./vcpkg install llvm llvm[clang-tools-extra] llvm[utils] --triplet x64-windows
Failure logs
[3299/3385] cmd.exe /C "cd . && D:\vcpkg\downloads\tools\cmake-3.14.0-windows\cmake-3.14.0-win32-x86\bin\cmake.exe -E vs_link_dll --intdir=tools\clang\tools\libclang\CMakeFiles\libclang.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\mt.exe --manifests  -- C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1425~1.286\bin\Hostx64\x64\link.exe  @CMakeFiles\libclang.rsp  /out:bin\libclangd.dll /implib:lib\libclangd.lib /pdb:bin\libclangd.pdb /dll /version:10.0 /machine:x64 /debug /INCREMENTAL   && cd ."
FAILED: bin/libclangd.dll lib/libclangd.lib
cmd.exe /C "cd . && D:\vcpkg\downloads\tools\cmake-3.14.0-windows\cmake-3.14.0-win32-x86\bin\cmake.exe -E vs_link_dll --intdir=tools\clang\tools\libclang\CMakeFiles\libclang.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100183~1.0\x64\mt.exe --manifests  -- C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1425~1.286\bin\Hostx64\x64\link.exe  @CMakeFiles\libclang.rsp  /out:bin\libclangd.dll /implib:lib\libclangd.lib /pdb:bin\libclangd.pdb /dll /version:10.0 /machine:x64 /debug /INCREMENTAL   && cd ."
LINK Pass 1: command "C:\PROGRA~2\MICROS~2\2019\COMMUN~1\VC\Tools\MSVC\1425~1.286\bin\Hostx64\x64\link.exe @CMakeFiles\libclang.rsp /out:bin\libclangd.dll /implib:lib\libclangd.lib /pdb:bin\libclangd.pdb /dll /version:10.0 /machine:x64 /debug /INCREMENTAL /MANIFEST /MANIFESTFILE:tools\clang\tools\libclang\CMakeFiles\libclang.dir/intermediate.manifest tools\clang\tools\libclang\CMakeFiles\libclang.dir/manifest.res" failed (exit code 1104) with the following output:
Microsoft (R) Incremental Linker Version 14.25.28614.0
Copyright (C) Microsoft Corporation.  All rights reserved.

...

LINK : fatal error LNK1104: cannot open file 'dl.lib'
ninja: build stopped: subcommand failed.

install-x64-windows-dbg-out.log

dl should not be linked in windows.

Dear @BenKey please test my fix in PR #11268
Thank you!

@yurybura
I was not certain how to sync the pull request to my fork.
What I ended up doing is as follows.

I replaced ports/llvm/CONTROL with https://raw.githubusercontent.com/microsoft/vcpkg/1b8eb0c93d9d75378e605542cd8a9ecf28ef0a9b/ports/llvm/CONTROL.
I replaced ports/llvm/portfile.cmake with https://raw.githubusercontent.com/microsoft/vcpkg/1b8eb0c93d9d75378e605542cd8a9ecf28ef0a9b/ports/llvm/portfile.cmake.
I then ran the following command.
vcpkg install llvm llvm[clang-tools-extra] llvm[utils] --triplet x64-windows

The build still failed with the same error. See the following log file.
install-x64-windows-dbg-out.log

In SOURCE_PATH/clang/tools/libclang/CMakeLists.txt line 63:
find_library(DL_LIBRARY_PATH dl)
if (DL_LIBRARY_PATH)
  list(APPEND LIBS dl)
endif()

Does this related?

Dear @BenKey you haven't been used my latest version..
Please apply my last commit from PR #11268 : https://github.com/microsoft/vcpkg/pull/11268/commits/a6ddd53c8428425f6b13e12e0a1c93375f70ed2f.
Thank you.

Does this related?

@JackBoosY  I think so yes. I don't want to patch LLVM code. Instead of that I overrides DL_LIBRARY_PATH with empty value using CMake command line (see https://github.com/microsoft/vcpkg/commit/a6ddd53c8428425f6b13e12e0a1c93375f70ed2f).

@yurybura After adding the other change I tried again. It works! Thanks.

Please keep this issue open before #11268 merged.

authors: BenKey JackBoosY yurybura

repo: microsoft/vcpkg


text:
[flashlight-cuda:x64-linux] build failure

Host Environment

OS: Ubuntu 10.04.2 LTS
Compiler: gcc 9.3.0, CUDA 11.3

To Reproduce
Steps to reproduce the behavior:
./vcpkg install flashlight-cuda
Failure logs
Computing installation plan...
The following packages will be built and installed:
    flashlight-cuda[core,fl]:x64-linux -> 0.3#1
Detecting compiler hash for triplet x64-linux...
Could not locate cached archive: /home/abhinav/.cache/vcpkg/archives/30/30aa48909bcda77e1c2239651ee34759b8646235.zip
Starting package 1/1: flashlight-cuda:x64-linux
Building package flashlight-cuda[core,fl]:x64-linux...
-- Using /home/abhinav/vcpkg/downloads/flashlight-flashlight-626914e79073c5547513de649af706f7e2b796ad.tar.gz
-- Cleaning sources at /home/abhinav/vcpkg/buildtrees/flashlight-cuda/src/f7e2b796ad-c1bedb72d5.clean. Use --editable to skip cleaning for the packages you specify.
-- Extracting source /home/abhinav/vcpkg/downloads/flashlight-flashlight-626914e79073c5547513de649af706f7e2b796ad.tar.gz
-- Using source at /home/abhinav/vcpkg/buildtrees/flashlight-cuda/src/f7e2b796ad-c1bedb72d5.clean
-- Configuring x64-linux-dbg
-- Configuring x64-linux-rel
-- Building x64-linux-dbg
-- Building x64-linux-rel
CMake Error at scripts/cmake/vcpkg_fixup_cmake_targets.cmake:95 (message):

   '/home/user/vcpkg/packages/flashlight-cuda_x64-linux/debug/share/flashlight-cuda'
  does not exist.
Call Stack (most recent call first):
  ports/flashlight-cuda/portfile.cmake:47 (vcpkg_fixup_cmake_targets)
  scripts/ports.cmake:139 (include)

Error: Building package flashlight-cuda:x64-linux failed with: BUILD_FAILED
Please ensure you're using the latest portfiles with `./vcpkg update`, then
submit an issue at https://github.com/Microsoft/vcpkg/issues including:
  Package: flashlight-cuda:x64-linux

  Vcpkg version: 2021-05-05-unknownhash
Additionally, attach any relevant sections from the log files above.

Additional context
Already installed MKL and ran environment setup for that. Also set up nvcc correctly. It correctly installed following
./vcpkg/vcpkg list
arrayfire:x64-linux                                3.7.3#3          ArrayFire is a general-purpose library that simp...
arrayfire[cpu]:x64-linux                                            ArrayFire CPU backend
arrayfire[cuda]:x64-linux                                           ArrayFire CUDA backend
arrayfire[unified]:x64-linux                                        ArrayFire unified backend
boost-algorithm:x64-linux                          1.75.0           Boost algorithm module
boost-align:x64-linux                              1.75.0           Boost align module
boost-any:x64-linux                                1.75.0           Boost any module
boost-array:x64-linux                              1.75.0           Boost array module
boost-assert:x64-linux                             1.75.0           Boost assert module
boost-atomic:x64-linux                             1.75.0#1         Boost atomic module
boost-bind:x64-linux                               1.75.0           Boost bind module
boost-build:x64-linux                              1.75.0           Boost.Build
boost-chrono:x64-linux                             1.75.0#1         Boost chrono module
boost-compatibility:x64-linux                      1.75.0           Boost compatibility module
boost-compute:x64-linux                            1.75.0           Boost compute module
boost-concept-check:x64-linux                      1.75.0#2         Boost concept_check module
boost-config:x64-linux                             1.75.0           Boost config module
boost-container-hash:x64-linux                     1.75.0           Boost container_hash module
boost-container:x64-linux                          1.75.0#1         Boost container module
boost-conversion:x64-linux                         1.75.0           Boost conversion module
boost-core:x64-linux                               1.75.0           Boost core module
boost-date-time:x64-linux                          1.75.0#1         Boost date_time module
boost-detail:x64-linux                             1.75.0           Boost detail module
boost-dynamic-bitset:x64-linux                     1.75.0           Boost dynamic_bitset module
boost-endian:x64-linux                             1.75.0           Boost endian module
boost-exception:x64-linux                          1.75.0#1         Boost exception module
boost-filesystem:x64-linux                         1.75.0#1         Boost filesystem module
boost-foreach:x64-linux                            1.75.0           Boost foreach module
boost-format:x64-linux                             1.75.0           Boost format module
boost-function-types:x64-linux                     1.75.0           Boost function_types module
boost-function:x64-linux                           1.75.0           Boost function module
boost-functional:x64-linux                         1.75.0           Boost functional module
boost-fusion:x64-linux                             1.75.0           Boost fusion module
boost-integer:x64-linux                            1.75.0           Boost integer module
boost-intrusive:x64-linux                          1.75.0           Boost intrusive module
boost-io:x64-linux                                 1.75.0           Boost io module
boost-iterator:x64-linux                           1.75.0           Boost iterator module
boost-lambda:x64-linux                             1.75.0           Boost lambda module
boost-lexical-cast:x64-linux                       1.75.0           Boost lexical_cast module
boost-math:x64-linux                               1.75.0#1         Boost math module
boost-modular-build-helper:x64-linux               1.75.0#9
boost-move:x64-linux                               1.75.0           Boost move module
boost-mp11:x64-linux                               1.75.0           Boost mp11 module
boost-mpl:x64-linux                                1.75.0           Boost mpl module
boost-multi-index:x64-linux                        1.75.0           Boost multi_index module
boost-multiprecision:x64-linux                     1.75.0           Boost multiprecision module
boost-numeric-conversion:x64-linux                 1.75.0           Boost numeric_conversion module
boost-optional:x64-linux                           1.75.0           Boost optional module
boost-phoenix:x64-linux                            1.75.0           Boost phoenix module
boost-pool:x64-linux                               1.75.0           Boost pool module
boost-predef:x64-linux                             1.75.0           Boost predef module
boost-preprocessor:x64-linux                       1.75.0           Boost preprocessor module
boost-property-tree:x64-linux                      1.75.0           Boost property_tree module
boost-proto:x64-linux                              1.75.0           Boost proto module
boost-random:x64-linux                             1.75.0#1         Boost random module
boost-range:x64-linux                              1.75.0           Boost range module
boost-ratio:x64-linux                              1.75.0           Boost ratio module
boost-rational:x64-linux                           1.75.0           Boost rational module
boost-regex:x64-linux                              1.75.0#2         Boost regex module
boost-serialization:x64-linux                      1.75.0#1         Boost serialization module
boost-smart-ptr:x64-linux                          1.75.0           Boost smart_ptr module
boost-spirit:x64-linux                             1.75.0           Boost spirit module
boost-stacktrace:x64-linux                         1.75.0#1         Boost stacktrace module
boost-static-assert:x64-linux                      1.75.0           Boost static_assert module
boost-system:x64-linux                             1.75.0#1         Boost system module
boost-thread:x64-linux                             1.75.0#1         Boost thread module
boost-throw-exception:x64-linux                    1.75.0           Boost throw_exception module
boost-tokenizer:x64-linux                          1.75.0           Boost tokenizer module
boost-tti:x64-linux                                1.75.0           Boost tti module
boost-tuple:x64-linux                              1.75.0           Boost tuple module
boost-type-index:x64-linux                         1.75.0           Boost type_index module
boost-type-traits:x64-linux                        1.75.0           Boost type_traits module
boost-typeof:x64-linux                             1.75.0           Boost typeof module
boost-uninstall:x64-linux                          1.75.0#1         boost uninstall port
boost-unordered:x64-linux                          1.75.0           Boost unordered module
boost-utility:x64-linux                            1.75.0           Boost utility module
boost-uuid:x64-linux                               1.75.0           Boost uuid module
boost-variant:x64-linux                            1.75.0           Boost variant module
boost-vcpkg-helpers:x64-linux                      7#2              a set of vcpkg-internal scripts used to modulari...
boost-winapi:x64-linux                             1.75.0           Boost winapi module
cereal:x64-linux                                   1.3.0            a header-only C++11 serialization library (built...
cub:x64-linux                                      1.12.0           CUB is a flexible library of cooperative threadb...
cuda:x64-linux                                     10.1#7           A parallel computing platform and programming model
cudnn:x64-linux                                    7.6.5#4          NVIDIA's cuDNN deep neural network acceleration ...
egl-registry:x64-linux                             2020-02-20       the EGL API and Extension Registry
fmt:x64-linux                                      7.1.3#4          Formatting library for C++. It can be used as a ...
glad:x64-linux                                     0.1.34#1         Multi-Language Vulkan/GL/GLES/EGL/GLX/WGL Loader...
glad[loader]:x64-linux                                              Generate loader logic.
intel-mkl:x64-linux                                2020.0.0         Intel® Math Kernel Library (Intel® MKL) accele...
nccl:x64-linux                                     2.4.6#1          Optimized primitives for collective multi-GPU co...
opengl-registry:x64-linux                          2020-03-25       the API and Extension registries for the OpenGL ...
openmpi:x64-linux                                  4.1.0            The Open MPI Project is an open source Message P...
spdlog:x64-linux                                   1.8.5#2          Very fast, header only, C++ logging library
stb:x64-linux                                      2020-09-14       public domain header-only libraries
vcpkg-cmake-config:x64-linux                       2021-05-22
vcpkg-cmake:x64-linux                              2021-02-28#3

Hi @abhinavdayal
Thanks for posting this issue.
Can you try to rebuild with the following changes?
Add these codes to vcpkg_configure_cmake()
OPTIONS_DEBUG
    -DFL_INSTALL_CMAKE_DIR=${CURRENT_PACKAGES_DIR}/debug/share/flashlight
OPTIONS_RELEASE
    -DFL_INSTALL_CMAKE_DIR=${CURRENT_PACKAGES_DIR}/share/flashlight

Remove this line:
https://github.com/microsoft/vcpkg/blob/680b27d15f4d62bc6181fd33dc5259482b0890b1/ports/flashlight-cuda/portfile.cmake#L22
Update this line
https://github.com/microsoft/vcpkg/blob/680b27d15f4d62bc6181fd33dc5259482b0890b1/ports/flashlight-cuda/portfile.cmake#L47
as
vcpkg_fixup_cmake_targets(CONFIG_PATH share/flashlight TARGET_PATH share/flashlight)
Reference from https://github.com/microsoft/vcpkg/pull/18089

@NancyLi1013
your fix worked for me
diff --git a/ports/flashlight-cuda/portfile.cmake b/ports/flashlight-cuda/portfile.cmake
index 982269b8f..ff6850080 100644
--- a/ports/flashlight-cuda/portfile.cmake
+++ b/ports/flashlight-cuda/portfile.cmake
@@ -19,7 +19,6 @@ set(FL_DEFAULT_VCPKG_CMAKE_FLAGS
   -DFL_BUILD_EXAMPLES=OFF
   -DFL_BACKEND=CUDA # this port is CUDA-backend only
   -DFL_BUILD_STANDALONE=OFF
-  -DFL_INSTALL_CMAKE_DIR=${CURRENT_PACKAGES_DIR}/share/${PORT} # for CMake configs/targets
 )

 # Determine which components to build via specified feature
@@ -41,10 +40,14 @@ vcpkg_configure_cmake(
     OPTIONS
         ${FL_DEFAULT_VCPKG_CMAKE_FLAGS}
         ${FEATURE_OPTIONS}
+    OPTIONS_DEBUG
+        -DFL_INSTALL_CMAKE_DIR=${CURRENT_PACKAGES_DIR}/debug/share/flashlight
+    OPTIONS_RELEASE
+        -DFL_INSTALL_CMAKE_DIR=${CURRENT_PACKAGES_DIR}/share/flashlight
 )
 vcpkg_install_cmake()

-vcpkg_fixup_cmake_targets(CONFIG_PATH share/flashlight-cuda TARGET_PATH share/flashlight)
+vcpkg_fixup_cmake_targets(CONFIG_PATH share/flashlight TARGET_PATH share/flashlight)

 file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/include")
 file(REMOVE_RECURSE "${CURRENT_PACKAGES_DIR}/debug/share")

Thanks for your test and reply @alteman . I will submit a PR to fix this later.

authors: NancyLi1013 abhinavdayal alteman


text:
"vcpkg remove" regularly fails with "error: directory not empty"

The bug: "vcpkg remove" regularly fails with "error: directory not empty"
Environment: Windows 7
Powershell 7.2.1
Visual Studio 2017
To Reproduce:
Steps to reproduce the behavior:

./vcpkg remove xxbigpackage (e,g, Boost all)
See error:
Removal fails with error "directory not empty"

Expected behavior:
ALL of Boost is removed and reinstalled when doing for example  ./vcpkg upgrade
Solution:
See this link : https://stackoverflow.com/questions/1752677/how-to-recursively-delete-an-entire-directory-with-powershell-2-0
Extra context:  (from StackExchange)
When deleting files recursively using a simple Remove-Item "folder" -Recurse I sometimes see an intermittent error : [folder] cannot be removed because it is not empty.
This answer attempts to prevent that error by individually deleting the files.
function Get-Tree($Path,$Include='*') {
@(Get-Item $Path -Include $Include -Force) +
(Get-ChildItem $Path -Recurse -Include $Include -Force) |
sort pspath -Descending -unique
}
function Remove-Tree($Path,$Include='*') {
Get-Tree $Path $Include | Remove-Item -force -recurse
}
Remove-Tree some_dir
I can confirm this solution ALWAYS works ;-)), but i dont know what file i have to change in vcpkg tree.

I think you just got lucky here or are getting "saved" by powershell being slower to do the delete than vcpkg. On Win10 we can engage POSIX delete support which fixes the issue another way but any kind of recursive delete on NT is hindered by NT being a delete-on-close universe, so if anything is held open in the directory by anyone deletion is likely to fail.

Thanks for posting this issue. Please reopen this issue if this is still a problem for you.

authors: BillyONeal Cheney-W Tizznt


text:
[boost-iostreams] Fail to build as x64-windows-static in Debug Mode

Host Environment

OS: Windows 10 X64
Compiler: In CMake Visual Studio Project,  MSVC (2022) and CLang 13 in Debug Mode

To Reproduce
Steps to reproduce the behavior:
./vcpkg install boost-filesystem:x64-windows-static boost-iostreams:x64-windows-static  zstd:x64-windows-static
CMakeLists.txt
cmake_minimum_required (VERSION 3.21)
set (CMAKE_CXX_STANDARD 20)

#if(NOT DEFINED CMAKE_TOOLCHAIN_FILE AND DEFINED ENV{CMAKE_TOOLCHAIN_FILE})
#   set(CMAKE_TOOLCHAIN_FILE $ENV{CMAKE_TOOLCHAIN_FILE})
#endif()

# Add source to this project's executable. "CMakeProject5.cpp" "CMakeProject5.h"
add_executable (CMakeProject5 "DatasetProcessor.cpp" "DatasetProcessor.h")

# TODO: Add tests and install targets if needed.
find_package(zstd CONFIG REQUIRED)
target_link_libraries(CMakeProject5 PRIVATE zstd::libzstd_static)

find_package(Boost REQUIRED COMPONENTS fiber filesystem iostreams)
target_link_libraries(CMakeProject5 PRIVATE Boost::boost Boost::fiber Boost::filesystem Boost::iostreams)

In the root Project file
#include <iostream>
#include <fstream>
#include <string>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/filter/zstd.hpp>
#include <boost/filesystem.hpp>

using namespace std;
using namespace boost::filesystem;

int main(int argc, char** argv) {
    path p("file.zst");
    boost::filesystem::ifstream file(p, ios_base::in | ios_base::binary);
    boost::iostreams::filtering_streambuf<boost::iostreams::input> inbuf;
    inbuf.push(boost::iostreams::zstd_decompressor());
    inbuf.push(file);

    istream instream(&inbuf);

    std::string line;
    std::getline(instream, line);
    std::cout << line << std::endl;

    return 0;

}

EDIT: I fixed a missing line in the code sample.
Failure logs
>------ Build started: Project: CMakeLists, Configuration: Debug ------
  [1/1] Linking CXX executable CMakeProject5\CMakeProject5.exe
  FAILED: CMakeProject5/CMakeProject5.exe
  cmd.exe /C "cd . && C:\msys64\mingw64\bin\cmake.exe -E vs_link_exe --intdir=CMakeProject5\CMakeFiles\CMakeProject5.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~4\2022\COMMUN~1\VC\Tools\MSVC\1430~1.307\bin\Hostx64\x64\link.exe /nologo CMakeProject5\CMakeFiles\CMakeProject5.dir\DatasetProcessor.cpp.obj  /out:CMakeProject5\CMakeProject5.exe /implib:CMakeProject5\CMakeProject5.lib /pdb:CMakeProject5\CMakeProject5.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\zstd_staticd.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\zlibd.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\libsodium.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_fiber-vc140-mt-gd.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_filesystem-vc140-mt-gd.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_iostreams-vc140-mt-gd.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\lzmad.lib  advapi32.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_context-vc140-mt-gd.lib  C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_regex-vc140-mt-gd.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cmd.exe /C "cd /D C:\Users\emide\source\repos\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5 && C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noprofile -executionpolicy Bypass -file C:/dev/vcpkg/scripts/buildsystems/msbuild/applocal.ps1 -targetBinary C:/xxxxxxx/CMakeProject5/out/build/x64-MSVC-Debug/CMakeProject5/CMakeProject5.exe -installedDir C:/dev/vcpkg/installed/x64-windows-static/debug/bin -OutVariable out""
  LINK Pass 1: command "C:\PROGRA~1\MICROS~4\2022\COMMUN~1\VC\Tools\MSVC\1430~1.307\bin\Hostx64\x64\link.exe /nologo CMakeProject5\CMakeFiles\CMakeProject5.dir\DatasetProcessor.cpp.obj /out:CMakeProject5\CMakeProject5.exe /implib:CMakeProject5\CMakeProject5.lib /pdb:CMakeProject5\CMakeProject5.pdb /version:0.0 /machine:x64 /debug /INCREMENTAL /subsystem:console C:\dev\vcpkg\installed\x64-windows-static\debug\lib\zstd_staticd.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\zlibd.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\libsodium.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_fiber-vc140-mt-gd.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_filesystem-vc140-mt-gd.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_iostreams-vc140-mt-gd.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\lzmad.lib advapi32.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_context-vc140-mt-gd.lib C:\dev\vcpkg\installed\x64-windows-static\debug\lib\boost_regex-vc140-mt-gd.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeProject5\CMakeFiles\CMakeProject5.dir/intermediate.manifest CMakeProject5\CMakeFiles\CMakeProject5.dir/manifest.res" failed (exit code 1120) with the following output:
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2019: unresolved external symbol "protected: __cdecl boost::iostreams::detail::zstd_base::zstd_base(void)" (??0zstd_base@detail@iostreams@boost@@IEAA@XZ) referenced in function "public: __cdecl boost::iostreams::detail::zstd_decompressor_impl<class std::allocator<char> >::zstd_decompressor_impl<class std::allocator<char> >(void)" (??0?$zstd_decompressor_impl@V?$allocator@D@std@@@detail@iostreams@boost@@QEAA@XZ)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2019: unresolved external symbol "protected: __cdecl boost::iostreams::detail::zstd_base::~zstd_base(void)" (??1zstd_base@detail@iostreams@boost@@IEAA@XZ) referenced in function "int `public: __cdecl boost::iostreams::detail::zstd_decompressor_impl<class std::allocator<char> >::zstd_decompressor_impl<class std::allocator<char> >(void)'::`1'::dtor$0" (?dtor$0@?0???0?$zstd_decompressor_impl@V?$allocator@D@std@@@detail@iostreams@boost@@QEAA@XZ@4HA)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2019: unresolved external symbol "protected: void __cdecl boost::iostreams::detail::zstd_base::before(char const * &,char const *,char * &,char *)" (?before@zstd_base@detail@iostreams@boost@@IEAAXAEAPEBDPEBDAEAPEADPEAD@Z) referenced in function "public: bool __cdecl boost::iostreams::detail::zstd_decompressor_impl<class std::allocator<char> >::filter(char const * &,char const *,char * &,char *,bool)" (?filter@?$zstd_decompressor_impl@V?$allocator@D@std@@@detail@iostreams@boost@@QEAA_NAEAPEBDPEBDAEAPEADPEAD_N@Z)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2019: unresolved external symbol "protected: void __cdecl boost::iostreams::detail::zstd_base::after(char const * &,char * &,bool)" (?after@zstd_base@detail@iostreams@boost@@IEAAXAEAPEBDAEAPEAD_N@Z) referenced in function "public: bool __cdecl boost::iostreams::detail::zstd_decompressor_impl<class std::allocator<char> >::filter(char const * &,char const *,char * &,char *,bool)" (?filter@?$zstd_decompressor_impl@V?$allocator@D@std@@@detail@iostreams@boost@@QEAA_NAEAPEBDPEBDAEAPEADPEAD_N@Z)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2019: unresolved external symbol "protected: int __cdecl boost::iostreams::detail::zstd_base::inflate(int)" (?inflate@zstd_base@detail@iostreams@boost@@IEAAHH@Z) referenced in function "public: bool __cdecl boost::iostreams::detail::zstd_decompressor_impl<class std::allocator<char> >::filter(char const * &,char const *,char * &,char *,bool)" (?filter@?$zstd_decompressor_impl@V?$allocator@D@std@@@detail@iostreams@boost@@QEAA_NAEAPEBDPEBDAEAPEADPEAD_N@Z)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2019: unresolved external symbol "protected: void __cdecl boost::iostreams::detail::zstd_base::reset(bool,bool)" (?reset@zstd_base@detail@iostreams@boost@@IEAAX_N0@Z) referenced in function "public: __cdecl boost::iostreams::detail::zstd_decompressor_impl<class std::allocator<char> >::~zstd_decompressor_impl<class std::allocator<char> >(void)" (??1?$zstd_decompressor_impl@V?$allocator@D@std@@@detail@iostreams@boost@@QEAA@XZ)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2019: unresolved external symbol "private: void __cdecl boost::iostreams::detail::zstd_base::do_init(struct boost::iostreams::zstd_params const &,bool,void * (__cdecl*)(void *,unsigned __int64,unsigned __int64),void (__cdecl*)(void *,void *),void *)" (?do_init@zstd_base@detail@iostreams@boost@@AEAAXAEBUzstd_params@34@_NP6APEAXPEAX_K3@ZP6AX22@Z2@Z) referenced in function "protected: void __cdecl boost::iostreams::detail::zstd_base::init<class std::allocator<char> >(struct boost::iostreams::zstd_params const &,bool,struct boost::iostreams::detail::zstd_allocator<class std::allocator<char>,class std::allocator<char> > &)" (??$init@V?$allocator@D@std@@@zstd_base@detail@iostreams@boost@@IEAAXAEBUzstd_params@23@_NAEAU?$zstd_allocator@V?$allocator@D@std@@V12@@123@@Z)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2001: unresolved external symbol "unsigned int const boost::iostreams::zstd::default_compression" (?default_compression@zstd@iostreams@boost@@3IB)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2001: unresolved external symbol "int const boost::iostreams::zstd::stream_end" (?stream_end@zstd@iostreams@boost@@3HB)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2001: unresolved external symbol "int const boost::iostreams::zstd::finish" (?finish@zstd@iostreams@boost@@3HB)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\DatasetProcessor.cpp.obj : error LNK2001: unresolved external symbol "int const boost::iostreams::zstd::run" (?run@zstd@iostreams@boost@@3HB)
C:\xxxxxxxxxxx\CMakeProject5\out\build\x64-MSVC-Debug\CMakeProject5\CMakeProject5\CMakeProject5.exe : fatal error LNK1120: 11 unresolved externals
  ninja: build stopped: subcommand failed.

Additional context
In release mode, the building process works like a charm, and the binary works fine. This problem only occurs in debug mode.
Others filters, such as gzip or lzma work well.
Moreover I found similar problems building on linux, but in this case also with gzip and lzma filters.

@emidelgo, thanks for reporting this issue! I tried to repro this issue with VS2022 preview4 cmake project with debug configuration, however, it failed with following errors, do I miss something here?
  [1/2] Building CXX object booststreamtest\CMakeFiles\booststreamtest.dir\booststreamtest.cpp.obj
  FAILED: booststreamtest/CMakeFiles/booststreamtest.dir/booststreamtest.cpp.obj
  C:\PROGRA~1\MIB055~1\2022\Preview\VC\Tools\MSVC\1431~1.311\bin\Hostx64\x64\cl.exe  /nologo /TP  -IF:\vcpkg\clean\vcpkg\installed\x64-windows-static\include /DWIN32 /D_WINDOWS /W3 /GR /EHsc /MDd /Zi /Ob0 /Od /RTC1 /showIncludes /Fobooststreamtest\CMakeFiles\booststreamtest.dir\booststreamtest.cpp.obj /Fdbooststreamtest\CMakeFiles\booststreamtest.dir\ /FS -c C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp
F:\vcpkg\clean\vcpkg\installed\x64-windows-static\include\boost\iostreams\filter\zstd.hpp(94): warning C4267: 'return': conversion from 'size_t' to 'int', possible loss of data
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(13): error C2039: 'filesystem': is not a member of 'boost'
  F:\vcpkg\clean\vcpkg\installed\x64-windows-static\include\boost/iostreams/filter/zstd.hpp(38): note: see declaration of 'boost'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(13): error C2871: 'filesystem': a namespace with this name does not exist
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(16): error C2065: 'path': undeclared identifier
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(16): error C2146: syntax error: missing ';' before identifier 'p'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(16): error C3861: 'p': identifier not found
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(17): error C2039: 'filesystem': is not a member of 'boost'
  F:\vcpkg\clean\vcpkg\installed\x64-windows-static\include\boost/iostreams/filter/zstd.hpp(38): note: see declaration of 'boost'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(17): error C3083: 'filesystem': the symbol to the left of a '::' must be a type
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(17): error C2039: 'ifstream': is not a member of 'boost'
  F:\vcpkg\clean\vcpkg\installed\x64-windows-static\include\boost/iostreams/filter/zstd.hpp(38): note: see declaration of 'boost'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(17): error C2065: 'p': undeclared identifier
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(17): error C2079: 'file' uses undefined class 'std::basic_ifstream<char,std::char_traits<char>>'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(17): error C2440: 'initializing': cannot convert from 'initializer list' to 'int'
  C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(17): note: The initializer contains too many elements
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(19): error C2065: 'fileExpandedData': undeclared identifier
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(19): error C3861: 'TestFilter': identifier not found
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(21): error C2065: 'fileReadData': undeclared identifier
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(21): error C3861: 'TestFilter': identifier not found
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(25): error C2672: 'std::getline': no matching overloaded function found
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(25): error C2784: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &,std::basic_string<_Elem,_Traits,_Alloc> &)': could not deduce template argument for 'std::basic_istream<_Elem,_Traits> &' from 'boost::iostreams::filtering_streambuf<boost::iostreams::input,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::public_>'
  C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.31103\include\string(81): note: see declaration of 'std::getline'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(25): error C2780: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &,std::basic_string<_Elem,_Traits,_Alloc> &,const _Elem)': expects 3 arguments - 2 provided
  C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.31103\include\string(75): note: see declaration of 'std::getline'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(25): error C2784: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &&,std::basic_string<_Elem,_Traits,_Alloc> &)': could not deduce template argument for 'std::basic_istream<_Elem,_Traits> &&' from 'boost::iostreams::filtering_streambuf<boost::iostreams::input,char,std::char_traits<char>,std::allocator<char>,boost::iostreams::public_>'
  C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.31103\include\string(69): note: see declaration of 'std::getline'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(25): error C2780: 'std::basic_istream<_Elem,_Traits> &std::getline(std::basic_istream<_Elem,_Traits> &&,std::basic_string<_Elem,_Traits,_Alloc> &,const _Elem)': expects 3 arguments - 2 provided
  C:\Program Files\Microsoft Visual Studio\2022\Preview\VC\Tools\MSVC\14.31.31103\include\string(26): note: see declaration of 'std::getline'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(26): error C2146: syntax error: missing ';' before identifier 'cout'
C:\Users\phoebe\source\repos\booststreamtest\booststreamtest\booststreamtest.cpp(30): error C2143: syntax error: missing ';' before '}'
  ninja: build stopped: subcommand failed.

@PhoebeHui
thank you for your attention. There was a error in the code sample I posted, now I fixed  in the code sample in the main post. However I add it also here:
#include <iostream>
#include <fstream>
#include <string>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/filter/zstd.hpp>
#include <boost/filesystem.hpp>

using namespace std;
using namespace boost::filesystem;

int main(int argc, char** argv) {
    path p("file.zst");
    boost::filesystem::ifstream file(p, ios_base::in | ios_base::binary);
    boost::iostreams::filtering_streambuf<boost::iostreams::input> inbuf;
    inbuf.push(boost::iostreams::zstd_decompressor());
    inbuf.push(file);

    istream instream(&inbuf);

    std::string line;
    std::getline(instream, line);
    std::cout << line << std::endl;

    return 0;

}

@emidelgo, thanks for updating the repro code, I can repro this issue now, it looks a port bug. I will take a look.

@emidelgo, thanks for updating the repro code, I can repro this issue now, it looks a port bug. I will take a look.

Thank you. These errors occurs also in linux, with triplet "x64-linux", in this case both in Debug and Release mode, when using boost-iostreams with zstd or gzip/zlib.

@emidelgo, thanks for trying it in linux! on windows, it's due to zstd, the static libs named zstd_static, which doesn't link to boost-iostream, that cause this issue.
I will try it with x64-linux.

on windows, it's due to zstd, the static libs named zstd_static

Note the discussion in #22822.

@emidelgo, thanks for trying it in linux! on windows, it's due to zstd, the static libs named zstd_static, which doesn't link to boost-iostream, that cause this issue.
I will try it with x64-linux.

I provide you the code for testing on linux with also gzip:
#include <iostream>
#include <fstream>
#include <string>
#include <boost/iostreams/filtering_streambuf.hpp>
#include <boost/iostreams/filter/gzip.hpp>
#include <boost/filesystem.hpp>

using namespace std;
using namespace boost::filesystem;

int main(int argc, char** argv) {
    path p("file.gz");
    boost::filesystem::ifstream file(p, ios_base::in | ios_base::binary);
    boost::iostreams::filtering_streambuf<boost::iostreams::input> inbuf;
    inbuf.push(boost::iostreams::gzip_decompressor());
    inbuf.push(file);

    istream instream(&inbuf);

    std::string line;
    std::getline(instream, line);
    std::cout << line << std::endl;

    return 0;

}

CMakeFile.txt
cmake_minimum_required (VERSION 3.21)
set (CMAKE_CXX_STANDARD 20)

#if(NOT DEFINED CMAKE_TOOLCHAIN_FILE AND DEFINED ENV{CMAKE_TOOLCHAIN_FILE})
#   set(CMAKE_TOOLCHAIN_FILE $ENV{CMAKE_TOOLCHAIN_FILE})
#endif()

add_executable (CMakeProject5 "DatasetProcessor.cpp" "DatasetProcessor.h")

find_package(ZLIB REQUIRED)
target_link_libraries(CMakeProject5 PRIVATE ZLIB::ZLIB)

find_package(Boost REQUIRED COMPONENTS fiber filesystem iostreams)
target_link_libraries(CMakeProject5 PRIVATE Boost::boost Boost::fiber Boost::filesystem Boost::iostreams)

@emidelgo, thanks for the repro code! could you try below code instead?
CMakeLists.txt
cmake_minimum_required (VERSION 3.21)
set (CMAKE_CXX_STANDARD 20)

#if(NOT DEFINED CMAKE_TOOLCHAIN_FILE AND DEFINED ENV{CMAKE_TOOLCHAIN_FILE})
#   set(CMAKE_TOOLCHAIN_FILE $ENV{CMAKE_TOOLCHAIN_FILE})
#endif()

add_executable (CMakeProject5 "DatasetProcessor.cpp" "DatasetProcessor.h")

find_package(Boost REQUIRED COMPONENTS fiber filesystem iostreams)
target_link_libraries(CMakeProject5 PRIVATE Boost::boost Boost::fiber Boost::filesystem Boost::iostreams)

find_package(ZLIB REQUIRED)
target_link_libraries(CMakeProject5 PRIVATE ZLIB::ZLIB)

@PhoebeHui
thank you. Yes, postponing the dependency of zlib or zstd after boost in the CMakeLists.txt appears to work fine for x64-linux, both in Debug and Release.
Is this an expected behavior about the ordering of dependencies?

@emidelgo, it's due to the library order in static linking in gcc, you can reference https://stackoverflow.com/questions/45135/why-does-the-order-in-which-libraries-are-linked-sometimes-cause-errors-in-gcc or https://www.linuxtopia.org/online_books/an_introduction_to_gcc/gccintro_18.html

This issue would be fixed by https://github.com/microsoft/vcpkg/pull/22822.

@emidelgo, the PR has been merged, please get lateset source and try again.

@PhoebeHui I confirm the bug is now fixed. Thank you.

authors: PhoebeHui dg0yt emidelgo