sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Add option to include default typeRoots when overriding typeRoots
Labels: Suggestion,Awaiting More Feedback

## Search Terms

default typeRoots

## Suggestion

By default, when `typeRoots` is unspecified, TypeScript looks for `node_modules/@types` in the project's directory and all ancestor directories, similar to Node's module resolution algorithm. This is covered in [the tsconfig.json docs](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html) and is implemented [here](https://github.com/Microsoft/TypeScript/blob/b534fb4849eca0a792199fb6c0cb8849fece1cfd/src/compiler/moduleNameResolver.ts#L240-L260).

When specifying `typeRoots` in tsconfig.json, this overrides the default `typeRoots` entirely. You can include `"node_modules/@types"` in your `typeRoots` array, but that does not include ancestor directories.

This is a feature request to provide a way, such as a new option, to include the default type roots in addition to the overridden values.

## Use Cases

The primary use case is within a repository using Yarn workspaces. Yarn hoists npm packages to the workspace root. This means you can end up with a directory hierarchy like this:

```
.
├── node_modules
│   └── @types
│       └── dependency
└── packages
    └── example
        ├── example.ts
        ├── package.json
        └── tsconfig.json
```

If `tsconfig.json` wants to include `node_modules/@types` in the workspace root (in addition to other type declaration directories specified in `typeRoots`), it needs to look like this:

```
{
  "compilerOptions": {
    "typeRoots": ["../../node_modules/@types", ...]
  }
}
```

## Examples

This feature request is a quality-of-life improvement to instead allow for:

```
{
  "compilerOptions": {
    "typeRoots": [...],
    "includeDefaultTypeRoots": true
  }
}
```

The default value of this option would be false and would not be a breaking change.

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: Support memoryview() method on torch.Tensor
Labels: feature,triaged,module: numpy

## 🚀 Feature
Support .tobytes() method on torch.Tensor

## Motivation

If I need to extract the raw bytes from a Tensor, I need to convert to numpy first and then use `tobytes`. It would be nice to have a tobytes() method for the Tensors themselves. For example, if I have a jpg image stored in a ByteTensor and I would like to open it using PIL, I need to do something like this currently:

```
data = tensor.numpy().tobytes()
img = Image.open(BytesIO(data), mode='r')
```
Repository: create-react-app
Issue: Should the CRA ESLint config warn for unused vars?
Labels: issue: needs investigation

I just started playing with React through create-react-app and was surprised when I wasn't warned about unused variables.

I had a look [at the ESLint config](https://github.com/facebook/create-react-app/blob/master/packages/eslint-config-react-app/index.js#L172) and it seems like it should. However, it isn't working for me and someone else on Reactiflux Discord confirm it wasn't for them.

My setup is VS Code 1.33.0 on Windows 10 with the ESLint 1.8.2 extension on a fresh create-react-app app. I added this code in the `render` method of the `App` component in _App.js_:

```
const a = 123;

eval('oh yeah');
```

VSCode shows a squiggly green line under the `eval` as an ESLint warning, so I know that's working. Nothing for the unused variable however. Same deal if I run `npx eslint src/`:

```
$ npx eslint src/

C:\Users\alext\src\react-tutorial\src\App.js
  9:3  warning  eval can be harmful  no-eval

✖ 1 problem (0 errors, 1 warning
```

Should this be causing an ESLint warning with CRA?
Repository: pytorch
Issue: Make operators like logsumexp and cumsum operate over dimension 0 by default (or at least for 1D arrays)
Labels: module: docs,triaged,enhancement,module: numpy,module: reductions

It's pretty ridiculous that, for a 1D input like `x = torch.rand(5)`, `torch.logsumexp` still requires you to specify you're operating over dimension 0.

In particular `torch.logsumexp(x)` will error, saying that it needs a dim argument. `torch.logsumexp(x, 0)` works.

My suggestion is that, at the very least for 1D inputs, the default dim you operate over is set to 0. This is a problem for `logsumexp` and `cumsum`, just to name two.

cc @jlin27 @mruberry @rgommers
Repository: pytorch
Issue: Improve unit test coverage of torch.unique
Labels: module: tests,triaged,module: sorting and selection

Currently it only covers `torch.unique(tensor, ...)`, but not `tensor.unique(...)` We should improve this after https://github.com/pytorch/pytorch/pull/18649 series get merged.

cc @mruberry @VitalyFedyunin
Repository: create-react-app
Issue: Need support for Typescript Project references
Labels: issue: proposal

Recently typescript has added the feature of project references:

https://www.typescriptlang.org/docs/handbook/project-references.html 

In the projects created with create-react-app (with --typescript switch), we are not able to use this feature of typescript because babel complains that we cannot refer files for compiling which are outside the 'src' folder. 

I know that there are other workarounds such as 
- publishing the other projects as modules to the npm repository and then we can install them in the create-react-app
- we can play around with 'npm link', but this approach is not clean. We have to simulate the project references, instead of using the actual references feature of typescript with this approach.
- otherwise, we can eject create-react-app, and then customize the options.
- last option is to do away with create-react-app and build the tool-chain from scratch, which I tried and made it to work with ts-loader instead of babel.  In this approach, I had to set the 'projectReferences=true' option for the ts-loader inside webpack.config.js. This worked smoothly. But then I'm loosing on create-react-app, which I don't want. 

But all these ways are not clean and involve the trade-off between something or the other.

Having the C# and Java background, I'm pretty much used to the concept of project references. Many will suggest to not go this route, but I do need it. If it was not useful enough, typescript wouldn't have come up with it in the first place.

Also, I'm new to the web development world (just a month old), so pardon me for my lack of knowledge and if I'm asking for something very trivial and already exists.

Thanks
-Ashish
Repository: neovim
Issue: OptionSet should not be fired during 'modeline' (E12)
Labels: bug-vim


## Steps to reproduce

```
nvim --clean +'au OptionSet filetype lua print()'
:h h
```



## Actual behaviour

When vim help is shown (e.g. <F1> or `:help`), the following error message appears and after that every single keystroke will have this error message happening, making neovim totally unusable.

```
Error detected while processing function coc#rpc#notify[2]..<SNR>108_notify:
line    7:
E12: Command not allowed from exrc/vimrc in current dir or tag search
Press ENTER or type command to continue
```

![image](https://user-images.githubusercontent.com/1009873/55936147-7808a300-5c03-11e9-9ec7-4ef02a48721f.png)


## Expected behaviour

The help page should open without any error.
Repository: pytorch
Issue: Suggest model.eval() in torch.no_grad (and vice versa)
Labels: module: docs,triaged

## 📚 Documentation

`model.eval()`  and `with torch.no_grad` are both commonly used in evaluating a model.

[Confusion exists about whether setting `model.eval()` also sets `autograd.no_grad`](https://discuss.pytorch.org/t/does-model-eval-with-torch-set-grad-enabled-is-train-have-the-same-effect-for-grad-history/17183/5?u=ataraxy)

Would you accept a PR which suggests usage of the other, with words like:

* If evaluating a model's performance, using Module.eval() may also be useful.
* If evaluating a model's performance, using autograd.no_grad may also be useful.
Repository: rust
Issue: Variance should perhaps take into account 'static bounds.
Labels: T-lang

For example, when trying to build something resembling a pointer w/ optional metadata:
```rust
struct Ptr<T: ?Sized + Pointee> {
    addr: usize,
    meta: T::Meta,
}

trait Pointee {
    type Meta: 'static + Copy;
}
impl<T> Pointee for T {
    type Meta = ();
}
impl<T> Pointee for [T] {
    type Meta = usize;
}
```
`Ptr<T>` ends up invariant over `T` *even though* lifetimes in `T` *cannot possibly* affect `T::Meta` (which has a `'static` bound), and that results in errors like these:
```rust
error[E0308]: mismatched types
  --> src/lib.rs:16:56
   |
16 | fn covariant<'a>(p: Ptr<&'static ()>) -> Ptr<&'a ()> { p }
   |                                                        ^ lifetime mismatch
   |
   = note: expected type `Ptr<&'a ()>`
              found type `Ptr<&'static ()>`
note: the lifetime 'a as defined on the function body at 16:14...
  --> src/lib.rs:16:14
   |
16 | fn covariant<'a>(p: Ptr<&'static ()>) -> Ptr<&'a ()> { p }
   |              ^^
   = note: ...does not necessarily outlive the static lifetime
```

cc @rust-lang/wg-traits
Repository: go
Issue: cmd/vet: +build comment error is confusingly worded
Labels: help wanted,NeedsFix,Analysis

Please answer these questions before submitting your issue. Thanks!

#### What did you do?

Hello up there. I was updating my [tracing/xruntime](https://godoc.org/lab.nexedi.com/kirr/go123/tracing/internal/xruntime) package for Go1.12 and hit test error:

```
.../src/lab.nexedi.com/kirr/go123/tracing/internal/xruntime$ go test
# lab.nexedi.com/kirr/go123/tracing/internal/xruntime
./runtime_g_amd64.s:3:1: +build comment must appear before package clause and be followed by a blank line
FAIL    lab.nexedi.com/kirr/go123/tracing/internal/xruntime [build failed]
```

The error here complains about `+build` directive in assembly file:

---- 8< ---- (`runtime_g_amd64.s`)
```asm
#include "textflag.h"

// +build amd64 amd64p

// func getg() *g
TEXT ·getg(SB),NOSPLIT,$0-8
	MOVQ (TLS), R14
	MOVQ R14, ret+0(FP)
	RET
```

(https://lab.nexedi.com/kirr/go123/blob/7ee2de42/tracing/internal/xruntime/runtime_g_amd64.s)

It was working with Go1.11 and previous releases.



#### What did you expect to see?

Build and test succeed; test pass, as with e.g. Go1.11:

```
.../src/lab.nexedi.com/kirr/go123/tracing/internal/xruntime$ go1.11 test -v
=== RUN   TestStartStopTheWorld
--- PASS: TestStartStopTheWorld (1.00s)
PASS
ok      lab.nexedi.com/kirr/go123/tracing/internal/xruntime     1.003s
```

#### What did you see instead?

```
.../src/lab.nexedi.com/kirr/go123/tracing/internal/xruntime$ go1.12 test -v
# lab.nexedi.com/kirr/go123/tracing/internal/xruntime
./runtime_g_amd64.s:3:1: +build comment must appear before package clause and be followed by a blank line
FAIL    lab.nexedi.com/kirr/go123/tracing/internal/xruntime [build failed]
```


#### System details

```
go version go1.12.3 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/kirr/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/kirr/go"
GOPROXY=""
GORACE=""
GOROOT="/home/kirr/src/tools/go/go"
GOTMPDIR=""
GOTOOLDIR="/home/kirr/src/tools/go/go/pkg/tool/linux_amd64"
GCCGO="/usr/bin/gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version go1.12.3 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.12.3
uname -sr: Linux 4.19.0-4-amd64
Distributor ID:	Debian
Description:	Debian GNU/Linux buster/sid
Release:	testing
Codename:	buster
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Debian GLIBC 2.28-8) stable release version 2.28.
gdb --version: GNU gdb (Debian 8.2.1-2) 8.2.1
```
Repository: rust
Issue: meta matches pseudo-identifiers
Labels: A-macros,T-lang,T-compiler,C-bug,S-has-mcve

[This (playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f0a01f8d82a2ce3c19b6ffac01a6050f) fails:

```rust
macro_rules! foo {
    ($($m:meta => $i:item)* _ => $j:item) => {};
}

foo! {
    _ => { fn f() -> i32 { 2 } }
}

fn main() { f(); }
```

```
error: local ambiguity: multiple parsing options: built-in NTs meta ('m') or 1 other option.
 --> src/main.rs:6:5
  |
6 |     _ => { fn f() -> i32 { 2 } }
  |     ^
```

---

[This also fails (playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=71db79668a74f60dd391cbebcedbc536):

```rust
macro_rules! foo {
    ($m:meta) => {};
    (_ => { $i:item }) => {
        $i
    };
}

foo! {
    _ => { fn f() -> i32 { 2 } }
}

fn main() {  f(); }
```

```
error: expected identifier, found reserved identifier `_`
 --> src/main.rs:9:5
  |
9 |     _ => { fn f() -> i32 { 2 } }
  |     ^ expected identifier, found reserved identifier
```

---

I believe both cases should work because `meta` should not match pseudo-identifiers.

cc @petrochenkov @Centril @nrc @alexcrichton
Repository: flutter
Issue: Support clipOp for clipRRect 
Labels: c: new feature,engine,dependency: skia,c: proposal,P3,team-engine,triaged-engine

`Canvas.clipRect` accepts `clipOp: ClipOp` argument but `Canvas.clipRRect` does not.
Skia's https://skia.org/user/api/SkCanvas_Reference#SkCanvas_clipRRect does support clipOp argument so in Dart this can be also supported.

Same for `Canvas.clipPath`.

This is really handy for implementing fully transparent window on darkened layer.
Repository: pytorch
Issue: [Feature Request] Common constants in the torch.* namespace
Labels: triaged,enhancement,module: numpy

## 🚀 Feature

Two feature requests asked for constants from the `math` package to be included in `torch` as well:
- https://github.com/pytorch/pytorch/issues/19123
- https://github.com/pytorch/pytorch/issues/6510

## Motivation

- To avoid adding an `import math` when you want to do it
- Because NumPy and SciPy do it

## Alternatives

Dont do it and tell users to `import math`
Repository: go
Issue: net: TestUnixAndUnixpacketServer flaky on linux
Labels: Testing,help wanted,NeedsInvestigation

https://build.golang.org/log/09fce21c31d8c4435fb99a4f7c0e8a1bb2bf900f and
https://build.golang.org/log/faa4560674d8e7d406b7031bfe985db237b9860a:
```
--- FAIL: TestUnixAndUnixpacketServer (0.00s)
    server_test.go:197: #3: EOF
FAIL
FAIL	net	8.796s
```

See previously #13205 (CC @bradfitz).
Repository: go
Issue: cmd/go/internal/modfetch: module path validation inconsistent between repo and proxy fetch paths
Labels: NeedsInvestigation,early-in-cycle,modules

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.11.4 darwin/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"
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
...
</pre></details>

### What did you do?

These are the reproduction steps posted in gocenter gopher  slack channel by @thepudds.

mkdir /tmp/scratchpad/hashicorp-vault-1
cd /tmp/scratchpad/hashicorp-vault-1

export GOPROXY='https://gocenter.io'
export GOPATH='/tmp/go-path-for-hashicorp-vault-test-1'

go mod init tempmod

cat <<EOF > main.go
package x
import (
    _ "github.com/hashicorp/vault/api"
)
func main() {}
EOF
go mod tidy

go list -m all | wc -l 
go list -m all > list.all.out
find $GOPATH/pkg/mod -name "*.mod" | wc -l
du -sh $GOPATH/pkg/mod


Repeat this in another window with different sets of directories(Replace -1 with -2 for example)  but without setting GOPROXY.

You can see the du output in the GOPROXY window to be significantly different in the window without GOPROXY setting and the list of modules (list_all.out) shows difference in the version number for one of the dependencies (github.com/pierrec/lz4)





### What did you expect to see?
In the both cases with GOPROXY and without GOPROXY, expect to see the dependencies of modules to be resolved to the same version


### What did you see instead?
There is a difference in the du output as well as the content of the list of modules with and without GOPROXY, 
With GOPROXY, the modules list shows 
          github.com/pierrec/lz4 v2.1.1+incompatible // indirect
Without GOPROXY, the modules list shows
          github.com/pierrec/lz4 v2.0.5+incompatible // indirect

Please note that the actual dependency based on vendor.json in the project github.com/hashicorp/vault is actually v0.0.0-20181005164709-635575b42742 (go mod init in that project generates this correctly) but go mod tidy overwrites it with a different version.
Repository: godot
Issue: HBoxContainer default separation not shown
Labels: enhancement,discussion,documentation,topic:gui

**Godot version:**
3.1.1 Mono 2fbc421

**Issue description:**
`HBoxContainer` has a default separation of some kind. But the field for it in the editor, when unchecked, displays 0. This is very confusing. Either it should display the correct separation value or the default should be set to 0.

I would prefer the latter, I was looking for a while for some margin or padding setting on some children nodes that were set to fill and expand because a random gap was between them for no obvious reason and the widths where a bit off. *But changing the default value would change everyone's HBoxContainers without custom separation in existing projects. So just displaying or mentioning it in the field or at least the docs is probably better.*

I thought we could discuss it here first before making a pull.
Repository: flutter
Issue: The height of CupertinoTextField will reduce on editing when the placeholder is not in English
Labels: a: text input,framework,a: internationalization,f: cupertino,has reproducible steps,P3,found in release: 3.3,found in release: 3.7,team-text-input,triaged-text-input

I set the placeholder to non-English words  when using CupertinoTextField, then I found that the height of the widget will reduce on editing.

![image](https://user-images.githubusercontent.com/26833355/56007137-45959d80-5d0a-11e9-8c84-dc3029f0fb9b.png)

I have tried four languages, and here is my test code:

```
class Filter extends StatefulWidget {
  @override
  _FilterState createState() => _FilterState();
}

class _FilterState extends State<Filter> {
  Map languages = {
    'English': 'test',
    'Chinese': '测试',
    'Japanese': 'テスト',
    'Korean': '테스트',
    'Arabic': 'اختبر',
  };

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        leading: CupertinoNavigationBarBackButton(),
        title: Text('CupertinoTextField Test'),
        centerTitle: true,
      ),
      backgroundColor: Colors.white,
      body: Container(
        padding: EdgeInsets.all(8.0),
        child: Center(
          child: CupertinoTextField(
            placeholder: 'Flutter ${languages['Chinese']}',
            decoration: BoxDecoration(border: Border.all(color: Colors.red)),
          ),
        ),
      ),
    );
  }
}
```
Did I do anything wrong?
Repository: rust
Issue: Implement `CStr` as a pointer rather than a slice
Labels: C-enhancement,A-FFI,T-libs-api

Littered throughout the `CStr` documentation are notes and hints that it should be eventually converted to using a pointer underneath the hood instead of a slice.  This change will make `CStr::from_ptr` O(1) instead of O(n).  Other constructors may still be O(n) because they have to check to ensure there is only one null terminator.  If someone wants to try implementing this, it seems like a pretty simple change.

[Current struct definition](https://github.com/rust-lang/rust/blob/master/src/libstd/ffi/c_str.rs#L116):

```
pub struct CStr {
    inner: [c_char]
}
```

Proposed:

```
pub struct CStr {
    inner: *const c_char
}
```
Repository: neovim
Issue: 'nofsync' may lose data (empty file + swapfile) after system crash
Labels: bug,robustness,complexity:high,has:workaround,has:plan,system,filesystem

I was using nvim to write a small python script.  I had another program watching the python script to run it when I wrote it to disk.  In addition, I had Syntastic installed and python support, but syntastic was temporarily set to not check (SyntasticCheckToggle off).

When I updated the file, the script was run, but my memory was exhausted and the system hung.  After reboot, I found that not only was the file I wrote emtpy (size 0 bytes), but nvim offered me the option of recovering the file, but when I hit 'r', nvim reported that the recovery file was missing. 

Could this be the result of a race condition in the recovery file management where old recovery data is deleted before current recovery data is flushed to disk.  Double buffer solution?

- `nvim --version`: NVIM v0.3.3
- Operating system/version: Fedora 29
- Terminal name/version: Gnome Terminal/TMUX
- `$TERM`: tmux-256color

### Steps to reproduce using `nvim -u NORC`
Sorry, I cannot reproduce this event, safely.

### Actual behaviour
Recover data is not available under some conditions that should be covered.

### Expected behaviour
Updating recovery data should be atomic
Repository: TypeScript
Issue: Rename field to a name with dash does not transform the field with quotes.
Labels: Suggestion,Experience Enhancement

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.5.0-dev.20190412

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** hyphen refactor, dash rename

**Code**

```ts
interface TestObject {
    test:string
}
const instance: TestObject = { test: "hello" };
console.log(instance.test);
```
Rename "test" to a variable with a hyphen, e.g "te-st"

**Expected behavior:**
Code is refactored to use quotes:
```ts
interface TestObject {
    "te-st":string
}
const instance: TestObject = { "te-st": "hello" };
console.log(instance["te-st"]);
```

**Actual behavior:**

Refactor replaces the variable as given, producing invalid code
```ts
interface TestObject {
    te-st:string
}
const instance: TestObject = { te-st: "hello" };
console.log(instance.te-st);
```
**Playground Link:** Replacing all occurrences in the playground also includes all Test matches, so I tested this in vscode

**Related Issues:** none I could find
Repository: go
Issue: x/all: gccgo support
Labels: NeedsDecision

In #31382, @mikioh asks an interesting questions about the maintenance of golang.org/x packages on gccgo. 

How are we sure that the changes made in golang.org/x will work on gccgo ? 

For Go toolchain, they are builders on every GOOS/GOARCH which check that it's working but what about the Gccgo toolchain ? Do we assume that if it works on Go, it must work on Gccgo ? 
The core code of each package should indeed work, after all that's just Go code. But what about special gccgo files, like in x/sys/unix for syscalls, or all the Go assembly files which cannot be built on gccgo, like in x/crypto ? 

CC @bradfitz @ianlancetaylor