sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Investigate supporting filesystem overlay in rustc
Labels: T-compiler,T-dev-tools,C-feature-request

## Rationale
This would allow us to support in-memory/patched (mainly for IDEs, maybe would be useful for build systems?) versions of source code when invoking rustc as a separate process.

While it's possible to provide a [`FileLoader`](https://github.com/rust-lang/rust/blob/00856722bad5e9d96048319fb41f4b7e249820cd/src/libsyntax/source_map.rs#L60-L61) trait implementation when [running rustc](https://github.com/rust-lang/rust/blob/9cd61f025b1b92076e69a9ef2d9233325c7d8bdc/src/librustc_driver/lib.rs#L121-L125), it requires the user to run the compiler in-process.

## Use cases
1. ~We would like to stop the RLS from depending on Clippy the library, which breaks often due to relying on rustc internals and thus is responsible for most of the RLS disappearances from nightly builds (#59761).
I can't think of how we could solve this, short of ugly build-time hacks that would somehow detect if Clippy is compilable and if so, conditionally enable it via a feature (or provide a custom Clippy shim with IPC VFS support but that'd still include the lib and thus this comes back to the original stability problem).~
EDIT: Done in  #61670.

2. Due to the current RLS' architecture, we'd like to run the compiler as a separate process to compute the analysis in parallel - right now we compile all the primary crates in the workspace in a linear fashion in order to support easy VFS access to in-memory files and to reduce save-analysis serialization overhead.
This particular case could be side-stepped by implementing IPC for our VFS implementation that could be relayed to using our FileLoader trait and rustc shim (`rls-rustc`).

## Pros
- Uniform way to provide patched versions of the file at a process level

## Cons
- This only helps dev tools use cases
- Has to be implemented and maintained
- We're not sure *yet* as to what the target architecture is for a rustc-as-a-language-server and in the long run this might not be necessary

I'd be interested in hearing your thoughts and whether we should ultimately support it.

cc'ing people that might be interested @nikomatsakis @matklad (anyone that I'm missing?)
Repository: godot
Issue: [Bullet] Raycasting a BoxShape hints round edges/artifacts
Labels: bug,confirmed,topic:physics,topic:3d

Godot 3.1

I wanted to use `BoxShape` to make cubes which I can raycast, but I quickly found that the normals I get from raycasting behave as if the cubes had round edges Oo
Not only on the edges, but also a little bit on the faces, there is a spot where normals become oblique.

