sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Infer parameter types from usage quick fix does not work for arrow function in class property initializers
Labels: Bug

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.3.0-dev.20181130

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

Infer parameter types from usage quick fix class property initializer arrow function

**Code**

```ts
class Foo {
    log = msg => {};

    do() {
        const m = "hello";
        this.log(m);
    }
}
```

**Expected behavior:**

When opening the quick fix menu for the `msg` argument in the `log` property "Infer parameter types from usage" quick fix should be shown

**Actual behavior:**

It's not shown.


**Related Issues:** <!-- Did you find other bugs that looked similar? -->

https://github.com/Microsoft/TypeScript/issues/28764

https://github.com/Microsoft/TypeScript/issues/22357
Repository: electron
Issue: Support z-ordering for BrowserView
Labels: enhancement :sparkles:,component/BrowserView

**Is your feature request related to a problem? Please describe.**
Maybe?  If the goal is to get people to move away from `<webview>`, it would be nice to be able to layer things on top of a BrowserView.

**Describe the solution you'd like**
A BrowserWindow hosting a BrowserView should be able to position an html element above (on top of) the BrowserView

**Describe alternatives you've considered**
I'm mainly using the `<webview>` because of this.
Repository: go
Issue: x/build/cmd/gomote: configure instance by an environment variable
Labels: Builders,FeatureRequest

I've been doing a fair amount of `gomote`-based debugging for the `cmd/go` file-locking changes, and wrote the following script to improve the ergonomics of gomote commands:

`~/bin/mote`:
```bash
#!/bin/sh

SUBCMD=$1
shift
gomote "${SUBCMD}" "${GOMOTE}" "$@"
```

That allows me to eliminate stutter in `gomote` commands and still keep them repeatable.
Instead of:

```
$ export GOMOTE=$(gomote create darwin-amd64-10_12)
$ gomote push $GOMOTE && gomote run $GOMOTE go/src/make.bash
$ gomote run $GOMOTE go/bin/go test -short cmd/go
```

I can run:
```
$ export GOMOTE=$(gomote create darwin-amd64-10_12)
$ mote push && mote run go/src/make.bash
$ mote run go/bin/go test -short cmd/go
```

However, there is no fundamental reason why this should be a separate bash script.
@bradfitz, @dmitshur, @aclements: what do you think of pulling this into `gomote` proper?
Repository: go
Issue: cmd/internal/xcoff: move to x/debug/xcoff
Labels: NeedsDecision

Hi, 

