sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: NonNullable isn't narrowing down object values' types for optional properties
Labels: Suggestion,Domain: Mapped Types,Experience Enhancement

<!-- 🚨 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.20181106

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
NonNullable object 
NonNullable object values

**Code**

Run the following code via `tsc --no-emit --strict test.ts`:
```ts
interface P {
  color?: 'red' | 'green';
}

type RequiredP = {
  [K in keyof P]: NonNullable<P[K]>;
}

declare const p: RequiredP;
const color: 'red' | 'green' = p.color;
```

**Expected behavior:**

The resulting type should not allow `undefined` for the value at a property `color`.

**Actual behavior:**

`undefined` is still allowed. Using the `NonNullable` type doesn't seem to have any effect.

**Playground Link:** Note: you need to enable `strictNullChecks` manually!
https://www.typescriptlang.org/play/#src=interface%20P%20%7B%0D%0A%20%20color%3F%3A%20'red'%20%7C%20'green'%3B%0D%0A%7D%0D%0A%0D%0Atype%20RequiredP%20%3D%20%7B%0D%0A%20%20%5BK%20in%20keyof%20P%5D%3A%20NonNullable%3CP%5BK%5D%3E%3B%0D%0A%7D%0D%0A%0D%0Adeclare%20const%20p%3A%20RequiredP%3B%0D%0Aconst%20color%3A%20'red'%20%7C%20'green'%20%3D%20p.color%3B%0D%0A

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: TypeScript
Issue: Introduce the opposite of the non-null assertion
Labels: Suggestion,Awaiting More Feedback

## Search Terms

non-null assertion opposite

## Suggestion

The opposite of the "non-null assertion", used to force the compiler to believe that something may be undefined.

The most obvious syntax would be a "?" postfix operator, similar to how the non-null assertion is a "!" postfix operator. This would be consistent with the use of "?" for optional function params and object properties (which adds "undefined" to the type). 
## Use Cases

Indexing into arrays and "dictionary" objects with indexes/keys that are expected to potentially not exist.

Arrays and dictionary objects (an object type with the string index defined) are typically defined as having items whose type does NOT include undefined, even though it is technically possible (and valid) to use a non-existent index/key and get an undefined value as a result. In most situations, this avoids unnecessary/tedious non-null assertions, because arrays are often iterated (indexes guaranteed to exist), and dictionary objects are often used only to lookup keys that are guaranteed to exist.

However, in situations where an "untrusted" index/key is used on an array/dictionary, there is no convenient way to alter the type of the expression to indicate that the programmer is aware that the result may be undefined:

## Examples

```ts
declare const array: Date[];
declare const untrustedIndex: number;

// Type is Date, but it may actually be undefined at runtime.
const item = array[untrustedIndex];

// To get useful "correct" typing, I must explicitly cast, duplicating the type 
// of the item and adding "| undefined" 
const item2 = array[untrustedIndex] as Date | undefined;

// Using the new proposed "possibly undefined assertion"
// Type is Date | undefined
const item3 = array[untrustedIndex]?;
```

## Checklist

My suggestion meets these guidelines:
* [?] 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. new expression-level syntax)
Repository: vue
Issue: vnode reference to original component (reopened)
Labels: feature request

### What problem does this feature solve?
Because we have to have lots of ads on our site we cannot hydrate our SSR'd page with VUE completely as the ads would break VUE. Also most of our site ist static and it would be stupid to ship our entire app for only some parts of our page being interactive.

