sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: addon-docs not showing all props for styled-component
Labels: bug,compatibility with other tools,has workaround,block: argstable

**Describe the bug**

Please note this is for the **pre-release** version as styled-components were not able to be documented until [this issue](https://github.com/storybookjs/storybook/issues/10197) was resolved.

When documenting a styled-component, not all props are rendered out into the props table.

**To Reproduce**
Steps to reproduce the behavior:

1. Clone the [repro repo](https://github.com/chrisahardie/storybook-styled-component)
2. `npx sb@next upgrade --prerelease`
3. `yarn add babel-loader --dev`
4. update the main.js stories glob from `../src/**/*.stories.(ts|tsx|js|jsx|mdx)` to `../src/**/*.stories.@(ts|tsx|js|jsx|mdx)`
5. View the [button story](http://localhost:9009/?path=/docs/form-controls--button-story)
6. The props table is missing the `disabled` and `type` props

**Expected behavior**

The props table should include all props.

**Screenshots**

![image](https://user-images.githubusercontent.com/2429373/90014814-abcf5f00-dc75-11ea-9fb6-d5dc636ad076.png)

**Code snippets**
```ts
// Button.tsx
interface Props {
  /**
   * Indicates if the button is disabled
   */
  disabled?: boolean;
  /**
   * Type of button
   */
  type: "submit" | "button" | "reset";
}

/**
 * Button component
  * @returns a button component
 */
export const Button = styled.button.attrs<Props>((props) => ({
  type: props.type
}))`
  ...
`
```

**System:**
```
Environment Info:

  System:
    OS: Windows 10 10.0.18363
    CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
  Binaries:
    Node: 12.16.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files\nodejs\yarn.CMD
    npm: 6.13.4 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 84.0.4147.105
    Edge: Spartan (44.18362.449.0)
  npmPackages:
    @storybook/addon-actions: ^6.0.2 => 6.0.2
    @storybook/addon-docs: ^6.0.2 => 6.0.2
    @storybook/addon-links: ^6.0.2 => 6.0.2
    @storybook/addons: ^6.0.2 => 6.0.2
    @storybook/preset-create-react-app: ^3.1.4 => 3.1.4
    @storybook/react: ^6.0.2 => 6.0.2
```
Repository: pytorch
Issue: Add typing information into variable declarations for JIT script ".code" output
Labels: oncall: jit,feature,triaged,days

Python does support adding typing information at variable declaration site (even if it's always FloatTensor/LongTensor). It would be good for better code inspection and comprehension

Compare (pay attention to typing in variable declaration):
```
graph(%self : __torch__.decoder.transformer.modules.decoder.AcousticTransformerDecoder,
      %tensor.1 : Tensor):
  %20 : bool = prim::Constant[value=0]()
  %14 : int = prim::Constant[value=-1]() #  ...
  %6 : None = prim::Constant()
  %3 : int = prim::Constant[value=0]() #  ...
  %12 : int = prim::Constant[value=1]() #  ...
  %dim.1 : int = aten::size(%tensor.1, %3) #  ...
  %arange.1 : Tensor = aten::arange(%dim.1, %6, %6, %6, %6) #  ...
  %15 : Tensor = aten::unsqueeze(%arange.1, %14) #  ...
  %19 : int[] = prim::ListConstruct(%14, %dim.1)
  %21 : Tensor = aten::expand(%15, %19, %20) # ...
  %24 : Tensor = aten::sub(%arange.1, %12, %12) #... 
  %_future_mask.1 : Tensor = aten::gt(%21, %24) #  ...
  %31 : Tensor = aten::to(%_future_mask.1, %tensor.1, %20, %20, %6) #  ...
  %_future_mask.3 : Tensor = aten::log(%31) #  ...
  %36 : Tensor = aten::slice(%_future_mask.3, %3, %3, %dim.1, %12) #  ...
  %39 : Tensor = aten::slice(%36, %12, %3, %dim.1, %12) #  ...
  return (%39)
``` 

and

```
def buffered_future_mask(self,
    tensor: Tensor) -> Tensor:
  dim = torch.size(tensor, 0)
  arange = torch.arange(dim, dtype=None, layout=None, device=None, pin_memory=None)
  _0 = torch.expand(torch.unsqueeze(arange, -1), [-1, dim], implicit=False)
  _future_mask = torch.gt(_0, torch.sub(arange, 1, 1))
  _1 = torch.to(_future_mask, tensor, False, False, None)
  _future_mask0 = torch.log(_1)
  _2 = torch.slice(_future_mask0, 0, 0, dim, 1)
  return torch.slice(_2, 1, 0, dim, 1)
```

cc @suo @gmagogsfm
Repository: rust
Issue: expected suffix token in proc macro
Labels: P-medium,T-compiler,regression-from-stable-to-stable,C-bug,E-needs-mcve,A-proc-macros

Picked up by the beta crater run 

* https://crater-reports.s3.amazonaws.com/beta-1.46-rustdoc-1/beta-2020-07-24/gh/retro486.task-progress/log.txt
* https://crater-reports.s3.amazonaws.com/beta-1.46-1/beta-2020-07-24/reg/woff2-sys-0.0.1/log.txt
* https://crater-reports.s3.amazonaws.com/beta-1.46-1/beta-2020-07-24/reg/static_map_macros-0.2.0-beta/log.txt

I've not attempted to reproduce these locally, but they don't look spurious.
Repository: terminal
Issue: wt --help should print text to terminal, instead of popping open a modal dialog ("Add a CLI executable for interacting with WT")
Labels: Issue-Feature,Product-Terminal,Area-Commandline

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement

When I run the `wt` command with the `--help` parameter, a modal dialog is popped up containing the help text. Instead, I would expect that the help text is printed directly to the terminal and immediately returns control to the user.

The modal dialog is visually disruptive to the terminal workflow, as it appears outside the bounds of the terminal window and doesn't match the terminal styling.

![image](https://user-images.githubusercontent.com/466713/90035611-3a94a980-dc7f-11ea-8403-77f2d127be82.png)


# Proposed technical implementation details (optional)

n/a
Repository: pytorch
Issue: Legacy Python2 and early Python3 leftovers
Labels: triaged,better-engineering,shadow review,OSS contribution wanted

1. A lot of references to Python 2 and workarounds: https://github.com/pytorch/pytorch/blob/master/torch/tensor.py
2. L631:
```
        if array.dtype == bool:
            # Workaround, torch has no built-in bool tensor
            array = array.astype('uint8')
```
But PyTorch has built-in bool tensor since a long while

cc @ezyang
Repository: node
Issue: "Support" static import in repl
Labels: repl,esm

Right now we can only support dynamic import in the repl as the repl is running in the script goal (rather than module). Currently there is experimental support in place for Top-Level Await, which is not supported in the script goal either. This is accomplished by using acorn to transpile the submitted code that is read, prior to evaluate, and wrapping stuff in an async function.

In theory we could utilize the same pipeline to transpile a static import into an `await import()`.

Thoughts?
Repository: terminal
Issue: Anti-Aliasing for powerline font icons is poor when using 12  pt or lower
Labels: Help Wanted,Area-Rendering,Issue-Bug,Product-Terminal,Priority-3,Impact-Visual

# Environment

```none
Windows build number: 19041.388
Windows Terminal version:1.1.2021.0
```

# Actual behavior
Icons in powerline fonts are blurred in the Windows Terminal using 12 pt or lower, therefore ,they are hardly recognizable 
The following sample is the Windows logo icon in Windows Terminal, Gnome Terminal on Ubuntu, and ConEmu:

![~ 8_13_2020 12_16_06 AM (2)](https://user-images.githubusercontent.com/52642831/90043510-cac60380-dcfe-11ea-98ff-68753c42795a.png)
Windows Terminal, font:3270NF, size:12pt  -  windows logo not recognizable 
![C__Windows 8_13_2020 12_29_29 AM](https://user-images.githubusercontent.com/52642831/90042089-c8fb4080-dcfc-11ea-8624-e0afb0db0146.png)
Gnome Terminal, font:UbuntuMono NF, size:12pt - windows logo recognizable
![~ 8_13_2020 12_16_12 AM](https://user-images.githubusercontent.com/52642831/90042275-0c55af00-dcfd-11ea-97e5-ab030c7b8f53.png)
ConEmu, font:3270NF, size:12pt - windows logo recognizable 

I also tested other non-terminal software:
![_Untitled - Notepad 8_13_2020 12_39_35 AM](https://user-images.githubusercontent.com/52642831/90042702-9a319a00-dcfd-11ea-9ea1-6b02f71e2195.png)
notepad.exe, font:Anonymous pro NF,size:12pt - windows logo recognizable 
![OneNote for Windows 10 8_13_2020 12_47_00 AM](https://user-images.githubusercontent.com/52642831/90043355-8fc3d000-dcfe-11ea-8633-d0cf8ee29e2b.png)
OneNote for W10 (100% resized), font:3270NF,size=12pt - windows logo recognizable
Repository: rust
Issue: Documentation pages are not displayed in Opera Mini
Labels: T-rustdoc,C-bug

[Migrated from the www.rust-lang.org repository.](https://github.com/rust-lang/www.rust-lang.org/issues/1223)

### Page(s) Affected
For example, http://doc.rust-lang.org/std/vec/struct.Vec.html (lots of them actually, probably all).

### What needs to be fixed?
It's just a typical case when Opera Mini transcoders try to execute JS, but do it partially and thus break the page at all :/
![2020-08-12-152012_1366x768_scrot](https://user-images.githubusercontent.com/2134486/90014306-7e9fa280-dcaf-11ea-9614-ac1d97c52a2a.png)
![2020-08-12-152041_1366x768_scrot](https://user-images.githubusercontent.com/2134486/90014327-8c552800-dcaf-11ea-964e-df0ba5e30673.png)
It's not even a layout problem, as the page is empty in Mobile View too.

### Suggested Improvement
The documentation is almost plain HTML by its nature, unlike brand new web apps that need bleeding edge technologies, so I see no reasons to make it inaccessible in outdated browsers.

I see non-transpilled ES6 lambdas here that cause a syntax error, but that may be only a part of the problem.

As a last resort, if the root cause is hard to find, scripts may be disabled at all for Opera Mini by detecting the `window.operamini` object. That's an ugly quirk, but there already are IE detections in the code, so why not? :)
Repository: scrcpy
Issue: Terminating scrcpy when screen is off (normally via POWER) would turn it on with all-black display
Labels: screenoff

 - [x] I have read the [FAQ](https://github.com/Genymobile/scrcpy/blob/master/FAQ.md).
 - [x] I have searched in existing [issues](https://github.com/Genymobile/scrcpy/issues).

**Environment**
 - OS: Windows
 - scrcpy version: 1.15, 1.15.1, 1.16
 - installation method: Windows release
 - device model: A: OnePlus 6, B: LeEco Max 2
 - Android version: A: 9 and B: 7.1

**Describe the bug**
A clear and concise description of what the bug is.

I launched `scrcpy` with no options except `-s SERIAL`, then turned off the phone screen via each of the following ways:

- the physical POWER button,
- the MOD + P shortcut. or
- executing `adb -s SERIAL shell input keyevent POWER`.

Specifically I didn't supply `--turn-screen-off`, `-S`, or press `MOD + o`. I terminated scrcpy while the screen is off, either by closing the window or pressing `^C` in the terminal. 

As a result, Phone B turned on with an all-black display, visible due to the backlight. For phone A, it was impossible to tell wherever the screen turned on just by looking, due to the AMOLED (or so) panel. However its 'wake on screen touch' feature was not working which is a clue phone A wasn't in its screen-off state normally. 

Both phones resumed normal after say another physical POWER press or scrcpy connection. Terminating scrcpy before turning off the screens produces no issues. V1.14 never had this issue.

I checked #1653 but it seems my case is not totally the same.

Extract of `logcat` from phone B on v1.16 (please tell me if more complete log is needed):
https://gist.github.com/automatata/b36a1ff2614125ad8d3f1e73c62d3f53
Repository: PowerToys
Issue: Keyboard Manager requires integration tests for the remapping logic
Labels: Product-Keyboard Shortcut Manager,Area-Tests,Issue-Task

Currently each of the remap methods have been unit tested, i.e. Remapping keys and remapping shortcuts. This doesn't however test the scenarios where a user remaps a key, and those key remaps are reflected in the shortcut remap. To do this we need to add integration tests for the `HandleKeyboardHookEvent` method https://github.com/microsoft/PowerToys/blob/master/src/modules/keyboardmanager/dll/dllmain.cpp#L381-L447
Repository: PowerToys
Issue: Keyboard Manager UI needs Win App Driver tests
Labels: Product-Keyboard Shortcut Manager,Area-Tests,Issue-Task

Unit tests for the UI logic for validating shortcut and key selections was added in #5718, however these tests only cover the scenarios of a single drop down changing. In order to test more complex interactions where an error while changing one drop down results in multiple warnings and multiple drop downs getting modified requires the use of Win App driver tests.
Win app driver tests will also allow us to test adding/removing rows in the UI.
Repository: TypeScript
Issue: Clean up old branches in the repo?
Labels: Infrastructure

Would you consider cleaning up unused branches? There are a lot of unmerged branches that are 5 years old that could probably be deleted. I think GitHub lets you recover branches if you really need them back.

<img width="1258" alt="Screen Shot 2020-08-12 at 13 12 04" src="https://user-images.githubusercontent.com/589034/90063025-9110e080-dc9d-11ea-87d9-571b78b4cff1.png">
Repository: node
Issue: esm: Modify ESM Experimental Loader Hooks
Labels: discuss,esm

<!--
Thank you for suggesting an idea to make Node.js better.

Please fill in as much of the template below as you're able.
-->
This issue is regarding #34144 .  The original proposal on that PR was to modify the `getSource` loader hook to be able to optionally return a `format` in its return object that overrides the format returned by `getFormat`.

This method was eventually discussed at a team meeting: [nodejs/modules#536](https://github.com/nodejs/modules/issues/536) and a new proposal was eventually brought up: [remove the `getFormat` hook entirely](https://github.com/nodejs/node/pull/34144/#issuecomment-666716738).

I plan to explore this option and submit a PR in the coming 2 weeks.

cc: @jkrems @nodejs/modules-active-members
Repository: TypeScript
Issue: Improving documentation for built-in type declarations
Labels: Suggestion,Awaiting More Feedback

Looking at for instance `lib.dom.d.ts`, what I notice is that the documentation isn't what it could be. Is there any policy w.r.t. improving on this? I think the benefits of better docs are quite obvious, for instance adding examples or stating browser support for certain features.

However I wonder if:
- Since the file is already quite large, and adding documentation could blow it up like 100x, would this cause any performance issues (in editors)? If so, is there a way around it?
- The best documentation on these things (that I know of) are on MDN. A nice start could be to link/auto add some docs from there, if the licensing allows it (https://wiki.developer.mozilla.org/en-US/docs/MDN/About#Copyrights_and_licenses). I think it does at least in part.
Repository: TypeScript
Issue: Language service support for classic JavaScript patterns meta-issue
Labels: Meta-Issue

One consistent piece of feedback from users who have been using Visual Studio long-term to develop JavaScript-only projects is that the old, execution-based language service in Visual Studio 2015 did a better job picking up certain common JavaScript patterns than the TypeScript language service.

This is a meta-issue to collect specific instances where TypeScript didn't do as good a job as VS 2015 IntelliSense. By targeting these specific fixes we hope to improve the experience of users upgrading from VS 2015, as well as improve our type inference for pure JavaScript in general.

* [x] Function declaration with aliased `this` not treated as a constructor #39842 
* [x] Prototype assignment doesn't work on default-assigned constructor functions #39167
* [ ] Prototype assignment should take the type of the initializer and not require a literal #39166
* [ ] Assignments to global objects in Javascript should be global declarations #22446
* [ ] `@description` JSDoc tag interferes with callback parameter documentation #37346
Repository: godot
Issue: Exporting to Android with AOT succeeded but with ExitCode 255
Labels: bug,platform:android,topic:editor,topic:porting,topic:dotnet

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
3.2.3.rc3.mono

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
macOS Catalina

**Issue description:**
<!-- What happened, and what was expected. -->
Exporting to Android with AOT succeeded but with message:
![Screenshot_2020-08-13_at_01.09.31.png](https://user-images.githubusercontent.com/29600539/90075431-0dd7a500-dd06-11ea-86ce-8bbe8cd3c9f8.png)

**Steps to reproduce:**
1. Get 3.2.3.rc3.mono 
2. Install export templates
3. Get AOT compiler for Android from # here https://github.com/godotengine/godot-mono-builds/releases/download/release-01beb2c/android-cross-arm64.zip
4. Move the binary to aot-compiler folder 
5. Export project

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: pytorch
Issue: [jit] std::exception_ptr can't be torchbind/convert to ivalue
Labels: oncall: jit

We want to convert ProcesssGroup::Work to Torchscript using Torchbind

See https://github.com/pytorch/pytorch/blob/ecb88c5d11895a68e5f20917d27a0debbc0f0697/torch/lib/c10d/ProcessGroup.hpp#L52

cc @suo @gmagogsfm
Repository: pytorch
Issue: [jit] TorchBind std::chrono::milliseconds 
Labels: oncall: jit

Find a way to Torchbind function with arguments `std::chrono::milliseconds`

https://github.com/pytorch/pytorch/blob/ecb88c5d11895a68e5f20917d27a0debbc0f0697/torch/lib/c10d/ProcessGroup.hpp#L88

cc @suo @gmagogsfm
Repository: pytorch
Issue: Verify TorchBind works with nested class type
Labels: triaged,enhancement,module: torchbind

We want to TorchBind `ProcessGroup::Work` and `ProcessGroup`, not sure if torchbind nested class types works directly, need to verify. https://github.com/pytorch/pytorch/blob/ecb88c5d11895a68e5f20917d27a0debbc0f0697/torch/lib/c10d/ProcessGroup.hpp#L118
Repository: pytorch
Issue: TorchBind C++ Enum Class
Labels: triaged,enhancement,module: torchbind

Need to find a way/verify that C++ Enum class can be TorchBinded, or using the existing JIT Enum somehow. See https://github.com/pytorch/pytorch/blob/945d7a7408891e25bc54a65015724f6d2de644e6/torch/lib/c10d/Types.hpp#L8
Repository: go
Issue: x/tools/cmd/goimports: recent commit using 700% of CPU
Labels: Performance,NeedsInvestigation,Tools

I try to stay close to the tip of `x/tools` (generally compiling every day or other day). Today I noticed goimports using 700% of my CPU after several hours of the fan being on (not unusual for the fan to go on on my machine, but unusual for it to go for several hours.) I'm running darwin and Go tip. It was not using that much RAM. It had been running for at least 7 hours according to Activity Monitor.

I'm not sure of the best way to troubleshoot that problem going forward, just wanted to make you aware of it in case you notice it on your machine or can think of a recent commit that could cause the CPU to spin.
Repository: godot
Issue: EditorPlugin.AddCustomType breaks when used custom inheritance
Labels: bug,topic:editor,topic:plugin,topic:dotnet

**Godot version:** 3.2.2.stable.mono

**Issue description:** 
_EditorPlugin.AddCustomType_ not includes custom base script. 
If custom base script is passed (_Pic1_) child script is not shown in "Add Node" Window at all (_Pic2_).
Expected behavior like GDScript class_name (_Pic3_).

`**Pic1**`
![изображение](https://user-images.githubusercontent.com/39778897/90077262-63ae4c00-dd0a-11ea-9f93-fd2e204c4a31.png)

`**Pic2**`
![изображение](https://user-images.githubusercontent.com/39778897/90077249-5b561100-dd0a-11ea-8535-8f730760b358.png)

`**Pic3**`
![изображение](https://user-images.githubusercontent.com/39778897/90077573-31511e80-dd0b-11ea-9c90-f8d4e49470d2.png)

**Steps to reproduce:**
1. Activate plugin in "Plugins" tab.

**Minimal reproduction project:** [custom_node_issue.zip](https://github.com/godotengine/godot/files/5066401/custom_node_issue.zip)

Thank you!
Repository: flutter
Issue: [Add Official Support] Add Support for Flutter Installer
Labels: c: new feature,tool,a: first hour,a: quality,c: proposal,P3,team-tool,triaged-tool

I would like to propose adding official support for Flutter Installer, a tool I made using Flutter to install Flutter on any desktop OS.

Link to GitHub repo: https://github.com/yazeedalkhalaf/Flutter_Installer
Repository: TypeScript
Issue: Allow tsconfig.yaml in addition to tsconfig.json
Labels: Suggestion,Awaiting More Feedback

## Search Terms

yaml
tsconfig format

## Suggestion

I suggest allowing the `tsconfig.json` file to be replaced with `tsconfig.yaml`.

This would be implemented by simply converting the yaml to json and passing it to whatever method currently interprets the contents of `tsconfig.json`.

Additionally, I would propose that the presence of both a `tsconfig.json` and a `tsconfig.yaml` file in the root of a project is an error.

## Use Cases

Like #30400 (which I found originally), I'd like to add comments to my project config. Also, yaml is just a nicer format for something intended to be edited by a human.

I have created this simply because #30400 (which called for adding `tsconfig.js`) was closed for reasons which do not apply to yaml. So I thought there should be an open issue. You can always close it for other reasons, right?

## Examples

following the [example in the handbook](https://www.typescriptlang.org/docs/handbook/tsconfig-json.html)

```
% cat example.json
{
  "compilerOptions": {
    "module": "commonjs",
    "noImplicitAny": true,
    "removeComments": true,
    "preserveConstEnums": true,
    "sourceMap": true
  },
  "files": [
    "core.ts",
    "sys.ts",
    "types.ts",
    "scanner.ts",
    "parser.ts",
    "utilities.ts",
    "binder.ts",
    "checker.ts",
    "emitter.ts",
    "program.ts",
    "commandLineParser.ts",
    "tsc.ts",
    "diagnosticInformationMap.generated.ts"
  ]
}
% cat example.yaml
compilerOptions:
  module: commonjs
  noImplicitAny: true
  removeComments: true
  preserveConstEnums: true
  sourceMap: true
files:
  - core.ts
  - sys.ts
  - types.ts
  - scanner.ts
  - parser.ts
  - utilities.ts
  - binder.ts
  - checker.ts
  - emitter.ts
  - program.ts
  - commandLineParser.ts
  - tsc.ts
  - diagnosticInformationMap.generated.ts
```

## Checklist

**I'M PRETTY SURE** 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).