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
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>
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.
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
* Fix rename error and its message and linux build
Rename was always outputting an error message since the callback is
always called. Included and error check. For offline install, if
opendebug.exe.config exists, rename needs to happen too. Added function
call for offline installation.
'use strict' was erroring on ubuntu build in copyScript.ts
* Prevent downloadCpptoolsJsonPkg from delaying activation.
* Also, changed the default workspaceParsingPriority to "highest" and the "normal" enum to "medium".
* And updated the changelog.
* Adding Gulp and tslint
Adding tslint and the associated changes that it complains about.
Adding gulp to do tests, tslint, and more.
Including package-lock.json that it keeps complaining about.
* Adding back license that was accidently deleted.
* Updating package-lock.json and missing import
* Sorting and fixing commands for npm run
Added npm run test, watch, and tslint.
* Adding rules for whitespace and types for tslint
* Updating .gitignore rules
* Adding more rules and sorting tslint.json
new-parens for forcing all constructor calls to have parenthesis.
no more than 1 consecutive blank lines
no useage of String(), Boolean(), or Number(), use native type.
* Adding rule to force brance on the same line
* tslint rule to add function return types
* Adding tslint as part of travisci
We still allow overrides for different package locations but this will
use the vscode extension folder as a fallback if you have the extension
installed to get the extension location.
As the latest recommended version of MinGW is 6.3.0 and MinGW strongly discourages using old versions, I think it's appropriate to update the version numbers for this file and add a notice informing users that they may have to change the MinGW file path to match their version.
about:'Issues pertaining to IntelliSense, autocomplete, code editing, etc. '
title:''
labels:''
assignees:''
---
**Type: LanguageService**
<!----- Input information below ----->
<!--
**Prior to filing an issue, please review:**
- Existing issues at https://github.com/Microsoft/vscode-cpptools/issues
- Our documentation at https://code.visualstudio.com/docs/languages/cpp
- FAQs at https://code.visualstudio.com/docs/cpp/faq-cpp
-->
**Describe the bug**
- OS and Version:
- VS Code Version:
- C/C++ Extension Version:
- Other extensions you installed (and if the issue persists after disabling them):
- Does this issue involve using SSH remote to run the extension on a remote machine?:
- A clear and concise description of what the bug is, including information about the workspace (i.e. is the workspace a single project or multiple projects, size of the project, etc).
**Steps to reproduce**
<!-- Provide clear steps to reproduce the behavior: -->
<!-- *The most actionable issue reports include a code sample including configuration files such as c_cpp_properties.json* -->
1. Go to '...'
2. Click on '....'
3. Scroll down to '....'
4. See error
**Expected behavior**
<!-- A clear and concise description of what you expected to happen. -->
<!-- Please provide the following logs that show diagnostics and debugging information about the language server.
1. Logs from the command `C/C++: Log Diagnostics`
2. Logs from [the language server](https://code.visualstudio.com/docs/cpp/enable-logging-cpp#_enable-logging-for-the-language-server)
-->
<details>
<summary><strong>Logs</strong></summary>
<!-- Note: do not remove empty line after </summary> tag, otherwise the code blocks formatting won't show correctly. -->
```
Insert logs here.
```
</details>
**Screenshots**
<!-- If applicable, add screenshots to help explain your problem. -->
**Additional context**
<!--
* Call Stacks: For bugs like crashes, deadlocks, infinite loops, etc. that we are not able to repro and for which the call stack may be useful, please attach a debugger and/or create a dmp and provide the call stacks. Windows binaries have symbols available in VS Code by setting your "symbolSearchPath" to "https://msdl.microsoft.com/download/symbols".
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact opencode@microsoft.com with any additional questions or comments.
* [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/master/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.
## 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().
* 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.
* **(optional)** Set an environment variable `CPPTOOLS_DEV=1`.
* This enables the local developer workflow when testing the debugger, copying dependencies from the **node_modules** folder. Testing the language server does not require this step.
* 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.
*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.
### Debugging MIEngine running on Linux or Mac OS X
#### With MonoDevelop
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).
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, 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.
**NOTE: Creator's Update 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.**
## Prerequisites
* [Windows 10 Creators Update with Windows Subsystem for Linux and Bash](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.
#### 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/)!
[Why do I have red underlines everywhere after updating to the latest version](#why-do-i-have-red-underlines-everywhere-after-updating-to-the-latest-version)?
[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)?
## Why do I have red underlines everywhere after updating to the latest version?
If you are using the VS Code Insider build with version 0.11.0 of the cpptools extension or any build of VS Code with version 0.11.1 or higher of the extension, then the extension will default to using the new IntelliSense engine for linting and providing quick info tooltips in your source files.
For some users this may result in a large number of red underlines ("squiggles") appearing in your source files. There are a few things you can do to resolve this issue. Select the one that best meets your needs for your situation.
1. Update your includePath and defines
2. Disable the error squiggles
3. Disable the new IntelliSense engine
#### Update your includePath and defines
If you haven't already created a c_cpp_properties.json file for your project, you can do so by selecting "C/Cpp: Edit Configurations" from the command palette. This will create and open the c_cpp_properties.json file for you. 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.
#### Disable the error squiggles
If you want to keep using the semantic-aware features that will be coming online via the new IntelliSense engine, but don't want to see the error squiggles in the editor, then you can disable the lint messages by adding `"C_Cpp.errorSquiggles": "Disabled"` to your settings.json file.
#### Disable the new IntelliSense engine
If you were happy with the old behavior of the extension or want to wait to get the semantic-aware features until build system support arrives in the extension so that you don't have to manually configure a c_cpp_properties.json file, you can disable the new IntelliSense engine entirely by adding `"C_Cpp.intelliSenseEngine": "Tag Parser"` to your settings.json file.
## How do I get the new IntelliSense to work with MinGW on Windows?
On Windows PCs, the new IntelliSense engine is configured to compile your source files in Microsoft mode. But since MinGW is a relative of GCC, Microsoft mode compilation doesn't work very well with it. While the IntelliSense engine supports compiling code in clang/gcc mode, the extension does not currently expose any settings that allow you to configure it.
You can, however, override the engine's configuration by changing the contents of the `%userprofile%\.vscode\extensions\ms-vscode.cpptools-0.11.1\bin\msvc.64.intel.json` file. In fact, copying `msvc.64.linux.json` over `msvc.64.intel.json` will reconfigure the engine to compile your source code in clang mode. The caveat is that making changes to the `msvc.64.intel.json` is not a permanent operation. The next time you upgrade the extension, your changes will be reverted. However, this workaround should be able to enable you to use the new IntelliSense engine with MinGW until we have time to expose a proper setting.
## 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.
The extension will also implicitly add `${workspaceRoot}` to the array of paths unless `"C_Cpp.addWorkspaceRootToIncludePath"` is explicitly set to `false` in your settings.json file.
The FAQs for the C/C++ extension has moved to https://code.visualstudio.com/docs/cpp/faq-cpp.
This preview release of the C/C++ extension adds language support for C/C++ to Visual Studio Code, including features such as IntelliSense and debugging.
If someone has already filed an issue that encompasses your feedback, please leave a 👍 or 👎 reaction on the issue to upvote or downvote it to help us prioritize the issue.
Let us know what you think of the extension by taking the quick survey.
## Offline installation
The extension has platform-specific binary dependencies, therefore installation via the Marketplace requires an Internet connection in order to download additional dependencies. If you are working on a computer that does not have access to the Internet or is behind a strict firewall, you may need to use our platform-specific packages and install them by running VS Code's `"Install from VSIX..."` command. These "offline' packages are available at: https://github.com/Microsoft/vscode-cpptools/releases.
Package | Platform
:--- | :---
`cpptools-linux.vsix` | Linux 64-bit
`cpptools-linux-armhf.vsix` | Linux ARM
`cpptools-linux-aarch64.vsix` | Linux ARM 64-bit
`cpptools-osx.vsix` | macOS
`cpptools-win32.vsix` | Windows 64-bit & 32-bit
`cpptools-linux32.vsix` | Linux 32-bit ([available up to version 0.27.0](https://github.com/microsoft/vscode-cpptools/issues/5346))
## Contribution
Contributions are always welcome. Please see our [contributing guide](CONTRIBUTING.md) for more details.
## Microsoft Open Source Code of Conduct
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact opencode@microsoft.com with any additional questions or comments.
## Data and telemetry
This extension collects usage data and sends it to Microsoft to help improve our products and services. Collection of telemetry is controlled via the same setting provided by Visual Studio Code: `"telemetry.enableTelemetry"`. Read our [privacy statement](https://privacy.microsoft.com/en-us/privacystatement) to learn more.
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.