sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking issue for `proc_macro::Span` inspection APIs
Labels: A-macros,T-lang,T-libs-api,B-unstable,C-tracking-issue,A-proc-macros,Libs-Tracked,S-tracking-design-concerns

This issue is intended to track a number of unstable APIs which are used to inspect the contents of a `Span` for information like the file name, byte position, manufacturing new spans, combining them, etc.

This issue tracks the `proc_macro_span` unstable feature.

### Public API

Already stabilized:

```rust
impl Span {
    pub fn source_text(&self) -> Option<String>;
}

impl Group {
    pub fn span_open(&self) -> Span;
    pub fn span_close(&self) -> Span;
}
```

To be stabilized, probably in their current form:

```rust
impl Span {
    pub fn line(&self) -> usize;
    pub fn column(&self) -> usize;

    pub fn start(&self) -> Span;
    pub fn end(&self) -> Span;
}
```

To be stabilized after some (re)design or discussion:

```rust
impl Span {
    pub fn source_file(&self) -> SourceFile;

    pub fn byte_range(&self) -> Range<usize>;
}

#[derive(Clone, Debug, PartialEq, Eq)]
pub struct SourceFile { .. }

impl !Send for SourceFile {}
impl !Sync for SourceFile {}

impl SourceFile {
    pub fn path(&self) -> PathBuf;
    pub fn is_real(&self) -> bool;
}
```

Things that require more discussion:

```rust
impl Span {
    pub fn eq(&self, other: &Span) -> bool;
    pub fn join(&self, other: Span) -> Option<Span>;
    pub fn parent(&self) -> Option<Span>;
    pub fn source(&self) -> Span;
}

impl Literal {
    pub fn subspan<R: RangeBounds<usize>>(&self, range: R) -> Option<Span>;
}
```
Repository: rust
Issue: Tracking issue for custom inner attributes
Labels: A-attributes,A-macros,T-lang,B-unstable,C-tracking-issue,A-proc-macros,S-tracking-design-concerns

Added in https://github.com/rust-lang/rust/pull/54093 inner attributes are not allowed to be procedural macros right now, and this issue is tracking that feature of procedural macros!

Assistance in filling in this issue would be greatly appreciated!
UPDATE: https://github.com/rust-lang/rust/issues/54726#issuecomment-431931166 below contains the detailed description.
Repository: rust
Issue: Tracking issue for procedural macros and "hygiene 2.0"
Labels: A-macros,T-lang,B-unstable,C-tracking-issue,A-proc-macros,S-tracking-needs-summary,A-hygiene

This is intended to be a tracking issue for enabling procedural macros to have "more hygiene" than the copy/paste hygiene they have today. This is a very vague tracking issue and there's a *very long* and storied history to this. The intention here though is to create a fresh tracking issue to collect the current state of play, in hopes that we can close some of the much older and very long issues which contain lots of outdated information.
Repository: rust
Issue: Wrong type inference for closure with impl Trait inside another type
Labels: A-inference,A-impl-trait

Hi.
It compiles with a type annotation as in [this code](https://play.rust-lang.org/?gist=ed9c10406b2faffd185977c4bfaf0783&version=stable&mode=debug&edition=2015).
```rust
fn work() -> impl FnMut(&u32, Option<u32>) -> bool {
    |current, msg| false
}

fn main() {}
```
This [code](https://play.rust-lang.org/?gist=b1ea9b04ab99a42820ddd9d6ab0fc8c8&version=stable&mode=debug&edition=2015) doesn't compile.
```rust
fn doesnt_work() -> Result<impl FnMut(&u32, Option<u32>) -> bool, ()> {
    Ok(|current, msg| false)
}

fn main() {}
```
error:
```
error[E0631]: type mismatch in closure arguments
 --> src/main.rs:1:28
  |
1 | fn doesnt_work() -> Result<impl FnMut(&u32, Option<u32>) -> bool, ()> {
  |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected signature of `for<'r> fn(&'r u32, std::option::Option<u32>) -> _`
2 |     Ok(|current, msg| false)
  |        -------------------- found signature of `fn(_, _) -> _`
  |
  = note: the return type of a function must have a statically known size

error[E0271]: type mismatch resolving `for<'r> <[closure@src/main.rs:2:8: 2:28] as std::ops::FnOnce<(&'r u32, std::option::Option<u32>)>>::Output == bool`
 --> src/main.rs:1:28
  |
1 | fn doesnt_work() -> Result<impl FnMut(&u32, Option<u32>) -> bool, ()> {
  |                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected bound lifetime parameter, found concrete lifetime
  |
  = note: the return type of a function must have a statically known size

error: aborting due to 2 previous errors
```