Instead we **partially hydrate** the page (with our own plugin https://github.com/spring-media/vue-plugin-moisturizer). For this we need to map SSR'd HTML to the corresponding VUE components, so we need to put some `data-attribute` in the HTML match them. 

We use the `name` setting of a component for this,  so if I have component like this:

```js
{
  name: 'my-component'
}
```

the html would read

```html
<div data-hydration-name="my-component">...</div>
```


but this does not work for 3rd party components. Anything we get without that ID we cannot hydrate. It would be great if we could find the component from a component's instance / vnode.

There is a `cid` property, but this is not the same on the server and on the client,  because we have a different number and oder of components on the client and server so we cannot use this.

There is a similiar issue for this here: https://github.com/vuejs/vue/issues/7213 but one of your members suggested to create a new issue because the old one would just not show up under your pile of issues.

### What does the proposed API look like?
```js
this.$vnode.cuuid // hash based on the filename and path
```

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: TypeScript
Issue: infer-from-usage codefix should mark parameters as optional
Labels: Suggestion,In Discussion,Domain: Quick Fixes

## Search Terms

codefix infer from usage optional parameter

## Suggestion

When you ask to for the infer-from-usage codefix for `f`:

```ts
function f(x, y) {
  return x + (y || 0)
}
f(1)
```

You should get `function f(x: number, y?: number | undefined)`

This already works in JS. You get `/** @param {number | undefined} [y] */`.
Repository: rust
Issue: Tracking issue for alloc_layout_extra
Labels: A-allocators,T-libs-api,B-unstable,C-tracking-issue,Libs-Tracked

This issue tracks additional methods on `Layout` which allow layouts to be composed to build complex layouts.

```rust
pub const fn padding_needed_for(&self, align: usize) -> usize;
pub const fn repeat(&self, n: usize) -> Result<(Layout, usize), LayoutErr>;
pub const fn repeat_packed(&self, n: usize) -> Result<Layout, LayoutErr>;
pub const fn extend_packed(&self, next: Layout) -> Result<Layout, LayoutErr>;
pub const fn dangling(&self) -> NonNull<u8>;
```

The main use case is to construct complex allocation layouts for use with the stable global allocator API. For example:
- [`std::collections::HashMap`](https://github.com/rust-lang/rust/blob/master/src/libstd/collections/hash/table.rs#L657)
- [`hashbrown`](https://github.com/Amanieu/hashbrown/blob/2f2af1d1e9bea9d7315b5a85d9cf5b5514f532fe/src/raw/mod.rs#L143)
- Not exactly an example of use, but it would be very useful in [`crossbeam-skiplist`](https://github.com/crossbeam-rs/crossbeam-skiplist/blob/master/src/base.rs#L99)

One concern is that not many of these methods have been extensively used in practice. In the examples given above, only `extend`, `array` and `align_to` are used, and I expect that these will be the most used in practice. `padding_needed_for` is used in the implementation of `Rc::from_raw` and `Arc::from_raw`, but in theory could be superseded by the offset returned by `extend`.
Repository: react
Issue: Autofocus Text puts cursor at end instead of beginning
Labels: Component: DOM,Type: Regression

**Do you want to request a *feature* or report a *bug*?**
Bug

**What is the current behavior?**
In React 16, a text input with a value and autofocus will set the cursor at the _end_ of the input.
`<input autoFocus={true} type="text" defaultValue="4444" />`

**If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. Your bug will get fixed much faster if we can run your code and it doesn't have dependencies other than React. Paste the link to your JSFiddle (https://jsfiddle.net/Luktwrdm/) or CodeSandbox (https://codesandbox.io/s/new) example below:**

See the React 16 repro here: https://codepen.io/matthewg0/pen/XymjYo

**What is the expected behavior?**
In React 15, and in plain HTML, the behavior is that the cursor is placed at the _start_ of the input.
React 15: https://codepen.io/matthewg0/pen/NEGRzv
Plain HTML: https://codepen.io/matthewg0/pen/wQKoap

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**
Reproduces as of React 16.  Worked as expected in React 15.
Repository: go
Issue: proposal: runtime: provide access to info about recent GC cycles
Labels: Proposal,Proposal-Hold

Currently, `runtime.parsedebugvars` is called from `schedinit` which is part of binary bootstrap. This means it's not possible to dynamically enable GODEBUG features once a binary has started.

Typically, we don't want gc traces to flood our logs, but when debugging specific memory issues, it would be helpful if we could enable features (such as gctrace=1 and scavenge=1) dynamically.

While it doesn't have to be via `os.Setenv`, it;d be useful to have some way to dynamically enable `GODEBUG` features.

### What version of Go are you using (`go version`)?

```
$ go version
go version go1.11.2 linux/amd64
```

### Does this issue reproduce with the latest release?
Yes, I'm using the latest release.


### What operating system and processor architecture are you using (`go env`)?

```
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/prashant/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/prashant/go"
GOPROXY=""
GORACE=""
GOROOT="/home/prashant/bin/go1.11.2"
GOTMPDIR=""
GOTOOLDIR="/home/prashant/bin/go1.11.2/pkg/tool/linux_amd64"
GCCGO="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-build849457703=/tmp/go-build -gno-record-gcc-switches"
```

### What did you do?

Set `GODEBUG` to `gctrace=1,scavenge=1` dynamically using `os.Setenv`.


### What did you expect to see?

Expected to see GC traces once the variable was set.

### What did you see instead?

No GC traces.
Repository: go
Issue: fmt: compound object rules don't seem to apply recursively
Labels: Documentation,NeedsFix

https://golang.org/pkg/fmt/#hdr-Printing reads:

> For compound objects, the elements are printed using these rules, recursively, laid out like this:
> ```
>     struct:             {field0 field1 ...}
>     array, slice:       [elem0 elem1 ...]
>     maps:               map[key1:value1 key2:value2 ...]
>     pointer to above:   &{}, &[], &map[]
> ```

It is specifically said that these rules apply recursively. However, take a look at this playground link: https://play.golang.org/p/CbrniH9q45I

It currently prints:

```
{x}
&{x}
{%!s(*main.T2=&{x})}
&{%!s(*main.T2=&{x})}
```

But I'd expect it to print:

```
{x}
&{x}
{&{x}}
&{&{x}}
```

Reading the docs carefully again, I can't find a reason why only top-level pointers would follow the "pointer to above" rule that's clearly documented.

It seems to me like either the code is wrong, or the docs need clarification. If only top-level pointers are supposed to follow the "pointer to above" rule, that should be made clear in the rules.

This issue is split from #27672. I initially thought this was a bug in vet, but then started wondering if this was a bug in fmt instead.

/cc @robpike @martisch @rogpeppe
Repository: TypeScript
Issue: "Unique symbol as the name of a private method" results in invalid .d.ts declaration
Labels: Bug,Domain: Declaration Emit

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. -->
**TypeScript Version:**  3.1.6 or 3.2.0-dev.20181106

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- unique symbol
- private class method name
- private symbol bad export
- bad code generation

&nbsp;

## Use case
Using a `unique symbol` as the name of a private class method (on an exported class)

&nbsp;

## Issue
The private method is _incorrectly_ exposed in the `.d.ts` module; as in, the unique symbol is used in the `.d.ts` module but never declared.

This means the exported class cannot be used by other TypeScript packages without a compiler error.

### [_Link to repro_](https://github.com/aleclarson/repro/tree/ts-issue-28383)

&nbsp;

## Related Issues
*Unknown*
Repository: go
Issue: cmd/compile: liveness analysis conservative for compound objects
Labels: GarbageCollector,compiler/runtime

```
func f(data []byte) {
	dataSize := len(data)
	g(data)
	runtime.GC()
	global = dataSize
}

func g([]byte)

var global int
```

The compiler reports (with `-live`) that `data` is live at the `runtime.GC` call.  In fact, only the `.len` field of `data` is live at that point. But because we track liveness by variable, if any field of that variable is live whole variable is live.  This means `data` will be retained unnecessarily by the garbage collector.

The generated code contains:
```
	0x001d 00029 (tmp1.go:7)	MOVQ	"".data+40(SP), AX
	0x0022 00034 (tmp1.go:7)	MOVQ	AX, (SP)
	0x0026 00038 (tmp1.go:7)	MOVQ	"".data+48(SP), AX
	0x002b 00043 (tmp1.go:7)	MOVQ	AX, 8(SP)
	0x0030 00048 (tmp1.go:7)	MOVQ	"".data+56(SP), CX
	0x0035 00053 (tmp1.go:7)	MOVQ	CX, 16(SP)
	0x003a 00058 (tmp1.go:7)	CALL	"".g(SB)
	0x003f 00063 (tmp1.go:8)	CALL	runtime.GC(SB)
	0x0044 00068 (tmp1.go:9)	MOVQ	"".data+48(SP), AX
	0x0049 00073 (tmp1.go:9)	MOVQ	AX, "".global(SB)
```
Even though the code looks like it reads the length first, the compiler postpones that read until after the `runtime.GC` call (so it doesn't have to issue a pointless spill).

Two solutions come to mind.  One is to track liveness of individual pointer fields of variables, instead of whole variables.  That would work, but could be expensive for variables which have lots of pointer fields.  It also isn't possible to do precisely for variables which are arrays of pointers and have non-constant indexes.

The other solution is to ignore reads of scalars when doing the liveness analysis, as the results of the liveness analysis are only used by the GC. This is more of a hack but would be a simpler fix for the code in this issue.
Repository: react-native
Issue: Fix StrictMode warnings
Labels: Help Wanted :octocat:,Resolution: PR Submitted,Bug

<!--
  - [x] Review the documentation: https://facebook.github.io/react-native
  - [x] Search for existing issues: https://github.com/facebook/react-native/issues
  - [x] Use the latest React Native release: https://github.com/facebook/react-native/releases
-->

## Description
When wrapping the app with `<StrictMode>`, there are warnings coming from internal react native components. They need to be updated to stop using the [legacy context api](https://github.com/facebook/react-native/search?q=childContextTypes&unscoped_q=childContextTypes) and unsafe methods like  [UNSAFE_componentWillReceiveProps](https://github.com/facebook/react-native/search?q=UNSAFE_componentWillReceiveProps&unscoped_q=UNSAFE_componentWillReceiveProps).

Also, I believe this is a prerequisite for Concurrent Mode support.

<div>
<img width="300" src="https://user-images.githubusercontent.com/619186/48099194-f486f800-e205-11e8-97da-a45ef2f25cb4.png" />
<img width="300" src="https://user-images.githubusercontent.com/619186/48099196-f486f800-e205-11e8-9277-d3cc15d1b9b4.png" />
</div>


<details>

<summary>Environment</summary>

## Environment
  React Native Environment Info:
    System:
      OS: macOS 10.14
      CPU: x64 Intel(R) Core(TM) i5-6267U CPU @ 2.90GHz
      Memory: 33.30 MB / 16.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 8.11.4 - /usr/local/bin/node
      Yarn: 1.10.1 - ~/.yarn/bin/yarn
      npm: 6.4.1 - /usr/local/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    SDKs:
      iOS SDK:
        Platforms: iOS 12.1, macOS 10.14, tvOS 12.1, watchOS 5.1
      Android SDK:
        Build Tools: 23.0.1, 23.0.3, 24.0.3, 25.0.0, 25.0.1, 25.0.2, 25.0.3, 26.0.0, 26.0.1, 26.0.2, 26.0.3, 27.0.0, 27.0.1, 27.0.2, 27.0.3, 28.0.0, 28.0.2, 28.0.3
        API Levels: 19, 22, 23, 24, 25, 26, 27, 28
    IDEs:
      Android Studio: 3.2 AI-181.5540.7.32.5014246
      Xcode: 10.1/10B61 - /usr/bin/xcodebuild
    npmGlobalPackages:
      react-native-cli: 2.0.1
</details>
Repository: go
Issue: fmt: differing output of printf %#010x with int and string types
Labels: Documentation,NeedsInvestigation

#### What did you do?
I wanted print a padded (zeros)  and prepended (0x) string character as a hex number.

[Link to example on play.golang.org](https://play.golang.org/p/RMzu8R3Q11M)

#### What did you expect to see?
The same result for a string character and an integer.
The string printed as an hexadecimal number should be prepended with '0x'.

#### What did you see instead?
```
> A hex Number (a int) with padding:    0x0000000030
> A hex Number (a string) with padding: 0000000x30
> 
> Program exited.
```

#### System details

```
go version go1.11.2 linux/amd64
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/sebi/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/sebi/go/"
GOPROXY=""
GORACE=""
GOROOT="/usr/local/go"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
GOROOT/bin/go version: go version go1.11.2 linux/amd64
GOROOT/bin/go tool compile -V: compile version go1.11.2
uname -sr: Linux 4.15.0-38-generic
Distributor ID:	Ubuntu
Description:	Ubuntu 16.04.5 LTS
Release:	16.04
Codename:	xenial
/lib/x86_64-linux-gnu/libc.so.6: GNU C Library (Ubuntu GLIBC 2.23-0ubuntu10) stable release version 2.23, by Roland McGrath et al.
gdb --version: GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
```
Repository: electron
Issue: Allow data URLs or Object URLs to work with nodeIntegrationInWOrker
Labels: enhancement :sparkles:

If you try to make a `new Worker` with, for example, an Object URL or Data URL instead of a more normal URL like  a `file://` URL, then module resolution will not work inside the Worker.

**Example**

The following works:

```js
const path = require('path')
new Worker(path.resolve(__dirname, 'worker.js'))
```

The following should work (doesn't):

```js
const fs = require('fs')
const source = fs.readFileSync(path.resolve(__dirname, 'worker.js'), 'utf8')
const sourceUrl = URL.createObjectURL(
	new Blob([source], { type: 'text/javascript' }),
)
const worker = new Worker(sourceUrl)
```

Here's a reproduction: https://github.com/trusktr/electron-web-worker-example/tree/electron-issue-15609.

To run it:

```sh
git checkout electron-issue-15609 # use this branch
npm install
npm start
```

then look at the console and you will see

```
Uncaught Error: Cannot find module 'lodash'
```

It doesn't work because the call to `Module._resolveLookupPaths` during module load is not able to find any `node_modules` folders. I suppose the object URL isn't relative to anywhere on the filesystem, so it has no way to know where to find `node_modules`.

How can we fix this?
Repository: go
Issue: html/template: document that it strips comments
Labels: Documentation,help wanted,NeedsFix

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?

go1.11.1 (playground)

### Does this issue reproduce with the latest release?

Yes.

### What did you do?

```go
package main

import (
	"fmt"
	"html/template"
	"os"
)

const templateSrc = `<style>/* one */</style> /* two */ <!-- three -->`

func main() {
	fmt.Println(templateSrc)
	tmpl := template.Must(template.New("").Parse(templateSrc))
	fmt.Println(tmpl.Tree.Root.String())
	tmpl.Execute(os.Stdout, nil)
}
```

https://play.golang.org/p/WPnEwLYTBkF

### What did you expect to see?

Comments preserved in output.

```text
<style>/* one */</style> /* two */ <!-- three -->
<style>/* one */</style> /* two */ <!-- three -->
<style>/* one */</style> /* two */ <!-- three -->
```

### What did you see instead?

Comments are stripped.

```text
<style>/* one */</style> /* two */ <!-- three -->
<style>/* one */</style> /* two */ <!-- three -->
<style> </style> /* two */ 
```

---

This behaviour is apparently intentional (https://github.com/golang/go/issues/14256), but it is surprising and undocumented.  Templates already have their own special comment syntax (`{{/* */}}`), so i didn't expect that they would gobble up HTML and CSS (and presumably JS) comments as well. This needs to be called out in the documentation, ideally with a rationale and workaround.
Repository: pytorch
Issue: [caffe2] How to export onnx model trained on Detectron in Caffe2?
Labels: caffe2
Repository: rust
Issue: Distributed libLLVM conflicts with system libraries
Labels: A-linkage,A-LLVM,T-compiler

Now that `libLLVM.so` is distributed with rust, we are unable to dynamically link a rust binary against a different `libLLVM.so` library. The rustlib directory containing `libLLVM` is prepended to the linker search path, and I don't see a good way to ask cargo to add a search path earlier than the rustlib is added. It looks to me like the rustlib directory is added here: https://github.com/rust-lang/rust/blob/15d770400eed9018f18bddf83dd65cb7789280a5/src/librustc_codegen_llvm/back/link.rs#L1044

I noticed that support for appending a suffix to the LLVM libs was added in https://github.com/rust-lang/rust/pull/53987. Can we turn that on for CI so the prebuilt distributions have a suffix on the library?

Unfortunately, the suffix won't actually fix this issue on MacOS, since the LLVM build does not append the suffix (or any version info) to the name of the dynamic library when building on MacOS: (see https://github.com/rust-lang/llvm/blob/7051ead40a5f825878b59bf08d4e768be9e99a4a/cmake/modules/AddLLVM.cmake#L520)