sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: extern crate in function body results in incorrect path suggestions.
Labels: T-compiler,C-bug,A-suggestion-diagnostics,D-invalid-suggestion

```rust
fn main() {
    extern crate num; // 0.2.1
    
    struct F<T: num::Integer>(T);
    
    fn foo<T>(_: F<T>) {}
}
```
[playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d1641035710d382c99e29dca6e17fca3)
has the following error:
```
error[E0277]: the trait bound `T: main::num::Integer` is not satisfied
 --> src/main.rs:6:18
  |
4 |     struct F<T: num::Integer>(T);
  |     ----------------------------- required by `main::F`
5 |     
6 |     fn foo<T>(_: F<T>) {}
  |                  ^^^^ the trait `main::num::Integer` is not implemented for `T`
  |
help: consider restricting this type parameter with `T: main::num::Integer`
 --> src/main.rs:6:12
  |
6 |     fn foo<T>(_: F<T>) {}
  |            ^
```

`main::num::Integer` is not a valid path. We probably want to use just `num::Integer` here instead
Repository: go
Issue: proposal: spec: disallow impossible interface-interface type assertions
Labels: LanguageChange,Proposal,Analysis,LanguageChangeReview

Now that we have introduced a vet check for this (see #4483), once we use modules to select the language version, we should disallow impossible interface-interface type assertions.

A quick refresher: Given a variable `x` of type interface `I1` with a method `m()`, and an interface `I2` with a method of the same name but different signature `m(int)`, the type assertion `x.(I2)` can never succeed because no value satisfying `I1` can also satisfy `I2`. The compiler can statically detect that this type assertion makes no sense (it will always panic or return false).
Repository: flutter
Issue: asset manifest rebuilt logic does not include additions to wildcard directories
Labels: tool,a: build,P3,team-tool,triaged-tool

Currently the asset manifest rebuild logic consists of a depfile produced from all known copied assets + the manifest itself. Unfortunately this is incorrect in the presence of wildcard directories, since the addition of a file should be picked up, but does not change the hash of any known dependencies.

To solve this without removing support for wildcards, we could create a psuedo-hash for directory inputs, which consists of a stable combination of a shallow file listing. This would also unblock unifying the debug asset manifest rebuild logic from the production build. Unfortunately we won't be able to communicate this information accurately to build systems we are embedded in (Gradle/Xcode), since these require a list of files for inputs/outputs. For Gradle, we could build special logic into the task to compute wildcard directories, but this will likely be cumbersome.

During flutter run, this is solved by calling stat on all wildcard directories. This is not feasible at build time.
Repository: go
Issue: x/website: link to signatures on Go releases and document how to validate
Labels: Documentation,Builders,NeedsInvestigation,FeatureRequest,website

On https://golang.org/dl/, there are links to each Go release, along with SHA256 checksums. However, the security of those checksums is only ensured by HTTPS. I learned recently that there are also PGP signatures for each release. So to go along with:

https://dl.google.com/go/go1.14.2.linux-amd64.tar.gz

There is also:

https://dl.google.com/go/go1.14.2.linux-amd64.tar.gz.asc

It would be great to document that fact on https://golang.org/dl/, along with instructions on how to validate the signature.
Repository: flutter
Issue: Un-merge threads when there are no mutations in the platform views and overlays.
Labels: platform-ios,engine,c: performance,a: platform-views,perf: speed,P2,team-ios,triaged-ios

Our first launch of dynamic thread merging will only un-merge the thread when there are no platform views at the current frame and next frame. No platform views also guarantees there are no overlay views.

In the future, we want to optimize this so that the threads can be un-merged while there are platform views and overlays on the scene and only keep the thread merged when there are changes in the platform views and overlays. 

The current limitation is that during preroll, we don't know if there are changes in the overlays. We should find a way to know if a platform view overlay is "added", "removed" or "changed" during preroll so we can optimize it.

@amirh @blasten
Repository: TypeScript
Issue: Allow trailing lines in multiline comment directives
Labels: Bug,Rescheduled

**TypeScript Version:**  4.0.0-dev.20200507

**Search Terms:** multiline comment directive ts-expect-error ts-ignore

**Code**

```ts
const x = 0;

/* @ts-ignore
continuing comment 
 that could be multiline*/

x();
```

**Expected behavior:**

The comment looks like a directive to ignore the `x();`'s type checking complaint.

**Actual behavior:**

Comment directive parsing only looks at the _last_ line of the comment. It should also allow the _first_ line of the comment.

I'm in favor of _not_ allowing any other lines (i.e. "middle" lines) to count as directives. Extending to allow characters after the `@ts-` has precedent from what's already allowed _(we're really just adding newlines)_. But putting characters before the `@ts-` has a precedent of not working even in single-line comments.

```tsx
/* Here we use a
@ts-ignore
 that is multiline*/
```

**Playground Link:** https://www.typescriptlang.org/play/?ssl=1&ssc=1&pln=28&pc=2#code/MYewdgzgLgBAHjAvDADAbgFAYPQCoYACUEAtAJYDmYIATgKYahhRlgCurFMoAtj3cxgYYUABYBDWKDYAbACYwARnRg9ZLGazq5sWOAAoAlGiA

**Related Issues:** Following discussion in https://github.com/microsoft/TypeScript/pull/38228#discussion_r420940329, as suggested by @sheetalkamat.
Repository: terminal
Issue: Support using the Accent Color for `cursorColor`, `selectionBackground`, etc.
Labels: Help Wanted,Area-TerminalControl,Area-Settings,Product-Terminal,Issue-Task

> 
> 
> Can there be support for the Accent Color brushes, so if I were to set my cursor or selction to my Accent Color, as it changes, that change will be reflected in Windows Terminal?

So that might need to be it's own separate feature request. The cursor and the selection are drawn in DirectX down in `TermControl`, so they work differently than a lot of the things in this spec (which are all XAML elements). 

For those, we'd need to accept something like `"cursorColor": "accent"`. When we did that, `CascadiaSettings` would know that the string isn't a "#rrggbb" color, so it could look up the color when we're building the `TerminalSettings` to pass to the `TermControl`. However, after that point, if the user changes their accent color, that wouldn't be reflected dynamically in the Terminal, until the user manually refreshes their settings.

It's not a horrible idea, but probably something we should move to it's own thread for discussion, since I don't think it really fits in with a lot of the other things in this spec.

_Originally posted by @zadjii-msft in https://github.com/microsoft/terminal/pull/5772#issuecomment-624908257_

#6338 is related.
Repository: flutter
Issue: pigeon: add constructor arguments to generated dart classes
Labels: package,team-ecosystem,p: pigeon,P3,triaged-ecosystem

right now the constructors are empty
Repository: flutter
Issue: pigeon: add nice error message if someone sends a message to an API that hasn't been setup
Labels: package,team-ecosystem,p: pigeon,P3,triaged-ecosystem
Repository: node
Issue: constants: stop exporting UV_ constants
Labels: discuss,lib / src

...and possibly other internal constants as well.

Context: #33246

Example: `os.constants` exports `UV_UDP_REUSEADDR`, which makes no sense for that module and isn't usable outside of core.

Introduced in dcccbfdc799 which turned the mostly-internal, undocumented `constants` module into something that's public and documented but apparently without reviewing whether it makes sense to export/document everything.
Repository: pytorch
Issue: torch.save incompatible with lzma file
Labels: module: serialization,triaged

## 🐛 Bug

Using the `lzma` module when opening a file for use with `torch.save` or `torch.load` does not work, when it should, since it provides file-like objects.

## To Reproduce

Steps to reproduce the behavior:

    t = torch.tensor(range(5))
    f = lzma.open('tmp.xz', 'wb')
    torch.save(t, f)
    f.close()

    f = lzma.open('tmp.xz', 'rb')
    torch.load(f)

Yields `LZMAError: Input format not supported by decoder`.

## Expected behavior

No error.

## Environment

- PyTorch version: 1.5.0
- Is debug build: No
- CUDA used to build PyTorch: 10.2

- OS: Arch Linux
- GCC version: (Arch Linux 9.3.0-1) 9.3.0
- CMake version: Could not collect

- Python version: 3.8
- Is CUDA available: Yes
- CUDA runtime version: 10.0.130
- GPU models and configuration: GPU 0: GeForce GTX 1070
- Nvidia driver version: 440.82
- cuDNN version: /usr/lib/libcudnn.so.7.6.5

Versions of relevant libraries:

- [pip3] numpy==1.18.4
- [pip3] torch==1.5.0
- [pip3] torchvision==0.6.0
- [pip3] torchviz==0.0.1
- [conda] Could not collect

## Additional context

I think `torch.save` is not using the `lzma` wrapper and writing directly to the underlying file or something, since the file does not have the lzma format at all. I don't know enough about the inner workings though.

cc @SsnL
Repository: TypeScript
Issue: Array literal of union type should be convertible to union of arrays
Labels: Bug

<!-- 🚨 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 the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  v4.0.0-dev.20200505, v3.8.3

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** array union literal

**Code**

```ts
declare let x: Date | Error;
const y: Date[] | Error[] = [x];
```

**Expected behavior:**

No errors.

Array literals of unions should be contextually typed by unions of array literals.

I would also expect `[Date | Error]` to be convertible to `Date[] | Error[]`, which [also fails](https://www.typescriptlang.org/play/index.html?ssl=3&ssc=10&pln=3&pc=26#code/CYUwxgNghgTiAEEQBd4A8Bc8AiVkIB94BRGGAexgG4AoMcgOwGdV8BbABywG1d94ipCjAC68ALzxuaEbXrNUATyx8Q3MYLKV1E+Ow60gA)

**Actual behavior:**

```
Type '(Date | Error)[]' is not assignable to type 'Date[] | Error[]'.
  Type '(Date | Error)[]' is not assignable to type 'Date[]'.
    Type 'Date | Error' is not assignable to type 'Date'.
      ...
```


**Playground Link:** [Link](https://www.typescriptlang.org/play/index.html#code/CYUwxgNghgTiAEEQBd4A8Bc8AiVkIB94BRGGAexgG4AoMcgOwGdUBPLXfAbQF14jSFGL3gBeeFzQ9aQA)

**Motivating real-life(-ish) example**: [Link](https://www.typescriptlang.org/play/index.html?ts=4.0.0-dev.20200505#code/CYUwxgNghgTiAEAzArgOzAFwJYHtXy1VRBgBUALQgcwAoAPALngBEoMQBtAXXgB94AojBg4Y3AJQBuAFDSU6bHng5k7MpVS1GLNgn5CRMcfADe0+BfgB6K-AB0D85cLF11GhzpcpTizfuOAL5AA)
Repository: svelte
Issue: Observer still called when unsubscribed during store update
Labels: awaiting submitter,stale-bot

https://svelte.dev/repl/703dd3e1045543388fd5583c489bac55?version=3.22.2
```js
const store = writable(0);
let is2cancelled = false;
const cancel_sub1 = store.subscribe((v) => {
	if(v === 1){
		cancel_sub2()
		is2cancelled = true
	}
});
const cancel_sub2 = store.subscribe((v) => {
	if(v === 1 && is2cancelled){
		console.log('I have been cancelled already');
	}
});
store.set(1); // logs 'I have been cancelled already'
cancel_sub1();
```
will fix with #4742 unless someone thinks this behavior is expected ?
Repository: pytorch
Issue: Special methods on torchscript custom class
Labels: oncall: jit,triaged

## 🚀 Feature

Allow torchscript custom extension class to define Python special methods such as `__len__` and `__getitem__`.

## Motivation

We are implementing torchscript-able Sentence Piece in torchtext. https://github.com/pytorch/text/pull/755
`__len__` and `__getitem__` are useful when building NLP pipeline.

The official Sentence Piece Python binding uses Swig to define `__len__` and `__getitem__`.

## Pitch

It would be nice if we can do `len` and indexing when encoding the input text.

## Alternatives

 I tried 
```
static auto sentencepiece =
    torch::class_<SentencePiece>("torchtext", "SentencePiece")
    .def(torch::init())
    .def("__len__", [](const c10::intrusive_ptr<SentencePiece>& self) {
                       return (int64_t)self->processor_.GetPieceSize();})
```

but got error

```
E       TypeError: object of type 'torch._C.ScriptObject' has no len()
```

cc @suo
Repository: pytorch
Issue: JIT compilation of NamedTuple Containing a NamedTuple fails
Labels: oncall: jit,triaged

## 🐛 Bug

When creating a Class inherited from NamedTuple which contains a member which is a type of a different class inherited from NamedTuple, jit compiler fails at resolving the type.

## To Reproduce

<img width="815" alt="Screen Shot 2020-05-06 at 5 58 42 PM" src="https://user-images.githubusercontent.com/20385914/81243189-fc268900-8fc3-11ea-8412-f9d282e7260e.png">


## Expected behavior

Recursively resolve the datatype for all the members in named_tuple. Functions compiled with jit can take input that are type of class inherited from NamedTuple which contains a member that as a NamedTuple.

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.

Collecting environment information...
PyTorch version: 1.4.0a0+7f73f1d.atg.3
Is debug build: No
CUDA used to build PyTorch: 10.1

OS: Ubuntu 18.04.4 LTS
GCC version: (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0
CMake version: Could not collect

Python version: 3.7
Is CUDA available: Yes
CUDA runtime version: Could not collect
GPU models and configuration: GPU 0: GeForce GTX 1080
Nvidia driver version: 430.64
cuDNN version: Could not collect

Versions of relevant libraries:
[pip] Could not collect
[conda] Could not collect
## Additional context

<!-- Add any other context about the problem here. -->


cc @suo
Repository: TypeScript
Issue: Better type printing for JSX IntrinsicElements
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker.

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ, especially the "Common Feature Requests" section: https://github.com/Microsoft/TypeScript/wiki/FAQ

-->

## Search Terms
JSX IntrinsicElements print

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion
When printing JSX IntrinsicElements related types, prefer the tag name


<!-- A summary of what you'd like to see added or changed -->

## Use Cases

<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples

```ts
const z1 = <a class="" />;
```
Now:
```
Type '{ class: string; }' is not assignable to type 'DetailedHTMLProps<AnchorHTMLAttributes<HTMLAnchorElement>, HTMLAnchorElement>'.
```

Suggest:

```
Type '{ class: string; }' is not assignable to type '<a />'.
```

This will make the error message easier to understand
<!-- Show how this would be used and what the behavior would be -->

## 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: flutter
Issue: Support `flutter attach` on iOS devices on non-macOS devices
Labels: c: new feature,platform-ios,tool,P3,team-ios,triaged-ios

It would be nice to be able to `flutter attach` to iOS devices on non-macOS devices.

This is related to #22771, but specifically for attaching.

I used to have [a patch (older, shorter)](https://gist.github.com/gabrc52/eb03009970d3baa30b0bb546e15aaa9f/bdb8acc4eaeacb61d2db1c5a87ea0e469fc84b9b) [(newer version, but longer)](https://gist.github.com/gabrc52/eb03009970d3baa30b0bb546e15aaa9f) to be able to do this, but #50252 has made listing devices Mac-only by using an XCode-specific tool.

Even if it's not possible to build iOS apps on Linux or Windows, it would still be very useful to people who don't have a Mac, since we can use tools like Codemagic to build the app. 

So, with this new feature:

* `flutter devices` would detect iOS devices on any platform, maybe with a disclaimer that `flutter run` is not supported
* `flutter run` would warn the user that it's not possible without a Mac, and would suggest using a build service like Codemagic
* `flutter attach` would work the same as with a Mac or with Android devices
* IDE/Daemon would work the same way

If a pull request to add this feature was made, considering the code adheres to the quality standards of the project, would it be merged?
Repository: pytorch
Issue: unsqueeze support for named tensors
Labels: triaged,enhancement,module: named tensor

## 🚀 Feature
I would love to be able to use unsqueeze on named tensors.

## Motivation
In my code using named tensors I end up with a lot of code that looks like: `
my_named_tensor.rename(None).unsqueeze(1).refine_names("x","y","z")
`
where the "x" and "z" are the existing names, and "y" would be the newly created dimension.

## Pitch
There seems to be an obvious extension to the API which would allow this functionality.  What I propose is as follows:  If you use the current unsqueeze API, you'll get:
`assert(my_named_tensor.unsqueeze(1).names == ("x", None, "z"))`

The new dimension will be created in the position requested, with a None name.

I'd like to go one step further, though, and add an optional name argument to unsqueeze.
`assert(my_named_tensor.unsqueeze(1,"y") == ("x","y","z"))
`

The only thing that's unclear to me is what should happen if `unsqueeze` is called with `name` on unnamed tensor.

## Alternatives
The current workaround is to rename to None and then back to a named tensor.  It's awkward.

## Additional context

I'd love to to implement this if my proposal is agreed to!


cc @zou3519
Repository: pytorch
Issue: New padding size format for F.pad, allowing named tensors and more clear syntax overall
Labels: feature,module: nn,triaged

## 🚀 Feature
This feature request is within regards to the padding size argument of `F.pad`.  From my perspective there are two deficiencies with the current format:

1. For normal tensors (not named), the current format can be very awkward.  If you're adding padding to the last dimension it's elegant.  But sometimes you're adding padding to the first or second dimension, and things can get awkward.  For instance I have code that adds padding to the second dimension of a tensor.  The unfortunate thing is that the tensor is sometimes 3d and sometimes 4d.  When you combine these situations with the awkward dimension counting from the end, you sometimes end up code like:
```
pad_size = [0 for i in range(2 * len(x.shape))]
pad_size[2*len(x.shape) - 1 - 2 * pad_dim] = padding
F.pad(x, pad_size, ...)
```

2. The more pressing issue, from my perspective, is that `F.pad`'s formatting is fundamentally incompatible with named tensors.

## Motivation

I'd like to see a more elegant way of padding both named tensors and regular tensors.

## Pitch

My proposal is to increase the expressiveness of the the padding_size argument of `F.pad`.  I propose padding_size can be one of two types:
- (tuple) in which case the current behavior is maintained.  This ensures total backward compatibility.
- (dict) in which case the padding format is `{dim: [padding_left, padding_right]}`.  `dim` could take multiple values
-- If dim is a positive int, it specifies the index of the dimension to be padded.
-- If dim is a negative int, it specifies the index from the back to be padded. `-1` would be the last dimension.
-- If dim is a string, it specifies the name of the dimension to be padded.

## Alternatives
The alternative is to continue to use `F.pad` as it's written, convert all named tensors to non-named tensors before padding, and then convert them back to named tensors afterward.

## Additional context

I'd be happy to implement this if a proposal is agreed upon.

cc @albanD @mruberry
Repository: ant-design
Issue: Remove inline styling from ant components (props)
Labels: Inactive,improvement

- [x] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### What problem does this feature solve?
Right now some components like **aside** navigation etc. have some of the styles by default in html structure, and some of them in css files. It makes the whole styling process way more complicated then it should be, and forces a front-end developer to split their work in two (by using css and props). 

### What does the proposed API look like?
Everything that relates to styling should be moved to CSS for easier and more consistent work. Elements like **aside** should not contain any inline styles when rendered and should get all styling from .css file/s.


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->