jiebi/CodeConvo huggingface dataset:
Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --Pasting the below into a markdown file will cause a cpu thread to be pinned at 100% because of catastrophic backtracking. fixes it.
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.947 --<!-- potentialduplicatescomment --
This bug has been fixed in to the latest release of ! you can help us out by confirming things are working as expected in the latest Insiders release. If things look good, please leave a comment with the text to let us know. If not, please ensure you're on version of Insiders (today's or later - you can use in the command palette to check), and leave a comment letting us know what isn't working as expected. Happy Coding!
/verified

Discussion:
} export default class LinkProvider implements vscode.DocumentLinkProvider { <del> private readonly linkPattern = /([((![[^]]*?](s*)([^s()]+?)s*)]|(?:]|[^]])*])(s*)(([^s()]|(S*?))+)s*(".*?")?)/g; </del> <ins> private readonly linkPattern = /([((![[^]]*?](s*)([^s()]+?)s*)]|(?:]|[^]])*])(s*)(([^s()]|([^s()]*?))+)s*(".*?")?)/g; </ins> private readonly referenceLinkPattern = /([((?:]|[^]])+)][s*?)([^s]]*?)]/g; private readonly definitionPattern = /^([t ]*[(?!^)((?:]|[^]])+)]:s*)(S+)/gm;
Change:
Issue Type: <bBug</bThe file has an incorrect language association by default ( instead of ). The has comments, so there are red squiggly lines when you open this file until you change the language to . VS Code version: Code 1.51.1 (, 2020-11-10T23:34:32.027Z) OS version: WindowsNT x64 10.0. Remote OS version: Linux x64 4.19.128-microsoft-standard Remote OS version: Linux x64 4.19.128-microsoft-standard Remote OS version: Linux x64 4.19.128-microsoft-standard <details<summarySystem Info</summary </details<details<summaryExtensions (2)</summaryExtensionVersion ------ remote-wsl0.51.3 vscode-eslint2.1.13 </details<!-- generated by issue reporter --
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.714 --- <!-- score: 0.534 --- <!-- score: 0.492 --<!-- potentialduplicatescomment --

Discussion:
], "filenames": [ "composer.lock", <del> ".watchmanconfig", ".ember-cli" </del> <ins> ".watchmanconfig" </ins> ], "mimetypes": [ "application/json",

".hintrc", ".babelrc" ], <ins> "filenames": [ ".ember-cli" ], </ins> "configuration": "./language-configuration.json" } ],
Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.51.1 OS Version: on both Fedora 32 and Linux Mint 20 Steps to Reproduce: clone issuesvscode1400markdownPreviewRootRelativeImg . doesn't display in ! <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes This issue had already occurred in past: In the latest insiders vs-code build - it's not fixed as well.
I took a look at this and found that the issue is that the resource vscode-webview-resource uri is invalid, is missing before I was looking how to fix it but I can't find the place where the gets mapped to a can you give me some code pointers?
here is my quick and dirty fix for this issue:
Start by looking in the markdown link normalizer I believe this is passed the raw image links and tries to transform them into url that VS Code can render in the preview
Thanks and after spending some more time looking at this I think I found a proper fix for it

Discussion:
return normalizeLink(vscode.Uri.parse(link).with({ scheme: vscode.env.uriScheme }).toString()); } <ins> // Support file:// links if (isOfScheme(Schemes.file, link)) { // Ensure link is relative by prepending `/` so that it uses the <base> element URI // when resolving the absolute URL return normalizeLink('/' + link.replace(/^file:/, 'file')); } </ins> // If original link doesn't look like a url with a scheme, assume it must be a link to a file in workspace if (!/^[a-z-]+:/i.test(link)) { // Use a fake scheme for parsing

