* Update lldb-mi build
Hardcode llvm/lldb-mi commits to match the ones in cgmanifest.
Added parameters to support building for different arch and on
different machines.
* Refactor
* Remove the remote extensions from the pack as remote is considered "advanced"
* Mark the pack to not be compatible with "web" so that it is not offered as a recommendation.
This PR adds in a cgmanifest.json file to comply with Component
Governance Compliance.
This adds two registrations to llvm-project and lldb-mi as components as
they are packaged and published with the macOS version of the VS Code
C/C++ Extension.
it looks like in [package.json line 5](https://github.com/microsoft/vscode-cpptools/blob/a62acdb5a52438540c266b409a0ee7f8e64f7a9b/Extension/package.json#L5), we add a suffix, "main", to the version. When we assign customers to target populations for experiments, we were trying to assign customers without any suffix to Public, which resulted in no one being included. Instead, I think we should be checking if the suffix is "main" and assign those customers to Public.
Debugger now ships using .NET 5 Runtime to run OpenDebugAD7.
Supports:
- win7-x86
- win-x64
- win10-arm64
- linux-x64
- linux-musl-x64
- linux-arm
- linux-arm64
- osx-x64
Cleaned up unused setup files.
Updated packageManager to download alpine dependencies.
Removed 'removeUnnecessaryFile' step since that removed windows
configurations for OpenDebugAD7.
* removed walkthrough task for Build your C++ file and simplified instructions for Run and debug your C++ file
* Addressing PR feedback - removed unused files and added step for selecting compiler in markdown file for Run and debug your C++ file
* Add new "console" launch config for vsdbg
This PR adds new console support for the cppvsdbg debug type.
This removes the legacy 'externalConsole' flag with 'console'.
Console has four enums:
- internalConsole: Output to the VS Code Debug Console. This doesn't
support reading console input (ex:Console.ReadLine)
- integratedTerminal: VS Code's integrated terminal
- externalTerminal: External terminal that can be configured via user
settings
- newExternalWindow: Console applications will be launched in their own
external console window which will end when the application stops.
Non-console applications will run without a terminal, and
stdout/stderr will be ignored.
* change master to main
* check for duplicate names
* check duplicates before removing the later configs
* spelling check
* fix spelling error
* add configNameInvalid for UI error(won't show yet)
* show the UI error
* squiggle for all duplicates
* change let to const
* squiggle for first one as well
* let to const
* Update link for Windows Debugger
This PR updated the License.txt when vsdbg is downloaded in
debugAdapters.
See https://github.com/microsoft/vscode-cpptools/pull/6735
* Update integreity hash for the Windows Debugger
* Output the cppbuild command used. Fixes#6647 .
Also fixes "D" command line warnings with cl.exe.
Move the build result message to the end.
Handle the /nologo case and always shows the logo/header if it exists (but default to use /nologo).
* localizing for task provider
* localize single_file_mode_not_available
* remove end of line from localalized string
* modify error(s)
* remove space from localized string
* remove space from localized string
* localizing for task provider
* localize single_file_mode_not_available
* remove end of line from localalized string
* modify error(s)
* remove space from localized string
* remove space from localized string
Add resolveDebugConfigurationWithSubstitutedVariables for
configurationProviders.
Keeping resolveDebugConfiguration to return null if type is not provided
in order to prompt `provideDebugConfiguration`.
* [cppdbg] Support new sourceFileMap schema
For cppdbg, sourceFileMap can be used for binding breakpoints.
If keeping with the old format "<source-path>":"<target-path>", it will
always be used for breakpoints.
If you use the new:
"<compile-path>" : {
"editorPath": "<target-path>",
"useForBreakpoints": true
}
The sourceMap will only be used for frame enumeration.
* Fix linter issues
* Addressing PR comments
This PR uses the
DebugConfigurationProvider.resolveDebugConfigurationWithSubstitutedVariables
which allows the debug configuration to wait for the preLaunchTask to
complete before continuing on and resolving variables that may have been
set in the 'tasks.json'.
This also resolves the logging issue where the 'Build and Debug Active
File' preLaunchTask uses the current file but we switch to the output
window for logging.
* Fix 'Build and Debug Active File' race condition with EngineLogs
If users use 'Build and Debug Active File' with "engineLogging", the resolveDebugConfigurations will quickly switch to the output window and `${fileBasenameNoExtension}` will resolve to something similar to `./extension-output-#5`.
This may be a bug with VS Code determining the output window to be a file, but this will unblock users who need to enable engine logging for this scenario.
* adding standard std version to clang_format_style
* add new cppBuildTaskProvider
* add Sean's changes to tasks
* draft
* draft 2
* draft 3 - working
* windows version
* fix cwd path
* fix cwd
* change header and source file set
* minor changes
* make new instance
* create new instance
* remove compilerPath input
* review changes
* solving the error due to space in file name
* showing the error message
* fix lint
* add set timeout and setinterval from timers
* Rename cppbuildTaskProvider.ts to cppBuildTaskProvider.ts
* fire the events with zero
* delete filewatcher
* localize strings
* change changelog.md
* changelog
* changelog
* change format
* wait dobuild
* use checkFileExists
* after test
* after test2
* add properties
* change the doBuild
* this.closeEmitter.fire(result);
* change doBuild
* very minor change
* label vs name resolved
* draft
* draft for Sean
* before cleaning the code
* Stable, Clean, Before API proposal
* adding details to the tasks menue
* add TODO
* remove extra ",remove description,merge from local
* remove task rename in this versoin
* remove TODOs
* merge the "default" stuff
* remove some parts of proposals
* fix linter errors
* add import * as which from 'which';
* clean up the code after version 1.0.0
* add new line
* adapt to the new Vs Code API
* linter error
* revert changelog
Co-authored-by: Elaheh Rashedi <[email protected]>
Co-authored-by: Sean McManus <[email protected]>
* Fix issue with LSP process not getting shut down gracefully (#6141)
* Update version number and changelog
* Update changelog, fwlinks, and hashes.
Co-authored-by: Colen Garoutte-Carson <[email protected]>
Co-authored-by: Sean McManus <[email protected]>
* add increment to progress bar
* remove localized string
* calculate the increment based on num of packages
* change increment function
* cleanup extra progress
* add typedef
Co-authored-by: Sean McManus <[email protected]>
Fix c_cpp_properties.json not opening as JSON with comments. Follow up to #5885
Fix the configuration UI disappearing when selection moves to the C/C++ or Log Diagnostics window, mentioned at #5822 .
Fix an unreported bug where the configuration UI wouldn't appear for non-cpp files that are active on startup (until the selection changed).
Add more more C/C++ related files to ShowConfigurations.
Authored-by: Elaheh Rashedi <[email protected]>
bug fix: https://github.com/microsoft/vscode-cpptools/issues/4829
- Check for the core binary files in the extension folder and show this warning message if any of the binaries are missing:
- Check for the important JSON files in the extension folder and show this error message if any of the binaries are missing (the message is shown if the user has installed a VSIX that doesn't match their OS).
* ignore 'screen size is bogus' error; fixesmicrosoft/vscode#75932; imitiates similar fix for a different extension microsoft/vscode-node-debug/commit/5298920
* ignore 'screen size is bogus' error; fixesmicrosoft/vscode#75932; imitiates similar fix for a different extension microsoft/vscode-node-debug/commit/5298920
Fixes:
- It doesn't check for a downgrade to non-insiders on startup, only when the setting changes.
- There was a bug with the timer code that checks for a new insiders every hour.
- It wasn't bypassing the autoUpdate check when the user manually switches the updateChannel.
* [cppvsdbg] Add logging ThreadExit and ProcessExit
This PR adds two log flags for ThreadExit and ProcessExit events.
This will remove the "The thread 10564 has exited with code 0 (0x0)."
and "The program '[24104] ConsoleApplication1.exe' has exited with code
0 (0x0)." messages.
* Print launch.json to C/C++ Output Log
This PR adds a check in resolveDebugConfiguration so that if a user adds
logging.engineLogging = true in the launch.json, we will output the
resovled json in the C/C++ Output.
* Use GitHub bug notation and add title for log
Co-authored-by: Sean McManus <[email protected]>
* Added system to store and query properties from the active C/C++ configuration
Co-authored-by: yngwe@farnsworth <yngwe@farnsworth>
Co-authored-by: yngwe@bender <yngwe@bender>
* Added system to store and query properties from the active C/C++ configuration
Co-authored-by: yngwe@farnsworth <yngwe@farnsworth>
Co-authored-by: yngwe@bender <yngwe@bender>
With https://github.com/microsoft/MIEngine/pull/1006, the debug adapter
supports 'quoteArgs' in pipeTransports. If the user wishes to handle the
quoting for pipeTransport arguments, they should set this field to
'false'. It currently defaults to true.
For example, if quoteArgs is 'true', the pipe command will result in
"bash.exe -c '/usr/bin/gdb --interpreter=mi'" If false,
it will result to "wsl.exe -c /usr/bin/gdb --interpreter=mi"
Fix for #5618
Scenario 1: Manually change files.associations. Bug: We weren't sending files.associations along with the settings change.
Scenario 2: Open a .C file. Bug: The language associations need to be changed before sending the didOpen.
* add new error message
* add error to the end of the list
* add new error message with no squiggles
* adding more info to the error message
Co-authored-by: Elaheh Rashedi <[email protected]>
Co-authored-by: Sean McManus <[email protected]>
Co-authored-by: Bob Brown <[email protected]>
* add test, no warning yet
* check for the assets, add more test
* addd test for Default channel
* fix spelling srrors
* update Default chanel tests
Co-authored-by: Elaheh Rashedi <[email protected]>
Co-authored-by: Sean McManus <[email protected]>
* Adding the arm/arm64 packages for mono runtime
Adding the arm/arm64 packages for the mono runtime. This is to enable
remote-ssh extension debugging.
* Undo activate change
* Fix lint error
* Remove vsce dependency
If the darwin version changes and is upgraded to Mojave or higher, users
will need to use ./debugAdapters/lldb-mi. These changes will cleanup the
old files and cause the online installation process to run again.
Co-authored-by: Sean McManus <[email protected]>
Our offline installer will include two versions of lldb.
./debugAdapters/lldb is lldb-mi 3.8 and is used for High-Sierra and older
./debugAdapters/lldb-mi is lldb-mi 10.x and is used for Mojave and
higher.
Co-authored-by: Andrew Wang <[email protected]>
Our offline installer will include two versions of lldb.
./debugAdapters/lldb is lldb-mi 3.8 and is used for High-Sierra and older
./debugAdapters/lldb-mi is lldb-mi 10.x and is used for Mojave and
higher.
Adds multiroot support for a single language server process.
Instead of a single settings and cpp_properties objects, there are one per workspace folder.
There is a single browse database, but multiple browse-related settings (e.g. for per-folder files.exclude), so workspace parsing operates with a separate pass per workspace folder.
If a user does not provide a custom lldb-mi on macOS running in LLDB
mode. We check to see if the XCode/XCode CLI LLDB.framework dependencies
exist.
Also adds both LLDB-MI Package based on versionRegex
This PR also adds in PlatformInfo.version and IPackage.versionRegex and
IPackage.matchVersion.
Currently only darwin PlatformInfo.version is set since only the LLDB-MI
package utilizes IPackage.versionRegex and matchVersion.
The LLDB-MI 3.8 package is used for High Sierra and lower and the newer
lldb-mi is used for Mojave and higher
* add support for a new command: cpptools.setActiveConfigName
Command allows other extensions to control activeConfigName
* post review fix: localized config-name-not-found message
* Add support for SymbolLoadInfo
This allows users to disable symbol loading by setting the LoadAll field
in the SymbolLoadInfo object to false.
The excludeList can be used to ignore specific modules.
* Add descriptions for SymbolLoadInfo
* Addressing PR issues
* Fixing descriptions
* Update c_cpp_properties.json desc
* minor text change
* fix casing on "the"
* update names
* update ipch on FAQ
* fix text
* fix wording
* update link in FAQ
* update ipch name and title
* missing s
* use macOS
* Update envFile variable substitution
In launch.json, the `envFile` configuration can substitute
${workspaceFolder}, ${workspaceRoot} and ${env::???}.
* Fix lint issues
* Decrease F5 workflow time w/ VSCode
webpack is being called twice. Once with --mode production and then
rewritten with --mode development. Fixing tasks and launch.
* Check host machine for specific quotes for command
Attach to process is not working on Windows OS due to the single quote
then double inner quote. However, this is required for linux because if
you do not, it will evaluate the variables within the double quotes.
* Enable 'envFile' for cppdbg
This PR allows the cppdbg configuration to set environment variables
via a envFile.
Example envFile:
ENVIRONMENT_VAR_1=Hello
ENVIRONMENT_VAR_2=15
* Flame on timing
* Fixed linter errors
* Log IntelliSense refresh time information for debug logging level.
* Rephrasing log message
* Print the message in the output window instead of the console.
* Work around issue with getting stale contents from openTextDocument
* Avoid calling openTextDocument when creating a new file, and use only writeFile. Unsubscribe from window activation when settings UI is not visible.
* Switch to using editorTabSize for settings file
* Adding support for .env files for cppvsdbg
This PR allows users to have a .env file that listed as
KEY=VALUE or KEY="VALUE WITH SPACE" to be used as environment variables
when launching a process. Anything that begins with '#' is treated as a
comment. Blank lines are ignored.
This .env file will be used if envFile passed in with the launch.json.
It will also work with the existing environment variable, however
anything listed in the .env file will overwrite anything from the
environment field in the launch.json.
* Update 'envFile' description and add documentation
* Add debugHeap toggle and turn off by default
This PR adds a launch.json setting to enable debugHeap if users are
intersted in using it. By default, debug heap will be disabled.
* Add settings webview
* Add setting: useSettingsUI
* Use existing global setting (workbench.settings.editor == ui | json)
* handle changes from webview
* Add content security policy to html
* Move use of workbench settings into OtherSettings class
* sync ui and json file
* Add functions for each way to open settings (UI, JSON, based on config)
* Remove unnecesary command
* add telemetry. handle failed parse. Add UI command to toast notification.
* add newline
* fix value properties of HTML element
* fix another html value
* fix formatting
* add typedef
* fix more formatting and ===
* fix code styling. fixed some bugs.
* move configDirty flag reset
* add typedef to onWindowStateChanged
* small clean up
* Update changelog.
* Remove confusing quotes from clang_format_style descriptions, and use the Visual Studio style as the clang_format_style examples.
Add call in provideCustomConfiguration to new QueryTranslationUnitSourceRequest. Use result to decide whether it's necessary to request a custom configuration.
* Add queryTranslationUnitSource
* Update "Building the Extension.md"
about:Issues pertaining to debugging such as call stack, breakpoints, watch window,
name:Bug Report - Debugger
about:Create a bug report for debugging such as call stack, breakpoints, watch window,
launching or attaching to a debuggee.
title:''
labels:''
assignees:''
---
Type: Debugger
**Input information below**
Bug type: Debugger
<!-- Prior to creating a bug report, please review:
📝 Existing issues at https://github.com/Microsoft/vscode-cpptools/issues
📜 Our documentation at https://code.visualstudio.com/docs/languages/cpp
📙 FAQs at https://code.visualstudio.com/docs/cpp/faq-cpp
-->
**Please review existing issues and our documentation at https://github.com/Microsoft/vscode-cpptools/tree/master/Documentation prior to filing an issue.**
**Describe the bug**
- OS and Version:
@@ -17,6 +24,7 @@ Type: Debugger
- Other extensions you installed (and if the issue persists after disabling them):
- A clear and concise description of what the bug is.
**To Reproduce**
*Please include a code sample and `launch.json` configuration.*
Steps to reproduce the behavior:
@@ -25,6 +33,7 @@ Steps to reproduce the behavior:
3. Scroll down to '....'
4. See error
**Additional context**
*If applicable, please include logging by adding "logging": { "engineLogging": true, "trace": true, "traceResponse": true } in your `launch.json`*
Add any other context about the problem here including log or error messages in your Debug Console or Output windows.
about:Issues pertaining to downloading, installing, or building the extension.
name:Bug Report - General Extension
about:Create a bug report for downloading, installing, or building the extension.
title:''
labels:''
assignees:''
---
Type: General
**Input information below**
Bug type: General
<!-- Prior to creating a bug report, please review:
📝 Existing issues at https://github.com/Microsoft/vscode-cpptools/issues
📜 Our documentation at https://code.visualstudio.com/docs/languages/cpp
📙 FAQs at https://code.visualstudio.com/docs/cpp/faq-cpp
-->
**Please review existing issues and our documentation at https://github.com/Microsoft/vscode-cpptools/tree/master/Documentation prior to filing an issue.**
**Describe the bug**
- OS and Version:
@@ -16,6 +23,7 @@ Type: General
- Other extensions you installed (and if the issue persists after disabling them):
- A clear and concise description of what the bug is.
**To Reproduce**
*Please include code sample and `task.json` files.*
Steps to reproduce the behavior:
@@ -24,11 +32,14 @@ Steps to reproduce the behavior:
3. Scroll down to '....'
4. See error
**Expected behavior**
A clear and concise description of what you expected to happen.
<!-- A clear and concise description of what you expected to happen. -->
**Screenshots**
If applicable, add screenshots to help explain your problem.
<!-- If applicable, add screenshots to help explain your problem. -->
**Additional context**
Add any other context about the problem here including log messages from the Output window.
<!-- Add any other context about the problem here including log messages from the Output window. -->
about:'Issues pertaining to IntelliSense, autocomplete, code editing, etc.'
name:Bug Report - Language Service
about:'Create a bug report for IntelliSense, autocomplete, code editing, code navigation, etc.'
title:''
labels:''
assignees:''
---
**Type: LanguageService**
<!----- Input information below ----->
Bug type: LanguageService
<!--
**Please review existing issues and our documentation at https://github.com/Microsoft/vscode-cpptools/tree/master/Documentation prior to filing an issue.**
<!-- Prior to creating a bug report, please review:
📝 Existing issues at https://github.com/Microsoft/vscode-cpptools/issues
📜 Our documentation at https://code.visualstudio.com/docs/languages/cpp
📙 FAQs at https://code.visualstudio.com/docs/cpp/faq-cpp
-->
**Describe the bug**
- OS and Version:
- VS Code Version:
- C/C++ Extension Version:
- Other extensions you installed (and if the issue persists after disabling them):
-A clear and concise description of what the bug is.
-If using SSH remote, specify OS of remote machine:
- A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).
**To Reproduce**
<!-- Steps to reproduce the behavior: -->
<!-- *The most actionable issue reports include a code sample including configuration files such as c_cpp_properties.json* -->
**Steps to reproduce**
<!-- Provide clear steps to reproduce the bug: -->
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
**Expected behavior**
<!-- A clear and concise description of what you expected to happen. -->
**Code sample and logs**
<!-- Please provide code sample, your c_cpp_properties.json and logs. -->
- Code sample
- Configurations in `c_cpp_properties.json`
- Logs from running `C/C++: Log Diagnostics` from the VS Code command palette
- Logs from [the language server logging](https://code.visualstudio.com/docs/cpp/enable-logging-cpp#_enable-logging-for-the-language-server)
**Screenshots**
<!-- If applicable, add screenshots to help explain your problem. -->
**Additional context**
<!--
* Call Stacks: For bugs like crashes, deadlocks, infinite loops, etc. that we are not able to repro and for which the call stack may be useful, please attach a debugger and/or create a dmp and provide the call stacks. Windows binaries have symbols available in VS Code by setting your "symbolSearchPath" to "https://msdl.microsoft.com/download/symbols".
* Add any other context about the problem here including log messages in your Output window ("C_Cpp.loggingLevel": "Debug" in settings.json).
Providing call stacks:
For bugs like crashes, deadlocks, infinite loops, etc. that we are not able to repro and for which the call stack may be useful, please attach a debugger and/or create a dmp and provide the call stacks. Windows binaries have symbols available in VS Code by setting your "symbolSearchPath" to "https://msdl.microsoft.com/download/symbols".
Instructions for attaching debugger to language service process:
- cron:012***# Run at 12:00 PM UTC (4:00 AM PST, 5:00 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:by design
ignoreLabels:debugger,Feature Request,more info needed,internal
closeDays:60
closeComment:"This issue has been closed automatically because it's labeled as 'by design' and has not had recent activity."
pingDays:80
pingComment:"Hey @${assignee}, this issue might need further attention.\n\n@${author}, you can help us out by closing this issue if it is no longer relevant."
- cron:1012***# Run at 12:10 PM UTC (4:10 AM PST, 5:10 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:duplicate
ignoreLabels:debugger,Feature Request,more info needed,by design,internal
closeDays:60
closeComment:"This issue has been closed automatically because it's labeled as a 'duplicate' and has not had recent activity."
pingDays:80
pingComment:"Hey @${assignee}, this issue might need further attention.\n\n@${author}, you can help us out by closing this issue if it is no longer relevant."
- cron:5011***# Run at 11:50 AM UTC (3:50 AM PST, 4:50 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:enhancement
ignoreLabels:debugger,internal,Feature Request
addLabels:more votes needed
closeDays:60
maximumVotes:2
closeComment:"This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog."
- cron:4011***# Run at 11:40 AM UTC (3:40 AM PST, 4:40 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:enhancement
ignoreLabels:debugger,internal,Feature Request
addLabels:more votes needed
closeDays:60
maximumVotes:2
closeComment:"This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog."
- cron:5011***# Run at 11:50 AM UTC (3:50 AM PST, 4:50 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:Feature Request
ignoreLabels:debugger,internal
addLabels:more votes needed
closeDays:60
maximumVotes:2
closeComment:"This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog."
- cron:4011***# Run at 11:40 AM UTC (3:40 AM PST, 4:40 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:Feature Request
ignoreLabels:debugger,internal
addLabels:more votes needed
closeDays:60
maximumVotes:2
closeComment:"This feature request is being closed due to insufficient upvotes. When enough upvotes are received, this issue will be eligible for our backlog."
- cron:1011***# Run at 11:10 AM UTC (3:10 AM PST, 4:10 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:more info needed,debugger
ignoreLabels:language service,internal
involves:wardengnaw,pieandcakes,calgagi
closeDays:14
closeComment:"This issue has been closed automatically because it needs more information and has not had recent activity."
pingDays:7
pingComment:"Hey @${assignee}, this issue might need further attention.\n\n@${author}, you can help us out by closing this issue if the problem no longer exists, or adding more information."
- cron:1011***# Run at 11:10 AM UTC (3:10 AM PST, 4:10 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:more info needed
ignoreLabels:debugger,internal
closeDays:60
closeComment:"This issue has been closed automatically because it needs more information and has not had recent activity."
pingDays:80
pingComment:"Hey @${assignee}, this issue might need further attention.\n\n@${author}, you can help us out by closing this issue if the problem no longer exists, or adding more information."
- cron:2011***# Run at 11:20 AM UTC (3:20 AM PST, 4:20 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:question,debugger
ignoreLabels:language service,internal
involves:wardengnaw,pieandcakes,calgagi
closeDays:14
closeComment:"This issue has been closed automatically because it's labeled as a 'question' and has not had recent activity."
pingDays:7
pingComment:"Hey @${assignee}, this issue might need further attention.\n\n@${author}, you can help us out by closing this issue if the question has been answered."
- cron:2011***# Run at 11:20 AM UTC (3:20 AM PST, 4:20 AM PDT)
workflow_dispatch:
inputs:
readonly:
description:"readonly: Specify true or 1 to prevent changes from being commited to GitHub"
default:false
jobs:
main:
runs-on:ubuntu-latest
steps:
- name:Checkout Actions
uses:actions/checkout@v2
- name:Install Actions
run:cd ./.github/actions && npm install --production && cd ../..
- name:Stale Closer
uses:./.github/actions/StaleCloser
with:
readonly:${{ github.event.inputs.readonly }}
labels:question
ignoreLabels:debugger,internal
closeDays:60
closeComment:"This issue has been closed automatically because it's labeled as a 'question' and has not had recent activity."
pingDays:80
pingComment:"Hey @${assignee}, this issue might need further attention.\n\n@${author}, you can help us out by closing this issue if the question has been answered."
This folder contains the entitlements needed for the debugger to run on macOS.
We use the entitlements that the .net runtime uses. See https://github.com/dotnet/runtime/blob/57678512d214af368ff055f358c5106f1aa19ac4/eng/pipelines/common/entitlements.plist
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact opencode@microsoft.com with any additional questions or comments.
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
Resources:
- [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/)
- [Microsoft Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/)
* File an [issue](https://github.com/Microsoft/vscode-cpptools/issues) and a [pull request](https://github.com/Microsoft/vscode-cpptools/pulls) with the change and we will review it.
* If the change affects functionality, add a line describing the change to [**CHANGELOG.md**](Extension/CHANGELOG.md).
* Try and add a test in [**test/extension.test.ts**](Extension/test/unitTests/extension.test.ts).
* Run tests via opening the [**Extension**](https://github.com/Microsoft/vscode-cpptools/tree/master/Extension) folder in Visual Studio Code, selecting the "Launch Tests" configuration in the Debug pane, and choosing "Start Debugging".
* Run tests via opening the [**Extension**](https://github.com/Microsoft/vscode-cpptools/tree/main/Extension) folder in Visual Studio Code, selecting the "Launch Tests" configuration in the Debug pane, and choosing "Start Debugging".
## About the Code
* Execution starts in the `activate` method in [**main.ts**](Extension/src/main.ts).
*`processRuntimeDependencies` handles the downloading and installation of the OS-dependent files. Downloading code exists in [**packageManager.ts**](Extension/src/packageManager.ts).
*`downloadCpptoolsJsonPkg` handles the **cpptools.json**, which can be used to enable changes to occur mid-update, such as turning the `intelliSenseEngine` to `"Default"` for a certain percentage of users.
* The debugger code is in the [**Debugger**](https://github.com/Microsoft/vscode-cpptools/tree/master/Extension/src/Debugger) folder.
* The debugger code is in the [**Debugger**](https://github.com/Microsoft/vscode-cpptools/tree/main/Extension/src/Debugger) folder.
* [**LanguageServer/client.ts**](Extension/src/LanguageServer/client.ts) handles various language server functionality.
* [**LanguageServer/configurations.ts**](Extension/src/LanguageServer/configurations.ts) handles functionality related to **c_cpp_properties.json**.
* [**telemetry.ts**](Extension/src/telemetry.ts): Telemetry data gets sent to either `logLanguageServerEvent` or `logDebuggerEvent`.
* The Tag Parser (symbol database) doesn't automatically expand macros, so the [**cpp.hint**](Extension/cpp.hint) file contains definitions of macros that should be expanded in order for symbols to be parsed correctly.
## String Localization
* [vscode-nls](https://github.com/microsoft/vscode-nls) is used to localize strings in TypeScript code. To use [vscode-nls](https://github.com/microsoft/vscode-nls), the source file must contain:
* For each user-facing string, wrap the string in a call to localize:
```typescript
constreadmeMessage: string=localize("refer.read.me","Please refer to {0} for troubleshooting information. Issues can be created at {1}",readmePath,"https://github.com/Microsoft/vscode-cpptools/issues");
```
* The first parameter to localize should be a unique key for that string, not used by any other call to localize() in the file unless representing the same string. The second parameter is the string to localize. Both of these parameters must be string literals. Tokens such as {0} and {1} are supported in the localizable string, with replacement values passed as additional parameters to localize().
This is a sample debuggable C++ project. It uses the vendor provided version of clang installed. `tasks.json` and `launch.json` have been edited to demonstrate how to create a configuration for a C++ project that builds with clang.
There's a sample build task in `.vscode/tasks.json`; you can also see the build configurations by using the menu option `Configure` -> `Configure Tasks` or by clicking the gear icon in the Debug Panel.
To run a build, use the menu option `Tasks` -> `Run Build Task...`.
There's a sample debug configuration in `.vscode/launch.json`; you can also see the configuration by using the menu option `Debug` -> `Open Configurations`.
To debug the build, use the menu option `Debug` -> `Start Debugging`. The executable will launch and stop in the main function.
* From a command line, run the following commands from the **Extension** folder in the root of the repository:
*`npm install` will install the dependencies needed to build the extension.
* **(optional)** `npm install -g vsce` will install `vsce` globally to create a VSIX package that you can install.
* **(optional)** Set an environment variable `CPPTOOLS_DEV=1`.
* This enables the local developer workflow when testing the debugger, copying dependencies from the **node_modules** folder. Testing the language server does not require this step.
*`yarn install` will install the dependencies needed to build the extension.
* **(optional)** `yarn global add vsce` will install `vsce` globally to create a VSIX package that you can install.
* Open the **Extension** folder in Visual Studio Code and press F5. This will launch a VS Code Extension Host window and activate the TypeScript debugger. You can set breakpoints on the extension source code and debug your scenario.
* If, after pressing F5, you see the following error in the `[Extension Development Host]` window,
> Unable to start the C/C++ language server. IntelliSense features will be disabled. Error: Missing binary at .../vscode-cpptools/Extension/bin/cpptools
* Then, you can follow the instructions in this [comment in a discussion about building this extension locally](https://github.com/microsoft/vscode-cpptools/discussions/8745#discussioncomment-2091563).
> get the <package.version.number> binaries from installing the extension and then copying the binaries
1. To do this, install this extension from the Visual Studio Marketplace and find its location on your device. It might be in a directory like `\\wsl$\Ubuntu\home\hamir\.vscode-server\extensions\ms-vscode.cpptools-<package.version.number>`, for example.
2. Next, go to the `bin/` directory of the aforementioned directory, and drag-and-drop, or copy-and-paste, `cpptools` and `cpptools-srv` from `...\extensions\ms-vscode.cpptools-<package.version.number>\bin\` to this repository's `Extension\bin\` directory on your local device, so that `.../vscode-cpptools/Extension/bin/cpptools` and `.../vscode-cpptools/Extension/bin/cpptools-srv` both exist in your workspace.
3. The aforementioned warning should be gone, and Intellisense, which gives those squiggly red error lines, should now be present.
4. The `insiders` branch has binaries compatible with the latest Pre-Release version of the extension, and the `release` branch has binaries compatible with the latest Release version, but the `main` branch may have TypeScript changes that are incompatible with the published binaries, in which case, you'll need to create a branch off the `insiders` or `release` branches.
* Feel free to use [the Discussions tab of this repository](https://github.com/microsoft/vscode-cpptools/discussions) if you have any further questions on building this extension locally.
The Microsoft Windows C/C++ debugger (cppvsdbg) supports configuration options for if the debugger stops when exceptions are thrown. This is done with the 'All Exceptions' check box in the BREAKPOINTS section of the 'Run and Debug' view.
Note that the BREAKPOINTS section will be missing this entry until the first time that the folder has been debugged with the 'cppvsdbg' debugger.
Checking 'All Exceptions' will configure the debugger to stop when an exception is thrown.
##### Exception Conditions
The 'All Exceptions' checkbox support conditions to break on only selected exception types (C++ exceptions) or codes (Win32 exceptions). To edit the condition, click on the pencil icon or right click on the entry and invoke 'Edit Condition'. The condition is a comma-separated list of exception types and codes to break on, or if the list starts with '!', a list of exception types and codes to ignore.
Examples conditions:
| Example condition value | Result |
|-------------------------|--------|
| 0xC0000005, 0xC0000094 | Break on Win32 Access Violation exceptions and integer division by zero exceptions |
| std::out_of_range, 0xC0000005 | This will break on out-of-range exceptions, and access violation exceptions |
| !MyExceptionClass | This will break on all exceptions except C++ `MyExceptionClass` exceptions |
| !MyExceptionClass, 0x6831C815 | This will break on all exceptions except C++ `MyExceptionClass` exceptions and Win32 exceptions with custom code 0x6831C815 |
MIEngine is one of the components used to enable the C/C++ debugging scenario with the Microsoft C/C++ extension with VS Code. This document is to help enable users who want to debug and contribute to MIEngine to fix issues or extend functionality. MIEngine is used to communicate with `gdb`/`lldb` using the MI protocol.
MIEngine is one of the components used to enable the C/C++ debugging scenario with the Microsoft C/C++ extension with VS Code. This document is to help enable users who want to debug and contribute to MIEngine to fix issues or extend functionality. MIEngine is used to communicate with `gdb`/`lldb` using the MI protocol.
@@ -19,7 +19,7 @@ You can open the solution file **MIDebugEngine.sln** located under **src** and c
The symbol files are as follows:
**On Windows**
**On Windows**
* Microsoft.MICore.pdb
* Microsoft.MIDebugEngine.pdb
* vscode\OpenDebugAD7.pdb
@@ -37,7 +37,7 @@ On Windows, the easiest way to debug is to use Visual Studio. Locate the **src\D
If you are not building the extension, Locate the **out\src\Debugger\extension.ts** file in the **.vscode\extensions\ms-vscode.cpptools** folder and open it in an editor.
Locate the following lines:
Locate the following lines:
```json
return{
command:command
@@ -48,13 +48,13 @@ and add the following line to the object:
args:["--pauseForDebugger"]
```
This will cause the debugger to look like it has hung once you start debugging, but in reality it is waiting for a debugger to attach. Set your breakpoints and attach your debugger to the `OpenDebugAD7.exe` process. Once the debugger is attached, VS Code should start debugging and you can reproduce your scenario.
This will cause the debugger to look like it has hung once you start debugging, but in reality it is waiting for a debugger to attach. Set your breakpoints and attach your debugger to the `OpenDebugAD7.exe` process. Once the debugger is attached, VS Code should start debugging and you can reproduce your scenario.
### Debugging MIEngine running on Linux or MacOS X
### Debugging MIEngine running on Linux or macOS
#### With MonoDevelop
On Linux and MacOS X, we use `mono` as our framework. You can download Xamarin Studio v5.10.1.6 and remotely attach to your Mac or Linux box to debug there.
On Linux and macOS, we use `mono` as our framework. You can download Xamarin Studio v5.10.1.6 and remotely attach to your Mac or Linux box to debug there.
##### Configure the extension to enable remote debugging
Open the **~/.vscode/extensions/ms-vscode.cpptools-\<version\>/debugAdapters/OpenDebugAD7** file with a text editor and locate and uncomment the line at the bottom. When you start debugging, it will now hang until the remote debugger is attached from Xamarin Studio.
Open the **~/.vscode/extensions/ms-vscode.cpptools-\<version\>/debugAdapters/OpenDebugAD7** file with a text editor and locate and uncomment the line at the bottom. When you start debugging, it will now hang until the remote debugger is attached from Xamarin Studio.
##### Attach the remote debugger
In MonoDevelop: Run -> Run With -> Custom Command Mono Soft Debugger.
Fill in the IP and port of the Linux/MacOS X machine and hit "Connect" to start debugging.
Fill in the IP and port of the Linux/macOS machine and hit "Connect" to start debugging.
After you've done this once, you can hit the MonoDevelop "Play" button or <kbd>F5</kbd> to bring up the connect dialog again.
@@ -113,7 +113,7 @@ After you've done this once, you can hit the MonoDevelop "Play" button or <kbd>F
##### Configure the extension to enable remote debugging
Open the **~/.vscode/extensions/ms-vscode.cpptools-\<version\>/debugAdapters/OpenDebugAD7** file with a text editor and locate and uncomment the line at the bottom. When you start debugging, it will now hang until the remote debugger is attached from VS Code.
Open the **~/.vscode/extensions/ms-vscode.cpptools-\<version\>/debugAdapters/OpenDebugAD7** file with a text editor and locate and uncomment the line at the bottom. When you start debugging, it will now hang until the remote debugger is attached from VS Code.
The `pipeArgs` can be any set of arguments necessary to setup and authenticate the pipe connection. In the example, a password is used but you can also use an ssh key.
You may also need to add a `sourceFileMap` to map the path of where the code exists on the remote shell to where it is locally:
```json
"sourceFileMap":{
// "remote": "local"
"/home/user/src":"/src/projectA/src"
}
```
## Attach
You can also use the above `pipeTransport` block to attach to a remote process. In the attach case, you will need to specify a `processId`. We have added the ability to query processes from the remote machine. To do this, change `"processId": "${command.pickProcess}"` to `"processId": "${command.pickRemoteProcess}"`. The `pipeTransport` settings will be used to query the processes on the remote machine. Then select the process from the drop down list. As with `launch`, you may need to configure `sourceFileMap`.
## Docker example
The `pipeTransport` can also be used to debug a process in a Docker container. For an attach, **launch.json** will include:
```json
"pipeTransport":{
"pipeCwd":"${workspaceRoot}",
"pipeProgram":"docker",
"pipeArgs":[
"exec",
"-i",
"hello_gdb",
"sh",
"-c"
],
"debuggerPath":"/usr/bin/gdb"
},
```
Where `hello_gdb` is the name of your container.
Launching a process is accomplished by starting a container and then using the same `pipeTransport` launch additional processes in the container. See this [**launch.json**](https://github.com/andyneff/hello-world-gdb/blob/master/.vscode/launch.json) for a [full example](https://github.com/andyneff/hello-world-gdb/).
The documentation for pipe transport has moved to https://code.visualstudio.com/docs/cpp/pipe-transport.
With the release of Windows 10 Creators Update (Build 15063), you will now be able to use Visual Studio Code and the Microsoft C/C++ extension to debug your [Windows Subsystem for Linux (WSL)](https://msdn.microsoft.com/en-us/commandline/wsl/about) projects.
Code can be written on Windows itself using VSCode and debugged through `bash.exe` to the Bash on Windows layer.
As of the Fall Creator's Update, you can have multiple distros installed, but `bash.exe` and `wsl.exe` use the default distro. Use [WSL Config](https://msdn.microsoft.com/en-us/commandline/wsl/wsl-config) to set your default distro.
**NOTE: Creator's Update (Build 15063 or later) is required due to bug-fixes within the subsystem that we rely on to provide debugging. Debugging using a previous version of WSL is unsupported and likely will not work. To check your Windows version, enter `winver` in a command prompt.**
## Prerequisites
* [Windows 10 Creators Update or later with Windows Subsystem for Linux](https://msdn.microsoft.com/en-us/commandline/wsl/install_guide) installed.
* Install g++/gcc and gdb within `WSL` to allow compiling and debugging. You can use the package manager to do this. For example, to install g++, you can run `sudo apt install g++` in the Bash window.
* [Visual Studio Code](https://code.visualstudio.com) + Microsoft C/C++ extension for VSCode.
## How-To
To debug, commands will be routed from Windows through `bash.exe` to set up debugging. Because our extension runs as a 32-bit process, it will need to use the `C:\Windows\SysNative` folder to access the `bash.exe` executable that is normally in `C:\Windows\System32`. We will be using the `"pipeTransport"` ability within the extension to do debugging and `"sourceFileMap"` to map the source from the subsystem's paths back to Windows path.
**NOTE: Applications will need to be compiled in the `Windows Subsystem for Linux (WSL)` prior to debugging.**
### Example `launch.json` for Launching
In the following example, I have a local drive, `Z:\` that has my source code within windows for an app called _kitchensink_. I have set up the `"program"` and `"cwd"` paths to point to the directory within `WSL`. I have set up the `"pipeTransport"` to use `bash.exe`. I have also set up a `"sourceFileMap"` to have everything that is returned by `gdb` that starts with `/mnt/z` to point to `Z:\\` in Windows.
```json
{
"name":"C++ Launch",
"type":"cppdbg",
"request":"launch",
"program":"/mnt/z/Bash/kitchensink/a.out",
"args":["-fThreading"],
"stopAtEntry":false,
"cwd":"/mnt/z/Bash/kitchensink",
"environment":[],
"externalConsole":true,
"windows":{
"MIMode":"gdb",
"setupCommands":[
{
"description":"Enable pretty-printing for gdb",
"text":"-enable-pretty-printing",
"ignoreFailures":true
}
]
},
"pipeTransport":{
"pipeCwd":"",
"pipeProgram":"c:\\windows\\sysnative\\bash.exe",
"pipeArgs":["-c"],
"debuggerPath":"/usr/bin/gdb"
},
"sourceFileMap":{
"/mnt/z":"z:\\"
}
}
```
### Example `launch.json` for Attaching to an Existing Process
This configuration similar to the launch process above. I have chosen to start the same application above from the Bash command line and now I want to attach to it for debugging. I have changed the `"processID"` to use the remote process picker by specifying the command `"${command:pickRemoteProcess}"` and set up the same `"sourceFileMap"`. When I press <kbd>F5</kbd> to attach, I get a picker drop down showing the running processes within `WSL`. I can scroll or search for the process I want to attach to and start debugging.
```json
{
"name":"C++ Attach",
"type":"cppdbg",
"request":"attach",
"program":"/mnt/z/Bash/kitchensink/a.out",
"processId":"${command:pickRemoteProcess}",
"windows":{
"MIMode":"gdb",
"setupCommands":[
{
"description":"Enable pretty-printing for gdb",
"text":"-enable-pretty-printing",
"ignoreFailures":true
}
]
},
"pipeTransport":{
"pipeCwd":"",
"pipeProgram":"c:\\windows\\sysnative\\bash.exe",
"pipeArgs":["-c"],
"debuggerPath":"/usr/bin/gdb"
},
"sourceFileMap":{
"/mnt/z":"z:\\"
}
}
```
The documentation for GCC on Windows Subsystem for Linux (WSL) has moved to https://code.visualstudio.com/docs/cpp/config-wsl.
The Natvis framework allows developers to write custom schemas to help visualize native objects.
For gdb/lldb debugging (`"type": "cppdbg"`), a subset of the Natvis framework has been ported to the C/C++ extension and the code resides in the [MIEngine](https://github.com/Microsoft/MIEngine) shared component. If additional features that are not implemented are requested, please file an [issue](https://github.com/Microsoft/MIEngine/issues) on the MIEngine GitHub page with details of what is missing.
For Visual C++ debugging (`"type": "cppvsdbg"`), the debugger contains the full implementation of the Natvis framework as Visual Studio.
## Documentation
The official documentation can be found [here](https://docs.microsoft.com/en-us/visualstudio/debugger/create-custom-views-of-native-objects).
## Schema
The Natvis schema can be found [here](natvis.xsd).
The documentation for Natvis has moved to https://code.visualstudio.com/docs/cpp/natvis.
<xs:documentation>Expression that points to value of the linked list node. It can be left empty or have 'this' to refer to the linked list node itself. This expression is evaluated under the context of the linked list node and not the parent linked list type.</xs:documentation>
@@ -402,7 +402,7 @@
<xs:documentation>
Indicates that the item should use the icon associated with general data.
</xs:documentation>
</xs:annotation>
</xs:annotation>
</xs:enumeration>
<xs:enumerationvalue="Method">
<xs:annotation>
@@ -864,16 +864,16 @@
<xs:complexTypename="MostDerivedObjectType">
<xs:annotation>
<xs:documentation>
Specifies an expression which evaluates to the current object, casted to its most-derived type.
In most cases, the debugger is able to automatically determine an object's most-derived type, in which case use of the <MostDerivedType>
Specifies an expression which evaluates to the current object, casted to its most-derived type.
In most cases, the debugger is able to automatically determine an object's most-derived type, in which case use of the <MostDerivedType>
element is unecessary. Automatic determination of an object's most-derived type requires the object to be an instance of a C++ class, with a
compiler-generated virtual function table. This is sufficient for most class-hierarchies; however, custom logic may occasionally be necessary
when dealing with a class hierarchy that does not contain virtual functions, or when the virtual function table is manually constructed by the
when dealing with a class hierarchy that does not contain virtual functions, or when the virtual function table is manually constructed by the
application code.
</xs:documentation>
</xs:annotation>
<xs:simpleContent>
<xs:extensionbase="StringType">
<xs:attributeGroupref="CommonAttributes"/>
@@ -935,12 +935,12 @@
<xs:annotation>
<xs:documentation>
Indicates that the given type is a smart pointer. The text inside this element specifies the expression to evaluate the underlying pointer.
The <SmartPointer> element has the following effects:
- If no alternative <DisplayString> element is provided (or all <DisplayString> elements have failed conditions), the underlying pointer will be the display string
- If no alternative <StringView> element is provided (or all <StringView> elements have failed conditions), the underlying pointer will be the string view, if it has one.
- If no alternative <Expand> element is provided, the expansion of the smart pointer will be the expansion of the underlying pointer.
- The smart pointer class will also support overloaded operators as determined by the <Usage> attribute. You can opt out of this behavior by specifying
- The smart pointer class will also support overloaded operators as determined by the <Usage> attribute. You can opt out of this behavior by specifying
<xs:documentation>Indicates which combinations of operators this smart pointer object supports.
<xs:documentation>Indicates which combinations of operators this smart pointer object supports.
</xs:documentation>
</xs:annotation>
</xs:attribute>
@@ -1004,10 +1004,10 @@
<xs:documentation>Specifies an optional priority to assign to this entry for type matching. Higher priority entries within a particular file or directory
are checked first. <Type> entries that do not specify a priority receive default priority of "Medium"<AlternativeType> entries which do not specify a priority
will inherit the priority of the enclosing <Type> element. The priority is only used to disambiguate type matching when all other means of disambiguation are unavailable.
For example, entries with more specific template instantiations, module constraints, or view constraints will take priority regardless of any priority values specified.
Similarly, regardless of priority, natvis files that are part of a loaded project will always take precedence over files in the user natvis directory,
which will, in turn, take precedence over files in the system-wide natvis directory.
For example, entries with more specific template instantiations, module constraints, or view constraints will take priority regardless of any priority values specified.
Similarly, regardless of priority, natvis files that are part of a loaded project will always take precedence over files in the user natvis directory,
which will, in turn, take precedence over files in the system-wide natvis directory.
If two entries have the same priority and cannot otherwise be disambiguated, it is unspecified which one will get used.
* Debugger: [Why is debugging not working?](#why-is-debugging-not-working)
* Build: [How to enable debug symbols](#how-to-enable-debug-symbols)
* Logging: [How to enable logging](#how-to-enable-logging)
## Debugging Setup
The debugger needs to be configured to know which executable and debugger to use:
Click menu item: `Debug` -> `Add Configuration...`
The file **launch.json** will now be open for editing with a new configuration. The default settings will *probably* work except that you need to specify the **program** setting.
See the [**Documentation/Debugger**](https://github.com/Microsoft/vscode-cpptools/tree/master/Documentation/Debugger) folder in this repository for more in-depth documentation on how to configure the debugger.
## Why is debugging not working?
### My breakpoints aren't being hit
When you start debugging, if it is showing that your breakpoints aren't bound (solid red circle) or they are not being hit, you may need to enable [debug symbols](#how-to-enable-debug-symbols) during compilation.
### Debugging starts but all the lines in my stack trace are grey
If your debugger is showing a grey stacktrace or won't stop at a breakpoint, or the symbols in the call stack are grey then your executable was compiled without [debug symbols](#how-to-enable-debug-symbols).
## How to enable debug symbols?
Enabling debug symbols are dependent on the type of compiler you are using. Below are some of the compilers and the compiler options necessary to enable debug symbols.
When in doubt, please check your compiler's documentation for the options necessary to include debug symbols in the output. This may be some variant of `-g` or `--debug`.
* #### Clang (C++)
* If you invoke the compiler manually then add the `--debug` option.
* If you're using a script then make sure the `CXXFLAGS` environment variable is set; e.g. `export CXXFLAGS="${CXXFLAGS} --debug"`
* If you're using CMake then set make sure the `CMAKE_CXX_FLAGS` is set; e.g. `export CMAKE_CXX_FLAGS=${CXXFLAGS}`
* #### Clang (C)
See Clang C++ but use `CFLAGS` instead of `CXXFLAGS`.
* #### gcc or g++
If you invoke the compiler manually, add the `-g` option.
* #### cl.exe
Symbols are located in the `*.pdb` file.
## How to enable logging
Enabling logging will show communication information between VS Code and our extension and between our extension and the debugger.
### Logging for `MI` debuggers
The logging block with its defaults is as follows:
```
"logging": {
"trace": false,
"traceResponse": false,
"engineLogging": false
}
```
#### VS Code and the CppTools extension
The logging here is called `trace` logging and can be enabled by setting `trace` and `traceResponse` to `true` in the logging block inside `launch.json`. This will help diagnose issues related to VS Code's communication to our extension and our responses.
#### CppTools extension and the debugger
The logging between CppTools and the debugger is called `engineLogging`. When using an `MI` debugger such as `gdb` or `lldb`, this will show the request, response and events using the `mi` interpreter. This logging will help us determine whether the debugger is receiving the right commands and generating the correct responses.
### Logging for `Visual C++` debugger
The logging block with its defaults is as follows:
```
"logging": {
"engineLogging": false
}
```
The `Visual C++` debugger logging will show only the communication to and from VS Code as all communication to the debugger is done internally to the process and is not visible through logging.
The FAQs for the C/C++ extension has moved to https://code.visualstudio.com/docs/cpp/faq-cpp.
# Configuring includePath for better IntelliSense results
This page describes how to configure include paths for folders containing C or C++ files to get the full IntelliSense experience. If you're seeing the following message when opening a folder in VS Code, it means the C++ IntelliSense engine needs additional information about the paths in which your include files are located.

## Where are the include paths defined?
The include paths are defined in the `"includePath"` setting in a file called **c_cpp_properties.json** located in the **.vscode** directory in the opened folder.
You can create or open this file by either using the `"C/Cpp: Edit Configurations"` command in the command palette or by selecting `"Edit "includePath" setting"` in the lightbulb menu (see the screenshot below). The quickest way to locate a lightbulb is to scroll to the top of the source file and click on any green squiggle that shows up under a #include statement.

When a folder is opened, the extension attempts to locate your system headers based on your operating system, but it does not know about any other libraries that your project depends on. You can hover over the green squiggles or open the Problems window to understand which headers the IntelliSense engine is unable to open - sometimes it's the dependent headers that can't be located.
You can specify the remaining paths using one of the techniques described below.
#### 1. Use `compile_commands.json` file to supply includePaths and defines information
The extension can get the information for `"includePath"` and `"defines"` from a **compile_commands.json** file, which can be auto-generated by many build systems such as CMake and Ninja. Look for the section where your current configuration is defined (by default there's one configuration per OS, such as "Win32 or "Mac"), and set the `"compileCommands"` property in **c_cpp_properties.json** to the full path to your **compile_commands.json** file and the extension will use that instead of the `"includes"` and `"defines"` properties for IntelliSense.
#### 2. Use the lightbulb suggestions to auto-resolve includePath
The first thing to try is to leverage the lightbulb path suggestions to auto-resolve the include paths. When you open a folder, the extension will **recursively** search for potential include paths that match the header files your code is using based on the paths set by the `"browse.path"` setting in **c_cpp_properties.json**. Click on the green squiggles under #include statements and you'll see a lightbulb offering suggestions of paths that will allow IntelliSense to resolve the included file.
If you don't see path suggestions in the lightbulb, try adding the root folder where the headers are likely located in to the `"browse.path"` setting in **c_cpp_properties.json**. This allows the extension to **recursively** search in these folders and offer more suggestions in the lightbulb as the search process goes on.
#### 3. Manually add include paths
If none of the above fully resolves the paths, you could manually specify the paths to the headers that your project depends on in the **c_cpp_properties.json** file. Look for the section where your current configuration is defined (by default there's one configuration per OS, such as "Win32 or "Mac"), and add your paths in the `"includePath"` setting and defines in the `"defines"` setting. For example, the following screenshot shows a snippet of the file specifying path for the Mac configuration.
## Verify the include paths are correctly resolved
There are two ways to verify that the include paths are correctly resolved:
1. The green squiggles in the source file are no longer showing
2. Error messages are cleared in the Problems window
This indicates that the IntelliSense engine has got the include paths resolved so you can start enjoying the full IntelliSense for your C or C++ code for the current translation unit. Note that you may still see errors on other files if they belong to a different translation unit that requires additional include paths to be configured.
In version 0.17.0 we introduced new settings that allow you to override the extension's default values for properties set in **c_cpp_properties.json**.
## New VS Code settings
The following `C_Cpp.default.*` settings map to each of the properties in a configuration block of **c_cpp_properties.json**. Namely:
These settings have all of the benefits of VS Code settings, meaning that they can have default, "User", "Workspace", and "Folder" values. So you can set a global value for `C_Cpp.default.cppStandard` in your "User" settings and have it apply to all of the folders you open. If any one folder needs a different value, you can override the value by adding a "Folder" or "Workspace" value.
This property of VS Code settings allows you to configure each of your workspaces independently - making the **c_cpp_properties.json** file optional.
## Updated **c_cpp_properties.json** syntax
A special variable has been added to the accepted syntax of **c_cpp_properties.json** that will instruct the extension to insert the value from the VS Code settings mentioned above. If you set the value of any setting in **c_cpp_properties.json** to "${default}" it will instruct the extension to read the VS Code default setting for that property and insert it. For example:
```
"configurations": [
{
"name": "Win32",
"includePath": [
"additional/paths",
"${default}"
],
"defines": [
"${default}",
],
"macFrameworkPath": [
"${default}",
"additional/paths"
],
"forceInclude": [
"${default}",
"additional/paths"
],
"compileCommands": "${default}",
"browse": {
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": "${default}",
"path": [
"${default}",
"additional/paths"
]
},
"intelliSenseMode": "${default}",
"cStandard": "${default}",
"cppStandard": "${default}",
"compilerPath": "${default}"
}
],
```
Take note that for the properties that accept string[], the syntax proposed above allows you to augment the VS Code setting with additional values, thus allowing you to have common paths listed in the VS Code settings and configuration-specific settings in **c_cpp_properties.json**.
If a property is missing from **c_cpp_properties.json**, the extension will use the value in the VS Code setting. If a developer assigns values to all of the settings that apply for a given folder, then **c_cpp_properties.json** could be removed from the .vscode folder as it will no longer be needed.
### System includes
A new setting will be added that allows you specify the system include path separate from the folder's include path. If this setting has a value, then the system include path the extension gets from the compiler specified in the `compilerPath` setting will not be added to the path array that the extension uses for IntelliSense. We may want to provide a VS Code command to populate this value from the compiler's default for users who are interested in using it in case they want to make some modifications to the defaults.
```
C_Cpp.default.systemIncludePath : string[]
```
### System Include Path/Defines Resolution Strategies
The extension determines the system includePath and defines to send to the IntelliSense engine in the following manner:
1. If `compileCommands` has a valid value and the file open in the editor is in the database, use the compile command in the database entry to determine the include path and defines.
* The system include path and defines are determined using the following logic (in order):
1. If `systemIncludePath` has a value, use it (continue to the next step to search for system defines).
2. If `compilerPath` is valid, query it.
3. Interpret the first argument in the command as the compiler and attempt to query it.
4. If `compilerPath` is `""`, use an empty array for system include path and defines.
5. If `compilerPath` is undefined, look for a compiler on the system and query it.
2. If `compileCommands` is invalid or the current file is not listed in the database, use the `includePath` and `defines` properties in the configuration for IntelliSense.
* The system include path and defines are determined using the following logic (in order):
1. If `systemIncludePath` has a value, use it (continue to the next step to search for system defines).
2. If `compilerPath` is valid, query it.
3. If `compilerPath` is `""`, use an empty array for system include path and defines (they are assumed to be in the `includePath` and `defines` for the current config already).
4. If `compilerPath` is undefined, look for a compiler on the system and query it.
System includes should no longer be added to the `"includePath"` or `"browse.path"` variables. If the extension detects any system include paths in the `"includePath"` property it will silently remove them so that it can ensure system include paths are added last and in the correct order (this is especially important for GCC/Clang). In a future update we may add a notification message to the extension to remind developers to remove system include paths from their `"includePath"` and `'browse.path"` as they will be ignored.
The documentation for customizing default settings has moved to https://code.visualstudio.com/docs/cpp/customize-default-settings-cpp.
If you are experiencing a problem that we are unable to diagnose based on information in your issue report, we might ask you to enable logging and send us your logs.
As of version 0.14.0 of the extension, logging information is now delivered directly to the Output window in VSCode. To turn on full logging for an issue report, add `"C_Cpp.loggingLevel": "Information"` or `"C_Cpp.loggingLevel": "Debug"` to your **settings.json**.
VS Code organizes the logging from different extensions to improve readability so you must select the "C/C++" option in the log filter selector to see logging from the C/C++ extension:
* [How do I get IntelliSense to work correctly?](#how-do-i-get-intellisense-to-work-correctly)
* [Why do I see red squiggles under Standard Library types?](#why-do-i-see-red-squiggles-under-standard-library-types)
* [How do I get the new IntelliSense to work with MinGW on Windows?](#how-do-i-get-the-new-intellisense-to-work-with-mingw-on-windows)
* [How do I get the new IntelliSense to work with the Windows Subsystem for Linux?](#how-do-i-get-the-new-intellisense-to-work-with-the-windows-subsystem-for-linux)
* [What is the difference between `"includePath"` and `"browse.path"` in **c_cpp_properties.json**?](#what-is-the-difference-between-includepath-and-browsepath-in-c_cpp_propertiesjson)
* [How do I re-create the IntelliSense database?](#how-do-i-re-create-the-intellisense-database)
## How do I get IntelliSense to work correctly?
There are two IntelliSense engines present in the extension: the "fuzzy" engine (or Tag Parser), and the new "Default" engine. If you are using version 0.11.0 or higher of the cpptools extension, then you can preview our new IntelliSense engine which has more accurate auto-complete suggestions and tooltips. To use the new engine, you need to ensure that `"C_Cpp.intelliSenseEngine"` is set to `"Default"` in your settings. Since the engine is still in preview it is not on by default for everyone yet.
After selecting the IntelliSense engine that you prefer, take a look at the Problems window in VS Code to see if you need to do any further configuration for your folder. For example, the Default engine will not provide squiggles and auto-complete suggestions for a translation unit (read: a source file and its dependencies) if the include path is not configured properly. You can select any of the problems in the window to navigate to the line when the problem was detected and a lightbulb will appear in the editor with some options (code actions) to help you resolve the problem:
1. Update your `includePath` (and preprocessor defines)
2. Force semantic IntelliSense
#### Update your `includePath` (and preprocessor defines)
Selecting this option will open a file called **c_cpp_properties.json**. If you haven't created this file already, it will be created for you in the **.vscode** folder of your workspace.
Add the necessary paths to your include files to the `"includePath"` array. The `${workspaceRoot}` variable is available to use to get a relative path to the folder you have opened. Also add any required symbols that need to be defined to the `"defines"` array. Both "\<var\>" and "\<var\>=\<value\>" syntax is accepted. When you edit and save this file, the IntelliSense engine will reset and reparse source your source files and headers with the new settings.
#### Force semantic IntelliSense
If you want IntelliSense to operate on your files even when all #include directives do not resolve, then you can choose the `Force semantic IntelliSense` code action to always use the new IntelliSense engine. You can also set the `C_Cpp.intelliSenseEngineFallback` setting to `"Disabled"`.
## Why do I see red squiggles under Standard Library types?
The most common reason for this is missing include paths and defines. The easiest way to fix this on each platform is as follows:
**Linux/Mac**
* Set `"intelliSenseMode": "clang-x64"` and `"compilerPath"` in **c_cpp_properties.json** to the path to your compiler.
**Windows**
* If you are using a Microsoft compiler from Visual Studio, set `"intelliSenseMode": "msvc-x64"`, but don't add the `"compilerPath"` property to **c_cpp_properties.json**.
* If you are using Clang for Windows, set `"intelliSenseMode": "msvc-x64"`, and `"compilerPath"` in **c_cpp_properties.json** to the path to your compiler.
## How do I get the new IntelliSense to work with MinGW on Windows?
The page discussing configuration with MinGW is [here](https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/MinGW.md).
## How do I get the new IntelliSense to work with the Windows Subsystem for Linux?
The page discussing configuration with WSL is [here](https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/Windows%20Subsystem%20for%20Linux.md).
## What is the difference between `"includePath"` and `"browse.path"` in **c_cpp_properties.json**?
Starting with version 0.11.0 of the cpptools extension, there are now two settings in the **c_cpp_properties.json** file. They are used by the different IntelliSense engines that we support and have slightly different meanings for the components that use them.
The active IntelliSense engine is controlled via the `"C_Cpp.intelliSenseEngine"` setting in your **settings.json** file. The valid values for this setting are `"Default"` and `"Tag Parser"`.
* #### `"includePath"`
This array of path strings is used by the new "Default" IntelliSense engine that was introduced in version 0.11.0 of the extension. This new engine provides semantic-aware IntelliSense features and will be the eventual replacement for the Tag Parser that has been powering the extension since it was first released. It currently provides tooltips and error squiggles in the editor. The remaining features (e.g. code completion, signature help, go to definition, ...) are implemented using the Tag Parser's database, so it is still important to ensure that the browse.path setting is properly set.
The paths that you specify for this setting are the same paths that you would send to your compiler via the `-I` switch. When your source files are parsed, the IntelliSense engine will prepend these paths to the files specified by your #include directives while attempting to resolve them. These paths are **not** searched recursively.
* #### `"browse.path"`
This array of path strings is used by the "Tag Parser" (a.k.a. "browse engine"). This engine will _recursively_ enumerate all files under the paths specified and track them as potential includes while tag parsing your project folder. To disable recursive enumeration of a path, you can append a `/*` to the path string.
When you open a workspace for the first time, the extension adds `${workspaceRoot}` to both arrays. If this is undesirable, you can open your **c_cpp_properties.json** file and remove it.
## How do I re-create the IntelliSense database?
Starting in version 0.12.3 of the extension, we added a command that will reset your IntelliSense database. Open the command palette and choose the "C/Cpp: Reset IntelliSense Database" command.
The FAQs for the C/C++ extension has moved to https://code.visualstudio.com/docs/cpp/faq-cpp.
There are two IntelliSense engines used to power the C/C++ IntelliSense experience in VS Code.
*`"Default"` - Visual Studio's IntelliSense engine, which is the default engine that provides semantic-aware IntelliSense features
*`"Tag Parser"` - the "fuzzy" IntelliSense engine that provides quick but "fuzzy" results, is used to provide the fallback experience if the default engine is unable to fully resolve include paths
Ultimately all the IntelliSense and code browsing features will be powered by the "Default" engine. The following features have been implemented so far:
* Auto-complete suggestions for class/struct/namespace members
* Parameter hints
* Quick info (hover over tooltip)
* Error squiggles
* Reference highlighting
The other IntelliSense features, such as global auto-complete, and code browsing features, such as Go to definition/declaration, are currently powered by the "Tag Parser" based engine.
### `includePath` and `browse.path`
The two IntelliSense engines use two different settings in the **c_cpp_properties.json** file for specifying include paths. This file is located in the **.vscode** directory in the opened folder. You can create or open this file by either using the "C/Cpp: Edit Configurations" command in the command palette or by selecting "Edit "includePath" setting" in the lightbulb menu. Look for the following settings in the section where your current configuration is defined (by default there's one configuration per OS, such as "Win32 or "Mac").
* #### `"includePath"`
This array of path strings is used by the "Default" IntelliSense engine. The paths that you specify for this setting are the same paths that you would send to your compiler via the -I switch. When your source files are parsed, the IntelliSense engine will prepend these paths to the files specified by your #include directives while attempting to resolve them. These paths are searched **non-recursively**.
* #### `"browse.path"`
This array of path strings is used by the "Tag Parser" (a.k.a. "browse engine"). This engine will **recursively** enumerate all files under the paths specified and track them as potential includes while tag parsing your project folder. To disable recursive enumeration of a path, you can append a `/*` to the path string.
### How fallback works and how to control the behavior
The extension first tries to fully parse any opened file using the "Default" IntelliSense engine. If it discovers that it cannot find a header file or a dependency, it will fall back to the tag parser and provide the fuzzy IntelliSense behavior. The fallback affects a full translation unit (TU), not just a single open file. The Problems panel provides details about unresolved headers and dependencies. Other opened TUs will continue to use the "Default" IntelliSense engine provided that all #include dependencies are resolved.
We recognize that resolving all #includes may not be necessary for all projects and you may still want to experience the productivity benefits of using the "Default" semantic engine without customizing the default include path. For that, the “Force semantic IntelliSense” action can be chosen. When invoked, all unresolved #include squiggles will turn red and semantic member list and linting will be enabled in all files regardless of whether or not #include statements can be resolved.
### IntelliSense engine setting
We recommend using the "Default" engine for the best IntelliSense experience. However, it is possible to explicitly choose the IntelliSense engine by editing your [user or workspace settings](https://code.visualstudio.com/docs/getstarted/settings). The setting you should modify is `"C_Cpp.intelliSenseEngine"`. There are two values for this setting:
*`"Default"` - use Visual Studio's IntelliSense engine
*`"Tag Parser"` - use the "fuzzy" IntelliSense engine
### See Also
[Configuring includePath for better IntelliSense results](https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/Getting%20started%20with%20IntelliSense%20configuration.md)
To use MinGW on Windows, we recommend you add the following configuration to your **c_cpp_properties.json** file. Select "C/Cpp: Edit Configurations" from the command palette to create this file if you haven't already.
## Extension version 0.17.0 and higher:
When you set the `compilerPath` property and change `intelliSenseMode` to `clang-x64` (or `gcc-x64` in version 0.18.0 and higher), you no longer need to copy the system include path or defines to `includePath`, `browse.path`, or `defines` to enable IntelliSense to work properly. For example:
```json
{
"name":"MinGW",
"intelliSenseMode":"gcc-x64",
"compilerPath":"C:/mingw64/bin/gcc.exe",
"includePath":[
"${workspaceFolder}"
],
"defines":[],
"cStandard":"c11",
"cppStandard":"c++17"
}
```
Replace "gcc.exe" with whatever compiler you're using, e.g. "g++.exe", "clang-5.0.exe", etc. -- just make sure the file is a valid Windows executable (not a 0 size symlink).
For Cygwin, set the `compilerPath` to the appropriate Cygwin path, e.g. "C:/cygwin64/bin/g++.exe".
If it seems like the `compilerPath` is not getting used, you can debug the issue via [enabling logging](Enabling%20logging.md).
## Extension version 0.16.1 and earlier:
If you have an older version of the C/C++ extension installed, use [these instructions](Archive/MinGW.md) instead.
The documentation for Mingw-w64 has moved to https://code.visualstudio.com/docs/cpp/config-mingw.
> **Note:** If you are on **build 17110 of Windows or higher**, you must use extension version 0.17.0 or higher for IntelliSense to work. The Windows team turned on case-sensitive folders for the WSL environment and the C/C++ extension doesn't support case-sensitive folders until version 0.17.0.
To use the Windows Subsystem for Linux with this extension you need to add a configuration to your **c_cpp_properties.json** file which adds the necessary header paths from within the WSL filesystem to the `includePath`.
Select "C/Cpp: Edit Configurations" from the command palette to create the **c_cpp_properties.json** file if you haven't already.
## With extension version 0.17.0 and higher:
In **c_cpp_properties.json** you can directly address your WSL compiler and include paths by using *nix-style paths and we will do the conversion to Windows paths for you. If you have multiple distros installed, we disambiguate the `compilerPath` by picking the one marked as Default when you run `wslconfig.exe /l` in a CMD or PowerShell window. We continue to support Windows-style paths for these properties as outlined in the [archived instructions](Archive/Windows%20Subsystem%20for%20Linux.md) if you prefer to use those.
```json
{
"name":"WSL",
"intelliSenseMode":"gcc-x64",
"compilerPath":"/usr/bin/gcc",
"includePath":[
"${workspaceFolder}/**"
],
"defines":[],
"cStandard":"c11",
"cppStandard":"c++17"
}
```
## Earlier versions of the extension:
If you are on a build of Windows prior to 17110 and you have an older version of the C/C++ extension installed, use [these instructions](Archive/Windows%20Subsystem%20for%20Linux.md) instead.
---
Remember to [heed the warnings of the Windows team about not creating or editing Linux files from a Windows app](https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/)!
The documentation for GCC on Windows Subsystem for Linux (WSL) has moved to https://code.visualstudio.com/docs/cpp/config-wsl.
An array of user-defined variables that will be available for substitution in the configurations via the standard environment variable syntax: `${<var>}` or `${env:<var>}`. Strings and arrays of strings are accepted.
* #### `configurations`
An array of configuration objects that provide the IntelliSense engine with information about your project and your preferences. By default, the extension creates a configuration for you based on your operating system. You may also add additional configurations.
* #### `version`
We recommend you don't edit this field. It tracks the current version of the **c_cpp_properties.json** file so that the extension knows what properties and settings should be present and how to upgrade this file to the latest version.
## Configuration properties
* #### `name`
A friendly name for the configuration. "Linux", "Mac", and "Win32" are special names that instruct the extension to load that configuration by default on the associated operating system unless additional configurations have been created. The status bar in VS Code will show you which configuration is active. You can also click on the label in the status bar to change the active configuration.
* #### `intelliSenseMode`
If `"C_Cpp.intelliSenseEngine"` is set to "Default" in your settings file, this property determines which mode the IntelliSense engine will run in. `"msvc-x64"` maps to Visual Studio mode with 64-bit pointer sizes. `"clang-x64"` maps to CLang mode with 64-bit pointer sizes. `"gcc-x64"` maps to GCC mode with 64-bit pointer sizes. Windows uses `"msvc-x64"` by default, macOS uses `"clang-x64"` by default, and Linux uses `"gcc-x64"` by default.
* #### `includePath`
If `"C_Cpp.intelliSenseEngine"` is set to "Default" in your settings file, this list of paths will be used by IntelliSense to search for headers included by your source files. This is basically the same as the list of paths you pass to your compiler with the `-I` switch. If a path ends with `/**` the IntelliSense engine will do a recursive search for includes starting from that directory. If on Windows with Visual Studio installed, or if a compiler is specified in the `compilerPath` setting, it is not necessary to list the system include paths in this list.
* #### `macFrameworkPath`
If `"C_Cpp.intelliSenseEngine"` is set to "Default" in your settings file, this list of paths will be used by IntelliSense to search for framework headers included by your source files. This is basically the same as the list of paths you pass to your compiler with the `-F` switch; the IntelliSense engine will not do a recursive search in these paths for includes.
* #### `defines`
If `"C_Cpp.intelliSenseEngine"` is set to "Default" in your settings file, this list of preprocessor symbols will be used by IntelliSense during the compilation of your source files. This is basically the same as the list of symbols you pass to your compiler with the `-D` switch. If on Windows with Visual Studio installed, or if a compiler is specified in the `compilerPath` setting, it is not necessary to list the system include paths in this list.
* #### `forcedInclude` (optional)
A list of files that should be included before any other characters in the source file are processed. Files are included in the order listed.
* #### `compilerPath` (optional)
The absolute path to the compiler you use to build your project. The extension will query the compiler to determine the system include paths and default defines to use for IntelliSense.
Args can be added to modify the includes/defines used, e.g. `-nostdinc++`, `-m32`, `-fno-ms-extensions`, etc., but paths with spaces must be surrounded by double quotes (`"`) if args are used.
If you want to disable automatic querying of system include paths and defines, set this value to the emptry string `""`. This is generally not recommended, but there are some cases where automatic querying of system includes and defines is undesirable.
* #### `cStandard`
The C standard revision to use for IntelliSense in your project.
* #### `cppStandard`
The C++ standard revision to use for IntelliSense in your project.
* #### `compileCommands` (optional)
If `"C_Cpp.intelliSenseEngine"` is set to "Default" in your settings file, the includes and defines discovered in this file will be used instead of the values set for `includePath` and `defines`. If the compile commands database does not contain an entry for the translation unit that corresponds to the file you opened in the editor, then a warning message will appear and the extension will use the `includePath` and `defines` settings instead.
>For more information about the file format, see the [Clang documentation](https://clang.llvm.org/docs/JSONCompilationDatabase.html). Some build systems, such as CMake, [simplify generating this file](https://cmake.org/cmake/help/v3.5/variable/CMAKE_EXPORT_COMPILE_COMMANDS.html).
* #### `browse`
The set of properties used when `"C_Cpp.intelliSenseEngine"` is set to `"Tag Parser"` (also referred to as "fuzzy" IntelliSense, or the "browse" engine). These properties are also used by the Go To Definition/Declaration features, or when the "Default" IntelliSense engine is unable to resolve the #includes in your source files.
### Browse properties
* #### `path`
This list of paths will be used by the Tag Parser to search for headers included by your source files. If omitted, `includePath` will be used as the `path`. The Tag Parser will automatically search all subfolders in these paths unless the path ends with a `/*` or `\*`. For example, `/usr/include` directs the Tag Parser to search the `include` folder and its subfolders for headers while `/usr/include/*` directs the Tag Parser not to look in any subfolders of `/usr/include`.
* #### `limitSymbolsToIncludedHeaders`
When true, the Tag Parser will only parse code files that have been directly or indirectly included by a source file in `${workspaceFolder}`. When false, the Tag Parser will parse all code files found in the paths specified in the **path** list.
* #### `databaseFilename`
When set, this instructs the extension to save the Tag Parser's symbol database somewhere other than the workspace's default storage location. If a relative path is specified, it will be made relative to the workspace's default storage location, not the workspace folder itself. The `${workspaceFolder}` variable can be used to specify a path relative to the workspace folder (e.g. `${workspaceFolder}/.vscode/browse.vc.db`)
The documentation for c_cpp_properties.json has moved to https://code.visualstudio.com/docs/cpp/c-cpp-properties-schema-reference.
# ignore vscode settings for extension development
.vscode/**
typings/**
out/test/**
# ignore binaries
obj/**
# ignore source files
tools/**
notices/**
test/**
src/**
**/*.map
.gitignore
# ignore .js files that are webpacked or only used for development
out/src/**
out/tools/**
# ignore ts files in ui
ui/*.ts
# ignore Azure-Pipelines files
jobs/**
cgmanifest.json
# ignore development files
tsconfig.json
test.tsconfig.json
tslint.json
.eslintrc.js
webpack.config.js
tscCompileList.txt
gulpfile.js
.gitattributes
.gitignore
CMakeLists.txt
debugAdapters/install.lock*
out/src/Debugger/copyScript.js
tools/**
out/tools/**
notices/**
typings/**
**/*.map
import_edge_strings.js
localized_string_ids.h
translations_auto_pr.js
# ignore i18n language files
i18n/**
# ignore node_modules
node_modules/
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.