* Add loc string and Add Missing Include handler
* Add AddMissingInclude Command and resolve lint
* Refactor codeActionProvider
* resolve formatting and append newline to includes
* Only apply new line to Add Missing Include
* Resolve lint issue
* Add new line specific to OS
* Resolve newline
* made sure that yarn install gets called before compile
* Add some nice messages
* better detection
* cleaned up more
* more tweaks
* remove old checks
* let unit tests run without binaries
* turn off scenario tests until binaries can be installed
* add another rule
* updated files
* queue and ready are now separate
* checkpoint
* found it! fixed missing call
* cleaned up and refactored a bit
* cleanup
* whoops. make sure linter runs!
* Make the queue itself static
* addressed formatting issues, added more rules to eslint
* more formatting, made ready Promise/void
* checkpoint
* checkpoint
* checkpoint
* checkpoint (linting)
* checkpoint
* checkpoint
* checkpoint
* checkpoint
* renamed path to filepath.
* checkpoint
* checkpoint
* so close...
* checkpoint again
* before making doc
* checkpoint
* checkpoint
* Checkpoint
* renamed awaiters
* eslint
* fix format on generated native strings
* add dummy pretest task back in for the moment
* change unit test runing
* posix calc test failure
* make signal dispose better
* add est regen script
* missed file
* checkpoint
* Improve scripts a bit
* remove hooks for now
* remove unused script
* remove unused script
* filter out files
* ensure that eslint works for scripts too
* fix build oses to specific version
* cleanups and tweaking
* adjusted for cosmetic feedback
* more
* add eslint rule to fix space before/after semicolon
* remove tba/tbd
* cleanup
* Added space-infix-ops rule
* cleanup
* resolve comments
* resolve comments
* add simple debug task
* spelling fixes
* cleanup more
* More changes. yay
* remove the extra whitespace from before comments
* add eslint rule to ensure that there are never extra spaces
* adding another eslint rule to ensure that there isn't spacing around unary operators, which we all know is dangerous. Or weird. I forget which
* added a space between vs and code because a space is the desired format
* removed all mentions of transpiler which was removed
* removed an extra comma
* removed a trailing slash
* removed useless lines
* missed as file
* reconfigure no-extra-parens rule
* added note about yarn install
* whatever
* more fun
* FIx it so that it webpacks correctly
* remove refernces to attic
* restore line to correct check
* fix whitespace
* added blank yarn install
* removed
For example, using the following tree:
rootUri
- sources
- main
- main.c
- vendor
- khash.h
- headers
- C001
- a.h
- C002
- b.h
The following directory paths works:
- `sources/**` for plain old recursive path
- `headers/C*/` dynamic path
- `missing/` reported as "not found"
- `missing/*` expanded as empty result (silent fail)
Note: bakslash paths need to be slash-converted to avoid be considered as "Dynamic"
Co-authored-by: Sean McManus <[email protected]>
Co-authored-by: browntarik <[email protected]>
* Fix configure IntelliSense UI bugs with non-C/C++ files.
* Fix "Configure IntelliSense" not going away until reload window.
* Move location to the left of the config.
* Refactor isCpp
* Stop showing the code action if the default compiler is already set.
* Multiple other fixes.
* Fix clang-tidy 'clang-analyzer-' documentation links not working.
* Fix file parsing ending not being displayed during pause
* Fix logic
* Remove redundant line
* Condense unpaused parser text
* Introduced parser indexing phase to UI
* Use lookupString() for parse status logic
* Update UI check logic
* Remove log
* Fix logic
* Seperate initializing from indexing in UI
* Change parser initalized text
* Remove extra new line
* Remove missed code
* Add uiOverride parameter to telemetry
* Resolve includePath before sending config notification
* Ensure all configuration paths are absolute
* Optimize implentation of resolution of arrays
* Move the resolving of config paths
* Reuse win32 check for all resolvePath's
* add explict type to isWin32
* Change engine logging and add natvis diagnostics
This PR adds logging categories to engineLogging and adds
in the option for natvisDiagnostics with different categories.
* change nls nativisDiagnostics to category
* Change engine logging and add natvis diagnostics
This PR adds logging categories to engineLogging and adds
in the option for natvisDiagnostics with different categories.
* change nls nativisDiagnostics to category
* Fix BufferOverflow with NativeAttach
This PR migrates the nativeAttach child_process calls to use 'spawn'
instead of 'exec'. This allows the extension to deal with large process
listing output via input/output streams instead of using a single
hardcoded buffer.
Added support for canceling and timeout if the spawned process does not
exit within 30 seconds.
* Contribute breakpoints for the "rust" language
Since rust code can be debugged with this extension, contribute breakpoints for the "rust" language such that the workaround of "allow breakpoints in all files" is no longer required.
* Contribute breakpoints for the "rust" language
Since rust code can be debugged with this extension, contribute breakpoints for the "rust" language such that the workaround of "allow breakpoints in all files" is no longer required.
* 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"
Removing .travis.yml and will be removing webhooks/app integration of
Travis-CI from vscode-cpptools.
Minor fixes and add debug integration tests back.
* Generate a C/C++ build task
* Cleaning
* Move args into definition
* Add args to shellexecution to allow calling the task without first configuring; Add TODO's
* Read compiler paths sent in defaults to generate task list
* Rename compilerPaths to compilerInfo; Filter tasks based on file extension
* Use our own file extension filters to decide whether tasks are presented
* Show dialog when no compilers are found
* Display a message if no compilers are found
* Add compilerPath getter to config; Use it to offer another task
* Refactoring; Commenting
* Remove CompilerInfo namespace; Formatting; Change return vals
* Commenting; Add telemetry; Inverse condition
* Change output program based on OS; Remove message and collect telemetry instead
* Filter out redundant compiler entries
* Remove TODO; Get proper exe name; Properly reassign compilerPaths after filtering
* Commenting; Fix cwd mingw bug
* Commenting; Refactor
* Mark compilerInfo const
* Remove whitespace; Remove bad comment
* Remove whitespace
* Replace unique algorithm with a map
* pre-compute basename
* Move comment
* Commenting; Ensure user's compilerPath setting is used
* Use indexOf instead of find
* Simplify isHeader calculation by using some instead of every
* Don't redundantly check extensions; Use some instead of indexOf
* Add comment punctuation
Use file macro instead of fileDirName and fileBaseName
Change path provider name; expose cwd in definition
Add shell task definition (it's not built into vs code apparently)
* Lowercase file extension to match; Count extensionless files as headers
* Add newline
* Change CompilerInfo to KnownCompiler
* Support ambiguous file extension
* Early out for extensionless files
* Commenting
* Commenting; Rename telemetry event
* Change languageAssociation to isC
* Fix bug where cwd was not used; Add comment
* Update How To Debug MIEngine.md
Added information on how to debug with VS Code
* Update How To Debug MIEngine.md
* .dll -> .pdb
Mistake on symbol list
* Add attach QuickView with refresh
* vscode engine 1.23 -> 1.26
* Clean up disposables
* Add entry to CHANGELOG
* Provide refresh image for dark and light themes
* Add title to QuickPick
* Use shell optional arg
* Add try/catch around spawn to override any possible exceptions
* Default vsixname to cpptools-linux32.vsix
* Move logFailure inline
* Remove potential PII from error message to be on the safe side
* Fix linter errors
* Remove spawn optional arg; instead remove quotes surrounding command
* Remove rethrowing of error at the top level checkAndApplyUpdate
* Commenting
* Remove default case in switch statement for vsixName; Add x86, i383, i686 cases
* Find Mac code script; Commenting; Move code into try catches correctly filter errors; Add notification on installation
* Merge files from correct commit
* Revert changes made from not having master branch code
* Read json from harded-coded file location
* Expose settings tracker
* Get linux download url
* Remove unused imports
* Correctly get changed setting
* Add update timer
* Minimum end to end
* Refactoring; Commenting; Renaming
* Commenting
* Add optional param to download fn; Refactoring; Renaming
* Commenting; Then parse fn
* Mark vars const; Add todos; Refactoring
* Commenting; Refactoring
* url from any to string; Index into parsed json as separate step
* Use temp files to prevent clutter
* Correct windows platform name check; Replace quotes
* Resolve vsixName for mac + win
* Factor version comparisons into ParsedVersion class while correcting version comparison
* Use which utility to find code script
* Update timer to once per hour
* Move downloadFileToDestination to common; Replace downloadCpptoolsJsonAsync
* Return changed settings on onDidChangeSettings
* Get changed settings without stealing them
* Remove tracker from client interface
* Add basic isReleaseJson fn; Add telemetry; Add catch functions
* Write type predicates for release json
* Refactoring; Rewrite version check; Rewrite build selection
* Factor target build search into helper fn
* Reorder fn defs
* Uninstall version before installing if downgrading
* Add undefined checks; Update version comparison
* Reorder fn
* Telemetry rename; Parse versions more safely
* Turn ParsedVersion into interface; Rename release to build
* Fix fn return types
* Commenting
* Remove unneeded validity check
* Rename telemetry event; Correct fn return type
* Update setting description
* Remove promise rejection
* Remove unwanted changes
* Rename var
* Remove imports; Move call to updateSettingsAsync to .then in abTesting
* Remove import; Remove unneeded uses of await
* Remove comment
* Reformat else ifs
* Remove '| undefined' instances
* Use find fn more idiomatically
* Add type specification for predicates + rename them
* Add url var to shorten call to downloadFileToDestination
* Move parsedVersion to separate file
* Move parsedVersion into PackageVersion class
* Move helper fn's to separate file
* Get script name for both insiders and release VSCode (untested)
* Move packageVersion + ghAPI from LanguageServe to src
* Update imports to reflect mv; Check isValid on PackageVersion
* Add todo's
* Correctly get download URL; Correctly verify releaseJson by only checking recent 5 builds
* Check version numbers against undefined instead of 0
* Await install command before removing install file; Change var name
* Re-merge package.json
* Rename ghAPI.ts to githubAPI.ts
* Rename vars; Remove TODO
* Modify version comparison (untested)
* Remove todo
* Create file async
* Download and install file async
* Rework promises
* Make functions async where possible
* Commenting
* Grandfather in insiders users
* Change syntax via await keyword
* Re-enable interval timer
* Add updateChannel settings get
* Immediately check for update on extension activation if on insiders
* Surround windows code script path in quotes
* Rename versionStr to version
* Change telemetry event
* Update telemetry/exception handling
* Update telemetry strings; Reformat is functions
* Another pass at promises + telemetry
* Commenting
* Remove undefined from fn return
* Fix headers not being forwarded to recursive call
* Another pass at promises
* Correctly return promise in checkAndApplyUpdate
* Remove debug vars
* Rename fns
* Fix version parsing
* Tidy version comparison
* Remove commented out code
* Variable rename; Add newline at EOF
* Add newline at EOF
* Commenting; Unbind functions and use function syntax for .thens
* Error message; add rejection
* Correct exceptions being handled one promise too late
* PR feedback
* Rewrite promise chain to await to allow premature cancellation of promise chain
* Mark vars const; Comment; Rename var
* Dependent variable definition
```
"env": {
"envRoot": "apps/tool/builldenv",
"arm6.include": "${envRoot}/arm6/include"
},
...
"some_config": "${arm6.include}
```
* Additionally, this fixes an open bug that was not reported. If a variable contained "env", "config", or "workspaceFolder" it would not be parsed correctly. If you used a variable ${envRoot} it would match "envR" as the type and "oot" as the variable. This has been resolved.
* Also fixes travis-ci to run the unit tests as part of checkin validation
* adds settings for inactive region font & bg color
This adds the inactiveRegionForegroundColor and inactiveRegionBackgroundColor
settings. If a preprocessor block is found to be inactive, it will be
colored by these fields if they are set. They accept hexadecimal font
strings or valid theme colors as their values.These fields also
interactive with the dimInactiveRegions setting.
This was requested in issue
https://github.com/Microsoft/vscode-cpptools/issues/2212.
1. Updated tasks.json to 2.0
2. Added tslint problem matcher
- Weird issue that problem does not disappear when resolved.
3. Adding tslint for class and function names.
- class must be in PascalCase
- funcitons must be in camelCase
4. Addressing vulnerability warning
- https://github.com/Microsoft/vscode/issues/49146
* Adding OptionsSchema generation
This is to prevent repetitive fields from being copy and pasted
improperly.
* Move tslint to be after compile
* Address PR issues
* Adding snippet to fix pipeProgram in pipeTransport
Now with VSCode 64 bit, WSL users need to use the correct pipeProgram in
the correct folder. We will attempt to help users with this.
* Fix tslint issue
* Remove 64 bit check and check for relative path
* Fix up package.json rewrite
VSCode package.json is readonly.
Rewriting package.json will use the disk package.json to prevent getting
expanded fields from VSCode. It will only read from disk once.
Added `gulp pr-check` to make sure that package.json activationEvents has
not been rewritten for open source contributers.
* run pr-check needs to be before run test
* Update log message
* Adding file validation for download and unzip.
Refactored the download retry code.
Added error handlers for read and write streams.
WriteStream writes to a *.tmp file and then renames. This catches the
case if VSCode dies in the middle of this process and the file is
partially written. We will continue where we left off.
* Adding return to resolve/reject calls.
* Fix retry loop and check err in unlink and rename
* Actually wait for those promises
* Fix TSLint error
* Add compilerPath setting.
* Add code to query the default compiler.
* Add cStandard and cppStandard settings.
* Fix bug with inactive region deletion.
* Correct Fix to make sure debugger dependencies are copied
Fix double compile and make sure that it is only run once.
* Fix log
* Andrew requested outDir
* Work in progress. Wrote framework for comment pattern handling. Implementation incomplete and some bugs remain.
* address TODOs
* incorrect disposal
* incorrect type decorations
* WIP: update changelog, add a test
* test updates
* rename the setting, update package.json and add more tests
* deal with whitespace continuations
* address PR feedback
* add a way to speed up subsequent launches of the extension.
* A cleaner way to exit
* update package.json
* read the environment variable to short-circuit the node_modules check.
* Add intermediary type to safely construct vscode.Ranges for use
* Fix incorrect object definition
* Fix file empty edge case; refactor + comment out code while testing
* Use InputRegions (lines only); Remove commented out code
* Commenting
* Fix linter error from merge with master
description:Create a bug report for IntelliSense, code editing, code navigation, code completion, code formatting, semantic colorization, etc.
body:
- type:markdown
attributes:
value:|
### Is there an existing issue for this?
Please search our [existing issues](https://github.com/microsoft/vscode-cpptools/issues) to see if an issue already exists for the bug you encountered.
Please also review our [documentation](https://code.visualstudio.com/docs/languages/cpp) and [FAQs](https://code.visualstudio.com/docs/cpp/faq-cpp).
- type:textarea
attributes:
label:Environment
description:|
Please provide the information for the following:
- OS and Version
- VS Code Version
- C/C++ Extension Version
- If using SSH remote, specify OS of remote machine
value:|
- OS and Version:
- VS Code Version:
- C/C++ Extension Version:
- If using SSH remote, specify OS of remote machine:
validations:
required:true
- type:textarea
attributes:
label:Bug Summary and Steps to Reproduce
description:|
Please describe the language service issue or language service feature that is not working as expected. Include information about the actual workspace project (for example, is the workspace a single project or multiple projects, size of the project, etc).
Include clear steps on how to reproduce the issue and a description of what you expected to happen.
value:|
Bug Summary:
Steps to reproduce:
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
Expected behavior:
validations:
required:true
- type:textarea
attributes:
label:Configuration and Logs
description:|
Please provide your c_cpp_properties.json and logs:
- 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)
render:shell
validations:
required:true
- type:textarea
attributes:
label:Other Extensions
description:If applicable, please list other extensions installed and if the issue persists after disabling other extensions.
validations:
required:false
- type:textarea
attributes:
label:Additional context
description:|
Optionally provide other information that will give us more context about the issue you are encountering, such as code sample, screenshots, screen recording of the issue, call stacks, etc.
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:
description:Create a bug report for debugging such as call stack, breakpoints, watch window, launching or attaching to a debuggee.
body:
- type:markdown
attributes:
value:|
### Is there an existing issue for this?
Please search our [existing issues](https://github.com/microsoft/vscode-cpptools/issues) to see if an issue already exists for the bug you encountered.
Please also review our [documentation](https://code.visualstudio.com/docs/languages/cpp) and [FAQs](https://code.visualstudio.com/docs/cpp/faq-cpp).
- type:textarea
attributes:
label:Environment
description:|
Please provide the information for the following:
- OS and version
- VS Code version
- C/C++ extension version
- OS and version of remote machine (if applicable)
- GDB / LLDB version
value:|
- OS and version:
- VS Code:
- C/C++ extension:
- OS and version of remote machine (if applicable):
- GDB / LLDB version:
validations:
required:true
- type:textarea
attributes:
label:Bug Summary and Steps to Reproduce
description:|
Please describe the debugging issue or debugger feature that is not working as expected.
Include clear steps on how to reproduce the issue.
value:|
Bug Summary:
Steps to reproduce:
1. In this environment...
2. With this config...
3. Do '...'
4. See error...
validations:
required:true
- type:textarea
attributes:
label:Debugger Configurations
description:Please provide the debugger configurations from the **tasks.json** and **launch.json** files.
render:shell
validations:
required:true
- type:textarea
attributes:
label:Debugger Logs
description:|
If applicable, please include [logging for the debugger adapter](https://code.visualstudio.com/docs/cpp/enable-logging-cpp#_enable-logging-for-the-debug-adapter) by adding `"logging": { "engineLogging": true, "trace": true, "traceResponse": true }` in the **launch.json** file.
Include logs or error messages from the Debug Console or Output windows.
render:shell
validations:
required:true
- type:textarea
attributes:
label:Other Extensions
description:If applicable, please list other extensions installed and if the issue persists after disabling other extensions.
validations:
required:false
- type:textarea
attributes:
label:Additional Information
description:|
Optionally provide other information that will give us more context about the issue you are encountering, such as a code sample, screenshots, or screen recording of the issue.
Tip: You can attach images or log files by clicking this area to highlight it and then dragging files in.
description:Suggest an idea for the C/C++ extension.
body:
- type:markdown
attributes:
value:|
### Is there an existing request for this feature?
Prior to creating a new feature request, please review our [existing feature requests](https://github.com/microsoft/vscode-cpptools/issues?q=is%3Aopen+is%3Aissue+label%3A%22Feature+Request%22) to avoid duplicates.
(0,utils_1.safeLog)(`Last comment on issue ${hydrated.number} by ${lastComment.author.name}. Pinging @${hydrated.assignee}`);
if(this.pingComment){
awaitissue.postComment(this.pingComment
.replace('${assignee}',hydrated.assignee)
.replace('${author}',hydrated.author.name));
}
}
else{
(0,utils_1.safeLog)(`Last comment on issue ${hydrated.number} by ${lastComment.author.name}. Skipping.${hydrated.assignee?' cc @'+hydrated.assignee:''}`);
}
}
}
else{
if(!hydrated.open){
(0,utils_1.safeLog)(`Issue ${hydrated.number} is not open. Ignoring`);
(0,utils_1.safeLog)(`Issue ${issue.number} skipped due to not having required milsetone id ${this.milestoneId}. Had: ${(_b=issue.milestone)===null||_b===void0?void0:_b.milestoneId}`);
returnfalse;
}
// Make sure a milestones we wanted to ignore is not present.
- 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@v3
- 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 because the described behavior was determined to be by design."
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 because it is a duplicate of another issue we are tracking."
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. Please leave a 👍-upvote or 👎-downvote reaction on the issue to help us prioritize it. 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. Please leave a 👍-upvote or 👎-downvote reaction on the issue to help us prioritize it. 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. Please leave a 👍-upvote or 👎-downvote reaction on the issue to help us prioritize it. 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. Please leave a 👍-upvote or 👎-downvote reaction on the issue to help us prioritize it. 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:investigate,debugger
ignoreLabels:language service,internal
closeDays:180
closeComment:"This issue has been closed as lower priority. We're sorry if this issue still impacts you but unfortunately we're not able to address this. We will accept a pull request from the community if it's applicable for this issue."
- 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:"investigate: costing,debugger"
ignoreLabels:language service,internal
closeDays:180
closeComment:"This issue has been closed as lower priority. We're sorry if this issue still impacts you but unfortunately we're not able to address this. We will accept a pull request from the community if it's applicable for this issue."
- 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 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 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 because it is 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 because it is 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."
# Do not modify. Required for GUI based tests: See https://docs.travis-ci.com/user/gui-and-headless-browsers/#Using-xvfb-to-Run-Tests-That-Require-a-GUI
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
* [Build and debug the extension](Documentation/Getting%20started.md#build-and-debug-the-cpptools-extension).
*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`.
## Contribution Steps
*[Build and debug the extension](Documentation/Building%20the%20Extension.md).
*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/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.
*[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.
* 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/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:
*`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 |
*This is a work in progress. Please create a pull request with updates if there is anything wrong with it.*
# How To Debug MIEngine
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.
@@ -9,69 +8,119 @@ MIEngine is one of the components used to enable the C/C++ debugging scenario wi
To build MIEngine, you will either need Visual Studio 2015+ installed or at the very least [MSBuild](https://github.com/Microsoft/msbuild) installed. The configuration you want to build is `Desktop.Debug`.
You can open the solution file `MIDebugEngine.sln` located under `src` and change the configuration and build. You will want to look in the `bin\Desktop.Debug` folder for the compiled bits. You will need to copy the following files to your `.vscode\extensions\ms-vscode.cpptools-<version>\debugadapters\bin` folder in your users/home folder:
You can open the solution file **MIDebugEngine.sln** located under **src** and change the configuration and build. You will want to look in the **bin\Desktop.Debug** folder for the compiled bits. You will need to copy the following files to your **.vscode\extensions\ms-vscode.cpptools-\<version\>\debugadapters\bin** folder in your users/home folder:
On Windows, the easiest way to debug is to use Visual Studio. Locate the `package.json` file in the extension folder and open it in an editor.
On Windows, the easiest way to debug is to use Visual Studio. Locate the **src\Debugger\extension.ts** file in the **Extension** folder and open it in an editor.
Locate the following line:
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:
```json
"program":"./debugAdapters/OpenDebugAD7",
return{
command:command
};
```
and add the following line below it:
and add the following line to the object:
```json
"args":["--pauseForDebugger"],
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
On Linux and Mac OS 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.
2. Install [Xamarin Studio v5.10.1.6](http://download.xamarin.com/studio/Windows/XamarinStudio-5.10.1.6-0.msi)
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.
2. Install [Xamarin Studio v5.10.1.6](http://download.xamarin.com/studio/Windows/XamarinStudio-5.10.1.6-0.msi).
Remote attach functionality behind a flag. You can run it like this:
```
cd "\Program Files (x86)\MonoDevelop\bin"
set MONODEVELOP_SDB_TEST=1
MonoDevelop.exe
```PowerShell
cd "\Program Files (x86)\MonoDevelop\bin"
set MONODEVELOP_SDB_TEST=1
MonoDevelop.exe
```
#### Create an empty project for attaching (one-time setup)
1. Launch MonoDevelop
2. File -> New Solution
3. Misc/Generic Project
4. Name project and hit "Create"
5. Right-click the project node (blue square) and do "Options"
6. Under Run -> Custom Commands, select "Execute" in the lower dropdown and choose a command (I use c:\windows\notepad.exe - it doesn't matter what the command is, but MonoDevelop requires it to exist before it'll light up the Run menu).
##### Create an empty project for attaching (one-time setup)
#### 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.
1. Launch MonoDevelop.
2. File -> New Solution.
3. Misc/Generic Project.
4. Name project and hit "Create".
5. Right-click the project node (blue square) and do "Options".
6. Under Run -> Custom Commands, select "Execute" in the lower dropdown and choose a command (I use `c:\windows\notepad.exe` - it doesn't matter what the command is, but MonoDevelop requires it to exist before it'll light up the Run menu).
#### Attach the remote debugger
In MonoDevelop: Run -> Run With -> Custom Command Mono Soft Debugger
Fill in the IP and port of the Linux/Mac OS X machine and hit "Connect" to start debugging
##### Configure the extension to enable remote debugging
After you've done this once, you can hit the MonoDevelop "Play" button or F5 to bring up the connect dialog again.
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.
Note: If you are debugging to CentOS, you will need to make an exception in the firewall
1. Open to a new folder and create `.vscode/launch.json`.
2. Create the following configuration in launch.json.
```
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach to Mono",
"request": "attach",
"type": "mono",
"address": "<INSERT_MACHINE_IP_ADDRESS_HERE>",
"port": 1234
}
]
}
```
##### 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.
##### Attach the remote debugger
Select the `Attach to Mono` configuration and hit F5.
#### Additional Notes
Note: If you are debugging to CentOS, you will need to make an exception in the firewall.
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:
```
"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, the `launch.json` will include:
```
"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)` [Bash on Ubuntu](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 bugfixes 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.
### 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 F5 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.
Natvis framework is a framework that 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
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.
* [Why is debugging not working](#why-is-debugging-not-working)?
* Build
* [How to enable debug symbols](#how-to-enable-debug-symbols)
## Debugging Setup
The debugger needs to be configured to know which executable and debugger to use:
Click menu item: `Debug` -> `Add Configuration...`
The `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.
The FAQs for the C/C++ extension has moved to https://code.visualstudio.com/docs/cpp/faq-cpp.
* From a command line, run the following commands from the Extension folder in the root of the repository:
*`npm install -g vsce`
* This will install `vsce` globally to create the vsix package.
*`npm install` will install the dependencies needed to build the extension.
* Set an environment variable `CPPTOOLS_DEV=1`.
* This enables the local developer workflow, copying dependencies from the `node_modules` folder.
* Open the Extension folder in Visual Studio Code and F5.
* [How to contribute changes](LanguageServer/How%20to%20Contribute%20Changes.md).
# 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 quickiest 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.
#### Old information (it still works, but is no longer recommended):
Logging is controlled by environment variables and is disabled by default. To enable logging, launch VS Code from an environment that contains the following variables:
```
VSCODE_CPP_LOGDIR=c:\path\to\logfolder
VSCODE_CPP_LOGFILE_LEVEL=5
```
When you open your folder in VS Code, we will create a **vscode.cpp.log.\<pid\>.txt** file for each extension process launched (\<pid\> = process id).
The log file level is a number that determines how much detail we'll log. Level 5 is generally detailed enough to give us information about what is going on in your session. We don't recommend you set this higher than 7 since the log quickly becomes cluttered with information that doesn't really help us diagnose your issues and actually makes it harder for us to spot problems. It may also slow down the extension considerably and make it harder for you to reproduce your problem.
**Note:** You will likely need to reload the window or close VS Code to flush the contents of the log file since we do not flush the log after every call. If your log file seems to be empty, try reloading the window after you have followed the steps to reproduce your issue.
**Don't forget to remove the environment variables when you are finished providing us with the logs.** You wouldn't want the extension to needlessly spend CPU time and disk space writing data you don't need into log files.
For developers using MinGW on Windows, we recommend you start with the following **c_cpp_properties.json** template. Select "C/Cpp: Edit Configurations" from the command palette to create this file if you haven't already.
In earlier versions of the extension, the `includePath` and a some system defines need to be set in order for IntelliSense to work properly. Note that you may have to change the MinGW version number to match what you have installed. Eg. `C:/MinGW/lib/gcc/mingw32/5.3.0/` instead of `C:/MinGW/lib/gcc/mingw32/6.3.0/`.
The `includePath` above includes the system header paths that gcc uses in version 6.3.0 for C++ projects and matches the output of `"gcc -v -E -x c++ nul"`. The `intelliSenseMode` should be set to **"clang-x64"** to get MinGW projects to work properly with IntelliSense. The `__GNUC__=#` define should match the major version of the toolchain in your installation (6 in this example).
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.
## Release
For developers using Ubuntu with the current version of WSL released with the Fall Creators Update, you can add the following configuration template to your **c_cpp_properties.json** file.
The `includePath` above includes the system header paths that gcc uses for C++ projects and matches the output of `gcc -v -E -x c++ - < /dev/null`. The intelliSenseMode should be set to **"clang-x64"** to get WSL projects to work properly with IntelliSense.
Note that `${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/` is the path to the root of the Ubuntu filesystem. This will be different if you are using a different distro. You can discover the paths to your distro's filesystem by using this handy PowerShell command:
For developers using Bash on Ubuntu on Windows with the beta version of WSL from before the Fall Creators Update, you can add the following configuration template to your **c_cpp_properties.json** file.
The `includePath` above includes the system header paths that gcc uses for C++ projects and matches the output of `gcc -v -E -x c++ - < /dev/null`. The intelliSenseMode should be set to **"clang-x64"** to get WSL projects to work properly with IntelliSense.
Note that `${localappdata}/lxss/rootfs/` is the path to the root of the filesystem for Bash on Ubuntu on Windows.
For C projects, simply remove the C++ lines as in the previous example.
---
With these configurations, you should be all set up to use the new IntelliSense engine for linting, memberlist autocomplete, and quick info (tooltips). Add `"C_Cpp.intelliSenseEngine": "Default"` to your **settings.json** file to try out the new IntelliSense engine.
And 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/)!
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"` to your settings.json.
#### Old information (it still works, but is no longer recommended):
~~Logging is controlled by environment variables and is disabled by default. To enable logging, launch VS Code from an environment that contains the following variables:~~
```
VSCODE_CPP_LOGDIR=c:\path\to\logfolder
VSCODE_CPP_LOGFILE_LEVEL=5
```
~~When you open your folder in VS Code, we will create a vscode.cpp.log.\<pid\>.txt file for each extension process launched (\<pid\> = process id).~~
~~The log file level is a number that determines how much detail we'll log. Level 5 is generally detailed enough to give us information about what is going on in your session. We don't recommend you set this higher than 7 since the log quickly becomes cluttered with information that doesn't really help us diagnose your issues and actually makes it harder for us to spot problems. It may also slow down the extension considerably and make it harder for you to reproduce your problem.~~
~~**Don't forget to remove the environment variables when you are finished providing us with the logs.** You wouldn't want the extension to needlessly spend CPU time and disk space writing data you don't need into log files.~~
The documentation for logging has moved to https://code.visualstudio.com/docs/cpp/enable-logging-cpp.
[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)?
[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 or sorted include paths. If you are using a compiler in the GCC family, the system includes that you add to your `"includePath"` in **c_cpp_properties.json** should match the output of the following command: `gcc -Wp,-v -E -xc -x c++ /dev/null` (replace 'gcc' with whichever compiler you are using). GCC and its relatives require the paths to be in a specific order too, so sorting the paths for aesthetics will likely result in incorrect IntelliSense results.
## How do I get the new IntelliSense to work with MinGW on Windows?
Since MinGW is a relative of GCC, Microsoft mode compilation (which is the default on Windows) doesn't work very well with it. To use GCC/CLang mode, set the `"intelliSenseMode"` property in your **c_cpp_properties.json** file to `"clang-x64"`. An example **c_cpp_properties.json** [is shared here for your convenience](https://github.com/Microsoft/vscode-cpptools/blob/master/Documentation/LanguageServer/MinGW.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"`
*`"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 differnt 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 #include’s may not be necessary for all projects and you may still want to experience the productivity benefits of using the "Default" sematic 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.md)
For developers using MinGW on Windows, we recommend you start with the following **c_cpp_properties.json** template. Select "C/Cpp: Edit Configurations" from the command palette to create this file if you haven't already.
Note that you may have to change the MinGW version number to match what you have installed. Eg. `C:/MinGW/lib/gcc/mingw32/5.3.0/` instead of `C:/MinGW/lib/gcc/mingw32/6.3.0/`.
The `includePath` above includes the system header paths that gcc uses in version 6.3.0 for C++ projects and matches the output of `gcc -v -E -x c++ -`. The `intelliSenseMode` should be set to **"clang-x64"** to get MinGW projects to work properly with IntelliSense. The `__GNUC__=#` define should match the major version of the toolchain in your installation (6 in this example).
For C projects, simply remove the c++ lines:
```
{
"configurations": [
{
"name": "Win32",
"intelliSenseMode": "clang-x64",
"includePath": [
"${workspaceRoot}",
"C:/MinGW/lib/gcc/mingw32/6.3.0/include",
"C:/MinGW/include",
"C:/MinGW/lib/gcc/mingw32/6.3.0/include-fixed"
],
"defines": [
"_DEBUG",
"UNICODE",
"__GNUC__=6",
"__cdecl=__attribute__((__cdecl__))"
],
"browse": {
"path": [
"C:/MinGW/lib/gcc/mingw32/6.3.0/include",
"C:/MinGW/lib/gcc/mingw32/6.3.0/include-fixed",
"C:/MinGW/include/*"
],
"limitSymbolsToIncludedHeaders": true,
"databaseFilename": ""
}
}
]
}
```
With these configurations, you should be all set up to use the new IntelliSense engine for linting, memberlist autocomplete, and quick info (tooltips). Add `"C_Cpp.intelliSenseEngine": "Default"` to your **settings.json** file to try out the new IntelliSense engine.
The documentation for Mingw-w64 has moved to https://code.visualstudio.com/docs/cpp/config-mingw.
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.
## Release
For developers using Ubuntu with the current version of WSL released with the Fall Creators Update, you can add the following configuration template to your **c_cpp_properties.json** file.
The `includePath` above includes the system header paths that gcc uses for C++ projects and matches the output of `gcc -v -E -x c++ - < /dev/null`. The intelliSenseMode should be set to **"clang-x64"** to get WSL projects to work properly with IntelliSense.
Note that `${localappdata}/Packages/CanonicalGroupLimited.UbuntuonWindows_79rhkp1fndgsc/LocalState/rootfs/` is the path to the root of the Ubuntu filesystem. This will be different if you are using a different distro. You can discover the paths to your distro's filesystem by using this handy Powershell command:
For developers using Bash on Ubuntu on Windows with the beta version of WSL from before the Fall Creators Update, you can add the following configuration template to your **c_cpp_properties.json** file.
The `includePath` above includes the system header paths that gcc uses for C++ projects and matches the output of `gcc -v -E -x c++ - < /dev/null`. The intelliSenseMode should be set to **"clang-x64"** to get WSL projects to work properly with IntelliSense.
Note that `${localappdata}/lxss/rootfs/` is the path to the root of the filesystem for Bash on Ubuntu on Windows.
For C projects, simply remove the c++ lines as in the previous example.
---
With these configurations, you should be all set up to use the new IntelliSense engine for linting, memberlist autocomplete, and quick info (tooltips). Add `"C_Cpp.intelliSenseEngine": "Default"` to your **settings.json** file to try out the new IntelliSense engine.
And 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.
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.