if (uri.path[0] === '/') { const root = vscode.workspace.getWorkspaceFolder(this.currentDocument!); if (root) { <del> const fileUri = vscode.Uri.joinPath(root.uri, uri.fsPath); uri = fileUri.with({ scheme: uri.scheme, </del> <ins> const fileUri = vscode.Uri.joinPath(root.uri, uri.fsPath).with({ </ins> fragment: uri.fragment, query: uri.query, }); <ins> // Ensure fileUri is relative by prepending `/` so that it uses the <base> element URI // when resolving the absolute URL uri = vscode.Uri.parse('markdown-link:' + '/' + fileUri.toString(true).replace(/^S+?:/, fileUri.scheme)); </ins> } }

private addLinkValidator(md: any): void { const validateLink = md.validateLink; md.validateLink = (link: string) => { <del> // support file:// links </del> return validateLink(link) <del> || isOfScheme(Schemes.file, link) </del> || isOfScheme(Schemes.vscode, link) || isOfScheme(Schemes['vscode-insiders'], link) || /^data:image/.*?;/.test(link);
Change:
<!-- Do Not Delete This! featurerequesttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Describe the feature you'd like. --Hello! I noticed that the current for in snippet uses the object.hasOwnProperty(), which can lead to a security vulnerability described here: I'm proposing a change to Object.hasOwnProperty.

Discussion:
"prefix": "forin", "body": [ "for (const ${1:key} in ${2:object}) {", <del> "tif (${2:object}.hasOwnProperty(${1:key})) {", </del> <ins> "tif (Object.hasOwnProperty.call(${2:object}, ${1:key})) {", </ins> "ttconst ${3:element} = ${2:object}[${1:key}];", "tt$0", "t}",
Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --The query parameter for "refsrc" when submitting "sad" feedback is "nullrefsrc" instead of just "refsrc" because null is erroneously concatenated. <!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.51.1 (user setup) OS Version: WindowsNT x64 10.0. Steps to Reproduce: the tweet feedback UI using the button in the bottom right of code. the sad face some tweet content tweet resulting URL will be something like ,twitter&text=123&twp=tweetbutton&via=code <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
(Experimental duplicate detection) Thanks for submitting this issue. Please also check if it is already covered by an existing one, like: <!-- score: 0.684 --- <!-- score: 0.579 --<!-- potentialduplicatescomment --
Up for grab.
It's still nullref for me: ^tfw&related=twitterapi,twitter&text=Testing&twp=tweetbutton&via=code
not for me when I update insiders to latest, what's your insiders version?
It works for me now too, after updating again. /verified

Discussion:
} submitFeedback(feedback: IFeedback, openerService: IOpenerService): void { <del> const queryString = `?${feedback.sentiment === 1 ? `hashtags=${this.combineHashTagsAsString()}&` : null}ref_src=twsrc%5Etfw&related=twitterapi%2Ctwitter&text=${encodeURIComponent(feedback.feedback)}&tw_p=tweetbutton&via=${TwitterFeedbackService.VIA_NAME}`; </del> <ins> const queryString = `?${feedback.sentiment === 1 ? `hashtags=${this.combineHashTagsAsString()}&` : ''}ref_src=twsrc%5Etfw&related=twitterapi%2Ctwitter&text=${encodeURIComponent(feedback.feedback)}&tw_p=tweetbutton&via=${TwitterFeedbackService.VIA_NAME}`; </ins> const url = TwitterFeedbackService.TWITTER_URL + queryString; openerService.open(URI.parse(url));
Change:
This just started very recently. !
I cannot reproduce. I tried with GitLens using the insiders: !
Yeah it went away for me in yesterday's insiders. Maybe it went away when we switched back to Electron 9?
Electron 11 went in at the beginning of last week, is that when you started noticing this ?
Not exactly sure but I only saw it very recently. And it was gone again a day or two ago.
OK, given we cannot reproduce right now, let's close for now and we can reopen if we see it again when we bring back Electron 11.
It's back in the current insiders.

Discussion:
} .monaco-hover hr { <ins> box-sizing: border-box; border-left: 0px; border-right: 0px; </ins> margin-top: 4px; margin-bottom: -4px; <del> margin-left: -10px; margin-right: -10px; </del> <ins> margin-left: -8px; margin-right: -8px; </ins> height: 1px; }
Change:
Issue Type: <bBug</bMarkdown's auto-links for emails show differently if the email domain has capital letters in it. See example below. I noticed that the regex used in vscode is not the same as the one mentioned in the commonmark spec. (This is cosmetic only. In the preview, both show the same formatting) /^? (?:.?)$/ VS Code: Screenshot: ! VS Code version: Code 1.51.1 (, 2020-11-10T23:34:32.027Z) OS version: WindowsNT x64 10.0. (Confirmed with all extensions disabled) <details<summarySystem Info</summary </detailsExtensions: none <!-- generated by issue reporter --
For anyone interested in contributing a fix, here's where the grammar live: Make sure to fix it in the file, which generates the file

Discussion:
* Submitting pull requests ## Related Projects <del> Many of the core components and extensions to Code live in their own repositories on GitHub. For example, the [node debug adapter](https://github.com/microsoft/vscode-node-debug), the [mono debug adapter](https://github.com/microsoft/vscode-mono-debug). </del> <ins> Many of the core components and extensions to Code live in their own repositories on GitHub. For example, the [node debug adapter](https://github.com/microsoft/vscode-node-debug) and the [mono debug adapter](https://github.com/microsoft/vscode-mono-debug). </ins> For a complete list, please see the [Related Projects](https://github.com/Microsoft/vscode/wiki/Related-Projects) page on our wiki.
Change:
Testing scenario in Codespaces web UI Opening a Python file in a fresh codespace Web UI shows a notification: ! Clicking on Yes shows ! VSCode desktop is opened Python calls VSCode should intercept that URI and handle it by directly opening the extensions viewlet and not make an external call
Unassigning myself as it seems url handling related. Please let me know if there is something I have to do in extensions area.
What do you think? Should we perform the fast-track to handle these URIs internally?
I can't repro this in desktop Code. I can repro in web
I couldn't get the Python extension to show that dialog again, so I verified that with my own extension that does That code is inspired by That code works and, on codespaces now directly opens the extension viewlet. -verified However, if you do '();' it opens the external open dialog again. In the first case the URL has a relative path (), in the second one an absolute (). Relative paths are kind of rare. Is that all as designed? Or would it be better to also accept the absolute path?
Paths are not required to be rooted in , or even separated by characters: they can be arbitrary strings within the allowed character set. We've long defined extension URIs to simply be . Not sure if you've seen the format anywhere in our docs? If so we gotta fix it.
I will have to revert the fix for this, since it broke existing functionality. With the fix, a web extension can no longer actually open a URI in desktop Code. When looking at the breakage, I no longer this this is true. If is invoked, it should always be handled externally, never internally, unless it's absolutely obvious (running in Desktop). The right way to move forward here is to have the Python extension run the instead of calling .

Discussion:
import { AbstractURLService } from 'vs/platform/url/common/urlService'; import { Event } from 'vs/base/common/event'; import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; <ins> import { IOpenerService, matchesScheme } from 'vs/platform/opener/common/opener'; import { IProductService } from 'vs/platform/product/common/productService'; </ins> export interface IURLCallbackProvider {

private provider: IURLCallbackProvider | undefined; constructor( <del> @IWorkbenchEnvironmentService environmentService: IWorkbenchEnvironmentService </del> <ins> @IWorkbenchEnvironmentService environmentService: IWorkbenchEnvironmentService, @IOpenerService openerService: IOpenerService, @IProductService productService: IProductService </ins> ) { super(); this.provider = environmentService.options?.urlCallbackProvider; this.registerListeners(); <ins> const that = this; this._register(openerService.registerOpener({ async open(resource: URI | string) { if (!matchesScheme(resource, productService.urlProtocol)) { return false; } if (typeof resource === 'string') { resource = URI.parse(resource); } return that.open(resource); } })); </ins> } private registerListeners(): void {
Change:
<!-- Do Not Delete This! bugreporttemplate --"accesible" -"accessible" Suggestion: Say "available" rather than "accessible". "Enables an experimental Get Started page, available via the Help menu."

Discussion:
properties: { 'workbench.experimental.gettingStarted': { type: 'boolean', <del> description: localize('gettingStartedDescription', "Enables an experimental Getting Started page, accesible via the Help menu."), </del> <ins> description: localize('gettingStartedDescription', "Enables an experimental Getting Started page, available via the Help menu."), </ins> default: false, } }
Change:
Steps to Reproduce: that 52 of 69 issues are unrelated to security
btw I am seeing 84 errors, many of those are errors for async-import-statements. I am also surprised that complains about the use of trusted types policies. What are we supposed to do with such errors?
84 errors ? After I only see 19 and related issues. The issues are a current limitation of tsec which does not yet understand the Worker construction (we will fix it in tsec and send you and update when it is done, likely sometime next quarter). As for the errors, these are "expected" as they indicate the "vulnerable surface" of your code that requires manual review. In google, usages of are only allowed for the security team, which we use to exposes secure by construction APIs. That being said this does not necessarily translate well to your case, and I will invest some time in the first half of 2021 to: reduce / restrict and review current usages of improve devX around non-TrustedTypes supported browsers The good news is that apart from , it seems that all of your code is Trusted Types compatible & you should be able to start experimenting with enforcing Trusted Types through the header. For reference, here are all the errors I see:
Yeah, the is something new and an oversight. There is also still this then we should we good. I have running locally with trusted types enforced and default policy that logs and haven't found more places
Yeah, after that. I have a feeling that yarn handle these packages well.

Discussion:
"source-map": "^0.4.4", "style-loader": "^1.0.0", "ts-loader": "^4.4.2", <del> "tsec": "googleinterns/tsec#630b53fe2b23815c28dd219119cc98dbd59e29b2", </del> <ins> "tsec": "googleinterns/tsec#7bf4ab23686500522341b977b3e2cc04b1f720b1", </ins> "typescript": "4.2.0-dev.20201207", "typescript-formatter": "7.1.0", "underscore": "^1.8.2",

micromatch "^3.1.4" semver "^5.0.1" <del> tsec@googleinterns/tsec#630b53fe2b23815c28dd219119cc98dbd59e29b2: </del> <ins> tsec@googleinterns/tsec#7bf4ab23686500522341b977b3e2cc04b1f720b1: </ins> version "0.0.1" <del> resolved "https://codeload.github.com/googleinterns/tsec/tar.gz/630b53fe2b23815c28dd219119cc98dbd59e29b2" </del> <ins> resolved "https://codeload.github.com/googleinterns/tsec/tar.gz/7bf4ab23686500522341b977b3e2cc04b1f720b1" </ins> dependencies: "@types/node" "^13.13.5" <ins> typescript "^4.1.2" </ins> tslib@^1.8.1, tslib@^1.9.0: version "1.9.3"

resolved "https://registry.yarnpkg.com/typescript/-/typescript-2.6.2.tgz#3c5b6fd7f6de0914269027f03c0946758f7673a4" integrity sha1-PFtv1/beCRQmkCfwPAlGdY92c6Q= <ins> typescript@^4.1.2: version "4.1.2" resolved "https://registry.yarnpkg.com/typescript/-/typescript-4.1.2.tgz#6369ef22516fe5e10304aae5a5c4862db55380e9" integrity sha512-thGloWsGH3SOxv1SoY7QojKi0tc+8FnOmiarEGMbd/lar7QOEd3hvlx3Fp5y6FlDUGl9L+pd4n2e+oToGMmhRQ== </ins> uc.micro@^1.0.1, uc.micro@^1.0.3: version "1.0.3" resolved "https://registry.yarnpkg.com/uc.micro/-/uc.micro-1.0.3.tgz#7ed50d5e0f9a9fb0a573379259f2a77458d50192"
Change:
Automatic port forwarding waits for environment tunnels to be set before starting. However, environment tunnels are not set with embedders.

Discussion:
import { IWorkbenchEnvironmentService } from 'vs/workbench/services/environment/common/environmentService'; import { IOpenerService } from 'vs/platform/opener/common/opener'; import { URI } from 'vs/base/common/uri'; <ins> import { IRemoteExplorerService } from 'vs/workbench/services/remote/common/remoteExplorerService'; </ins> export class TunnelFactoryContribution extends Disposable implements IWorkbenchContribution { constructor( @ITunnelService tunnelService: ITunnelService, @IWorkbenchEnvironmentService environmentService: IWorkbenchEnvironmentService, <del> @IOpenerService openerService: IOpenerService </del> <ins> @IOpenerService openerService: IOpenerService, @IRemoteExplorerService remoteExplorerService: IRemoteExplorerService </ins> ) { super(); const tunnelFactory = environmentService.options?.tunnelProvider?.tunnelFactory;

} })); } <ins> remoteExplorerService.setTunnelInformation(undefined); </ins> } }
Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --- VSCode Version: 1.53.0-Insider OS Version: Windows 10 Steps to Reproduce: Settings (CTRL + , or CMD + ,) for 'sugget' description for 'Setting: Show Inline Details' and you'll find the typo 'sugget' instead of 'suggest' <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes/No Yes !

Discussion:
'editor.suggest.showInlineDetails': { type: 'boolean', default: defaults.showInlineDetails, <del> description: nls.localize('suggest.showInlineDetails', "Controls whether sugget details show inline with the label or only in the details widget") </del> <ins> description: nls.localize('suggest.showInlineDetails', "Controls whether suggest details show inline with the label or only in the details widget") </ins> }, 'editor.suggest.maxVisibleSuggestions': { type: 'number',
Change:
felix becker php-debug extension php file not set breakpoint
Related
This is fixed, thus closing
Can't also set breakpoints on cpp.
please open a new issue. Use the option from the Help menu to do this so you include plenty of information. Add repro steps including pasted screenshots if you think they can help.

Discussion:
if (!rawAdapter.type || (typeof rawAdapter.type !== 'string')) { added.collector.error(nls.localize('debugNoType', "Debugger 'type' can not be omitted and must be of type 'string'.")); } <ins> if (rawAdapter.enableBreakpointsFor && rawAdapter.enableBreakpointsFor.languageIds) { rawAdapter.enableBreakpointsFor.languageIds.forEach(modeId => { this.breakpointModeIdsSet.add(modeId); }); } </ins> if (rawAdapter.type !== '*') { const existing = this.getDebugger(rawAdapter.type);

// supported languages languages?: string[]; <ins> enableBreakpointsFor?: { languageIds?: string[] }; </ins> // debug configuration support configurationAttributes?: any;
Change:
Line 99 should NOT be only comparing to . That is a recipe for missing the correct tunnel. It should instead use the proper utility to check for all strings.
To repro the original issue with Containers: vscode with --enable-proposed-api=alexr00.helloworld-sample into a container this vsix it to be UI and reload: install start that a port was auto forwarded the "Hello Port" command that port 3000 was forwarded a second time To verify, follow the above steps and make sure that (7) doesn't happen.

Discussion:
if (originalAddress) { return originalAddress; } <del> const otherHost = isAllInterfaces(host) ? 'localhost' : (host === 'localhost' ? '0.0.0.0' : undefined); </del> <ins> const otherHost = isAllInterfaces(host) ? 'localhost' : (isLocalhost(host) ? '0.0.0.0' : undefined); </ins> if (otherHost) { return mapHasAddress(map, otherHost, port); }
Change:
VSCode Version: 1.52.1 OS Version: Win10 20H2 Steps to Reproduce: a task to run with the default ("stylish") formatter, using the problem matcher code that trips a linter rule with a multi-line message, such as the task Problems tab has a new problem that points to a file called "ban-types" (in this example), because it matched the rule message as if it were a file path Does this issue occur when all extensions are disabled?: Yes Note that the linked issue has an example of some Typescript source that will trigger the example rule.
If somebody also waits for this fix to be merges, you can temporary override problemMatcher patters directly in the
, any plans to merge this PR soon? I'm using this fix for some time and all looks good.
I missed the PR when it came in . I've posted a comment in the PR.

Discussion:
}); this.add('eslint-stylish', [ { <del> regexp: /^([^s].*)$/, </del> <ins> regexp: /^((?:[a-zA-Z]:)*[/.]+.*?)$/, </ins> kind: ProblemLocationKind.Location, file: 1 },
Change:
<!-- Do Not Delete This! bugreporttemplate --<!-- Please read our Rules of Conduct: --<!-- Please search existing issues to avoid creating duplicates. --<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: --<!-- Use Help Report Issue to prefill these. --Steps to Reproduce: the cursor with arrow keys (no modifiers) onto a word then stop after a moment it will highlight other matches that are visible on screen (or in the whole file, with the scrollbar markers) particular, notice that if you stop on the edge of a word, it will still highlight it. , move around with ctrl+left or ctrl+right. You will only be able to stop on word edges in this case. that in this case, no highlight happens, unlike when you land on a word edge by moving only with arrows. , if you move the cursor more than one character in other ways (f.e. you use VS Code APIs to programmatically move the cursor), no highlight happens. As an effect of this, plugins like (which move the cursor in custom ways) will not show any highlight when moving more than one character (or line) at a time. <!-- Launch with to check. --Does this issue occur when all extensions are disabled?: Yes
In the following example recording, first I move character by character with the left and right arrows keys, and when I stop moving, you see that highlight works. In the last half of the recording I move with ctrl + arrow keys, in which case no highlight happens when I stop moving: !

Discussion:
this.updateSoon.schedule(); } else { this._setState(null); } } else { this._update();

}); model.pushStackElement(); <del> editor._getViewModel().setCursorStates('moveWordCommand', CursorChangeReason.NotSet, result.map(r => CursorState.fromModelSelection(r))); </del> <ins> editor._getViewModel().setCursorStates('moveWordCommand', CursorChangeReason.Explicit, result.map(r => CursorState.fromModelSelection(r))); </ins> if (result.length === 1) { const pos = new Position(result[0].positionLineNumber, result[0].positionColumn); editor.revealPosition(pos, ScrollType.Smooth);