Thanks to fix this issue.
Repository: TypeScript
Issue: Distinguishing suggestions from global scope from local suggestions
Labels: Suggestion,VS Code Tracked,Experience Enhancement

From https://github.com/Microsoft/vscode/issues/59437

<!-- Please try to reproduce the issue with `typescript@next`. It may have already been fixed. --**TypeScript Version:**  3.2.0-dev.20180928

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
- TSServer
- completions
- suggestions

**Code**
For the example ts file:

```ts
class FooClass {
    toString(): void {
        |
    }
}
```

Trigger suggestions at the `|` inside the `toString` method

**Problem**
We get back two completions from `completionInfo`:

```json
     {
            "name": "toString",
            "kind": "function",
            "kindModifiers": "declare",
            "sortText": "0"
        },
        {
            "name": "toString",
            "kind": "method",
            "kindModifiers": "",
            "sortText": "0",
            "insertText": "this.toString"
        },
```

However when we then make the `completionEntryDetails` request, we can only pass  the identifier name: `"toString"`. This makes it unclear which completion entry we are actually requesting completion details for.

**Proposal**
`completionEntryDetails` already has a `source` field that is used to identify when a suggestion is an auto import. I believe that this field could also be used for global symbols, such as when a symbol name comes from a global `lib.d.ts` file. In this case, the first `toString` suggestion comes from a  global in `dom.d.ts`
Repository: create-react-app
Issue: Support scoped CSS in the same file
Labels: issue: proposal

This is kinda vague but I'd like to have a built-in option to write CSS that:

* Exists in the same file as my components
* Is scoped
* Has auto generated class names, like CSS Modules
* Extracted via the same pipeline as CSS Modules
* Could potentially use Sass (since we already support it)
* Fully static

Basically I want "CSS Modules" but without the "Modules" part. Just put it in the same file if that's the only place I use it anyway.

https://github.com/4Catalyzer/astroturf looks related. cc @jquense @markdalgleish
Repository: pytorch
Issue: .cuda() changes a module's behavior when there are registered buffers with requires_grad=True
Labels: module: autograd,module: nn,triaged

## 🐛 Bug

When a module that has a registered buffer with `requires_grad=True` is moved to the GPU, the buffer no longer accumulates gradients.

## To Reproduce

Run the code below with and without the specified line commented out:

```
import torch
from torch.autograd import Function, Variable

m = torch.nn.Module()
m.register_buffer('b', Variable(torch.ones(3), requires_grad=True)) # need the gradient
m = m.cuda() # works when this line is commented out
m.b.sum().backward()
assert m.b.grad is not None
```

## Expected behavior

I think people generally expect a module to behave the same way after it's been moved to the GPU with `.cuda()`

## Environment

Torch 0.4.1


cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @mruberry @jbschlosser
Repository: create-react-app
Issue: Static keys for vendor bundle in asset-manifest.json
Labels: issue: proposal

Currently the asset-manifest.json in my build folder looks like this:

```
{
  "main.css": "/static/css/main.f4f38731.chunk.css",
  "main.js": "/static/js/main.56255761.chunk.js",
  "main.js.map": "/static/js/main.56255761.chunk.js.map",
  "static/css/1.36ceda45.chunk.css": "/static/css/1.36ceda45.chunk.css",
  "static/js/1.ade53803.chunk.js": "/static/js/1.ade53803.chunk.js",
  "static/js/1.ade53803.chunk.js.map": "/static/js/1.ade53803.chunk.js.map",
  "runtime~main.js": "/static/js/runtime~main.229c360f.js",
  "runtime~main.js.map": "/static/js/runtime~main.229c360f.js.map",
  "static/media/icons.svg": "/static/media/icons.6e39cadf.svg",
  "static/media/logo.svg": "/static/media/logo.61c6330d.svg",
  "static/media/help_logo.svg": "/static/media/help_logo.1ef27f5c.svg",
  "static/media/help_logo_mark.svg": "/static/media/help_logo_mark.8265813a.svg",
  "static/media/youtube_icon.svg": "/static/media/youtube_icon.d435ea9a.svg",
  "static/media/guarantee_emblem.svg": "/static/media/guarantee_emblem.d49af9a1.svg",
  "static/css/main.f4f38731.chunk.css.map": "/static/css/main.f4f38731.chunk.css.map",
  "static/css/1.36ceda45.chunk.css.map": "/static/css/1.36ceda45.chunk.css.map",
  "index.html": "/index.html",
  "precache-manifest.be82c4ddabdcb9e12cd3d143baad1412.js": "/precache-manifest.be82c4ddabdcb9e12cd3d143baad1412.js",
  "service-worker.js": "/service-worker.js"
}
```

