sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: unsizing fails when associated types are involved
Labels: A-trait-system,T-lang,C-bug

I am trying to implement something very generic, and in the course of doing so, am using trait associated types. That, in turn, apparently doesn't allow the unsizing rules to kick in.

The following compiles fine:
```rust
#![crate_type="lib"]
use std::cell::UnsafeCell;

struct Foo<T: ?Sized>(UnsafeCell<T>);

impl<T> Foo<T> {
    fn new(t: T) -> Foo<T> {
        Foo(UnsafeCell::new(t))
    }
}

pub fn foo() {
    let foo: &Foo<[i32]> = &Foo::new([1,2,3]);
}
```

Now, adding some nesting in the above fails:
```rust
#![crate_type="lib"]
use std::cell::UnsafeCell;

trait Wrapper {
    type Type: ?Sized;
}

struct Wrap<T: ?Sized>(T);

impl<T: ?Sized> Wrapper for Wrap<T> {
    type Type = T;
}

struct Foo<T: Wrapper + ?Sized>(UnsafeCell<T::Type>);

impl<T> Foo<Wrap<T>> {
    fn new(t: T) -> Self {
        Foo(UnsafeCell::new(t))
    }
}

pub fn foo() {
    let foo: &Foo<Wrap<[i32]>> = &Foo::new([1,2,3]);
}
```

That fails with:
```
error[E0308]: mismatched types
  --> src/lib.rs:23:34
   |
23 |     let foo: &Foo<Wrap<[i32]>> = &Foo::new([1,2,3]);
   |                                  ^^^^^^^^^^^^^^^^^^ expected slice, found array of 3 elements
   |
   = note: expected type `&Foo<Wrap<[i32]>>`
              found type `&Foo<Wrap<[i32; 3]>>`
```

In fact, it fails similarly with a simplified version that differs even less with the original:
```rust
#![crate_type="lib"]
use std::cell::UnsafeCell;

trait Wrapper {
    type Type: ?Sized;
}

impl<T: ?Sized> Wrapper for T {
    type Type = T;
}

struct Foo<T: Wrapper + ?Sized>(UnsafeCell<T::Type>);

impl<T> Foo<T> {
    fn new(t: T) -> Self {
        Foo(UnsafeCell::new(t))
    }
}

pub fn foo() {
    let foo: &Foo<[i32]> = &Foo::new([1,2,3]);
}
```

```
error[E0308]: mismatched types
  --> src/lib.rs:21:28
   |
21 |     let foo: &Foo<[i32]> = &Foo::new([1,2,3]);
   |                            ^^^^^^^^^^^^^^^^^^ expected slice, found array of 3 elements
   |
   = note: expected type `&Foo<[i32]>`
              found type `&Foo<[i32; 3]>`
```

(In fact, the `UnsafeCell` is irrelevant, and can be removed too)
```rust
#![crate_type="lib"]
trait Wrapper {
    type Type: ?Sized;
}

impl<T: ?Sized> Wrapper for T {
    type Type = T;
}

struct Foo<T: Wrapper + ?Sized>(T::Type);

impl<T> Foo<T> {
    fn new(t: T) -> Self {
        Foo(t)
    }
}

pub fn foo() {
    let foo: &Foo<[i32]> = &Foo::new([1,2,3]);
}
```
```
error[E0308]: mismatched types
  --> src/lib.rs:19:28
   |
19 |     let foo: &Foo<[i32]> = &Foo::new([1,2,3]);
   |                            ^^^^^^^^^^^^^^^^^^ expected slice, found array of 3 elements
   |
   = note: expected type `&Foo<[i32]>`
              found type `&Foo<[i32; 3]>`
```
Repository: go
Issue: cmd/link: include DWARF declaration position for types
Labels: NeedsInvestigation,Debugging,compiler/runtime

The linker should include the declaration position for types so that we can use this information in editors and disambiguate where the types come from.

The easiest to replicate the confusion is to have a project which has multiple main packages and to try to go to a specific type declared in both those main package. In this case, the type contains only the ` main.TypeName ` information so an editor would be forced to implement additional logic to infer where the ` main ` package is located in the binary.

Thank you.
Repository: godot
Issue: RichTextLabel append_bbcode doesn't add the string to bbcode_text property
Labels: bug,confirmed,topic:gui

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 3.0.2
<!-- Specify commit hash if non-official. -->


**OS/device including version:** Linux (but probably any platform)
<!-- Specify GPU model and drivers if graphics-related. -->


