sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Support ts-ignore, ts-expect-error and ts-nocheck in angular template
Labels: feature,area: compiler,P4,feature: under consideration

In typescript, we can use [`// @ts-ignore` and `// @ts-expect-error`](https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-9.html#ts-ignore-or-ts-expect-error) in codes.

Can we add it in template?

For example:

```ts
@Component()
export class FooComponent {
  @Input() foo!:string
}
```

We can use it with type error by `ts-ignore`, `ts-expect-error` or `ts-nocheck`:

```html
<!-- @ts-ignore -->
<app-foo [foo]="123">
</app-foo>
```

```html
<!-- @ts-expect-error -->
<app-foo 
  [ffoo]="123"
>
</app-foo>
```


```html
<!-- @ts-nocheck -->
<app-foo [foo]="123">
</app-foo>
<app-foo [fo]="123">
</app-foo>
```
Repository: storybook
Issue: Incorrect eslint config being applied
Labels: question / support,compatibility with other tools,has workaround

While building or running storybook, we're getting a ton of errors from eslint, which are not relevant to us. This is because storybook is using a different eslint config than the one in my project. Even disabling eslint in our craco config is completely ignored.

Building storybook using the `--debug-webpack` flag, reveals the eslint rule being applied:

```js
{
  test: /\.(js|mjs|jsx|ts|tsx)$/,
  enforce: 'pre',
  use: [
    {
    options: {
      cache: true,
      formatter: 'C:\\workspaces\\mijn-enexis\\Sources\\Solution\\node_modules\\react-scripts\\node_modules\\react-dev-utils\\eslintFormatter.js',
      eslintPath: 'C:\\workspaces\\mijn-enexis\\Sources\\Solution\\node_modules\\eslint\\lib\\api.js',
      resolvePluginsRelativeTo: 'C:\\workspaces\\mijn-enexis\\Sources\\Solution\\node_modules\\react-scripts\\config',
      ignore: false,
      baseConfig: {
      extends: [
        'C:\\workspaces\\mijn-enexis\\Sources\\Solution\\node_modules\\eslint-config-react-app\\index.js'
      ]
      },
      useEslintrc: false
    },
    loader: 'C:\\workspaces\\mijn-enexis\\Sources\\Solution\\node_modules\\eslint-loader\\dist\\cjs.js'
    }
  ],
  include: [
    'C:\\workspaces\\mijn-enexis\\Sources\\Solution\\src',
    'C:\\workspaces\\mijn-enexis\\Sources\\Solution\\.storybook'
  ]
}
```

This is completely incorrect. First of all, its base config is assumed to be craco's base eslint config. This should be overruled by an existing `.eslintrc` file (not extended - **overruled**). In our `.eslintrc`, we are extending from the airbnb config. The craco eslint config we don't use at all. Why is it being forced upon us here?

As a result, not only are we getting a ton of eslint errors, we are also getting them as fatal errors, so building storybook fails.

It gets weirder though. When I rename our `/.storybook` to `/config/storybook` and build storybook with the `-c ./config/storybook` flag, it spews out the same metric ton of errors, but as **warnings**, so building storybook just carries on and succeeds. This makes no sense to me.

Actually tbh, We got our storybook config in `/config/storybook` but I moved it to `/.storybook` hoping it would fix those warnings and make it pick up our `.eslintrc`.

And as icing on the cake, completely disabling eslint in the craco config, is completely ignored. Eslint is executed anyway.

Questions:

1. Why is Storybook using this particular eslint config? What's the reasoning behind setting it up like this?
2. How do I overrule this behaviour?
3. Is this fixed in Storybook 6?

TLDR, what I want to achieve:

1. Have build-storybook pick up our eslint config.
2. Not having it apply *any* other eslint config.
3. Warnings be warnings, not errors.

I'm on Storybook 5.3 still, so I understand this won't be fixed on the Storybook side, which is why I would rather like a workaround of sorts. If this is fixed in Storybook 6, that'll be good to know when we can do the upgrade.
Repository: vscode
Issue: Markdown hovers in `IconLabel` shouldn't preclude decoration hovers
Labels: debt,file-decorations,workbench-hover

See https://github.com/microsoft/vscode/pull/108403#discussion_r504791866 for the whole story.
Repository: node
Issue: decide the fate of http2.connect(url, { socket })
Labels: http2

<!--
Thank you for reporting an issue.

This issue tracker is for bugs and issues found within Node.js core.
If you require more general support please file an issue on our help
repo. https://github.com/nodejs/help


Please fill in as much of the template below as you're able.

Version: output of `node -v`
Platform: output of `uname -a` (UNIX), or version and 32 or 64-bit (Windows)
Subsystem: if known, please specify affected core module name
-->

* **Version**: 12, 14 and master
* **Platform**: All
* **Subsystem**: http2

### What steps will reproduce the bug?

<!--
Enter details about your bug, preferably a simple code snippet that can be
run using `node` directly without installing third-party dependencies.
-->

Calling `http2.connect(url, { socket })` is not supported but (almost) works by passing the socket option to the `tls.connect` call. I don't think this was an intended behavior.

The following (broken) unit test will produce a segfault:
```js
'use strict';

const common = require('../common');
if (!common.hasCrypto)
  common.skip('missing crypto');
const h2 = require('http2');
const net = require('net');
const fixtures = require('../common/fixtures');

const server = h2.createSecureServer({
  key: fixtures.readKey('agent1-key.pem'),
  cert: fixtures.readKey('agent1-cert.pem')
});

server.listen(0, common.mustCall(function() {
  const socket = net.connect({
    host: 'localhost',
    port: this.address().port
  }, () => {
    const client = h2.connect(`https://localhost:${this.address().port}`, {
      rejectUnauthorized: false,
      socket
    });
    const req = client.request();

    setTimeout(() => socket.destroy(), 100);
    setTimeout(() => client.close(), 200);
    setTimeout(() => server.close(), 300);

    req.on('close', common.mustCall(() => { }));
  });
}));

