sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: Search and replace across files corrupts files with CR line endings
Labels: bug,search,confirmed


Issue Type: <b>Bug</b>

Execute these commands:

```cmd
git clone https://github.com/AArnott/pinvoke.git
cd pinvoke
git checkout b1239bc075f87f202a410973d7faa468a5e6b9cf
code .
```

In the Search panel, search for "LICENSE.txt" and replace with "LICENSE" (no other options such as regex are selected).

In the search and replace results (before commiting them), notice how the second line of most source files has a small change applied. This is good.
But notice how 4 files have an erroneous change applied to the first line:

* src/User32/User32+DLGITEMTEMPLATE.cs
* src/User32/User32+DLGTEMPLATE.cs
* src/User32/User32+MSG.cs
* src/User32/User32+PeekMessageRemoveFlags.cs

VS Code version: Code 1.22.1 (950b8b0d37a9b7061b6f0d291837ccc4015f5ecd, 2018-04-06T02:26:57.615Z)
OS version: Windows_NT x64 10.0.16299

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8650U CPU @ 1.90GHz (8 x 2112)|
|Memory (System)|15.93GB (2.72GB free)|
|Process Argv|C:\Program Files\Microsoft VS Code\Code.exe .|
|Screen Reader|no|
|VM|0%|

</details><details><summary>Extensions (16)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-markdownlint|Dav|0.14.1
githistory|don|0.4.0
xml|Dot|1.9.2
gitlens|eam|8.2.1
EditorConfig|Edi|0.12.1
git-project-manager|fel|1.5.1
docker-linter|hen|0.5.0
docomment|k--|0.0.18
azure-account|ms-|0.4.0
cpptools|ms-|0.16.1
csharp|ms-|1.14.0
PowerShell|ms-|1.6.0
team|ms-|1.133.0
vscode-docker|Pet|0.0.26
java|red|0.23.0
vsc-docker|Zim|0.34.0


</details>
<!-- generated by issue reporter -->
Repository: angular
Issue: Generated output in ngsw.json is wrong
Labels: type: bug/fix,freq1: low,area: service-worker,state: needs more investigation,P4

## I'm submitting a...
<pre><code>
[x] Bug report 
[ ] Feature request
</code></pre>

## Current behavior
When run the build script with the inline argument of `--base-href /current/` and in the `ngsw.json` file use the absolute path for the files, it produces the path `/current/index.html` in the built `ngsw.json`. Using of the relative path in the `ngsw.json` does not help.

## Expected behavior
Either using the relative path in the `ngsw.json` or generating the output due to the `--base-href` value. 

## Environment

<pre><code>
Angular version: 5.0.0
@angular/service-worker: 5.2.10

Browser:
- [x] Chrome (desktop) version 65
For Tooling issues:
- Node version: 8.9.4
- Platform: Windows

</code></pre>
Repository: TypeScript
Issue: In JS, type annotations should not block errors from the rest of the program
Labels: Suggestion,Awaiting More Feedback,Domain: JavaScript

In a Javascript file that is checked by flow, we may see code like this (from create-react-app/packages/react-error-overlay/src/utils/parseCompileError.js)
```js
export type ErrorLocation = {|
  fileName: string,
  lineNumber: number,
  colNumber?: number,
|}
function parseCompileError(message: string): ?ErrorLocation {
  const lines: Array<string> = message.split('\n');
  for (let i = 0; i < lines.length; i++) {
// ...................
  return fileName && lineNumber ? { fileName, lineNumber, colNumber } : null;
}
```

This behaves badly when the typescript compiler compiles it with checkJs on:

**Expected behavior:**
1. Errors on the type declaration and all the type annotations. 
2. However, ErrorLocation should be declared as a type alias, and message, lines, etc should all have their declared types. 
3. If they are used incorrectly, they should have errors.

**Actual behavior:**
1. Errors on the type declaration and all the type annotations.

In the language service:
2. message, lines, etc have the correct types, **but ErrorLocation is type any**.
3. If they are used incorrectly, they have errors.

In batch compilation:
2. No errors show up except those from (1), even if there are lots of other javascript files without type annotations.
Repository: kubernetes
Issue: Guidelines for node-level plugin auth
Labels: kind/cleanup,kind/feature,sig/auth,priority/important-longterm,lifecycle/frozen

**Overview**

I get a lot of questions about how to setup mutual authentication for node-level cluster plugins. Examples include:

- Local volume provisioning
- Device plugins (modify node object)
- Device metrics (scraping)
- CRI Streaming
- _Are there others I'm missing?_