![image](https://user-images.githubusercontent.com/1311555/56101541-bca28000-5f1c-11e9-9b31-1018ec38147a.png)

test project:
[BoxShapeRaycast.zip](https://github.com/godotengine/godot/files/3078022/BoxShapeRaycast.zip)

Outputting raycast normals on a texture for every pixel of the screen gives the following normal map:
![image](https://user-images.githubusercontent.com/1311555/56102573-bd8bdf80-5f25-11e9-8a0b-0cc7f238228b.png)

Same test, in Unity3D, provides a much cleaner result:
![image](https://user-images.githubusercontent.com/1311555/56103359-473dac00-5f2a-11e9-915c-9a63880779ec.png)

This does not happen with GodotPhysics either. Is that due to how Bullet was configured in Godot?

Edit: while I understand this has practical uses for collision dynamics, it doesnt feel useful for raycasts.
Repository: TypeScript
Issue: Missing string indexer on NamedNodeMap interface in lib.dom.d.ts?
Labels: Bug,Domain: lib.d.ts

For context, see https://github.com/sindresorhus/refined-github/pull/1783, specifically this commit, https://github.com/sindresorhus/refined-github/pull/1783/commits/48baae0a1952e05b35c3a93d25c854bec2f99b6f.

Also, just posting my tweet about this so that people can find discussions about the issue. See https://twitter.com/nickytonline/status/1117524648982392833

I'll restate what I tweeted as I probably should have posted my question here originally.

The NamedNodeMap interface in lib.dom.ts does not allow for a string indexer, even though vanilla JS supports this in browsers, e.g. `someDomElement.attribute['aria-label'].value`.

We have code like this in the Refined GitHub extension, so for the time being, I've gone ahead via a declaration merge for `NamedNodeMap`

```javascript
interface NamedNodeMap {
      [key: string]: Attr;
}
```

I can't tell from the [MDN docs for NamedNodeMap](https://developer.mozilla.org/en-US/docs/Web/API/NamedNodeMap) if it's standard or not. All they seem to mention is "Attr nodes' indexes may differ among browsers" which wouldn't apply to access by the attribute name.

Just wondering if this was omitted by mistake or is it because this is not considered WHATWG DOM standard? I went to https://dom.spec.whatwg.org/#interface-namednodemap and unless I'm reading it incorrectly, I believe it states that using a string indexer is valid.

Thoughts? Happy to PR this up if it's valid.
Repository: neovim
Issue: Cannot map <c-n>/<c-p> when completion is active
Labels: bug-vim,needs:discussion,mappings

<!-- Before reporting: search existing issues and check the FAQ. -->

- `nvim --version`:
```
NVIM v0.4.0-603-gd81b510ec
Build type: Debug
LuaJIT 2.1.0-beta3
Compilation: /usr/bin/cc -g -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fdiagnostics-color=auto -Wno-array-bounds -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/home/mayuanpeng/work/ncm2-ws/neovim/build/config -I/home/mayuanpeng/work/ncm2-ws/neovim/src -I/usr/include -I/home/mayuanpeng/work/ncm2-ws/neovim/build/src/nvim/auto -I/home/mayuanpeng/work/ncm2-ws/neovim/build/include
Compiled by mayuanpeng@dpu208

Features: +acl +iconv +tui 
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/home/mayuanpeng/work/ncm2-ws/local/share/nvim"

Run :checkhealth for more info
```

- Vim (version: ) behaves differently?
Vim 8.0.1453 behaves the same.

- Operating system/version:
```
NAME="Ubuntu"
VERSION="18.04.2 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.2 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
```

- Terminal name/version:
xfce4-terminal

- `$TERM`:
`xterm-256color`

### Steps to reproduce using `nvim -u NORC`

```
nvim -u NORC
:imap <c-n> 123
:call feedkeys("i\<c-r>=complete(1, ['completion1', 'completion2'])?'':''\<cr>\<c-n>")
```

### Actual behaviour

Get `completoin2` in the buffer.

### Expected behaviour

Get `completion1123` in the buffer

Note that I'll get the expected result if I replace `<c-n>` with `<c-g>`
Repository: godot
Issue: Godot prevents automatic sleeping due to the audio system
Labels: bug,confirmed,topic:audio,performance

___

***Bugsquad note:** This issue has been confirmed several times already. No need to confirm it further.*

___

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.1
<!-- Specify commit hash if non-official. -->


**OS/device including version:** Mac OSX 10.14


**Issue description:** 
The godot editor is preventing Mac's from automatically sleeping, according to the activity monitor.

<img width="973" alt="Screen Shot 2019-04-14 at 7 45 14 PM" src="https://user-images.githubusercontent.com/2387719/56104869-70d8e200-5eee-11e9-95f9-7ff7398765ef.png">


**Steps to reproduce:** Open any godot project.
Repository: flutter
Issue: Questions for porting flutter engine to a new os
Labels: engine,d: wiki,P3,team-engine,triaged-engine

Hi,
I want to port the engine to a new  **non-linux**  os(RTOS) platform and have several questions about that:
1)  Can I port the flutter engine on the rtos?
2) If can ,  which system interfaces the OS must support  for  the flutter engine.  You know the linux platform has a libc(glibc) to provide the interface for application to access the kernel's services. But in the non-linux OS, it doesn't support the entire libc functionality, such as fuchsia. Or it doesn't support libc.   So what the exact system interface the flutter engine need is  in new OS platform?
3) what’s the difference between "fml / platform" and “shell / platform” , why there has two platforms ?

Thanks,

@chinmaygarde
Repository: TypeScript
Issue: Allow `export type Foo;` as valid syntax
Labels: Suggestion,Awaiting More Feedback

## Search Terms
Exporting a type defined elsewhere. Export a defined type. Type alias circularly references itself. Can't export a type with the same name.

## Suggestion
Currently you can only export types right when you declare them:
```typescript
export type Foo = string | number;
```
But many people often use ambient files to make their types available globally throughout the project without the need to import them. This however means that the types cannot be exported directly where they define them because the file would cease to be ambient. The current way of coping with this is naming the type differently for internal use and then reexporting it with a different name:
```typescript
// in types.ts
type _Foo = string | number;

// in index.ts
export type Foo = _Foo;
```

I suggest that this inconvenience could be easily solved by allowing this syntax:
```typescript
export type Foo;
```

## Use Cases
As described above, it's useful to export types defined in ambient files.

## Examples
As above

## 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: react
Issue: Field type="email" with multiple attribute cursor jumps to start
Labels: Type: Bug,Component: DOM

<!--
  Note: if the issue is about documentation or the website, please file it at:
  https://github.com/reactjs/reactjs.org/issues/new
-->

**Do you want to request a *feature* or report a *bug*?**
Bug

**What is the current behavior?**
While adding multiple comma separated email addresses the cursor will jump to te beginning the input field. First i thought it was a [Formik](https://github.com/jaredpalmer/formik/issues/1428) issue, but it seems to be a React one.

Example pure React: https://codesandbox.io/embed/0y06zo7l8p
Example React with Formik: https://codesandbox.io/embed/k57zw7wz5
MDN docs: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/email#multiple

**What is the expected behavior?**
Cursor stays on current position.

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**
Chrome 73, Safari 12.1, Opera 60.0
React 16.7.0

Maybe #14551 related?
Repository: ant-design
Issue: TreeSelect树选择 组件，多选情况下，子节点选择后禁用，仍可在input中通过关闭，将选择后禁用的节点删除选中
Labels: 🐛 Bug,Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/wkp7xw7p47)

### Steps to reproduce
- treeData数据中将选中的目标节点禁用（通过treeData和TreeNode生成的树都有此问题）
- 打开树里面的Node 2节点，可以看到生成的Child Node3是选中禁用状态
- 直接在input中点击Child Node3标签的删除x按钮，树中之前选中的Child Node3节点状态直接设置为了未选择


### What is expected?
按照正常逻辑，选择并且禁用后的节点，不应该被input中的标签操作

### What is actually happening?
选择并且禁用的节点，在树里面是不可操作情况，但可以通过标签的删除越过禁用，然后清除了数据

| Environment | Info |
|---|---|
| antd | 3.16.3 |
| React | react |
| System | mac 10.14.4 |
| Browser | chrome 73.0.3683.103 |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: Cycle error from pretty printer with RUST_LOG
Labels: A-pretty,T-compiler,C-bug,I-cycle

*(I wasn't able to find any existing discussion, issues or PRs about this, I'd not be surprised if someone had found it already, so my bad if this isn't a new problem)*

Yesterday, I was about to take a look into #59494 (the test case for that will trigger this), running that test case with `RUST_LOG=rustc::traits` makes a cycle error happen instead of the expected ICE. I can get the ICE with just `RUST_LOG=rustc::traits::select` (IIRC), but not when I include other modules.

The cycle error comes from the pretty printer, in particular [this line](https://github.com/rust-lang/rust/blob/master/src/librustc/ty/print/pretty.rs#L547). I managed to resolve the issue, [here's the diff that fixed it](https://gist.github.com/davidtwco/2ad19e572b568bc3464563c4a13bb208) - when the pretty printer calls `predicates_of` for existential types then it ends up calling code with debug logs that print the same type, causing a cycle.

The diff above only bypasses the cycle error when `RUST_LOG=rustc::ty::subst,rustc::ty::context,rustc_typeck`, I assume it won't when you add more modules. Here's the [relevant Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/pretty.20print.20type.20debug.20log.20cycle.20error/near/163340604).
Repository: vue
Issue: Custom directive binds differs on components vs elements
Labels: bug,has workaround

### Version
2.6.10

### Reproduction link
[https://jsfiddle.net/bponomarenko/uom10qd2/](https://jsfiddle.net/bponomarenko/uom10qd2/)







### Steps to reproduce
1. Open browser console.
2. Click on Toggle button two times. 

### What is expected?
Directive will emit the same console messages when applied to DOM elements and to components (on init and after click on button).

I'm not sure what should be expected output. Either
```
bind: first comp
bind: first elem
unbind: first comp
unbind: first elem
bind: first comp
bind: first elem
```

or 

```
bind: first comp
bind: first elem
unbind: second comp
unbind: second elem
bind: first comp
bind: first elem
```

### What is actually happening?
Messages from the directive are the same on init, but different after button have been clicked.

Actual console output:
```
bind: first comp
bind: first elem
unbind: first comp
unbind: second elem
bind: second comp
bind: first elem
```

---
It seems that order in which directives are applied to DOM elements and components are different. In my setup I have custom directive which relies on some DOM attribute with configuration data. When this custom directive is bound/unbound in a "regular flow" – everything works as expected (directive binds after element attributes are updated). However when directive is bound/unbound in case of Vue "in-place patch strategey", behavior seems to be different.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: vue-element-admin
Issue: 全局配置，fixedHeader 设置为true时，引导页，圈定内容被遮挡，显示空白
Labels: not vue-element-admin bug

<!--
    注意：为更好的解决你的问题，请参考模板提供完整信息，准确描述问题，信息不全的 issue 将被关闭。

    Note: In order to better solve your problem, please refer to the template to provide complete information, accurately describe the problem, and the incomplete information issue will be closed.
-->


## Bug report（问题描述）
全局配置，fixedHeader 设置为true时，引导页，圈定内容被遮挡，显示空白

#### Steps to reproduce（问题复现步骤）
1. 全局配置，fixedHeader 设置为true
2. 进入引导页，打开引导
3. 此时即可看到问题效果


#### Screenshot or Gif（截图或动态图）
无

#### Link to minimal reproduction（最小可在线还原demo）
无
<!--
Please only use Codepen, JSFiddle, CodeSandbox or a github repo
-->

#### Other relevant information（格外信息）
- Your OS: windows 10
- Node.js version: v8.12.0
- vue-element-admin version: v4.0.1
Repository: go
Issue: crypto, x/crypto: apply golang.org/wiki/TargetSpecific policy
Labels: NeedsFix

A lot of packages need to be adapted to follow the new https://golang.org/wiki/TargetSpecific policy.

In particular, point 1 would make the generic code always available for testing, fuzzing, and analysis like https://github.com/golang/go/issues/31456#issuecomment-483104913.
Repository: pytorch
Issue: GCP Base Image Wrong CUDA Version
Labels: triaged,module: doc infra

## 🐛 Bug

Working through the suggested PyTorch GCP base image, the wrong version of CUDA was installed.

## To Reproduce

Steps to reproduce the behavior:

1. On "New Deep Learning VM deployment" select "Intel Optimized Base 9.2"
1. Deploy and SSH into the machine
1. ``nvidia-smi`` shows CUDA Version is at 10.0

## Expected behavior

The CUDA Version is correct after setting up a GCP machine.
Repository: godot
Issue: Inspector audio preview is tied to the master bus state
Labels: bug,topic:editor,confirmed

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.1 & 9612303


**Issue description:**

When trying to preview a sound resource in the inspector, no sound will come out of it.

I closed this as I found out that the audio preview is tied to the master bus state, which was muted in my project. But thinking better about it, **why** is it tied to the master bus?
Repository: rust
Issue: Support Windows kernel mode for driver development
Labels: A-linkage,O-windows,T-libs-api,T-compiler,O-windows-msvc,C-feature-request

Several people have approached me about this, and I definitely think this is an area Rust should try to support.

* [ ] Add targets for Windows kernel mode.
* [ ] Update `cc` to be able to locate kernel mode libraries instead of user mode libraries for those targets.
* [ ] Update `winapi` to link to kernel mode libraries instead of user mode libraries for those targets.
* [ ] ? `libc` ?
* [ ] ??? `std` ???
Repository: pytorch
Issue: torch.distributed.broadcast should default to current stream
Labels: oncall: distributed,triaged

## 🐛 Bug

This is the `torch.distributed` portion of #19219.

Repeated calls to `torch.distributed.broadcast` (and other distributed ops) with the NCCL backend will eat up all available GPU memory. This leads to repeated CUDA synchronizations and bad performance.

The `torch.distributed` ops should **default to the current stream** like all other PyTorch ops. DistributedDataParallel, which benefits from broadcasting in a background stream, should explicitly use a background stream (currently `ncclStream`) to keep good performance.

## To Reproduce

Here is a small repro. It should use a small amount of memory, but uses all available GPU memory (watch `nvidia-smi`):

```python
import torch
import torch.distributed as dist

def worker(rank):
    for itr in range(1000):
        x = torch.randn(int(25 * 1024 * 1024), device='cuda')  # 100 MiB
        dist.broadcast(x, src=1, async_op=False)
        del x

def main(rank, init_method, world_size):
    torch.cuda.set_device(rank)
    dist.init_process_group("nccl", init_method, rank=rank, world_size=world_size)
    worker(rank)

if __name__ == '__main__':
    init_method = 'tcp://127.0.0.1:23123'
    world_size = 2
    torch.multiprocessing.spawn(main, (init_method, world_size), nprocs=world_size)
```

## Additional context

- This wasn't an issue prior to #18465 because the distributed ops were missing calls to `record_stream`. (However, the ops behaved incorrectly and could overwrite memory that was in-use)
- Between #18465 and #19222 this led to out-of-memory errors
- After #19222 was landed, this generally does not lead to out-of-memory errors (due to synchronization, free, and retry on OOM) but still uses up all available memory

@ailzhang @teng-li @pietern @mrshenli
Repository: flutter
Issue: ImageStream's onError listener catches all errors
Labels: framework,a: quality,c: proposal,a: error message,P3,team-framework,triaged-framework

When using `ImageStream.addListener(..., onError: ...)`, the `onError` callback will be invoked with anything that's thrown, including `Error` types.  Once I add an `onError` callback, `assert` failures, for example, are no longer reported and instead get swallowed.

There is no way for callers to specify what exception types the `onError` callback should receive (for example, compare to [`Future.catchError`](https://api.dartlang.org/stable/2.2.0/dart-async/Future/catchError.html) or to [`Stream.handleError`](https://docs.flutter.io/flutter/dart-async/Stream/handleError.html) which take an additional `test` callback to filter out exceptions).

Alternatively, `ImageStream` could rethrow `Error` types instead of passing them to the `onError` callback.  That would better follow [Effective Dart's guideline on not catching `Error` types](https://www.dartlang.org/guides/language/effective-dart/usage#dont-explicitly-catch-error-or-types-that-implement-it).

(I think even better would be if `ImageErrorListener` returned a `bool` so that an `ImageStream` could iterate through all registered error callbacks and rethrow if nothing handled it.  But that'd be a breaking change so probably would be a non-starter.)

(Flutter (Channel unknown, v1.4.20-pre.10, on Linux, locale en_US.UTF-8))
Repository: flutter
Issue: Would like the ability to stop the gradle daemon from flutter tool
Labels: c: new feature,tool,t: gradle,P2,team-tool,triaged-tool

I regularly see gradle consuming nearly 700+ MB of RAM on my Linux system.  I consider that to be a lot, especially when it's sitting there doing nothing.

The path to my gradle binary is convoluted (e.g. `~/.gradle/wrapper/dists/gradle-4.4-all/9br9xq1tocpiv8o6njlyu5op1/gradle-4.4/bin/gradle`) and changes with gradle versions, so manually invoking `gradle --stop` is non-trivial.

Additionally, the `flutter` tool tries to abstract away build processes for Android (and iOS) apps, so many users might not even know what gradle is or why it's running.  Since `flutter run` started the gradle daemon, it'd be nice if the `flutter` tool also provided some mechanism to stop it.

I mentioned this in chat a few months ago. @dnfield considered disabling the gradle daemon unless the user opts in.  I suggested making `flutter stop` (possibly with a command-line option) stop the gradle daemon, but @Hixie didn't like that since it's not really what `stop` is meant for. He suggested adding a command-line option to `flutter clean` to do it.

Some other ideas:
* Automatically stop gradle if `flutter run` hasn't been used in some time. (But this would require some other daemon.  Ideally gradle would provide the ability to do this itself.)
* Automatically stop gradle when there's no longer a connected device. (But even if there is a way to be notified of this, this probably also would need some other process.)