```

### How often does it reproduce? Is there a required condition?

Always

### What is the expected behavior?

Either
* socket option is ignored which will further brake existing (broken) user code
* socket option is made to work
* intimidate developers into fixing their code with a nasty warning when this is detected
* something else


<!--
If possible please provide textual output instead of screenshots.
-->

### What do you see instead?

<!--
If possible please provide textual output instead of screenshots.
-->

### Additional information

<!--
Tell us anything else you think we should know.
-->
Repository: TypeScript
Issue: Union of functions with typed `this`, fails with no parameters
Labels: Bug,Help Wanted

**TypeScript Version:**  4.0.2

**Code**

```ts
interface Context {
  hello: boolean
}

type OptionsTest =
      | ((this: Context) => void)
      | ((this: Context) => PromiseLike<any>)
      | ((this: Context, done: boolean) => void)

function container (test: OptionsTest) {

}

// This does not work!

container(function () {
  console.log(this.hello);
})

// This works!

container(function (done) {
  console.log(this.hello);
})

// This works!

type Single = (this: Context) => void;
function SingleContainer (test: Single) {}
SingleContainer(function () {
  console.log(this.hello)
})
```

**Expected behavior:**

Correctly provide `this` type to (typed union) functions without arguments.

**Actual behavior:**

No `this` type is being provided for functions without arguments.

[Playground Link](https://www.typescriptlang.org/play?ssl=8&ssc=49&pln=7&pc=7#code/JYOwLgpgTgZghgYwgAgMIHtwQB5mQbwChlkALCAGwvQC5kAjddCiOEQgX0MLAE8AHFAHl+YYJgDOAFQgS8AXmIllAH2QAKdWFLAJdDFlwBKZPIB8yAG7pgAEyNLlyNZu279mSMdMWAClHQAW10IABlgAGsIAB42XjMHJxIXLR09NE8cMAAaZFtMCDpGZlYQE3MrG3tuGABXEAQxTGQETzhQaA1IOToRJpBpWTATIk5uVvB2kGh1Oob+jRGlCYkSgDpqAHNU3TXyKnQjAG5OB0IJsCmZucbxEA186aWSFfWtnYk9ympj0+4Aen+yCkaWQAHV0FAIhIAITcPiCZAAZVAmxYpi6aQ8hmGPkqdhONwWKJAaIgBkuHSgXSGdBJZJGXHpLApVygs3qt2a6meLUkb3Q2zcn32P1OQA)

[StackOverflow Link](https://stackoverflow.com/questions/64500872/union-of-functions-with-typed-this-fails-with-no-parameters)

**Search Terms**

* contextually typed
* this parameter
* union of functions
Repository: rust
Issue: Move `StorageDead`/`StorageLive` around to allow more optimizations to trigger
Labels: C-enhancement,T-compiler,A-mir-opt

#78191 fixes a bug in MatchBranchSimplification but causes it to create some "boilerplate". We should try to optimize it away again. One example is 

```diff
-         switchInt(_4) -> [false: bb7, otherwise: bb8];
+         StorageLive(_9);
+         _9 = _4;
+         _3 = Ne(_9, const false);
+         StorageDead(_9);
+         goto -> bb9;
```

for which we should make sure that copy prop still manages to remove `_9`.

Other situations are

```diff
-         switchInt(move _3) -> [false: bb11, otherwise: bb10];
+         StorageLive(_10);
+         _10 = move _3;
+         StorageDead(_3);
+         _1 = Ne(_10, const false);
+         StorageDead(_10);
+         goto -> bb12;
```

which are more complex. But since it is always safe (haha, uh, I think) to move a `StorageDead` further down and a `StorageLive` further up, we should be able to move the `StorageDead(_3)` after `_1 = Ne(_10, const false);`, thus allowing copy prop to handle this again.
Repository: godot
Issue: [3.2.4 beta1]Strange bug causes Editor lagging on Mac
Labels: bug,platform:macos,topic:rendering,topic:editor,needs testing,performance

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.4 beta1

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
2013 late MacBookPro 13' MacOS 10.14.6 Intel GPU

**Issue description:**
<!-- What happened, and what was expected. -->
**Steps to reproduce:**
### _In GLES2_

Add a Spatial node as root
Add a MeshInstance node
Add a WorldEnvironment node, turn on Adjustments and change some defualt property
Opening Project Settings and just randomly switching between different labs, waiting a few seconds then Editor will become lagging

Deleting the WorldEnvironment node won't make Editor smoothing again, You have to switch to Desktop or other Programs then turn back, that will make Editor smoothing again.

### _In GLES3_
this issue become if you turn on some Post-Processing like SSAO, it will directly make Editor lagging. I test again in 3.2.3 office stable, the Editor won't lagging even turn on with SSR and Dof Far Blur

It's an really strange bug, I'm not sure if the WorldEnvironment Post-Processing causes this problem, but at least I found it in this way, maybe this issue only appears on Intel GPU?
Repository: go
Issue: cmd/compile: escape analysis for backing arrays
Labels: NeedsInvestigation

Go's automatic memory management doesn't rely entirely on garbage collection. Escape analysis provides a faster solution where possible. 
Lets apply escape analysis to backing arrays (the arrays behind slices). 

### Example
In the next example, if append grows the array, it could put the old array directly back into the free lists:
``` go
func filter(haystack []X, predicate func(X) bool) []X {
  var result []X
  for _, v := range haystack {
    if predicate(v) {
      result = append(result, v)               // result may grow many times. 
  }
  return result
}
```

An alternate append-grow that returns the heap memory to a thread-local free list could be proven safe.

The compiler can verify that no references to intermediate slice values survive later iterations, so there are zero references at the function end to previous backing arrays. If an intermediate was used in a function call, this would follow the regular escape analysis logic.

### Collision with GC
To avoid Garbage Collection competition, these non-escaping slices could be removed from stack maps. Their capturing func would need an implicit defer-type behavior to add them to GC when returned. 
``` go
 defer func(){ retValGC = retValNoEscape }()      // added by compiler. Shouldn't affect line numbers, etc.
```
This also enables panic() scenarios to not leak. This is perhaps too literal as all that would happen would be a stack map reference. 

### Result
Garbage Collection would be reduced and Go programs would use considerably less memory-over-time (derivative). No language changes would be necessary, and the Go1 promise is kept. Potentially the same work will be completed with less total CPU. 

Maps' private slices should be able to benefit from this too as they only grow when a single thread is writing and no other activity is taking-place. I doubt escape analysis can determine this, so it may need to be hard-coded. 

### Future
 Future advances in Escape Analysis would help more cases of Go's automatic memory management to have a minimal footprint in all but the most especially-complex cases where Garbage Collection is  the most reasonable solution.
Repository: go
Issue: proposal: x/net/xsrftoken: add new, less error-prone API
Labels: Security,Proposal,Proposal-Hold

See https://github.com/golang/go/issues/42166#issuecomment-732061886 for concrete API.

- - - 

# Preface
The only thing that Go provides to protect against [CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery) is the [x/net/xsrftoken](https://pkg.go.dev/golang.org/x/net/xsrftoken) package. This is [per-se an issue](https://github.com/golang/go/issues/42168) but there is an additional problem.

The API of said package is the following:
```go
const Timeout
func Generate(key, userID, actionID string) string
func Valid(token, key, userID, actionID string) bool
```
This is the whole API surface, it is very low-level and **requires its users to have a somewhat advanced knowledge of web security to use it properly**.
I would invite the reader to stop here for a handful of seconds and think how they would use this package to protect a web application, including how they would retrieve the required `userID`.

# The issue
By looking at the naming here a programmer might be inclined to use the XSRF protection only for authenticated users, especially since `userID` is the name of one of the parameters for both `Generate` and `Valid`.

This means that users of this package will probably be vulnerable to [Login CSRF](https://en.wikipedia.org/wiki/Cross-site_request_forgery#Forging_login_requests). I say this because some colleagues of mine and I analyzed quite a lot of Go web services code we could access and found it consistently vulnerable to some form of CSRF (the maintainers have already been warned and have fixed the issues).

I propose to apply one or more of the following:
1. Provide a **higher-level protection** alongside the low-level one: something that works on http handlers and manages cookies/token injection transparently. This would remove the burden of understanding the internals of CSRF from the users and would require less code to be written. As an example there are [NoSurf](https://pkg.go.dev/gopkg.in/go-on/nosurf.v1) and [csrf](https://pkg.go.dev/github.com/gorilla/csrf) that have a quite small but significantly harder to misuse API
2. Add **documentation** to this package with examples and detailed explanation on how to use it, especially wrt pseudonymous tokens to pass as `userID`, which from our analysis was one of the most frequent mistakes.
3. Provide **other functions**: add some functions to this package. For example helpers to issue and validate csrf-related cookies and inject tokens in html templates. These would basically be the easy-to-use and slightly more versatile building blocks for the first point of this list.

I am willing to do the work for any of these, but I would like to discuss all alternatives and gather some consensus and more ideas before I do.
Repository: react
Issue: Feature Request: Adding filter (search) to react DevTools Profiler
Labels: Type: Feature Request,Component: Developer Tools

A few months ago, we added a tooltip to react DevTools Profiler (cc @bvaughn), so that for very small components, without clicking on them it is possible to see an overview of why they are re-rendered.
However, still, for a not very big page, there can be tens of re-renders, so it is hard to find the component that you are looking for.

An easy solution for this to add some search bar, where the user can type down the name of the component, and find the component. 

If this is something that you think we care about, I can pick it up and add the search field. 

<img src="https://user-images.githubusercontent.com/28848972/97014068-25bf7680-154a-11eb-8ba3-a07dd7a45d45.png" width="250">
Repository: flutter
Issue: Google Sign In - OAuth Consent Screen Shows Once
Labels: p: google_sign_in,package,team-ecosystem,P2,triaged-ecosystem

I am currently using the Google Sign In package to facilitate Social Sign In and also to request consent with the scope, "https://www.googleapis.com/auth/adwords". 

The issue I am having involves the serverauthcode that is generated from the requesting of the above scope. It is known that the package itself has some issue with returning the serverauthcode, and based on a PR floating on this repo, a workaround for it has been suggested but not officially supported yet (to my knowledge). The actual problem is when sending this serverauthcode to the backend WebAPI and trying to establish a link between the Google Ads account and the MCC, there is some unexpected behaviour occurring.

I am not sure as to why this might be the case, but when a user consents and gives access to their account for some app, the serverauthcode and the subsequent credentials generated (access token and refresh token) seem to be valid and manages to establish the link properly. However if the user decides to unlink their account from the MCC and then at a later point try to link again, the OAuth consent screen no longer appears, but the serverauthcode is still generated, but the linking in the backend fails due to the refresh token being set to null in some part of the flow.

In summary, I am not too clear as to why there's a difference between the two serverauthcodes generated (one from the initial consent prompt scenario and another from the no consent prompt scenario) and if there is some sort of setting in the package I am aware of that would resolve this.
Repository: create-react-app
Issue: Compilation error with react-scripts 4.0.0 ( Can't resolve file )
Labels: needs triage,issue: bug report

latest update of react-scripts to 4.0.0 from 3.4.4 causes a compilation problem.
With 3.4.4 it works, and the file exists 

```bash
./src/styles/mycssfile.css
Error: Can't resolve '/images/module/filename.png' in 'D:\dev\workspace\xxxxxxxxx\src\styles'


npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! xxxxxxxxxxxxxxx@1.0.0 build: `react-scripts build`
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the xxxxxxxxxxxxx@1.0.0 build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     C:\Users\xxxxxxxxxxxxxx\AppData\Roaming\npm-cache\_logs\2020-10-23T16_16_47_530Z-debug.log
```
Repository: flutter
Issue: `flutter drive` should not print warning about chrome debug extension
Labels: a: tests,tool,t: flutter driver,platform-web,a: annoyance,P2,team-web,triaged-web

The standard way to run a driver web test is via this command: `flutter drive -d web-server --browser-name=chrome --target=...`. This completes successfully. However, along the way it will print the following confusing messages:

```
Waiting for connection from Dart debug extension at http://localhost:34955
The web-server device requires the Dart Debug Chrome extension for debugging. Consider using the Chrome or Edge devices for an improved development workflow.
```

`flutter drive` should not be attempt to establish a debug connection because it uses the WebDriver protocol instead.
Repository: create-react-app
Issue: Import fails when file contains computed property syntax
Labels: needs triage,issue: bug report

### Describe the bug
The react build fails when an inconsequential line containing the computed property syntax is added to a file. Example:

```javascript
const randomThingy = { ['soda']: 'wizard' };
```

If this line is present in a file, then exports will not work for that file in the build. However, they work when running the development server.

### Did you try recovering your dependencies?
npm version: 6.14.8

### Which terms did you search for in User Guide?
"react build"
"fail"
"computed property"
"import"
...

### Environment
```
Environment Info:
  System:
    OS: Linux 4.4 Ubuntu 18.04.5 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i5-7200U CPU @ 2.50GHz
  Binaries:
    Node: 12.18.0 - /usr/local/bin/node
    Yarn: Not Found
    npm: 6.14.8 - /usr/local/bin/npm
  Browsers:
    Chrome: Not Found
    Firefox: Not Found
  npmPackages:
    react: ^17.0.1 => 17.0.1
    react-dom: ^17.0.1 => 17.0.1
    react-scripts: 4.0.0 => 4.0.0
  npmGlobalPackages:
    create-react-app: 3.3.0
```

### Steps to reproduce
1. Create a new app
1. Add the files with the code
1. Run the dev server and see that it appears to work
1. Try the build and see that it fails
1. Comment out the problematic line
1. See that it still works in the dev server
1. Run the build and see that it no longer fails

### Expected behavior
I expect the build to not fail when the problematic syntax is used.

### Actual behavior
The build fails.

### Reproducible demo
I have created a minimal working example repository [here](https://github.com/nullromo/import-issue-react-10-23-2020). The repo's README explains the import structure and it is very simple.

#### Repo's README copied here
##### CRA Shared Module Import Issue

###### Description
When importing `okayExport` from `src/common/okayExport.js` into `src/App.js`, everything is fine. When importing `sketchyExport` from `src/common/sketchyExport.js` into `src/App.js`, the react build fails with the message: "Attempted import error: 'sketchyExport' is not exported from './common/sketchyExport.js'." If the line declaring `randomThingy` in `src/common/sketchyExport.js` is removed, then the build succeeds with no errors.

The issue is that the build somehow breaks when the "computed property" syntax is used in exporting file (i.e. the `{['foo']: bar}` syntax).

When running the development server, the app does not crash and behaves as expected. It is only during the build process that it fails.
Repository: ant-design
Issue: [Tabs] ant-tabs-nav-more missing in mobile view
Labels: 💄 Design,Inactive,📱Mobile Device

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[https://ant.design/components/tabs/#components-tabs-demo-slide](https://ant.design/components/tabs/#components-tabs-demo-slide)

### Steps to reproduce
View https://ant.design/components/tabs/#components-tabs-demo-slide in mobile display. 

### What is expected?
Display `ant-tabs-nav-more` button in mobile view

### What is actually happening?
In large display, it's showing. But in mobile view, it's getting removed. 
![image](https://user-images.githubusercontent.com/45073703/97047014-1c5dfa80-159a-11eb-8b83-a7434aed5eb4.png)


| Environment | Info |
|---|---|
| antd | 4.7.2 |
| React | 16.14.0 |
| System | Windows 10, Xiaomi Note 5 |
| Browser | Chrome |

---
Can be seen in demo. In 4.7.0, it was ok.


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->