For the general case, our recommendation has been to use a service mesh (such as Istio), or NetworkPolicy (although this isn't really a full solution). But as both of those are optional features on Kubernetes, I don't think they are sufficient for core functionality.

We need some general guidelines for plugins, and may need to build some additional capabilities or libraries to support them.

The architecture we need to target includes:
- A central control component, running as a deployment in the cluster. Let's call this the "CCC".
- A DaemonSet that handles node operations, and communicates back to the controller. Let's call this the "DSP" (DaemonSet Pod).
- K8s API server

Things we might need to solve:

1. CCC -> apiserver (solved)
  a. [x] server (apiserver) authn -- cluster CA
  b. [x] client (CCC) authn -- Use service account tokens
  c. [x] authz -- RBAC
2. CCC -> DSP
  a. [ ] server (DSP) authn
  b. [x] client (CCC) authn -- Service account tokens + TokenReview
  c. [x] authz -- RBAC + SubjectAccessReview
3. DSP -> CCC
  a. [ ] server (CCC) authn
  b. [ ] client (DSP) authn
  c. [ ] authz
4. DSP -> apiserver
  a. [x] server (apiserver) authn -- cluster CA
  b. [ ] client (DSP) authn
  c. [ ] authz

Optionally, we could only solve one of (2) and (3), and just require communications to happen in a single direction (i.e. pull or push). We also might be able to avoid (4) by delegating to the CCC (i.e. require all DSP requests to the apiserver to go through the CCC).

/kind technical-debt
/sig auth

/cc @dashpole @vishh @davidz627 @Random-Liu
Repository: go
Issue: testing: show rusage statistics for benchmarks
Labels: NeedsInvestigation

When optimizing CPU usage, it would be useful to get CPU usage information from Go benchmarks.

Could we add, where supported, [getrusage](http://man7.org/linux/man-pages/man2/getrusage.2.html) calls before and after running each benchmark, in addition to wall-time?

I have no opinion about the API for requesting those statistics. Perhaps adding a `-test.stats` or `-test.resources` flag would work?
For example: `-test.stats=utime,stime,maxrss`. 

This doesn't have to be rusage specific. For instance, it could be extended with statistics from the [perf_event](http://man7.org/linux/man-pages/man2/perf_event_open.2.html) API at some point.

I could send a CL if this is a welcome change.
Repository: rust
Issue: Detect recursive instantiation of generic functions
Labels: A-type-system,C-enhancement,A-diagnostics,T-compiler,D-terse,T-types

#### We currently have a quite helpful diagnostic for unconditionally recursive functions:

```rust
pub fn recur() {
    recur();
}
```

```
warning: function cannot return without recurring
 --> src/main.rs:1:1
  |
1 | pub fn recur() {
  | ^^^^^^^^^^^^^^ cannot return without recurring
2 |     recur();
  |     ------- recursive call site
  |
  = note: #[warn(unconditional_recursion)] on by default
  = help: a `loop` may express intention better if this is on purpose
```

#### And infinitely sized recursive types:

```rust
pub struct S {
    s: S,
}
```

```
error[E0072]: recursive type `S` has infinite size
 --> src/main.rs:1:1
  |
1 | pub struct S {
  | ^^^^^^^^^^^^ recursive type has infinite size
2 |     s: S,
  |     ---- recursive without indirection
  |
  = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `S` representable
```

#### But no good error for infinite instantiation of generic functions.

The following is minimized from @LPGhatguy's syntax tree library ([original playground](https://play.rust-lang.org/?gist=c21ebe815e8cc00680bfd85d51ce8d0d)).

```rust
trait Serializer {
    type Associated;
    fn leaf() -> Self::Associated { unimplemented!() }
}

pub enum Expression {
    Leaf,
    Node(Box<Expression>),
}

fn print<S: Serializer>(e: Expression) {
    match e {
        Expression::Leaf => drop(S::leaf()),
        Expression::Node(e) => print::<Wrapper<S>>(*e),
    }
}

use std::marker::PhantomData as Wrapper;
impl<S: Serializer> Serializer for Wrapper<S> {
    type Associated = S::Associated;
}

enum Json {}
impl Serializer for Json {
    type Associated = ();
}

fn main() {
    print::<Json>(Expression::Leaf);
}
```

Here the instantiation of `print::<Json>` requires instantiating `print::<Wrapper<Json>>` which calls `print::<Wrapper<Wrapper<Json>>` which calls `print::<Wrapper<Wrapper<Wrapper<Json>>>`... (The use case in this example is noteworthy because it is conceptually sensible; the trouble happens only when combined with Rust's approach of monomorphizing generic functions. [Analogous code in Swift](https://iswift.org/playground?XO5tjo&v=4) where generics are not monomorphized does not hit the same overflow.)

As of rustc 1.27.0-nightly we get an unhelpful message with a recommendation that can't work. It would be better to detect this pattern of a generic function generating a tower of recursive instantiations.

```
error[E0275]: overflow evaluating the requirement `<Json as Serializer>::Associated`
  |
  = help: consider adding a `#![recursion_limit="128"]` attribute to your crate

error: aborting due to previous error
```
Repository: go
Issue: x/sys/linux/perf: add package for Linux perf tracing
Labels: Proposal,Proposal-Accepted

Linux ships with a robust suite of performance counters and samplers accessed via the [perf_event_open](http://man7.org/linux/man-pages/man2/perf_event_open.2.html) system call.

Recent [changes](https://go-review.googlesource.com/c/sys/+/105756) to x/sys/unix make it possible to call perf_event_open from Go, but using the perf events system correctly is notoriously hard.

Having recently implemented a wrapper for perf events in Go, I would like to generalize and contribute it upstream.

As regards the code location: x/sys/windows seems to have specialized subpackages, so maybe similar structure under x/sys/unix would work.
Repository: puppeteer
Issue: Inconsistent text rendering in headless mode
Labels: feature,upstream,chromium

**EDIT:** The fix is to add `--font-render-hinting=none` to the launch args. E.g.
```
  var browser = await puppeteer.launch({
    headless: true,
    args: ['--font-render-hinting=none']
  });
```

**Original Comment:**
Font spacing seems to be inconsistent between headless and non headless mode.
This is likely a Chromium bug for Puppeteer versions 1.2.0 and above.

### Steps to reproduce

**Tell us about your environment:**

* Puppeteer version: 1.2
* Platform / OS version: Linux
* URLs (if applicable):
* Node.js version: 8.6.0

**What steps will reproduce the problem?**

1. screenshot.js
```
'use strict';

const puppeteer = require('puppeteer');

(async() => {
  const browser = await puppeteer.launch({ headless: true }); // toggle to false
  const page = await browser.newPage();
  await page.goto('file:///tmp/test.html');
  await page.waitFor(5000);
  await page.screenshot({path: '/tmp/screenshot.png'});
  await browser.close();
})();
```
2. test.html
```
<html>
  <head>
    <link rel="stylesheet"
          href="https://fonts.googleapis.com/css?family=Lato">
    <style>
      body {
        font-family: 'Lato', serif;
        font-size: 15px;
      }
      div.a {
        line-height: 0.5;
      }
    </style>
  </head>
  <body>
    <div class="a">
      <div>aaaaa..............................................................................|111</div><br>
      <div>qwertyasdfzxcvyuiohjklbnm................................|222</div><br>
      <div>longlonglonglonglonglonglonglongshorty......|333</div>
    </div>
  </body>
</html>
```
3. `node /tmp/screenshot.js`, then repeat with `headless: false` 

**What is the expected result?**
Text is correctly aligned and looks the same as opening the HTML in browser. `headless: false`

![headless_false](https://user-images.githubusercontent.com/1380839/38925691-f36ba690-4332-11e8-96b4-a1cc0e784e60.png)

**What happens instead?**
Text is misaligned with `headless: true`

![headless_true](https://user-images.githubusercontent.com/1380839/38925690-f33bcfce-4332-11e8-9a19-0ef463f032e9.png)
Repository: ant-design
Issue: slider缺少对某个点禁止选中的API
Labels: help wanted,Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
当 included=false 时，表明不同标记间为并列关系；此时marks其中的某一个点需要设置为disabled状态；然而现有的API是针对整个slide设置的disabled，不能满足扩展要求。

### What does the proposed API look like?
暂无想法


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: vscode
Issue: editor.action.sortLinesAscending has confusing sort order for symbols
Labels: feature-request,editor-sorting

When sorting lines using `editor.action.sortLinesAscending` ("Sort Lines Ascending" via the Command Palette) the lines are sorted in a very strange order when the comparison involves a symbol character.

I would expect that `.` (period) would be sorted before `_` (underscore) because in ASCII, period is 46 and underscore is 95.

However, vscode uses `localeCompare` as its sorting method (see [sortLinesCommand.ts:76]( https://github.com/Microsoft/vscode/blob/54e7055c12f4e9a80f44c67758a12cf248d5f374/src/vs/editor/contrib/linesOperations/sortLinesCommand.ts#L76)), which results in underscore being sorted before period. See the repro steps below for an example.

I saw a previous issue regarding this (#15516) but it was closed because the ASCII ordering was in fact correct. In the case I've outlined below, the ordering is not correct.

I'm not sure what the correct solution would be but I think that for ASCII symbols, ASCII ordering should be obeyed. I do realise that "Sort Lines Ascending" is an ambiguous term - ascending according to what criteria? - so perhaps the command could be renamed to something more specific, or you could provide different default sorting options.

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version: 1.22.1 Commit 950b8b0d37a
- OS Version: Windows 10 Enterprise Version 1709 OS Build 16299.371

Steps to Reproduce:

1. Copy the following into a new file:

```
a_b.txt
a_b_c.txt
````

2. Highlight the file contents.

3. Open the Command Palette and select "Sort Lines Ascending".

**Expected:**

The file is sorted in the following order:

```
a_b.txt
a_b_c.txt
```

**Actual:**

The file is sorted in the following order:

```
a_b_c.txt
a_b.txt
```

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
Repository: ant-design
Issue: The `Row` component will overflow when setting gutter
Labels: Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Version
3.4.1

### Environment
os: mac os 12, browser: chrome 65

### Reproduction link
[https://zhuchuji.github.io/antd-issues/](https://zhuchuji.github.io/antd-issues/)

### Steps to reproduce
1. Layout with `Row` and `Col`
2. Set `gutter` to the `Row`

### What is expected?
The `Row` should not overflow

### What is actually happening?
The `Row` overflows and produces the scrollbar

---
Antd sets `margin-left` and `margin-right` to a negative value on `Row` to compensate the `padding-left` of the first `Col` child and `padding-right` of the last `Col` child, which will make the `Row` box larger than its parent as it's set to `box-sizing: border-box`. Users have to provide a `container` with padding to ensure the `Row` will not overflow, which is a big problem in layout especially in responsive web, because they have to set variables for gutters and calculate it for the padding of the `container`. It's totally inconvenient. If the grid system removes the first column's `padding-left` and the last column's `padding-right`, the `Row` does not need a negative margin any more. Perhaps, it could be fixed by adding a container in `Row`, so that you don't have to detect which column is the first child and which is the last.


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: proc_macro::TokenStream: provide AST node kind hint
Labels: C-feature-request,A-macros-2.0

```rust
/// Enum representing AST nodes a #[proc_macro_attribute] may be applied to
// Bikeshedding welcome
pub enum SyntaxNodeKind {
    // when crates as macro inputs aren't pretty-printed as modules (#41430) 
    Crate,
    Item, // could be module, function, impl, etc. `syn` can figure the rest out
    Statement,
    Expression, 
    ExternItem, // since item kinds are restricted in `extern {}`
} 

impl TokenStream {
    /// If this token stream represents a valid syntax tree node, return its kind. 
    /// Returns `None` for raw tokens
    // Alternately it could simply panic when not available because that would only happen in
    // `#[proc_macro]` which should expect only raw tokens anyway
    pub fn syntax_node_kind(&self) -> Option<SyntaxNodeKind> {}
}
```

This would be exclusively for `#[proc_macro_attribute]`s which parse their input as AST nodes:

* attributes that only accept one kind could assert equality and error immediately instead of attempting to parse their expected kind (allowing them to emit a concise error message instead of "expected [token] got [token]") 
* attributes that accept multiple kinds won't have to guess at what node kind they should attempt to parse

cc @alexcrichton @dtolnay @petrochenkov
Repository: go
Issue: cmd/compile: avoiding zeroing new allocations when possible
Labels: Performance,compiler/runtime

Consider:

```go
func f() *int {
  x := new(int)
  *x = 1
  return x
}
```

The first line gets translated into `x = newobject(type-of-int64)`, which calls `mallocgc` with a "needszero" argument of true. But it doesn't need zeroing: it has no pointers, and data gets written to the whole thing.

Same holds for:

```go
func f() *[2]int {
  x := new([2]int)
  x[0] = 1
  x[1] = 2
  return x
}
```

and more interestingly:

```go
func f() *[1024]int {
  x := new([1024]int)
  for i := range x {
    x[i] = i
  }
  return x
}
```

We could detect such scenarios in the SSA backend and replace the call to `newobject` to a call to a (newly created) `newobjectNoClr`, which is identical to `newobject` except that it passes `false` to `mallocgc` for `needszero`.

Aside: The SSA backend already understands `newobject` a little. It removes the pointless zero assignment from:

```go
func f() *[2]int {
  x := new([2]int)
  x[0] = 0 // removed
  return x
}
```

although not from:

```go
func f() *[2]int {
  x := new([2]int)
  x[0] = 1
  x[1] = 0 // not removed, but could be
  return x
}
```

Converting to `newobjectNoClr` would probably require a new SSA pass, in which we put values in store order, detect calls to `newobject`, and then check whether subsequent stores obviate the need for zeroing. And also at the same time eliminate unnecessary zeroing that the existing rewrite rules don't cover.

This new SSA pass might also someday grow to understand and rewrite e.g. calls to `memmove` and `memequal` with small constant sizes.

It is not obvious to me that this pass would pull its weight, compilation-time-wise. Needs experimentation. Filing an issue so that I don't forget about it. :)
Repository: go
Issue: runtime: sparse zeroing in mallocgc
Labels: Performance,compiler/runtime

This is a performance idea; it needs experimentation to see whether it is worth it.

mallocgc accepts a flag to not zero the new allocation. It is used in a few places in the runtime where we know already that we'll entirely overwrite the new memory; #24926 contemplates having the compiler use it too.

mallocgc must however always zero the new allocation if it contains pointers; runtime uses check for pointers before asking for raw memory. However, we could change the meaning of the "don't zero" flag to mean "I'm going to overwrite all the memory". mallocgc could then decide to only zero the pointers in the new memory, instead of zeroing everything. The decision to only zero pointers might be helpful if pointers are sparse in the type. Deciding whether pointers are sparse in the type is probably something we would do at compile time and set a flag in the type.
Repository: go
Issue: cmd/compile: sometimes issue rematerializable values early
Labels: Performance,compiler/runtime

```go
package p

var (
	s *int
	b bool
)

func f() {
	var q *int
	if b {
		q = new(int)
	} else {
		q = new(int)
	}
	s = q
}
```

This code is a bit silly, but it's the smallest reproduction I have handy. :)

When compiled, this code tests b, and on each branch it contains an LEAQ of `type.int`. The LEAQ should be hoisted above the branch, since it is needed immediately in each case, and there are registers to spare.

The CSE pass does its work, and there is a single LEAQ instruction going into regalloc. However, early in regalloc, we decide to issue it every place we need it:

```go
			if s.values[v.ID].rematerializeable {
				// Value is rematerializeable, don't issue it here.
				// It will get issued just before each use (see
				// allocValueToReg).
				for _, a := range v.Args {
					a.Uses--
				}
				s.advanceUses(v)
				continue
			}
```

This is usually the right decision--disabling this bit of code causes an overall regression. But as the initial code shows, there are instances in which it'd be better to issue the rematerializable value right away. I'm not sure exactly what the right set of conditions is, though.

cc @cherrymui @randall77
Repository: go
Issue: x/build/cmd/gerritbot: don't push to Gerrit if checklist hasn't been deleted
Labels: Builders

In https://github.com/golang/go/pull/24927 the checklist was kept in the commit message and gopherbot pushed it to Gerrit.

Gopherbot could instead just look for "Please ensure you adhere to every item in this list" and, if found, refuse to push it to Gerrit, saying something on the PR instead.

/cc @andybons
Repository: vscode
Issue: Option to configure editor scrollbar to be opaque
Labels: feature-request,editor-scrollbar

Currently, if editor.renderLineHighlight is set to "line" or "all", the highlight extends into the scrollbar. It would be helpful if it stopped just left of the scrollbar. Here is my rationale:
- The line position isn't the same as the scrollbar position, except by coincidence. They are independent, however the highlighting suggests a linkage of some kind.
- With certain color schemes it can be confusing at a quick glance to determine where on the scrollbar I actually am.

Example of intrusion of line highlight into the scrollbar:

![image](https://user-images.githubusercontent.com/5439104/38955070-60bf0aaa-4308-11e8-9603-9d0620c13bcf.png)

Notice how similar the two highlighted areas look on the scrollbar? On closer inspection I can tell that I am actually at the lower point on the scrollbar, because of the brown horizontal line. 

As a workaround, I could easily change the color of the highlight to prevent confusion. But, I'm having trouble understanding why the highlight extends into the scrollbar in the first place. 

Thanks for your consideration! 

VS Code 1.22.1