**Issue description:**
<!-- What happened, and what was expected. -->
RichTextLabel *bbcode_text* field is empty during runtime no matter what changes you do to it. The display is valid though and plain *text* field contains the text as expected.

**Steps to reproduce:**
```
extends RichTextLabel

func _ready():
    append_bbcode("[color=red]red[/color]/n")
    prints("BBCODE:", bbcode_text)
```
**Expected:**
The output is:
```
[color=red]red[/color]
```
**Actual:**
The ouput is an empty string.

**NOTE:** Remote inspector shows the field is empty as well
Repository: vscode
Issue: FileSystemProvider: no way of handling permissions issues
Labels: feature-request,remote,file-io

Refs: https://github.com/Microsoft/vscode/issues/48421

**Setup:**
* clone https://github.com/bpasero/remote-fs
* F5
* click "Refresh" in the explorer
* you should see the current working directory as a remote folder using the file system provider for scheme `datei://`

I can think of 2 reasons why a permission error raises:
* user needs elevated rights to change a file or folder
* a file can be readonly (e.g. Windows) and to save it you need to first remove the readonly flag

Currently there does not seem to be a way to signal a) to save as elevated user or b) to remove the readonly flag.

I am not sure how relevant this is for any other file system provider that does not have these concepts but this is something our file service can do (via the options `overwriteReadonly` and `writeElevated`).
Repository: vscode
Issue: Revamp findFiles
Labels: feature-request,search,on-testplan,api-proposal

