sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: neovim
Issue: Disabling netrw disables the spelling files download suggestion
Labels: bug,enhancement,runtime,complexity:low,netrw

```
$ nvim --version
NVIM v0.2.0
Build type: Release
Compilation: /usr/bin/cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -Wconversion -DNVIM_MSGPACK_HAS_FLOAT32 -O2 -DNDEBUG -DDISABLE_LOG -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wvla -fstack-protector-strong -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -I/build/neovim/src/build/config -I/build/neovim/src/neovim-0.2.0/src -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/usr/include -I/build/neovim/src/build/src/nvim/auto -I/build/neovim/src/build/include
Compiled by builduser

Optional features included (+) or not (-): +acl   +iconv    +jemalloc +tui      
For differences from Vim, see :help vim-differences

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "/usr/share/nvim"

```
- Vim (version: ) behaves differently? no
- Operating system/version: Arch Linux
- Terminal name/version (`$TERM`): `rxvt-unicode-256color`

### Steps to reproduce

1. Put in `init.vim`:

```
let g:loaded_netrwPlugin = 1
```

Thus prevents loading netrw. In the [help file](https://github.com/neovim/neovim/blob/master/runtime/doc/pi_netrw.txt#L180), it is also suggested to `let g:loaded_netrw = 1` as well but it is not nescesarry to prove the bug.

2. run `nvim` or `vim`:

```
nvim # or vim
```
3. run inside it:
```
set spell
set spelllang=he " Just for example..
```

### Actual behaviour

`{n,}vim` don't suggest to download the spell files from public ftp server of vim.

### Expected behaviour

downloading spell files from vim's public ftp server is suggested although netrw is disabled.
Repository: angular
Issue: ngIf transition inside another animated element does not work
Labels: type: bug/fix,area: animations,freq3: high,P3

<!--
PLEASE HELP US PROCESS GITHUB ISSUES FASTER BY PROVIDING THE FOLLOWING INFORMATION.

ISSUES MISSING IMPORTANT INFORMATION MAY BE CLOSED WITHOUT INVESTIGATION.
-->

## I'm submitting a...
<!-- Check one of the following options with "x" -->
<pre><code>
[ ] Regression (a behavior that used to work and stopped working in a new release)
[x] Bug report  <!-- Please search GitHub for a similar issue or PR before submitting -->
[ ] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question
</code></pre>

## Current behavior
A transition on a :enter/:leave state change for an element with an *ngIf is not displayed if at the same time an ancestor element has another animation triggered at the same time. However, it does wait the appropriate amount of time before actually removing the element.

## Expected behavior
Both transitions should work.

## Minimal reproduction of the problem with instructions
Have a look at the following example: https://plnkr.co/edit/27EFz3h16icnh3qDzQbY?p=preview
When clicking the button what should happen is that the spacing between the two frames increases and another frame grows inside that space. However, what happens is that the other frame just pops in place ignoring the transition that is defined on it. The transition works if the animation on the first div is removed. It also works if the inside div is placed outside of the first div.

## What is the motivation / use case for changing the behavior?
It seems counterintuitive that this doesn't work.

## Environment

<pre><code>
Angular version: 4.3.5

Browser:
- [x] Chrome (desktop) version 60.0.3112.78

</code></pre>
Repository: vscode
Issue: Cannot display emoji ✔️, 🙋‍♂️
Labels: upstream,font-rendering,chromium

Steps to Reproduce:

1. Open a new file
2. Copy these two emoji ✔️❌ to it
3. See this result

![image](https://user-images.githubusercontent.com/7588612/29491952-b43f748a-859e-11e7-826b-21d147b9a598.png)

Expected ![image](https://user-images.githubusercontent.com/7588612/29542481-9ea6a2c2-870d-11e7-96c1-e5b08bcec770.png)

on Windows 10


----
> 2022.12: Edited to add a workaround:

**Workaround**. Append a color emoji font to the editor font family e.g.:
* Windows:  `Consolas, 'Courier New', monospace, 'Segoe UI Emoji'`
* MacOS: `Menlo, Monaco, 'Courier New', monospace, 'Apple Color Emoji'`
* Linux: `'Droid Sans Mono', 'monospace', monospace, 'Droid Sans Fallback', 'Noto Color Emoji'`

e.g. on macOS
* `"editor.fontFamily": "Roboto Mono, 'Apple Color Emoji'",`

or for a cross-platform solution:
* `"editor.fontFamily": "Consolas, 'Segoe UI Emoji', 'Apple Color Emoji', 'Noto Color Emoji'"`
Repository: vscode
Issue: Inline text adornments break word wrapping
Labels: feature-request,editor-wrapping

<!-- Do you have a question? Please ask it on http://stackoverflow.com/questions/tagged/vscode. -->

<!-- Use Help > Report Issues to prefill these. -->
- VSCode Version: 1.15.1
- OS Version: Windows 10 x64

Steps to Reproduce:

1. Settings:
```
    "editor.wordWrap": "on",
    "css.colorDecorators.enable": true
```
2. Code example:
```
   .form-control:focus { border-color: #141d36; box-shadow: 0 1px 1px rgba(0, 0, 0, 0.075) inset, 0 0 4px rgba(165,128,57,0.6); -webkit-box-shadow: 0 1px 1px rgba(0, 0, 0, 0.075) inset, 0 0 4px rgba(165,128,57,0.6); }
```

With colorDecorators disabled word wrapping works fine. After enabling it wordWrap completely ignores the width of added decorators and wrapes the code as they are not there what makes parts of the code to be pushed out of viewport.

I think it would be better to just underline the colors accordingly instead adding new elements next to it.
Also it would be great to add some margin between wrapped code and minimap (or whatever is on the right).

<!-- Launch with `code --disable-extensions` to check. -->
Reproduces without extensions: Yes

**Edit**: Added a screenshot to demonstrate the issue:
<img width="1072" alt="screen shot 2018-05-15 at 1 09 33 am" src="https://user-images.githubusercontent.com/8781353/40044668-f200623c-57dc-11e8-841f-a32a06e54b5a.png">
Repository: TypeScript
Issue: MethodDecorator gets TS2322/TS2315
Labels: Bug,Domain: Decorators

<!-- BUGS: Please use this template. -->
<!-- QUESTIONS: This is not a general support forum! Ask Qs at http://stackoverflow.com/questions/tagged/typescript -->
<!-- SUGGESTIONS: See https://github.com/Microsoft/TypeScript-wiki/blob/master/Writing-Good-Design-Proposals.md -->

**TypeScript Version:**  2.4.2
**Code**

```ts
export function route(method: string, path: string): MethodDecorator {
    return (target: any, name: string, descriptor: TypedPropertyDescriptor<Function>) => {
        routeManager.regeisterRoute({
            constructor: target.constructor,
            function: descriptor.value,
            method,
            path
        });
    }
}
```
```ts
export function route(method: string, path: string): MethodDecorator<Function> {
    return (target: any, name: string, descriptor: TypedPropertyDescriptor<Function>) => {
        routeManager.regeisterRoute({
            constructor: target.constructor,
            function: descriptor.value,
            method,
            path
        });
    }
}
```

**Expected behavior:**
No error
**Actual behavior:**

```
error TS2322: Type '(target: any, name: string, descriptor: TypedPropertyDescriptor<Function>) => void' is not assignable to type 'MethodDecorate
or'.
  Types of parameters 'descriptor' and 'descriptor' are incompatible.
    Type 'TypedPropertyDescriptor<T>' is not assignable to type 'TypedPropertyDescriptor<Function>'.
      Type 'T' is not assignable to type 'Function'.
```
```
error TS2315: Type 'MethodDecorator' is not generic.
```
Repository: TypeScript
Issue: Use a consistent ordering when writing union types
Labels: Suggestion,Awaiting More Feedback,Domain: Type Display

In DefinitelyTyped, `$ExpectType` assertions depend on a type having a consistent string represenation across TypeScript versions.
It looks like the ordering of union types is dependent on some implementation details that change between versions. When we output unions as strings, we should sort them in some consistent way first instead of just using whatever order we happened to use internally.

I would suggest this ordering:
* numeric literals, low to high
* string literals, low to high (by `<`)
* named types (including type aliases, enum, class and interface names), by name
* function literals: by length (`() => void` before `(x: number) => void`), then by parameter name, then by parameter type
* type literals: Sorted smallest to largest (`{ x: number }` before `{ x: number, y: number }`); and type literals of the same size should be alphabetically sorted by property (`{ a: number }`) before `{ b: number }`) or by the sorting of values (`{ s: "a" }` before `{ s: "b" }`)

Of course, another solution would be to try to handle this in `$ExpectType` by parsing out unions and allowing it if any sorting is valid. But it is strange in TS to see a string literal union displayed in a seemingly random order.
Repository: rust
Issue: "Use of undeclared type or module" doesn't detect accidental use of variable
Labels: C-enhancement,A-diagnostics,A-resolve,T-compiler,D-terse

```rust
trait Foo {
    type Bar;
    fn bar(&self) -> Self::Bar;
}

impl Foo for i32 {
    type Bar = i32;
    fn bar(&self) -> i32 {
        *self
    }
}

fn main() {
    let x = 5i32;
    let y = x::Bar;
}
```

reports

```
error[E0433]: failed to resolve. Use of undeclared type or module `x`
  --> src/main.rs:15:13
   |
15 |     let y = x::Bar;
   |             ^ Use of undeclared type or module `x`
```

Which is correct, but not helpful.

Imo this should at minimum tell the programmer that you cannot statically access elements of the variable `x`. At best it it suggests to call a method that yields a type that's reachable via `typeof(x)::Bar`.
Repository: go
Issue: runtime: audit mapfast routines for indirectvalue support
Labels: Testing,NeedsFix,compiler/runtime

On reflection, the most recent CLs I mailed suggest that mapdelete_fast* might not be handing indirect value maps correctly. I'm out of computer time for today and maybe tomorrow as well. Filing this as a reminder, and because these were newly introduced in 1.9, and if they're not well-handled, it could cause memory corruption. Should double check all routines, really.
Repository: go
Issue: net/http: Add Error Callbacks
Labels: NeedsFix,FeatureRequest

I've written a little REST server on net/http that's *supposed* to only ever return JSON contents. At least, that's what the parts I wrote do. However, there are certain errors that net/http encounters before my code is ever called. In those situations, I have no access to any code to determine what the content type and message should be for a given error. For example, take this stupid simple implementation:

    package main

    import (
    	"encoding/json"
    	"net/http"
    )

    type Server struct{}

    func (server *Server) ServeHTTP(w http.ResponseWriter, r *http.Request) {
    	w.Header().Set("Content-Type", "application/json; charset=UTF-8")
    	w.WriteHeader(http.StatusOK)
    	if err := json.NewEncoder(w).Encode(http.StatusText(http.StatusOK)); err != nil {
    		panic(err)
    	}
    }

    func main() {
    	http.ListenAndServe(":8080", &Server{})
    }

If I submit a request with borked headers (this one has a wayward newline in the `Authorization` header), my `ServeHTTP()` method is never called, presumably because there's an error when parsing the request to create the Request object:

    > curl -i -H 'Authorization: Basic hi
    there' 'http://localhost:8080/'
    HTTP/1.1 400 Bad Request
    Content-Type: text/plain; charset=utf-8
    Connection: close

    400 Bad Request

This makes complete sense to me, but if I'm creating an API with a contract to only ever return JSON, I'd like to have some way to plug into this error response and set the content-type and the body. I think the same challenge exists for `Not Found` errors. Perhaps there could be special handlers to configure these situations, similar to how Gorilla mux [provides](http://www.gorillatoolkit.org/pkg/mux#Router) an assignable `NotFoundHandler` field in its Router object?

I'm not sure exactly what a generalized interface would look like for such error handlers (methods on Handler protocol?), but some way to hook in and get some control over net/http-initiated error responses would be very useful for guaranteeing the content-type contract of a web API.
Repository: rust
Issue: Generated doc pages for types should include more info about the type's relationships
Labels: T-rustdoc,C-feature-request

It would be useful if the generated doc page for each type had an expandable section at the bottom that shows functions (incl. methods of other types) in the crate where the type appears in the function's argument types or return type to see possible uses of a type that aren't apparent from its methods and trait impls.
It could be divided into two sections, one for where the type appears as input (so you'd look at the section when you already know how to get an instance of the type), and one for where the type appears as output (for where you'd look if you want to get an instance of the type when it's constructed by another function).
Another useful thing would be to have another expandable section of other types that this type is a (public) constituent of. 
Together these sections paint a fuller picture of the the role this type plays in the crate and its relationships to everything else in the crate.
(This approach could then also be extended to inter-crate references.)

Of course it's encouraged to include info about the type's relationship in the doc comments but many crates's docs don't do that enough. Making the type's relationships more obvious in the above way would complement the doc comments.

Example: This page for [DeviceHandle](https://dcuddeback.github.io/libusb-rs/libusb/struct.DeviceHandle.html) would have a link to [Context.html::open_device_with_vid_pid](https://dcuddeback.github.io/libusb-rs/libusb/struct.Context.html#method.open_device_with_vid_pid()) and [Device::open()](https://dcuddeback.github.io/libusb-rs/libusb/struct.Device.html#method.open) and the page for [Device](https://dcuddeback.github.io/libusb-rs/libusb/struct.Device.html) would have a link to the [Iterator impl for Devices](https://dcuddeback.github.io/libusb-rs/libusb/struct.Devices.html) and the page for Devices would have a link to [DeviceList::iter()](https://dcuddeback.github.io/libusb-rs/libusb/struct.DeviceList.html#method.iter) and DeviceList would have a link to [Context::devices()](https://dcuddeback.github.io/libusb-rs/libusb/struct.Context.html#method.devices)...

Another example: [PortSettings](https://docs.rs/serial-core/0.4.0/serial_core/struct.PortSettings.html) would have a link to [SerialPort::configure()](https://docs.rs/serial-core/0.4.0/serial_core/trait.SerialPort.html#tymethod.configure).

This would make it much easier to find out all the necessary info from reading the doc.
Repository: react
Issue: Symbol Tagging for dangerouslySetInnerHTML to Help Prevent XSS
Labels: Component: DOM,Type: Discussion,React Core Team

If you're spreading props from a user provided source we have a XSS. E.g.

```js
var data = JSON.parse(decodeURI(location.search.substr(1)));

function Foo(props) {
  return <div><div {...props} /><span>{props.content}</span></div>;
}

ReactDOM.render(<Foo {...data} />, container);
```

That's already true today because this URL is now an XSS hole:
```
?{"content":"Hello","dangerouslySetInnerHTML":{"__html":"<a%20onclick=\"alert(%27p0wned%27)\">Click%20me</a>"}}
```

This is very uncommon. There are many different ways to screw up getting user data. However doing that + also spreading is unusual. We decided in #3473 that React should add an extra layer of protection for these types of mistakes. This one is __much__ more uncommon than the one in #3473 though.

You should already have a pretty centralized way of sanitizing these objects so it seems to me that adding a Symbol to this object shouldn't be that big of a deal though.

Either:

```js
{ $$typeof:Symbol.for('react.rawhtml'), __html: myHTML }
```
or:
```js
{ [Symbol.for('react.rawhtml')]: myHTML }
```
Repository: rust
Issue: Tracking issue for `#[doc(masked)]`
Labels: T-rustdoc,B-unstable,C-tracking-issue,S-tracking-needs-summary,F-doc_masked

At time of implementation, i'm not sure the utility of this outside the standard library, but in case anyone else wants to prune their documentation, here's the place to be.
Repository: rust
Issue: Crate local state for procedural macros?
Labels: A-macros,T-lang,C-feature-request,A-proc-macros

I'm tinkering a bit with procedural macros and encountered a problem that can be solved by keeping state in between proc macro invocations. 

Example from my real application: assume my `proc-macro` crate exposes two macros: `config! {}` and `do_it {}`. The user of my lib is supposed to call `config! {}` only once, but may call `do_it! {}` multiple times. But `do_it!{}` needs data from the `config!{}` invocation.

Another example: we want to write a `macro_unique_id!()` macro returning a `u64` by counting internally. 

---

How am I supposed to solve those problems? I know that somewhat-global state is usually bad. But I do see applications for crate-local state for proc macros.
Repository: rust
Issue: Expose target cpu to conditional compilation
Labels: T-lang,C-feature-request

I've recently created a crate that provides IO/microcontroller specific constants to Rust programs written for the [AVR architecture](https://github.com/avr-rust/rust).

[avrd on GitHub](https://github.com/avr-rust/avrd)
[avrd on Docs.rs](https://docs.rs/avrd)

I've made it so that there is always a `current` module in the crate root that reexports all items from a microcontroller-specific crate, depending on what CPU is being targeted.

In order to achieve this, I needed to add a `target_cpu` conditional compilation flag to my fork of the Rust compiler

https://github.com/avr-rust/rust/commit/1f5f6bd8f85e905ffb5da6389e879277f7f6b708

I would like to upstream this (with cleanups like more documentation), as it seems generally useful, but it also would make it easier to merge the fork into mainline if that were to ever happen in the future. On top of this, it would be quite a useful feature to other people who fork Rust for more esoteric architectures.

The in-tree targets don't seem to specify CPUs most of the time - looking in the `librustc_back` module, it looks like some targets set CPU to `cortex-a8`, some to a CPU name used by Sparc, but almost everything else is left blank, generic, or "x86_64", etc.

Before I file a PR, are there any glaring objections to this?
Repository: pytorch
Issue: detach_() variant that affects all past uses too
Labels: feature,module: autograd,triaged

Right now `detach_()` only modifies the current Variable, without modifying the graph in any way, which doesn't stop backprop for its previous uses. This behavior is sometimes wanted when e.g. doing BPTT and reusing some of the steps (say you do BPTT over 20 steps with stride of 2 steps).

Current behavior:
```python
a = Variable(torch.randn(2, 2), requires_grad=True)
b = a * 2
c = b * 2
b.detach_()
c.sum().backward()
assert a.grad is not None
```

Proposed fix:
```python
a = Variable(torch.randn(2, 2), requires_grad=True)
b = a * 2
c = b * 2
b.detach_(with_uses=True)
c.sum().backward()
assert a.grad is None
```

Implementation is not straightforward at this point and some parts still need to be worked out.

cc @ezyang @SsnL @albanD @zou3519 @gqchen
Repository: youtube-dl
Issue: I can't download the spanish caps from pluralsight
Labels: subtitles

Hello, thanks for this tool, i have this issue, and i don't know how to fix it, i have tried with this command line

youtube-dl --username XXXXXXXXXXXXXXXXX --password XXXXXXXXXXXXX https://www.pluralsight.com/courses/bash-shell-scripting --all-subs -o "%USERPROFILE%\Downloads\%(playlist)s\%(chapter_number)s. %(chapter)s\%(playlist_index)s. %(title)s.%(ext)s"

and it only downloads the english captions, thank you in advance.
Repository: flutter
Issue: getOffsetForCaret should return two values at an LTR/RTL boundary
Labels: a: text input,framework,a: internationalization,has reproducible steps,P2,found in release: 3.3,found in release: 3.4,team-text-input,triaged-text-input

In `editable.dart`, `getEndpointsForSelection` says:
```
      // TODO(mpcomplete): This doesn't work well at an RTL/LTR boundary.
```
Repository: go
Issue: runtime/cgo: bad debug_frame entry for crosscall2
Labels: help wanted,NeedsFix,Debugging,compiler/runtime

```
go version go1.9rc1 linux/amd64
```

```
go env:
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/a/n/go/"
GORACE=""
GOROOT="/usr/local/go19rc1"
GOTOOLDIR="/usr/local/go19rc1/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build839946921=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
```

The debug_frame entry for crosscall2 is wrong in any cgo program. 

This is crosscall2:

```
  asm_amd64.s:12	0x457cc0		4883ec58		SUBQ $0x58, SP		
  asm_amd64.s:16	0x457cc4		48895c2418		MOVQ BX, 0x18(SP)	
  asm_amd64.s:17	0x457cc9		48896c2420		MOVQ BP, 0x20(SP)	
  asm_amd64.s:18	0x457cce		4c89642428		MOVQ R12, 0x28(SP)	
  asm_amd64.s:19	0x457cd3		4c896c2430		MOVQ R13, 0x30(SP)	
  asm_amd64.s:20	0x457cd8		4c89742438		MOVQ R14, 0x38(SP)	
  asm_amd64.s:21	0x457cdd		4c897c2440		MOVQ R15, 0x40(SP)	
  asm_amd64.s:57	0x457ce2		48893424		MOVQ SI, 0(SP)		
  asm_amd64.s:58	0x457ce6		4889542408		MOVQ DX, 0x8(SP)	
  asm_amd64.s:59	0x457ceb		48894c2410		MOVQ CX, 0x10(SP)	
  asm_amd64.s:61	0x457cf0		ffd7			CALL DI			
  asm_amd64.s:64	0x457cf2		488b5c2418		MOVQ 0x18(SP), BX	
  asm_amd64.s:65	0x457cf7		488b6c2420		MOVQ 0x20(SP), BP	
  asm_amd64.s:66	0x457cfc		4c8b642428		MOVQ 0x28(SP), R12	
  asm_amd64.s:67	0x457d01		4c8b6c2430		MOVQ 0x30(SP), R13	
  asm_amd64.s:68	0x457d06		4c8b742438		MOVQ 0x38(SP), R14	
  asm_amd64.s:69	0x457d0b		4c8b7c2440		MOVQ 0x40(SP), R15	
  asm_amd64.s:72	0x457d10		4883c458		ADDQ $0x58, SP		
  asm_amd64.s:76	0x457d14		c3			RET			
```

The debug_info entry:

```
 <1><169bb>: Abbrev Number: 2 (DW_TAG_subprogram)
    <169bc>   DW_AT_name        : crosscall2
    <169c7>   DW_AT_low_pc      : 0x457cc0
    <169cf>   DW_AT_high_pc     : 0x457d15
    <169d7>   DW_AT_frame_base  : 1 byte block: 9c      (DW_OP_call_frame_cfa)
    <169d9>   DW_AT_external    : 1
 <2><169da>: Abbrev Number: 0
```

the debug_frame CIE:

```
00000000 0000000000000010 ffffffff CIE
  Version:               3
  Augmentation:          ""
  Code alignment factor: 1
  Data alignment factor: -4
  Return address column: 16

  DW_CFA_def_cfa: r7 (rsp) ofs 8
  DW_CFA_offset_extended: r16 (rip) at cfa-8
  DW_CFA_nop
```

and the debug_frame entry for crosscall2:

```
0000b4d4 000000000000001c 00000000 FDE cie=00000000 pc=0000000000457cc0..0000000000457d15
  DW_CFA_def_cfa_offset_sf: 8
  DW_CFA_advance_loc1: 84 to 0000000000457d14
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
  DW_CFA_nop
```

the cfa offset is 8, it should be 0x58 + 0x8 after the first instruction.