I want to be able to use this asset-manifest.json to reference and and include my own script tags.  However, the vendor bundle has dynamic keys:

```
  "static/css/1.36ceda45.chunk.css": "/static/css/1.36ceda45.chunk.css",
  "static/js/1.ade53803.chunk.js": "/static/js/1.ade53803.chunk.js",
  "static/js/1.ade53803.chunk.js.map": "/static/js/1.ade53803.chunk.js.map",
```

Is it possible to make these references something like `static/css/1.chunk.css` instead?

Using react-scripts@2.0.3
Repository: go
Issue: cmd/gofmt: incorrect indentation of comments for LabeledStmt
Labels: NeedsFix

Please answer these questions before submitting your issue. Thanks!

### What version of Go are you using (`go version`)?
`go1.11`

### Does this issue reproduce with the latest release?
Yes

### What operating system and processor architecture are you using (`go env`)?
`darwin/amd64`

### What did you do?
If a LabeledStmt has an inline comment before and after the `Colon`, then an inline comment on the previous line will be indented incorrectly:

https://play.golang.org/p/mSDEYsc_34O

This code should not change with gofmt:

```go
package main

func main() {

	/* comment */
L /* long comment */ : /* comment */
	print("foo")

	goto L

}
```

... however it changes to:

```go
package main

func main() {

			/* comment */
L /* long comment */ : /* comment */
	print("foo")

	goto L

}
```
Repository: rust
Issue: Bootstrap cargo crashes on i486 machine
Labels: T-bootstrap,A-docs,A-target-specs,O-x86_32

I have a user who sees the stage0 cargo crash:

```
running: /var/tmp/portage/dev-lang/rust-1.25.0/work/rust-stage0/bin/cargo build --manifest-path /var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/Cargo.toml --verbose --verbose --locked --frozen
Traceback (most recent call last):
  File "./x.py", line 20, in <module>
    bootstrap.main()
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 763, in main
    bootstrap()
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 743, in bootstrap
    build.build_bootstrap()
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 621, in build_bootstrap
    run(args, env=env, verbose=self.verbose)
  File "/var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/bootstrap.py", line 148, in run
    raise RuntimeError(err)
RuntimeError: failed to run: /var/tmp/portage/dev-lang/rust-1.25.0/work/rust-stage0/bin/cargo build --manifest-path /var/tmp/portage/dev-lang/rust-1.25.0/work/rustc-1.25.0-src/src/bootstrap/Cargo.toml --verbose --verbose --locked --frozen
```

(BTW, it would be nice if that error was improved to have a few more details about how the command failed to run.)

The user hypothesizes that this might be due to cargo being with SSE2, which his machine (which has an Athlon MP 2800+) does not support.

