sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Suggest examples of format specifiers in error messages
Labels: C-enhancement,A-diagnostics,T-compiler,A-suggestion-diagnostics

This is [real code](https://twitter.com/Sunjay03/status/1217930353874276352) that someone I am helping learn Rust wrote today. It's a problem you could easily stare at for hours and never figure it out. Especially if you're new to using format strings. The code actually looks **correct** (from a distance).

```rust
fn main() {
    println!(":#?", vec![123]);
}
```

Here's the error message we produce:

```rust
error: argument never used
 --> src/main.rs:2:21
  |
2 |     println!(":#?", vec![123]);
  |              -----  ^^^^^^^^^ argument never used
  |              |
  |              formatting specifier missing
```

The person I was helping assumed that some formatting trait hadn't been implemented. It didn't occur to them that the format specifier was incorrect even though it said "formatting specifier missing".

I think we could help them by adding a hint or something that shows an example of a specifier whenever we say "formatting specifier missing".

Something like:

```
hint: format specifiers usually look like `{}` or `{:?}`
```

This would then help them compare against what they have and find the problem sooner.

From @estebank: ([source](https://twitter.com/ekuber/status/1217936806269710336))

> We already handle C-style formatting strings and provide an appropriate suggestion, so I think this would also be reasonable to handle this.
> ```rust
> fn main() {
>     println!("%d", 42);
> }
> ```
>
> Adding logic to [here](https://github.com/rust-lang/rust/blob/48840618382eccb8a799320c8e5d08e3b52f4c42/src/librustc_builtin_macros/format_foreign.rs) should be relatively straightforward.
>
> Also, this case should also be slightly tweaked to point at the formatting
> specifiers that *were* found:
>
> ```rust
> fn main() {
>     println!("{} :#?", 1, 42);
> }
> ```
Repository: go
Issue: cmd/compile: set prologue_end on every arch
Labels: NeedsDecision,Debugging,compiler/runtime

As of Go 1.11 and commit https://github.com/golang/go/commit/7bac2a95f65418ec18d1fb5f30ae47e91980f30c support was added to put information about the end of the function prologue into the produced DWARF information, however it currently only works for x86.

Ideally the DWARF information produced is consistent across arches. In Delve if this information is not present we have to disassemble the function in order to pattern match known function prologues in order to skip them. This is undesirable to say the least and I would like to delete that code.

Opening this issue to track adding prologue_end to the DWARF information produced on every arch.
Repository: excalidraw
Issue: Ability to Print directly from the editor
Labels: enhancement,pdf

Like Google Drive is doing it..

Generating a PDF out of it and sending it to print. Then it's up to the user to download as PDF or send it directly to printer. I'm sure people would do that just to post them somewhere on their whiteboards :)
Repository: vscode
Issue: Please address the security of vscode and plugins when opening files with secrets
Labels: under-discussion

When opening a file that contains secrets, how does vscode address security, especially as it concerns any plugins that may be installed and send those secrets to a remote URL.

See also: https://stackoverflow.com/q/47404582/172207
Repository: tensorflow
Issue: Add python dev (alpha version) for testing and building in CI
Labels: stat:awaiting tensorflower,type:feature

Add python dev in CI can efficiently avoid the problem in next release. it it can make TensorFlow always support latest python stable release.
Repository: TypeScript
Issue: Expose more internal api for making language service plugins.
Labels: Suggestion,Awaiting More Feedback

## Search Terms
language service plugin api refactor codefix vscode

## Suggestion

* `ts.refactor.registerRefactor` 
    A more standard way to make refactor rather than hook the language servies functions.
    And refactor is a rare api that I do not need to write ui code or command for vscode.
* `ts.textChanges.*`
   Use this, I can easily generate code or modify code that conform the current code format style.
   Especially you don't expose the `ts.formatting.*`
* `ts.TypeChecker.getTrueType()` `ts.TypeChecker.getFalseType()`
   The `TypeFlags.BooleanLiteral` is not enough to determine it is `true` or `false`.


## Use Cases

https://github.com/heroboy/generate-typescript-switch-case-for-enum-type-language-service-plugin

## 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: rust
Issue: Feature request: Make queries more discoverable
Labels: T-compiler,A-docs,C-feature-request,A-query-system

We already have the `rustc_queries!` macro, so we should create a script (similar to clippy's `clippy_dev update_lints`) that builds a list of queries with their arguments and description to add to the rustc guide, to make existing queries more discoverable.
Repository: go
Issue: cmd/go: add option to propagate '-D' flags to SWIG
Labels: NeedsInvestigation

Related with #18339.

When building a package using go + swig, it would be great if we could provide custom flags to swig (specially -D flags).

One example where this would be needed is when we need to pass -DSWIGWORDSIZE64 or -DSWIGWORDSIZE32 so swig can properly generate its bindings.
Repository: nvm
Issue: macOS Catalina: unable to retrieve the right shell
Labels: shell: zsh,OS: Mac OS,installing nvm: profile detection,pull request wanted

#### Operating system and version:
macOS Catalina.

#### `nvm debug` output:
as no `nvm` command becomes available, it's hard to answer this one.

#### `nvm ls` output:
as no `nvm` command becomes available, it's hard to answer this one.

#### How did you install `nvm`?
install script in readme

#### What steps did you perform?
just executed the script in the readme

#### What happened?
it couldn't find any file to put `nvm` environment variables, because no `~/.zshrc` file was there after a clean Catalina installation.

#### What did you expect to happen?
I was expecting `nvm` to check, as last resort, for `if [ "$SHELL" = "/bin/zsh" ]; then ...` and eventually create by itself the `$HOME/.zshrc` file with those entries.

#### Is there anything in any of your profile files that modifies the `PATH`?
Nope.
Repository: flutter
Issue: ListView itemExtent breaks Dismissible
Labels: framework,f: material design,f: scrolling,has reproducible steps,P2,found in release: 3.3,found in release: 3.7,team-design,triaged-design

## Steps to Reproduce
If a ListView has itemExtent, dismissible will not remove itself.

**Expected results:**
<details><summary>Click to see gif, Without ItemExtent</summary>
<img src="https://user-images.githubusercontent.com/11790350/72607194-286faa00-38ee-11ea-89f8-b1007982e4b6.gif" width="360">
</details>

**Actual results:** <!-- what did you see? -->
<details><summary>Click to see gif, With ItemExtent</summary>
<img src="https://user-images.githubusercontent.com/11790350/72607155-142bad00-38ee-11ea-9475-d641b90b5f2c.gif" width="360">
</details>


## Code Snippet
```
import 'package:flutter/material.dart';

void main() => runApp(MyApp());

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(home: MyHomePage());
  }
}

class MyHomePage extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return Scaffold(
      body: ListView(
        itemExtent: 48,
        children: <Widget>[
          Dismissible(
            background: Container(color: Colors.red),
            child: ListTile(title: Text('Item 1')),
            key: UniqueKey(),
          ),
          Dismissible(
            background: Container(color: Colors.red),
            child: ListTile(title: Text('Item 2')),
            key: UniqueKey(),
          ),
          Dismissible(
            background: Container(color: Colors.red),
            child: ListTile(title: Text('Item 3')),
            key: UniqueKey(),
          ),
        ],
      ),
    );
  }
}

```

## Flutter Doctor
```
Doctor summary (to see all details, run flutter doctor -v):
[√] Flutter (Channel master, v1.14.2-pre.34, on Microsoft Windows [Version 10.0.18363.592], locale en-US)

[√] Android toolchain - develop for Android devices (Android SDK version 29.0.2)
[√] Visual Studio - develop for Windows (Visual Studio Enterprise 2019 16.3.1)
[√] Android Studio (version 3.5)
[√] IntelliJ IDEA Community Edition (version 2019.3)
[√] Connected device (2 available)

• No issues found!
```

Thank you for any consideration Flutter team.
Repository: rust
Issue: Specialization should allow for delegation to default trait method implementation
Labels: T-lang,A-specialization,C-feature-request,F-specialization,F-associated_type_defaults

Given the following trait:
```rust
trait Trait {
    fn test(&self) { println!("default implementation"); }
}
```
To provide a default specialization on `Trait::test`, `test` must be redefined;
```rust
impl<T> Trait for T {
    default fn test(&self) { println!("default implementation"); }
}
```
However this violates the DRY principle. The solution here would be to provide a way to delegate the implementation of `test` to the already existing default implementation found in the trait definition.

Proposed syntax to allow for this delegation:
```rust
impl<T> Trait for T {
    default fn test(&self);
}
```
Repository: flutter
Issue: Allow shadow to be set on Icon 
Labels: c: new feature,framework,f: material design,c: proposal,P3,team-design,triaged-design

I'd like to give `Icon`s a shadow. `Icon` uses `RichText` which can be given a shadow through its `TextStyle` shadow property. However, `Icon` doesn't expose the property and its `TextStyle` disables inheritance for `DefaultTextStyle`.
Repository: flutter
Issue: TextField: Allow showSelectionHandles=true even if readOnly=true
Labels: a: text input,c: new feature,framework,f: material design,c: proposal,P3,team-design,triaged-design

## Use case

I'm using my own custom keyboard to input text into a text field. To prevent the default "soft input panel" (keyboard) to show on focus and other events we can use readOnly=true + showCursor=true. This is according to issue #16863 (see this commenthttps://github.com/flutter/flutter/issues/16863#issuecomment-567201637). 

This is working great for me but in text_field.dart we can find this code snippet: `_showSelectionHandles = !widget.readOnly;`. I would like to show the selection handle under the cursor at all times, even if I'm in readOnly mode.

## Proposal

Allow showSelectionHandle to work even if I'm in readOnly mode. I have tested to copy text_field.dart to a separate file in my project, rename it to e.g. TextField2 and then explicitly setting showSelectionHandles=true even if I have readOnly=true and it seems to work great.

My proposal is to allow showSelectionHandle to be set explicitly as a constructor parameter to TextField and that value should be honored even if we are in readOnly mode, e.g. my explicit value should be sent to EditableText widget.

Another alternative is to make _TextFieldState non-private and allow me to override it's behaviour. In this case it would be nice to break up the build method into more methods to more easily override a specific part, e.g. the building of the EditableText widget.

![image](https://user-images.githubusercontent.com/18122438/72615370-d00fcb00-3934-11ea-9447-7447a36afefb.png)
Repository: pytorch
Issue: torch.bartlett_window not jitable
Labels: oncall: jit,triaged

## 🐛 Bug

```
In [1]: import torch                                                                                                                                                                                      

In [2]: method = torch.bartlett_window                                                                                                                                                                    

In [3]: jit_method = torch.jit.script(method)                                                                                                                                                             
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-3-e9dbd59dab67> in <module>
----> 1 jit_method = torch.jit.script(method)

~/anaconda3/envs/audio-built/lib/python3.7/site-packages/torch/jit/__init__.py in script(obj, optimize, _frames_up, _rcb)
   1255         return torch.jit._recursive.recursive_script(obj)
   1256 
-> 1257     qualified_name = _qualified_name(obj)
   1258     if inspect.isclass(obj):
   1259         # If this type is a `nn.Module` subclass, they probably meant to pass

~/anaconda3/envs/audio-built/lib/python3.7/site-packages/torch/_jit_internal.py in _qualified_name(obj)
    694     if module_name is None:
    695         raise RuntimeError("Could not get qualified name for class '{}': "
--> 696                            "__module__ can't be None.".format(name))
    697 
    698     # if getattr(sys.modules[module_name], name) is not obj:

RuntimeError: Could not get qualified name for class 'bartlett_window': __module__ can't be None.
```

## Environment

PyTorch version: 1.4.0
Is debug build: No
CUDA used to build PyTorch: None

OS: Mac OSX 10.14.6
GCC version: Could not collect
CMake version: version 3.15.2

Python version: 3.7
Is CUDA available: No
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA

Versions of relevant libraries:
[pip3] numpy==1.16.4
[pip3] torch==1.1.0.post2
[pip3] torchvision==0.3.0
[conda] blas                      1.0                         mkl  
[conda] mkl                       2019.4                      233  
[conda] mkl-service               2.3.0            py37hfbe908c_0  
[conda] mkl_fft                   1.0.15           py37h5e564d8_0  
[conda] mkl_random                1.1.0            py37ha771720_0  
[conda] pytorch                   1.4.0                   py3.7_0    pytorch
[conda] torchaudio                0.5.0a0+2c49528          pypi_0    pypi

## Additional context

torchaudio jitability test is failing for dither, see pytorch/audio#417.

cc @suo
Repository: godot
Issue: Viewport doesn't resize with XFCE when using maximize button or using docking feature
Labels: bug,platform:linuxbsd,topic:gui

**Godot version:**
3.2.beta6
and 3.1.2.stable

**OS/device including version:**
Manjaro stable with XFCE
Kernel: 5.4.2-1-MANJARO

**Issue description:**
I have a Viewport in a ViewportContainer (set to full_rect) and set the size of the Viewport in the `process` function to the rect_size of the ViewportContainer.
This works fine when manually dragging the window size, but doesn NOT work when using the maximize button, or using the docking features of my window manager. Using `wmctrl` also leads to the same problem.
Printing the viewport.size prints the correct size, but it seems the viewport somehow simply ignores the change when using any other resizing method as dragging the window border.

*(Off topic: It would be awesome if the ViewportContainer itself would support automatically updating the viewport size)*

**Steps to reproduce:**
- Create a ViewportContainer and set to FullRect
- Add a Viewport as child
- Add a control (to demonstarte the problem) as child to the viewport and give it a background color via customStyle
- In the `_process` function do:
```
	var size = viewport_container.rect_size
	viewport.size = size
	viewport_background.rect_size = size
	print("Viewport size: ", viewport.size)
	print("Background size: ", viewport_background.rect_size)
```
- Double click the window or use the maximize button

**Minimal reproduction project:**
[Demo.zip](https://github.com/godotengine/godot/files/4077885/Demo.zip)
Repository: pytorch
Issue: Possible ProcessGroup::Work::abort correctness issue
Labels: oncall: distributed,triaged,module: rpc

## 🐛 Bug

https://github.com/pytorch/pytorch/pull/29928 added an abort API to `ProcessGroup::SendWork` and `ProcessGroup::RecvWork` that is designed to support the following functionality:

```
auto sendWork = pg.send(tensors, dst)
sendWork->wait(); // block for the write to complete
// in some separate thread of execution
sendWork->abort(); // abort the current wait
```

Semantically what happens above is that the user is able to abort blocking for a send to complete (the same functionality exists for `recvWork`, this is useful to be able to recover gracefully from errors/timeouts and shutdown the ProcessGroupAgent currently). 

One additional requirement is that the user should be able to successfully create new send/recv work items via `pg.send()` and `pg.recv()`. Right now, to do this, they would have to do:

```
sendWork->wait() // wait for the original send to complete, even though we aborted waiting for it earlier
auto nextSendWork = pg.send(new_tensors, dst)
nextSendWork->wait(); 
```

But according to the discussion in https://github.com/pytorch/pytorch/pull/32134/files, the first line above should not have to be there. 

From initial debugging, it seems that this could happen because the original send completion in gloo will correspond to the buffer associated with the original `sendWork` object, and we still need to wait on this send before being able to start another. Although currently if we remove the above line, we don't get a successful send completion. We need to dig deeper into how gloo allocates/deallocates `UnboundBuffer`s and processes send/recv completions.

Another example in code that is more clear is given by the current tests in `ProcessGroupGloo::testRecv` and `ProcessGroupGloo::testSend` that were added in this PR; https://github.com/pytorch/pytorch/pull/32134/files

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @xush6528 @osalpekar @jjlilley to provide clarity on the desired interface.
Repository: pytorch
Issue: [jit] Calling `torch.jit.script` on `@staticmethod`s which in turn call other `@staticmethod`s results in a `TypeError`
Labels: oncall: jit,triaged

## 🐛 Bug

Calling `torch.jit.script` on `@staticmethod`s that in turn call other `@staticmethod`s results in an internal error.

## To Reproduce

```Python3
class Foo:
  @staticmethod
  def bar():
    return Foo.whiz()

  @staticmethod
  def whiz():
    return 1

torch.jit.script(Foo.bar)
```

Results in `TypeError: <module '__main__'> is a built-in class`.

## Environment

Google Colab with a fresh GPU runtime on which `!pip install -q torch==1.4.0` has been run.

This is a spin off of #32300 at @driazati's request.

cc @suo
Repository: godot
Issue: Export variable not shown in inspector when using external script editor
Labels: bug,topic:gdscript,topic:editor,confirmed

**Godot version:** 3.2.rc1.mono

**OS/device including version:** Linux 5.4.12-1-MANJARO

**Issue description:**
I wrote a GDscript, not C#. 
When I save the exported variables aren't shown in the inspector.
I only can see them after I restart Godot.

**Steps to reproduce:**
- Open a project with the mono version of Godot and create a scene
- Create a node and a `GDscript` script
- Create a second `GDscript` where you put the `export` variable
- Inherit the second script in the script attached to the node
- No exported variable is shown in inspector
- Build the project
- Restart Godot and the exported variable is shown

**Minimal reproduction project:**
Create any Node, add two GDscript / one attached to the node, make an `export` variable in the script without a node and inherit the script with the variable in the script attached to the node
Repository: rust
Issue: Tracking issue for negative impls
Labels: A-trait-system,T-lang,B-unstable,C-tracking-issue,F-negative_impls,I-lang-nominated,S-tracking-impl-incomplete,S-tracking-needs-summary

Generalized negative impls were introduced in https://github.com/rust-lang/rust/pull/68004. They were split out from "opt-in builtin traits" (https://github.com/rust-lang/rust/issues/13231). 

## Work in progress

This issue was added in advance of #68004 landed so that I could reference it from within the code. It will be closed if we opt not to go this direction. A writeup of the general feature is available in [this hackmd](https://hackmd.io/2FYm23s0R-igRnTLaFoo8w), but it will need to be turned into a proper RFC before this can truly advance.

## Current plans

* [ ] Forbid conditional negative impls or negative impls for traits with more than one type parameter (https://github.com/rust-lang/rust/issues/79098)
* [ ] Forbid `!Drop` (negative impls of `Drop`)

## Unresolved questions to be addressed through design process

* What should the WF requirements be? ([Context](https://github.com/rust-lang/rust/pull/68004#discussion_r367586615))
* Should we permit combining default + negative impls like `default impl !Trait for Type { }`? ([Context](https://github.com/rust-lang/rust/pull/68004#discussion_r367588811))
Repository: TypeScript
Issue: Investigate eagerly returning more information about suggestions 
Labels: Suggestion,Awaiting More Feedback

## Problem 
Suggestions VS Code have three broad UX parts:

- Name/label. Primary identifier for a suggestion, such as `foo`.
- Details. Type information or auto import info, such as `string`.
- Documentation. Js doc info and additional details about the suggestion item

Currently VS Code only shows the details of the currently active suggestion. This can be problematic in cases like auto imports, where multiple symbols may all have the same `name`:

<img width="789" alt="Screen Shot 2020-01-17 at 11 26 30 AM" src="https://user-images.githubusercontent.com/12821956/72640392-a34fb980-391c-11ea-9d49-bbd13917e5bc.png">

This design also reflects the design of the suggestion api:

- `completionInfo`  returns the entire list of suggestions, but only includes the name
- `completionEntryDetails` returns the details and documentation for an individual suggestion

## Investigation
With https://github.com/microsoft/vscode/issues/39441, VS Code is exploring letting languages/extensions return the details part of the suggestion eagerly. This would let VS Code show details for the entire list of suggestions instead of just for the active one. In the auto import case specifically, this would likely mean showing the file paths we would import from.

We would like the typescript team's feedback on these idea and our current proposals:

- What information would be most helpful to render in the main suggestion list?
- How much overhead would returning this information add? Both in terms of message size and TS server computation time?

/cc @jrieken For VS Code apis
/cc @amcasey @minestarks for VS