sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Investigate replacing most of the debugger pretty-printing scripts with traits.
Labels: A-debuginfo,E-hard,P-medium,T-compiler,WG-debugging,E-needs-design,E-needs-investigation

In the case of `Vec<T>` and `String`, it would be possible to have e.g.:
```rust
impl<'a, T> DebuggerView<'a> for Vec<T> {
    type View = &'a [T];
    fn debugger_view(&'a self) -> Self::View { &self[..] }
}
```
```rust
impl<'a> DebuggerView<'a> for String {
    type View = &'a str;
    fn debugger_view(&'a self) -> Self::View { &self[..] }
}
```
We would then need:
* support for pretty-printing `&[T]` and `&str`
  * already exists in our custom pretty-printing scripts
  * long-term DWARF should allow us to express these directly (see #37504)
* a way to encode `<X as DebuggerView>::debugger_view` in `X`'s debuginfo
  * i.e. a symbol name, or maybe we can make symbol names based on DWARF type IDs?
* support for going through `<X as DebuggerView>::debugger_view` for pretty-printing
  * the method signature above should be relatively simple to call

I suspect there are better APIs that could accommodate more complex data structures, but I'm not sure what the limitation of the pretty-printer scripts are, around being able to call arbitrary functions.

There's also the possibility that we could encode this sort of information as data, instead of compiling it into functions, but that's probably a lot more work.

cc @michaelwoerister
Repository: vue
Issue: transition-group has stutter when component updated elsewhere
Labels: bug,transition

### Version
2.6.10

### Reproduction link
[https://jsfiddle.net/zncxud6q/](https://jsfiddle.net/zncxud6q/)







### Steps to reproduce
Use test1, test2, or test3 buttons to see transition without stutter.
Use test4, test5, or test6 buttons to see transition with stutter.

### What is expected?
No stutter

### What is actually happening?
While the DOM is updating, the transition restarts, even though the portion updating isn't a child of anything transitioning

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: rust
Issue: Audit uses of pprint in suggestions
Labels: C-cleanup,A-diagnostics,T-compiler

The preferred source of user code in suggestions should be coming from `span_to_snippet`, optionally with `pprint`ing an expression if desired. There are places in the codebase where older code might be using `pprint` directly, which can end up with us suggesting code that doesn't look like what the user already wrote. We should clean this up, ideally by making also simplifying the API for "get snippet from span, make a new suggestion string, fallback if needed".
Repository: terminal
Issue: Code health: consider splitting Pane class into leaf and parent classes
Labels: Area-UserInterface,Product-Terminal,Issue-Task,Area-CodeHealth

Idea: Split `Pane` class into `LeafPane` and `ParentPane`, both inheriting from abstract base `Pane`.

Currently Pane class has many members that are used only in leaf or only in parent mode. IMHO proposed splitting would make the code much cleaner and safer (e.g. from accidentally accessing a terminal when we're not a leaf). There is a long way ahead of panes so this might be worthwhile.
Repository: pytorch
Issue: [jit] scripted module and user defined methods
Labels: oncall: jit,triaged

Currently, for a scripted module, user-defined methods that return `self` will return a **unscripted** module, yet builtin ones return the scripted one:

```py

In [14]: import torch
    ...:
    ...: class SimpleNet(torch.nn.Module):
    ...:     def __init__(self, mult):
    ...:         super().__init__()
    ...:         self.register_buffer('mult', torch.as_tensor(mult))
    ...:
    ...:     def forward(self, x):
    ...:         return x * self.mult
    ...:
    ...:     def set_mult(self, mult):
    ...:         self.mult.fill_(mult)
    ...:         return self
    ...:
    ...:
    ...: m = SimpleNet(3)
    ...: m = torch.jit.script(m)

In [17]: print(m)
ScriptModule(original_name=SimpleNet)

In [18]: print(m.set_mult(2342))
SimpleNet()

``` 

This could be intended. However, it is pretty unintuitive from user land. And it leads to weird cases like
```py
In [19]: isinstance(m, SimpleNet)
Out[19]: False

In [20]: isinstance(m.set_mult(2), SimpleNet)
Out[20]: True

In [21]: isinstance(m.train(), SimpleNet)
Out[21]: False

In [22]: isinstance(m.set_mult(2).train(), SimpleNet)
Out[22]: True

In [15]: m.set_mult(44)(3)
Out[15]: tensor(132)

In [16]: m(3)
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-16-7d05f9f266c1> in <module>
----> 1 m(3)

~/miniconda3/lib/python3.7/site-packages/torch/nn/modules/module.py in __call__(self, *input, **kwargs)
    539             result = self._slow_forward(*input, **kwargs)
    540         else:
--> 541             result = self.forward(*input, **kwargs)
    542         for hook in self._forward_hooks.values():
    543             hook_result = hook(self, input, result)

RuntimeError: forward() Expected a value of type 'Tensor' for argument 'x' but instead found type 'int'.
Inferred 'x' to be of type 'Tensor' because it was not annotated with an explicit type.
Position: 1
Value: 3
Declaration: forward(ClassType<SimpleNet> self, Tensor x) -> (Tensor)
```

## General case 

The problem is more general. If the method returns, e.g., a child, then it will be a normal child, rather than a scripted child, different from `getattr`.

cc @suo
Repository: react
Issue: SuspenseList in DevTools could cycle through the Suspense states
Labels: Component: Developer Tools,React Core Team

We currently have a way to force a fallback on a Suspense boundary in DevTools.

It might be cool to have a "play" button or something on SuspenseList that cycles through the states.

E.g. if it's "together" mode it shows all the fallbacks and then switches to showing all the content and then back again in a loop.

If it's "forwards" it shows all the fallbacks then one at a time and then back to all fallbacks. If it's tail "hidden" or "collapsed" it hides all the ones that are not yet inserted and then inserts one at a time.

Could be a nice way to demo/test the loading sequence experience.
Repository: flutter
Issue: Documentation for how to share assets from the host app to the flutter module
Labels: framework,engine,d: api docs,a: existing-apps,P2,team-engine,triaged-engine

cc @gaaclarke, @matthew-carroll
Repository: pytorch
Issue: `torch.nn.Module._load_state_dict` catch-all error message can be misleading
Labels: triaged

## 🐛 Bug

`torch.nn.Module._load_state_dict` loads parameter values by an in-place `copy_` operation on the module parameters. Sometimes the parameter values may be initialized to an expanded tensor, in which case the `copy_` call fails with a catch-all error message,

```
RuntimeError: Error(s) in loading state_dict for Foo:
	While copying the parameter named "bar", whose dimensions in the model are torch.Size([2, 3]) and whose dimensions in the checkpoint are torch.Size([2, 3]).
```

## To Reproduce

```
import torch


class Foo(torch.nn.Module):
    def __init__(self):
        super().__init__()
        # initialize with placeholder data
        data = torch.randn(3).expand(2, -1)
        self.register_parameter("bar", torch.nn.Parameter(data))


# make a model checkpoint
foo = Foo()
foo.bar = torch.nn.Parameter(torch.randn(2, 3))
state_dict = foo.state_dict()

# attempt to load the checkpoint
new_foo = Foo()
new_foo.load_state_dict(state_dict)
```

## Expected behavior

At the very least the correct error message should be displayed,

```
*** RuntimeError: unsupported operation: more than one element of the written-to tensor refers to a single memory location. Please clone() the tensor before performing the operation.
```

Ideally, since the old parameter data is being overwritten anyways, `Module._load_state_dict` should catch this exception and find another way to load the checkpointed data. 

## Environment

PyTorch version: 1.3.0
Is debug build: No
CUDA used to build PyTorch: 10.1.243

OS: Ubuntu 16.04.6 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~16.04~ppa1) 7.4.0
CMake version: version 3.16.0-rc1

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: 10.1.243
GPU models and configuration: GPU 0: GeForce GTX 1080 Ti
Nvidia driver version: 418.87.01
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] gpytorch==0.3.6
[pip] numpy==1.17.2
[pip] torch==1.3.0
[pip] torchvision==0.4.1a0+d94043a
[conda] blas                      1.0                         mkl  
[conda] gpytorch                  0.3.6                     dev_0    <develop>
[conda] mkl                       2019.4                      243  
[conda] mkl-service               2.3.0            py37he904b0f_0  
[conda] mkl_fft                   1.0.14           py37ha843d7b_0  
[conda] mkl_random                1.1.0            py37hd6b4f25_0  
[conda] pytorch                   1.3.0           py3.7_cuda10.1.243_cudnn7.6.3_0    pytorch
[conda] torchvision               0.4.1                py37_cu101    pytorch


## Additional context

This use case can occur when parameter values are initialized with placeholder values, or when an expanded view of the tensor is necessary for broadcasted operations.
Repository: pytorch
Issue: Seg-fault in LayerNormKernelImpl
Labels: needs reproduction,module: crash,module: cuda,triaged

## 🐛 Bug

While implementing a recurrent neural network with Layer normalization on the GPU I get a segmentation fault in the kernel implementation of the normalization. The model runs fine on CPU.

## To Reproduce

Steps to reproduce the behavior:

1. create a model with layerNormalization and try to run it on GPU
2. run forward pass

Error message in debugger is:

Thread 1 "python" received signal SIGSEGV, Segmentation fault.
0x00007fffbc6607e2 in at::native::(anonymous namespace)::LayerNormKernelImpl(at::Tensor const&, at::Tensor const&, at::Tensor const&, long, long, double, at::Tensor*, at::Tensor*, at::Tensor*) ()
   from [...]/lib/python3.7/site-packages/torch/lib/libtorch.so

## Expected behavior

not crash

## Environment
PyTorch version: 1.2.0
Is debug build: No
CUDA used to build PyTorch: 10.0.130

OS: Ubuntu 18.04.3 LTS
GCC version: (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0
CMake version: Could not collect

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: GeForce RTX 2080 Ti
Nvidia driver version: 418.87.00
cuDNN version: /usr/lib/x86_64-linux-gnu/libcudnn.so.7.6.4

Versions of relevant libraries:
[pip] numpy==1.17.2
[pip] numpydoc==0.9.1
[pip] torch==1.2.0
[pip] torchvision==0.4.0a0
[conda] _pytorch_select           0.2                       gpu_0  
[conda] blas                      1.0                         mkl  
[conda] mkl                       2019.4                      243  
[conda] mkl-service               2.3.0            py37he904b0f_0  
[conda] mkl_fft                   1.0.14           py37ha843d7b_0  
[conda] mkl_random                1.1.0            py37hd6b4f25_0  
[conda] pytorch                   1.2.0           cuda100py37h938c94c_0  
[conda] torchvision               0.4.0           cuda100py37hecfc37a_0

not sure why the script misses the cuda version: copied from nvidia-smi:
NVIDIA-SMI 418.87.00    Driver Version: 418.87.00    CUDA Version: 10.1 



cc @ngimel
Repository: TypeScript
Issue: Creating too many types for DOM & D3
Labels: Domain: Performance

Commit 06fe1ed53721862b56c61ebb89b1daee2bc10710 introduced a regression in the number of types created when compiling a snippet of `@types\d3`.  Specifically, it appears to be elaborating types for an error message that ends up getting dropped.

Repro:
```json
{
  "compileOnSave": false,
  "compilerOptions": {
    "alwaysStrict": true,
    "noImplicitAny": true,
    "noEmit": true,
    "lib": [ "es5", "dom" ],
    "noResolve": true,
    "types": [],
    "skipLibCheck": true
  },
  "files": [
    "test.ts",
}
```

test.ts
```ts
declare function select<GElement extends BaseType, OldDatum>(selector: string): Selection2<GElement, OldDatum, HTMLElement, any>;

type BaseType = Element | Document | Window | null | number;

type ValueFn<T extends BaseType, Datum, Result> = (this: T, datum: Datum, index: number, groups: T[] | ArrayLike<T>) => Result;

interface Selection2<GElement extends BaseType, Datum, PElement extends BaseType, PDatum> {
    select<DescElement extends BaseType>(selector: ValueFn<GElement, Datum, DescElement>): Selection2<DescElement, Datum, PElement, PDatum>;
}
```

For an apples-to-apples comparison, use `nolib` and specify the 3.1 lib.es5.d.ts and lib.dom.d.ts for both compilations.

In round numbers, there are ~150 types without the change and ~2500 types with the change.
Repository: go
Issue: cmd/go: go mod download does not report invalid certificate error
Labels: help wanted,NeedsFix,modules

### What version of Go are you using (`go version`)?
`go version go1.13.3 linux/amd64`

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
`golang:1.13.3` Docker image:

```
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
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-build897368373=/tmp/go-build -gno-record-gcc-switches"
```

### What did you do?
Using a network that performs TLS MiTM decryption (that is, uses an internal root certificate for TLS traffic so that network inspection can be performed):

```
# docker run -it golang:1.13.3
# GOPROXY=direct go mod download -json rsc.io/sampler@v1.3.1
go: finding rsc.io/sampler v1.3.1
{
        "Path": "rsc.io/sampler",
        "Version": "v1.3.1",
        "Error": "rsc.io/sampler@v1.3.1: invalid version: unknown revision v1.3.1"
}
```

### What did you expect to see?
The fetch operation is actually failing because the fetch operation can't validate the certificate injected by the TLS MiTM decryption. Verified this by adding the root certificate to the trust store and running the same command again:

```
# wget -qO- http://{URL_FOR_CERT} >> /etc/ssl/certs/ca-certificates.crt
# GOPROXY=direct go mod download -json rsc.io/sampler@v1.3.1
go: finding rsc.io/sampler v1.3.1
{
        "Path": "rsc.io/sampler",
        "Version": "v1.3.1",
        "Info": "/go/pkg/mod/cache/download/rsc.io/sampler/@v/v1.3.1.info",
        "GoMod": "/go/pkg/mod/cache/download/rsc.io/sampler/@v/v1.3.1.mod",
        "Zip": "/go/pkg/mod/cache/download/rsc.io/sampler/@v/v1.3.1.zip",
        "Dir": "/go/pkg/mod/rsc.io/sampler@v1.3.1",
        "Sum": "h1:F0c3J2nQCdk9ODsNhU3sElnvPIxM/xV1c/qZuAeZmac=",
        "GoModSum": "h1:T1hPZKmBbMNahiBKFy5HrXp6adAjACjK9JXDnKaTXpA="
}
```

I would expect the original error to state that it could not determine the version because the network call it made could not validate the certificate -- because the error didn't make this clear, it took trial-and-error debugging to determine that the TLS decryption policy was the cause for this failure.

### What did you see instead?
Error that did not describe the root cause:

```
{
        "Path": "rsc.io/sampler",
        "Version": "v1.3.1",
        "Error": "rsc.io/sampler@v1.3.1: invalid version: unknown revision v1.3.1"
}
```
Repository: flutter
Issue: Account for null values in `AnimatedPositioned`
Labels: c: new feature,framework,a: animation,c: proposal,P3,team-framework,triaged-framework

I was using animated positioned an I wanted to move a widget from the top of a stack to the bottom. I was using top: 0, bottom: null and then setting the state to top: null, bottom:0. This made the widget move, but no animation. I'm told that since it's interpolation between the values of the old position and new, it can't have null values, since that wouldn't make sense.
This makes since with that explanation, but it doesn't from an outside view. Could the widget be a little "smarter" and determine its relative position and use that for interpolation rather than the values **if** interpolation from a null value?
Repository: pytorch
Issue: No in-place version of where()
Labels: triaged,OSS contribution wanted,actionable,module: sorting and selection,function request

## 🚀 Feature
There is no way to perform the functionality of `torch.where()` in-place. This feature would either add a `.where_()` method to `Tensor` or an `out` parameter to the existing `torch.where()`, or both.

## Motivation

All of the usual reasons for doing operations in-place.

## Pitch

As stated above, add a `.where_()` method to `Tensor` or an `out` parameter to the existing `torch.where()`.

## Alternatives

One could use the out-of-place `torch.where()` for a less efficient alternative.

Note that the `.masked_scatter_()` method does not have the same functionality as an in-place `where()`.
Repository: TypeScript
Issue: TS 3.7: optional chaining output is introducing a local variable
Labels: Suggestion,Experience Enhancement

**TypeScript Version:**  3.7.x-dev.201xxxxx

**Search Terms:**
optional chaining

**Code**

```ts
function isTrue(something: { value: boolean} | undefined): boolean {
	return something?.value === true; 
}
```

**Expected behavior:**
Output:
```js
"use strict";
function isTrue(something) {
    return (something === null || something === void 0 ? void 0 : something.value) === true;
}
```

**Actual behavior:**
Actual Output:
```js
"use strict";
function isTrue(something) {
    var _a;
    return ((_a = something) === null || _a === void 0 ? void 0 : _a.value) === true;
}
```
Repository: terminal
Issue: 'fontFace' not working for any profile after system reboot.
Labels: Resolution-External,Area-Rendering,Issue-Bug,Product-Terminal,Tracking-External

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment
- Microsoft Windows [Version 10.0.18362.418]
- Windows Terminal (Preview) Version: 0.5.2762.0
- Ubuntu subsystem with Oh My Zsh using the agnoster theme with Powerline Fonts installed.

# Steps to reproduce
1. Setup Windows Terminal (With Ubuntu subsystem)
2. Set the `fontFace` for various profiles (Tested with powershell, cmd and Ubuntu WSL)
   Note, that everything was working as intended up to here.
3. Restart Windows.

# Expected behavior
The font setting being applied:
![grafik](https://user-images.githubusercontent.com/13157984/67148722-ed37ed80-f2a2-11e9-8662-4892e527839f.png)
![grafik](https://user-images.githubusercontent.com/13157984/67148831-713ea500-f2a4-11e9-9561-b582a0bf17fd.png)

<!-- A description of what you're expecting, possibly containing screenshots or reference material. -->

# Actual behavior
After restarting Windows `fontFace` is being ignored:
![grafik](https://user-images.githubusercontent.com/13157984/67148876-d85c5980-f2a4-11e9-91ea-5f78a369a7d5.png)
![grafik](https://user-images.githubusercontent.com/13157984/67148894-122d6000-f2a5-11e9-8228-561ff76d468e.png)

# Additional Info
My current profiles.json: [profiles.txt](https://github.com/microsoft/terminal/files/3746987/profiles.txt)
Repository: TypeScript
Issue: TS 3.7: unlike `x is T`, `asserts x is T` cannot close over generics defined in outer scopes
Labels: Suggestion,Experience Enhancement

**TypeScript Version:**  3.7.0-dev.20191016

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
asserts, asserts return, asserts higher order, asserts type, 2775

**Code**

```ts
function literal<T extends keyof any>(lit: T): {
    is(value: any): value is T
    assert(value: any): asserts value is T
} {
    return null as any; // implementation doesn't matter
}

const isHi = literal("hi")
const x: unknown = "test"

if (isHi.is(x)) {
    console.log(x) // x is correctly inferred to be 'hi' :)
}

isHi.assert(x); // error: Assertions require every name in the call target to be declared with an explicit type annotation.(2775)
console.log(x); // x should be inferred to be 'hi' here :(
```

**Expected behavior:**

No compile error, `x` is inferred to be `"hi"` on the last line.

**Actual behavior:**

Compile error on `isHi.assert`. `Assertions require every name in the call target to be declared with an explicit type annotation.(2775)`

Construction higher order type guards is possible without problem (as shown in the snippet). This mechanism used heavily in libraries like `io-ts` and `mobx-state-tree`. 

However, when trying to extend the latter library with assertion functionality for more convenient control flow, we run into this issue.

We can build `type.is` properly, but not `type.assert`, although they seem to be needing the exact same type / depth of type analysis; if type guards can close over `T`, so should type assertions?

**Playground Link:** [link](http://www.typescriptlang.org/play/?ts=3.7-Beta#code/C4TwDgpgBAggznCAnYcA8AVAfFAvFACgDcBDAGwFcIAuKCgOwGt6B7Ad3oEo8cSFlUUUpWgBLOFAwAoKQDMGAY2CiW9KGVHBk5TFAgAPLfQAmExhBAtZUEvRBYCG4LQydaAbylRvUccXJUtLYgbkIBYhLSPjb8KP4iQXahfIgoEsJUvpFePgD0uTGpzrCxqJhYUgC+UJ7RSBDAFEhq9BRkZDE2dgDcVTIKqnDAWQASonjqmtpkBABEABais5z9g8P6tAzM7Gr4s1pDszKi1gTiYwB0fvqc3LU+A-RwLGQQF2QsAOYEN1D5UPoslABkh6koyCBfPRZMh6sYoMAWFAAOSLZF9KTnUQXFICH6cbp-AqwlhIKDUAirJ4vN4fb43Qn-QFweYsNrwgBGYmhsIg8L4KLRUBYRGQUHmyAgQA)

**Related Issues:** 

#34523