Since CL [149957,](https://go-review.googlesource.com/c/go/+/149957) the tests inside gccgoimporter as long as the gccgo command is available, which is the case on most of AIX machines. However, it's only aware of ELF gccgo files, it doesn't recognize XCOFF files. To add the features, cmd/internal/xcoff must be moved to x/debug/xcoff as it was suggested by issue [28037](https://github.com/golang/go/issues/28037). 
Is that possible ? 

Morever, big archive format is only available on AIX, as far as I know. Therefore, is that okay if I implement functions to read them in x/debug/xcoff ? Or I'd rather do a x/debug/ar as it was suggested here: 
https://github.com/golang/go/blob/master/src/cmd/internal/buildid/buildid.go#L121

/cc @ianlancetaylor  @bradfitz
Repository: rust
Issue: Borrow error in if statement inside match arm, but not when a match guard is used
Labels: T-compiler,A-NLL,NLL-polonius

https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=10d4259862f36ad0571fb43da5855401

The two functions `remove` and `remove_not_ok` should be equivalent, but the borrow checker only allows the first.

```Rust
    // This method compiles
    fn remove(&mut self, v: usize) -> Option<usize> {
        let mut current = &mut self.head;
        loop {
            match current {
                None => return None,
                Some(node) if node.v == v => {
                    *current = node.next.take();
                    return Some(v);
                },
                Some(node) => {
                    current = &mut node.next;
                }
            }
        }
    }
    
    // This method does not compile
    fn remove_not_ok(&mut self, v: usize) -> Option<usize> {
        let mut current = &mut self.head;
        loop {
            match current {
                None => return None,
                Some(node) => {
                    if node.v == v {
                        *current = node.next.take();
                        return Some(v);
                    } else {
                        current = &mut node.next;
                    }
                }
            }
        }
    }
```

The error is:

```
error[E0506]: cannot assign to `*current` because it is borrowed
  --> src/main.rs:39:25
   |
37 |                 Some(node) => {
   |                      ---- borrow of `*current` occurs here
38 |                     if node.v == v {
39 |                         *current = node.next.take();
   |                         ^^^^^^^^
   |                         |
   |                         assignment to borrowed `*current` occurs here
   |                         borrow later used here
```
Repository: create-react-app
Issue: No tests found on Windows with Jenkins
Labels: issue: needs investigation

### Is this a bug report?

Yes

### Did you try recovering your dependencies?

Yes

### Which terms did you search for in User Guide?

test

### Environment

From `npx create-react-app --info`:
`(node:2604) UnhandledPromiseRejectionWarning: Error: The system cannot find the path specified.`

```
System:
OS: Microsoft Windows Version 10.0.14393
CPU: x64 Intel(R) Xeon(R) CPU E5-2420 0 @ 1.90GHz
Binaries:
Node: 10.13.0
npm: 6.4.1
npmPackages:
"@coreui/coreui": "^2.1.1",
    "@coreui/icons": "0.3.0",
    "@coreui/react": "^2.1.0",
    "bootstrap": "^4.1.3",
    "classnames": "^2.2.6",
    "flag-icon-css": "^3.2.1",
    "font-awesome": "^4.7.0",
    "node-sass": "^4.10.0",
    "prop-types": "^15.6.2",
    "react": "^16.6.1",
    "react-dom": "^16.6.1",
    "react-helmet": "5.2.0",
    "react-loadable": "^5.5.0",
    "react-redux": "^5.1.0",
    "react-router-bootstrap": "^0.24.4",
    "react-router-dom": "^4.3.1",
    "react-router-redux": "^5.0.0-alpha.8",
    "react-scripts": "2.1.1",
    "reactstrap": "^6.5.0",
    "redux": "^4.0.1",
    "redux-immutable": "4.0.0",
    "redux-thunk": "^2.3.0",
    "rimraf": "^2.6.2",
    "simple-line-icons": "^2.4.1"
```
### Steps to Reproduce

1. Write test file and save it in `src` folder as `App.test.js`
2. `npm run react-scripts test --env=jsdom --no-watchman`
or
3. `npm react-scripts test --env=jsdom --coverage`

Reproduction repository: https://github.com/Saibamen/react_test

### Expected Behavior

Tests should be executed

### Actual Behavior

No tests found

```
react-scripts test --env=jsdom --no-watchman
00:02:06.736 
00:02:11.011 No tests found
00:02:11.011 In C:\Program Files (x86)\Jenkins\workspace\xxx\src\Web\xxx.Web\ClientApp
00:02:11.011   50 files checked.
00:02:11.011   testMatch: C:\Program Files \(x86\)\Jenkins\workspace\xxx\src\Web\xxx.Web\ClientApp\src\**\__tests__\**\*.{js,jsx,ts,tsx},C:\Program Files \(x86\)\Jenkins\workspace\xxx\src\Web\xxx.Web\ClientApp\src\**\?(*.)(spec|test).{js,jsx,ts,tsx} - 0 matches
00:02:11.011   testPathIgnorePatterns: \\node_modules\\ - 50 matches
00:02:11.011 Pattern:  - 0 matches
00:02:11.045 npm ERR! code ELIFECYCLE
00:02:11.046 npm ERR! errno 1
00:02:11.048 npm ERR! xxx@0.1.0 test:ci: `react-scripts test --env=jsdom --no-watchman`
00:02:11.049 npm ERR! Exit status 1
00:02:11.049 npm ERR! 
00:02:11.049 npm ERR! Failed at the xxx@0.1.0 test:ci script.
00:02:11.050 npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
00:02:11.086 
00:02:11.087 npm ERR! A complete log of this run can be found in:
00:02:11.087 npm ERR!     C:\Users\jenkins\AppData\Roaming\npm-cache\_logs\2018-11-30T12_24_24_901Z-debug.log
00:02:11.109 Build step 'Execute Windows batch command' marked build as failure
```
Repository: go
Issue: crypto/x509: DN OU ordering
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go.1.11.1 linux/amd
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
linux amd64
</pre></details>

### What did you do?
When getting the subject of a certificate through cert.Subject.String(), where the DN has multiple OU's, the OU's are in a backwards order and joined with a '+'

https://play.golang.org/p/hKtL6TEeln5

### What did you expect to see?
`CN=Example User,OU=Upper,OU=Lower,O=My Org,C=GB`


### What did you see instead?
`CN=Example User,OU=Lower+OU=Upper,O=My Org,C=GB`
Repository: create-react-app
Issue: Change proxying to work more like hosting providers
Labels: issue: proposal

### Is this a bug report?

No

### Well then ... what?!

I want to discuss possibly changing the way proxying works in development.

Most static site hosting providers will run proxies/rewrites **only if a static file does not match the request**. See e.g. the rules about "shadowing" URLs in [Netlify's guide on Redirects](https://www.netlify.com/docs/redirects/#rewrites-and-proxying), or the "Hosting Priorities" section in [Firebase hosting's section about URL rewrites](https://firebase.google.com/docs/hosting/url-redirects-rewrites#section-rewrites). In both of these providers, if a request matches a static file, that file is served first **before any proxies/rewrites**.

This is in contrast to the way that proxying currently works in CRA, [where the proxy runs **before** checking static URLs](https://github.com/facebook/create-react-app/blob/ffb219d84d8bc88dc1b94878b6ae10c528c37a57/packages/react-scripts/config/webpackDevServer.config.js#L93-L97), both when using `pkg.proxy` and `src/setupProxy.js`. So a proxy in CRA is actually able to overwrite valid URLs that may be in your bundle! This can be really confusing. We should be able to **always** assume that requests for static files that are part of the bundle resolve to that file, period.

### How to fix

Now, the thing about webpack-dev-server is that it's like a black box, so you're never quite sure what URLs are in the bundle (i.e. pathnames it is able to serve) because it's hard (using webpack's API) to predict all the filenames. So e.g. if a request comes through for `/scripts/whatever-23abcd.js`, you have to first check with the compiler to see if it has a file with that name. If it does, webpack-dev-middleware (WDM) serves that file. If not, it doesn't.

So what I've typically had to do is to [do my proxying **after** WDM runs](https://github.com/unpkg/unpkg.com/blob/41806b211724093afa8774b74b3912fa7e88c29d/modules/createDevServer.js#L41-L49), not before it. If WDM can serve a URL, we should *always* let it do so. If not, let's see if we can proxy the request somewhere else.

Does that make sense?
Repository: TypeScript
Issue: ResolvedModuleWithFailedLookupLocations does not publicly expose failedLookupLocations
Labels: Bug,API

**TypeScript Version:**  3.3.0-dev.20181130

**Search Terms:** ResolvedModuleWithFailedLookupLocations, failedLookupLocations

**Expected behavior:** `ts.ResolvedModuleWithFailedLookupLocations` has a `failedLookupLocations` property which reports locations where the lookup was tried and failed.

**Actual behavior:** `failedLookupLocations` is marked `@internal` and thus not available in the public typings. This is in contrast to `ResolvedTypeReferenceDirectiveWithFailedLookupLocations` which does expose the `failedLookupLocations`, which leads me to believe this was an omission and not an intentional hiding of the field.

**Related Issues:** #28276
Repository: go
Issue: x/build/maintner: Add Ability to Add GitHub and Gerrit Repositories while in SyncLoop
Labels: Builders

Currently if you call `SyncLoop` in a goroutine, and later call `TrackGitHub` or `TrackGerrit`, the corpus will not actually track that repository until the `sync` method returns and `SyncLoop` is called again. 

This means that users of `corpus` that wish to add repositories to track on the fly need to maintain a custom written loop and call `Sync`.
Repository: flutter
Issue: Doctor validator for minimum Gradle version
Labels: tool,t: gradle,a: first hour,P2,team-tool,triaged-tool

Context: https://github.com/flutter/flutter/issues/24757#issuecomment-442144708

> Is there anywhere to find the minimum Gradle version supported by Flutter? Or, if the minimum Gradle version changes, where can I find that info?

The developer was using Gradle 4.4, when flutter_tools was using 4.10.2 in its Gradle wrapper -- and this caused the build to fail with an NPE when Gradle was invoked.

We should add a validator to ensure that the user has a minimum version of Gradle installed.
Repository: go
Issue: x/debug/cmd/viewcore: confusing error message when not specifying --exe
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.1 linux/amd64
</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/michael/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/michael/go"
GOPROXY=""
GORACE=""
GOROOT="/home/michael/sdk/go1.11.1"
GOTMPDIR=""
GOTOOLDIR="/home/michael/sdk/go1.11.1/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/tmp/vc/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build665857060=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

```
% viewcore /tmp/core.dcs-package-imp.23131.ex61.1543603411 breakdown
can't read DWARF info from /lib/x86_64-linux-gnu/libc-2.24.so: decoding dwarf section info at offset 0x0: too short

% viewcore /tmp/core.dcs-package-imp.23131.ex61.1543603411 --exe ./bin/dcs-package-importer breakdown 
 all                  13451362304 100.00% 
[…]
```

I’m not sure what’s happening without --exe, but the error message should suggest I use --exe in that situation, I suppose?
Repository: pytorch
Issue: [c10d] Check that allgather/gather output tensors point to different storage
Labels: oncall: distributed,feature,triaged

This will avoid the type of confusion in this comment: https://github.com/pytorch/pytorch/issues/14536#issuecomment-443257710.

List replication means the tensors refer to the same underlying storage. I can't think of a case where this would be expected behavior, so we can check and throw if two output tensors point to the same memory for these operations.
Repository: flutter
Issue: Adding "copied" feedback to Sample Code UI on API doc
Labels: c: new feature,team,framework,from: study,d: api docs,P3,team-framework,triaged-framework

In recent study, on master channel's API doc (e.g. [actions](https://master-docs-flutter-io.firebaseapp.com/flutter/material/AppBar/actions.html)) we observed that participant was unsure if the sample code was successfully copied to clipboard --- after clicking on the copy all sample code button, she pressed ctrl + C again.

To further improve the usability of Sample code UI, we suggest this change: after clicking on it, show the message: "_Successfully copied to clipboard_". A brief messages popping up at the bottom of the screen (i.e. toast/[snackbar](https://material.io/design/components/snackbars.html#usage) in material design) should be enough.

cc: @jayoung-lee @gspencergoog @InMatrix
Repository: TypeScript
Issue: USVString type definition
Labels: Suggestion,Breaking Change,Domain: lib.d.ts,Awaiting More Feedback

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.2.0-dev.201xxxxx

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
USVString

**Code**

```ts
function example(uri: USVString) {
    // Do some work
}
```

**Expected behavior:**
Until typescript version 3.0.3 USVString used to be an existing type defined in `lib.dom.d.ts `
in version 3.1, according to the breaking changes page, some vendor-specific types are removed from lib.d.ts, a full list of removed types is [included](https://github.com/Microsoft/TypeScript/wiki/Breaking-Changes#typescript-31). 
USVString is not on that list, yet it's type definition was also removed.

USVString is defined under webIDL, as can be seen [here](https://www.w3.org/TR/WebIDL/#idl-USVString).

**Actual behavior:**
`error TS2304: Cannot find name 'USVString'.`
Repository: rust
Issue: Using absolute paths from std combined with no_implicit_prelude has no edition 2018 compat warning
Labels: A-lints,T-compiler,C-bug,A-edition-2018

This code compiles without warning on edition 2015 with `#![warn(rust_2018_compatibility)]` active, but fails to build on edition 2018 ([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e5c4eae35ba9a23a8c07dd5d1b169dd6)):

```rust
#![no_implicit_prelude]

#![warn(rust_2018_compatibility)]

fn main() {
    std::process::exit(0);
}
```

error:

```
error[E0433]: failed to resolve: use of undeclared type or module `std`
 --> src/main.rs:6:5
  |
6 |     std::process::exit(0);
  |     ^^^ use of undeclared type or module `std`
```

Note: changing the path to instead use `::std::process::exit` compiles on both editions.
Repository: pytorch
Issue: fc_without_bias / FCWithoutBias
Labels: caffe2

Hello all,

what is the correct way to call fc_without_bias or FCWithoutBias using the Python API?  I tried with model.FCWithoutBias and fc_without_bias directly but I always get:

```
  File "/home/carlos/Documents/git/pytorch/build/caffe2/python/model_helper.py", line 453, in __getattr__
    ','.join(workspace.C.nearby_opnames(op_type)) + ']'
AttributeError: Method fc_without_bias is not a registered operator. Did you mean: []
```
Repository: go
Issue: x/text/currency: rouble symbol is only printed with language.Russian
Labels: NeedsInvestigation

### What version of Go are you using (`go version`)?
<pre>
$ go version
go version go1.11 linux/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/ainar/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/ainar/go"
GOPROXY=""
GORACE=""
GOROOT="/home/ainar/go/go1.11"
GOTMPDIR=""
GOTOOLDIR="/home/ainar/go/go1.11/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build112907181=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
https://play.golang.org/p/umgrxwND7k4

(Using floats because #15274.)

### What did you expect to see?
<pre>
₽ 100.00 = € 1.33
100.00 ₽ = 1.33 €
100.00 ₽ = 1.33 €
</pre>

### What did you see instead?
<pre>
RUB 100.00 = € 1.33
RUB 100.00 = € 1.33
₽ 100.00 = € 1.33
</pre>

There is  #14308 about the symbol position, but I don't understand why the rouble symbol is only used when I use `language.Russian`, while the euro symbol is used in all cases.
Repository: rust
Issue: Known deviations of macro paths and 2018 import paths from the "uniform path" model
Labels: A-resolve,T-compiler,C-bug

"Uniform path" model for macros/imports means that if macro/import path compiles without errors, it's resolved in exactly same way as non-macro/import path.

(Possible differences in resolution of macro/import paths and other paths are caused by the fact that macro/import paths are resolved early, when module structure of the crate is still in flux.)

There are two known deviations from this model.
Import/macro resolution never sees local variables (`let x`) and generic parameters (`T` in `fn f<T>() { ... }`) - we don't have necessary infrastructure to do that during early resolution right now.

There's still some future-proofing in place turning imports referring to local variables and generic parameters into errors - https://github.com/rust-lang/rust/pull/55884/commits/22a13ef1584a06cd5b08c57b285925d5b4ebf0b6, but that future proofing has two holes.

First, macro paths are not future-proofed:
```rust
mod T { // T1
    pub macro mac() {}
}
fn f<T>() { // T2
    T::mac!(); // Should be an error because T2 shadows T1, but it's not.
}
```
To fix this, expanded macros need to leave better traces for late resolution, so that positions of expanded macros relative to generic parameters are known.

**UPDATE**: Fixed in https://github.com/rust-lang/rust/pull/56759 --> Second, future-proofing for non-renamed single-segment imports referring to generic parameters doesn't work due to an implementation issue:
```rust
fn self_import<T>() {
    use T; // FIXME Should be an error, but future-proofing fails due to `use T` being "self-confirming"
}
```
To fix this we need to stop treating the import `use T;` as "self-confirming" during future-proofing resolution (similarly to how it's done for single-segment imports in https://github.com/rust-lang/rust/pull/56392). <--