(From a [downstream bug report](https://bugs.gentoo.org/665660).)

@Mark-Simulacrum do you happen to know about this stuff?
Repository: pytorch
Issue: [Caffe2] Relink error after installing Caffe2 from conda
Labels: caffe2

Hi,

I just installed cuda-9.0, cudnn and nccl for cuda 9-0 and thereafter I followed the instructions [Caffe2](https://caffe2.ai/docs/getting-started.html?platform=ubuntu&configuration=prebuilt) to install caffe2 using conda. 

When I start `python` and enter `import caffe2.python` it does not say anything, but when executing `from caffe2.python import core` I get 

 `WARNING:root:This caffe2 python run does not have GPU support. Will run in CPU only mode.
    python: `
     `Relink /home/myname/anaconda2/lib/python2.7/site-packages/caffe2/python/../../../../././.     /liblzma.so.5' with /lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol clock_gettime'`
    `python: Relink /home/myname/anaconda2/lib/python2.7/site-packages/caffe2/python/../../../.././libopencv_core.so.3.3' with /lib/x86_64-linux-gnu/librt.so.1' for IFUNC symbol clock_gettime'`
   
   `Segmentation fault (core dumped)`

I have previously tried to build from source, but removed that installation. (As far as I know).

I installed `caffe2` by `conda install -c caffe2 caffe2-cuda-9.0-cudnn7` and I run Kubuntu 18.04.
I use a `condaenv` when I install caffe2. 

/ Erik
Repository: vscode
Issue: file icons for QuickPickItem
Labels: feature-request,quick-pick

It would be great if the QuickPickItem also can specify an icon as well as a file icon from the file icon themes.
Repository: go
Issue: x/net/websocket: Read() doesn't read the whole frame
Labels: NeedsInvestigation

The documentation for `websocket.(*Conn).Read()` states:

> `func (ws *Conn) Read(msg []byte) (n int, err error)`
> 
> Read implements the io.Reader interface: it reads data of a frame from the WebSocket connection.
> if msg is not large enough for the frame data, it fills the msg and next Read will read the rest of the
> frame data. it reads Text frame or Binary frame.

I interpret this as meaning that if msg *is* large enough, then the whole frame will be read (_exceptio probat regulam in casibus non exceptis_, the exception proves the rule).

However, in case of large frames (larger than bufio defaultBufSize) the read will always be short. Either the documentation or the implementation is wrong.

`websocket.Message.Receive()` does read the whole frame.

### What version of Go are you using (`go version`)?

go1.11

### Does this issue reproduce with the latest release?

Yes.

### What operating system and processor architecture are you using (`go env`)?

Reproduced on:
* GOOS=windows GOARCH=amd64
* GOOS=linux GOARCH=amd64

### What did you do?

I connected an `x/net/websocket` client and server, and had the server write a 5000 byte long frame using `websocket.(*Conn).Write()` and the client read it using `websocket.(*Conn).Read()`. 

Client: https://play.golang.org/p/BYtr4kSJUfu
Server: https://play.golang.org/p/LHWv9YfqsjB



### What did you expect to see?

I expected `websocket.(*Conn).Read()` to read the whole 5000 byte long frame.

### What did you see instead?

`websocket.(*Conn).Read()` read only 4092 bytes of the 5000 byte long frame.
Repository: rust
Issue: Insufficiently clear explanation of E0310
Labels: C-enhancement,A-diagnostics,A-lifetimes,T-compiler,D-confusing

The following program ([Playground](https://play.rust-lang.org/?gist=38c9aaff864faffb6c50e4fcdbb5f148&version=stable&mode=debug&edition=2015)):

```rust
pub struct Foo<T>(T, &'static str);

pub trait Bar {
    fn baz(self) -> Box<dyn Baz>;
}

pub struct Bazzzz<T>(T, &'static str);

pub trait Baz {}
impl<T> Baz for Bazzzz<T> {}

impl<T> Bar for Foo<T> {
    fn baz(self) -> Box<dyn Baz> {
        Box::new(Bazzzz(self.0, self.1))
    }
}

fn main() {}
```

errors with

```
error[E0310]: the parameter type `T` may not live long enough
  --> src/main.rs:14:9
   |
12 | impl<T> Bar for Foo<T> {
   |      - help: consider adding an explicit lifetime bound `T: 'static`...
13 |     fn baz(self) -> Box<dyn Baz> {
14 |         Box::new(Bazzzz(self.0, self.1))
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
note: ...so that the type `Bazzzz<T>` will meet its required lifetime bounds
  --> src/main.rs:14:9
   |
14 |         Box::new(Bazzzz(self.0, self.1))
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to previous error

For more information about this error, try `rustc --explain E0310`.
error: Could not compile `playground`.
```

From reading the explanation of `E0310`, which only mentions the situation in which `T` is used behind a static reference, e.g., `foo: &'static T`, I really had no idea what was going on. It seems that other people have had similar issues with this (e.g. https://stackoverflow.com/questions/40053550/the-compiler-suggests-i-add-a-static-lifetime-because-the-parameter-type-may-no ).

The explanation of E0310 should be improved to make it more clear why `T: 'static` is necessary, and what alternatives are there. 

What confused me most is that `T` was not used in any reference type of the example above, but it was only used behind a reference in the example of the error message explanation.
Repository: create-react-app
Issue: Allow patch level differences in preflight check
Labels: issue: proposal

<!--
  PLEASE READ THE FIRST SECTION :-)
-->

### Is this a bug report?

Yes, I am getting an eslint preflight check error hen I don't think I should be.

### Did you try recovering your dependencies?

Yes, I've tried deleting the package-lock and rebuilt some stuff, but this issue seems pretty clearcut 

### Which terms did you search for in User Guide?

I searched for `eslint` there and in the issues but this is for the new release and I dont' think thats updated yet

### Environment

<!--
  To help identify if a problem is specific to a platform, browser, or module version, information about your environment is required.
  This enables the maintainers quickly reproduce the issue and give feedback.

  Run the following command in your React app's folder in terminal.
  Note: The result is copied to your clipboard directly.

  `npx create-react-app --info`

  Paste the output of the command in the section below.
-->

(paste the output of the command here)

### Steps to Reproduce

To reproduce 

    create-react-app craeslint
    cd craeslint
    npm install eslint@5.6.1

I get the following. I don't think this is correct - a difference in patch version shouldn't cause the preflight check to fail, should it? (Also react-scripts should probably update their eslint version)

```
> craeslint@0.1.0 test /Users/gmauer/code/craeslint
> react-scripts test


There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "eslint": "5.6.0"

Don't try to install it manually: your package manager does it automatically.
However, a different version of eslint was detected higher up in the tree:

  /Users/gmauer/code/craeslint/node_modules/eslint (version: 5.6.1) 
```


### Expected Behavior

tests run fine - there is only a difference in patch level of eslint

### Actual Behavior

I get the following 

```
> craeslint@0.1.0 test /Users/gmauer/code/craeslint
> react-scripts test


There might be a problem with the project dependency tree.
It is likely not a bug in Create React App, but something you need to fix locally.

The react-scripts package provided by Create React App requires a dependency:

  "eslint": "5.6.0"

Don't try to install it manually: your package manager does it automatically.
However, a different version of eslint was detected higher up in the tree:

  /Users/gmauer/code/craeslint/node_modules/eslint (version: 5.6.1) 
```
Repository: godot
Issue: _Init() is not being called for C# scripts.
Labels: topic:gdscript,documentation,topic:dotnet

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
dacc3f3 and 3.1 alpha


**OS/device including version:**
Window 7 x64


**Issue description:**
`_Init()` is not being called on my c# scripts


**Steps to reproduce:**
Create a node with this script:
```csharp
using Godot;
using System;

public class InitTest : Node
{
    public override void _Init()
    {
        GD.Print("Hello World!");
    }
}
```

But when it runs no message is printed.


**Minimal reproduction project:**
[init-test.zip](https://github.com/godotengine/godot/files/2438716/init-test.zip)
Repository: rust
Issue: windows: when creating process with redirected stdio, make parent's std handles not inheritable
Labels: O-windows,A-process

Currently, if this happens:
```
use std::process::Command;
...
Command::new("child.exe")
        .stdin(Stdio::null())
        .stdout(Stdio::null())
        .stderr(Stdio::null())
        .spawn()
```
the `child.exe` accidentally inherits stdin, stdout and stderr handles of the parent process. This can be bad, because the objects these handles point to (say pipes), may be watched by some third process. 

Since at the point of creating a child process we know that it does not need our std handles (because it's explicitly being created with `Stdio::null()`), we can temporarily disable handle inheritance on these handles.
Repository: flutter
Issue: MonthPicker should be a first-class widget
Labels: c: new feature,framework,f: material design,f: date/time picker,d: api docs,P2,team-design,triaged-design

Many customer apps need an inline Calendar widget. Flutter already has a Calendar widget in the form of MonthPicker, but the documentation points people to use the [showDatePicker](https://docs.flutter.io/flutter/material/showDatePicker.html) dialog instead of using `MonthPicker` directly. 

```
/// The month picker widget is rarely used directly. Instead, consider using
/// [showDatePicker], which creates a date picker dialog.
class MonthPicker extends StatefulWidget {
  /// Creates a month picker.
  ///
  /// Rarely used directly. Instead, typically used as part of the dialog shown
  /// by [showDatePicker].
```

While @Hixie rightly points out that `MonthPicker` is an implementation detail of the dialog box, it has much broader utility and is sufficient for many calendar uses. The alternative is one of the many [calendar packages](https://pub.dartlang.org/flutter/packages?q=calendar) on pub, but they are of mixed quality and largely reimplementing what is already in the framework. It's conceivable that many of these exist either because the author was unaware of `MonthPicker` or because they were scared off by the warning message above. 

As @willlarche notes, "I don't think there's anything wrong with making it usable without a dialog." It's not a bad practice or in contravention of Material Design to use this control directly, so this issue proposed we remove or clarify the warning. 

Also note that the linked documentation for showDatePicker is no longer live -- it should probably point to https://flutter.io/widgets/material/#Input%20and%20selections or https://docs.flutter.io/flutter/material/showDatePicker.html. 

@Sfshaza this would also be a potential candidate for the Widget catalog. 

One last comment: the name of the widget is probably misleading, since it returns a day (`DateTime selectedDate`) rather than a month. Meanwhile, `DayPicker` exists, but is truly an implementation detail of `showDatePicker` because it only allows picking from within a single specified month, whereas `MonthPicker` allows selection of an arbitrary day within a given range.