Hello, [`findFiles`](https://code.visualstudio.com/docs/extensionAPI/vscode-api#workspace.findFiles)'s `exclude` argument says that if you pass in `undefined`, default excludes will apply.

I have found this to not work in my extension despite my configuration being correct. Consider this piece of code:

```typescript
const files = await workspace.findFiles('**/*.md'); // https://github.com/Microsoft/vscode/issues/47645
// TODO: Figure out https://github.com/Microsoft/vscode/issues/48674
console.log(workspace.getConfiguration('search.exclude'));
for (const file of files) {
    console.log(file.fsPath);
}
```

Above, `workspace.getConfiguration('search.exclude')` returns:

```json
{
    "**/node_modules": true,
    "**/bower_components": true
  }
```

This is merged from the default settings, I never change this configuration section.

Despite that, the `workspace.findFiles('**/*.md')` (with or without `undefined` explicitly passed as a 2nd argument, shouldn't make a difference unless some weird parameter counting is going on) returns MarkDown files from my `node_modules` directory.

I do not know how to run extension debugging in a "none but this extension" mode, but I installed a published version of my extension and tried installing it alone in my Insiders instance and was able to reproduce the problem.

I am using VS Code 1.22.2 and VS Code Insiders 1.23.0-insider`.

Is there anything else I can do to debug this further?
Repository: rust
Issue: Rust cannot use universal LLVM on macOS
Labels: A-LLVM,O-macos,T-compiler,C-bug

I install Rust using [MacPorts](https://www.macports.org) on macOS.
Rust was recently [updated](https://github.com/macports/macports-ports/commit/77b2ac31e027672243e78942002737e7185ba125#diff-9b88aea0a5317f434b5fe2a6d02cb0c1) from 1.24.1 to 1.25.0.
For version 1.24.1, the Rust compiler did not seem to care if LLVM was built as a [universal binary](https://en.wikipedia.org/wiki/Universal_binary).
Starting with version 1.25.0, I get the error
> error: failed to add native library /opt/local/libexec/llvm-6.0/lib/libLLVMX86Disassembler.a: File too small to be an archive

Rust was compiled with `--llvm-root=/opt/local/libexec/llvm-6.0`.
If I reinstall LLVM so it is **not** universal, Rust compiles correctly.
There is a MacPorts [bug report](https://trac.macports.org/ticket/56351).
Repository: go
Issue: cmd/link: enable linker dead code pruning when using reflect
Labels: NeedsInvestigation,compiler/runtime

Follow-up from https://groups.google.com/d/topic/golang-nuts/syC4LpVf7sw

The link-time optimisation to prune unused methods is disabled when reflect.Value.Call() is used anywhere within a program.

With large codebases with many vendored libraries, it's hard to avoid including something which calls reflect.Value.Call(), e.g. anything that uses text/template.

This problem is causing serious bloat on kubernetes and openshift binaries.

One improvement that might be feasible is to enable pruning of methods of a type where:
- the set of packages which use that type is statically determinable (e.g., the type doesn't leak from the package set via an exported identifier), and
- no packages in the set reference reflect.Value.Call()

The intention is to be able to prune methods which are provably non-reachable from any reflect.Value.Call() callpoint.

Such an improvement may be complex but I believe the commensurate reduction in binary sizes for projects such as kubernetes make it highly worth considering.
Repository: go
Issue: cmd/compile: add bounds information from non-control ops to prove pass
Labels: Performance,compiler/runtime

Probably low priority; I'm not sure.

Some ops have strongly bounded output. For example, Ctz64 is always in [0,64], and Ctz64NonZero is in [0, 63]. Rsh by a constant also provides bounds.

The prove pass seems unaware of this. Does it / should it care? Where/how should it be added?

@rasky
Repository: go
Issue: cmd/compile: use bounds from prove pass to simplify shifts
Labels: Performance,compiler/runtime

Shifts generally require extra code to correctly handle shifting by more than the width of the value.

We have a bunch of ad hoc rewrite rules to detect and handle this. But the prove pass might be able to do a better job of this, and more simply too.

CL 109358 uses the prove pass to simplify CtzNN. Maybe we should do something similar for shifts. (And anything else?)

cc @rasky @randall77
Repository: terminal
Issue: Create exporting interface to allow more formats than just .ini
Labels: Product-Colortool,Help Wanted,Area-Settings,Issue-Task

As follow on from #19, this issue encompasses making the export feature generic through an interface like ISchemeExporter so we can export in more formats than .ini
Repository: rust
Issue: Associated types bounds seem to be ignored in generic impls
Labels: A-trait-system,C-bug,T-types

Consider the following code:
```rust
#![crate_type="lib"]

use std::marker::PhantomData;

trait Foo {
    type Type: Qux;
}

struct Bar<T>(PhantomData<T>);

trait Qux {}

impl<T: Foo> From<T::Type> for Bar<T> {
    fn from(t: T::Type) -> Self {
        Bar(PhantomData)
    }
}
```

This fails to build with:
```
error[E0119]: conflicting implementations of trait `std::convert::From<Bar<_>>` for type `Bar<_>`:
  --> src/lib.rs:13:1
   |
13 | impl<T: Foo> From<T::Type> for Bar<T> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<T> std::convert::From<T> for T;
```

This implies the compiler thinks `T::Type` might be `Bar<T>`, but because of the `Qux` bound, and the fact that there is no `impl<T> Qux for Bar<T> {}`, it's not possible.

In fact, doing some handholding works: `impl<T: Foo<Type=U>, U: Qux> From<U> for Bar<T>` yields no error and is equivalent, albeit unnecessarily verbose.
Repository: rust
Issue: Spurious "downstream crates may implement trait ..."
Labels: A-trait-system,T-compiler,C-bug

Consider the following code, close to the one in #50237:
```rust
#![crate_type="lib"]

use std::marker::PhantomData;

trait Foo {
    type Type: Qux<Self>;
}

struct Bar<T>(PhantomData<T>);

trait Qux<T> {}

impl<T: Foo<Type=U>, U: Qux<T>> From<U> for Bar<T> {
    fn from(t: U) -> Self {
        Bar(PhantomData)
    }
}
```

This fails to build with:
```
error[E0119]: conflicting implementations of trait `std::convert::From<Bar<_>>` for type `Bar<_>`:
  --> src/lib.rs:13:1
   |
13 | impl<T: Foo<Type=U>, U: Qux<T>> From<U> for Bar<T> {
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = note: conflicting implementation in crate `core`:
           - impl<T> std::convert::From<T> for T;
   = note: downstream crates may implement trait `Qux<_>` for type `Bar<_>`
```

But how can a downstream crate implement `Qux<_>` for `Bar<_>`?
Repository: flutter
Issue: Would like a benchmark tracking embedding latency
Labels: engine,c: performance,a: existing-apps,customer: dream (g3),team: benchmark,P3,team-engine,triaged-engine

Now that more folks are embedding flutter, I'm being asked for two numbers:

1.  How much time does adding Flutter to your binary affect startup time (not necessarily displaying a FlutterView at all).  Presumably this is zero or close to?

2.  How long does it take to bring a FlutterView on screen (presumably there are 2 numbers here.  one for first Flutter view and a second for any future view?)

Thoughts @mravn-google @yjbanov 

This isn't urgent, just something we should eventually track.
Repository: neovim
Issue: binding ALT (or CTRL) + function key (F1-F12) works with some $TERM but not others
Labels: bug,tui,input

- `nvim --version`: NVIM v0.3.0-1029-g48967695c, Build type: RelWithDebInfo
- Vim (version: ) behaves differently? `vim.tiny version 8.0.707`. Yes.
- Operating system/version: MX Linux 17 Horizon
- Terminal name/version: `terminator 1.90`, `xfce4-terminal 0.8.3 (Xfce 4.12)`, `GNOME Terminal 3.22.2`
- `$TERM`: `xterm-256color`
- [infocmp output](https://hastebin.com/oyozusapam.pl)
- If I hit <c-v> on the terminal and type `<M-F5>` I get this: `^[[15;3~`.
- `nnoremap <M-F53> :UUU<cr>` doesnt work either.
- [the rest of my environment](https://gist.github.com/mrbig033/63fd7f4f51b6a8ae379abae74c52aff2)

### Steps to reproduce using `nvim -u NORC`

1. open this version of nvim on any of the terminals I listed when `$TERM` variable is set to `xterm-256color` or `xterm`.
2. `:nnoremap <M-F5> echo "testing"<cr>`
3. Press `<M-F5>`
4. Echoed message is not printed.

The problem appears in every condition unless $TERM is different than `xterm-256color` or `xterm`. I tried nvim with `-u NONE`, `-u NORC`, `--no-plugins` and all of those combined. I also tried on the terminals mentioned above, as root, as root on the tty and without dotfiles. `vim.tiny` doesn't have the problem.

Unfortunately other setting as my $TERM is unacceptable, because it will breaks many things. As far as I know `xterm256color` is the only setting that is able to correctly display my nvim colorschemes and non-ascii characters.

### Output of `nvim -V3log`  in several conditions:

- `Xfce4-terminal` with `xterm-256color` (issue present):
`&term: xterm-256color`
`Description: xterm with 256 colors`
`Aliases: xterm-256color`

- `Xfce4-terminal` after the command `export TERM=xterm` (issue present):
`&term: xterm`
`Description: X11 terminal emulator`
`Aliases: xterm | `
`xterm-debian`

- `Xfce4-terminal` under `Tmux` with `$TERM = screen-256color` (issue not present):
`&term: screen-256color`
`Description: GNU Screen with 256 colors`
`Aliases: screen-256color

- `Xfce4-terminal` after the command `export TERM=xterm-color` (issue not present): 
`&term: xterm-color`
`Description: generic "ANSI" color xterm (X Window System)`
`Aliases: xterm-color`

### Actual behaviour

Mappings like <M-F5>, involving function keys in combination with others, do not work whem $TERM is set to `xterm-256color` or `xterm`.

### Expected behaviour

nvim should be able to use those mappings when the `$TERM` variable is set to `xterm-256color` or `xterm-color`. I use the former.
Repository: pytorch
Issue: [Caffe2] Is there any way to load custom operators in c++?
Labels: caffe2

It's easy to load custom operators [in Python](https://github.com/caffe2/caffe2_bhtsne). But when I wanted to load operators of a .so file in c++ by linking the .so file, I got 
```
Key already registered.
Offending key: simple
```
when I ran my binary file.
Could you please tell me how to load custom operators in c++?
Repository: vue
Issue: Vue breaks the styling when using comments in inline style attribute
Labels: improvement

### Version
2.5.16

### Reproduction link
[https://jsbin.com/gutivaf/edit?html,css,js,output](https://jsbin.com/gutivaf/edit?html,css,js,output)

### Steps to reproduce
- Add a comment inside any style attribute on an element within the Vue app instance. Example:

      ... style="color:blue; /* This is a comment */ background-color:yellow;" ...


### What is expected?
The element should have blue text on yellow background.

### What is actually happening?
The comment breaks the attribute and all the style properties *after* the comment are ignored (not coming in effect).

In the reproduction example the text is blue but the background is *not* yellow. 

---
(The JSBin contains a slightly different example. I hope you can live with that.)

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: angular
Issue: Angular Elements should keep an HTML attribute value in sync with a property value
Labels: feature,help wanted,freq3: high,area: elements,P4,feature: under consideration

<!--
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 -->
[ ] Performance issue
[X] 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
[ ] Other... Please describe:
</code></pre>

## Current behavior
<!-- Describe how the issue manifests. -->

We encountered a bug/missing feature in Angular Elements in synchronizing between the property and the HTML attribute that reference to the same variable. 

In other words, when the HTML attribute is changed using setAttribute() method, it will change the property value. However, changing the property value will not affect the HTML attribute value (please see the example below).

**Component Declaration**
```
@Component({
  selector: 'test-component',
  templateUrl: './test-component.component.html',
  styleUrls: ['./test-component.component.scss']
})
export class TestComponent implements OnInit {
  
  @Input('custom-name')
  public customName : string = "test some string";

  ngOnInit() {
  }
}
```
**Component Usage**
```
// Changing Attribute value --> affects the corresponding property
document.querySelector('test-component').setAttribute('custom-name', 'from attribute');
console.log(document.querySelector('test-component).customName); // "from attribute"

// Changing Property value --> DOSE NOT affect the corresponding attribute
document.querySelector('test-component).customName = 'from property';
console.log(document.querySelector('test-component').getAttribute('custom-name')); //"from attribute"
```

## Expected behavior
<!-- Describe what the desired behavior would be. -->

Properties and HTML Attributes should still in sync, regardless how they were changed.

**E.g.**
```
// Changing Attribute value --> affects the corresponding property
document.querySelector('test-component').setAttribute('custom-name', 'from attribute');
console.log(document.querySelector('test-component).customName); // "from attribute"

// Changing Property value --> affects the corresponding attribute
document.querySelector('test-component).customName = 'from property';
console.log(document.querySelector('test-component').getAttribute('custom-name')); //"from property"
```
Another Subject that related to the same context: Polymer creates automatically for each property an event that has the name "property-name-changed" that will be triggered, when the property is changed. Are you planning to do the same in Angular Elements?
Repository: vscode
Issue: Allow programatically un-selecting an item in a contributed tree
Labels: feature-request,api,tree-views

We can select items in the tree node with `reveal`, but we can't un-select. For an outline view that follows the users cursor, it would be good to unselect when the user moves the cursor to some empty whitespace that doesn't have a matching node.

The existing explorer treeview also does this; if you open a file that's outside of the workspace folders (or create a new untitled file) then no items are selected in the tree.
Repository: godot
Issue: Godot should add a warning symbol when a compressed emissive texture is used
Labels: topic:rendering,documentation,topic:3d

By default Godot compresses every textures in Video Ram mode, that is fine for most textures type but with an emissive if a GIProbes is used the color will be wrong. Godot should add a warning message when the texture plugged in the emissive slot is compressed, saying that the colors of the GI may be wrong and that the image should be uncompressed. An emissive map is poor in informations and low resolution so even uncompressed it will still be very optimized.

![wrong gi](https://user-images.githubusercontent.com/30020215/39307490-383b1d74-4963-11e8-9dc3-d89a4825b923.png)
Repository: pytorch
Issue: [pytorch] Not handling python reload properly
Labels: todo,module: crash,triaged

Trying to reload some modules cause crashes:

On python 2.7 (crash with ubuntu release, error messages from debug build).

```
>>> import torch
>>> reload(torch)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/home/alban/workspace/dev-pytorch/torch/__init__.py", line 288, in <module>
    from . import _torch_docs, _tensor_docs, _storage_docs
ImportError: cannot import name _torch_docs
>>> exit()
python: ../Objects/typeobject.c:2739: type_dealloc: Assertion `type->tp_flags & (1L<<9)' failed.
Aborted (core dumped)
```

```
>>> from torch import autograd
>>> reload(autograd)
terminate called after throwing an instance of 'std::runtime_error'
  what():  generic_type: cannot initialize type "ProfilerEvent": an object with that name is already defined
Aborted (core dumped)
```

@colesbury can you see an obvious reason for this? Or should I look into more details?
Repository: youtube-dl
Issue: ERROR: Unsupported URL: http://play.afreecatv.com/whiteang/embed
Labels: site-support-request

```
➜  ~  youtube-dl   --proxy socks5://127.0.0.1:1080/ -F http://play.afreecatv.com/yuna830/203150344
[generic] 203150344: Requesting header
WARNING: Falling back on generic information extractor.
[generic] 203150344: Downloading webpage
[generic] 203150344: Extracting information
[generic] embed: Requesting header
WARNING: Falling back on generic information extractor.
[generic] embed: Downloading webpage
[generic] embed: Extracting information
ERROR: Unsupported URL: http://play.afreecatv.com/yuna830/embed
➜  ~ 


```