sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [FlutterWeb] RouteInformationParser.parseRouteInformation could not be awaited.
Labels: f: routes,platform-web,has reproducible steps,P2,found in release: 2.1,found in release: 2.2,team-web,triaged-web

## Steps to Reproduce

<!-- You must include full steps to reproduce so that we can reproduce the problem. -->

1. From this [gist](https://gist.github.com/sohyuyuan/c385ce87e3a11faf638a86b3ade8726c)
2. In `BookRouteInformationParser. parseRouteInformation` there is a `await Future.delayed(const Duration(milliseconds: 1));`
3. Without this await, everything works fine.
4. However, if we add this await statement into `parseRouteInformation`, and we manually insert the `http://localhost:8100/book/0` into the browser's address bar, the page is navigated correctly but the link in the address bar is being manipulated to `http://localhost:8100/book`.

<details>
  <summary>Logs</summary>

<!--
      Run your application with `flutter run --verbose` and attach all the
      log output below between the lines with the backticks. If there is an
      exception, please see if the error message includes enough information
      to explain how to solve the issue.
-->

```
```

<!--
     Run `flutter analyze` and attach any output of that command below.
     If there are any analysis errors, try resolving them before filing this issue.
-->

```
```

<!-- Finally, paste the output of running `flutter doctor -v` here. -->

```
[✓] Flutter (Channel stable, 2.0.4, on Mac OS X 10.15.7 19H524 darwin-x64, locale en-GB)
    • Flutter version 2.0.4 at /Users/sohyuyuan/Developer/flutter
    • Framework revision b1395592de (13 days ago), 2021-04-01 14:25:01 -0700
    • Engine revision 2dce47073a
    • Dart version 2.12.2

[✓] Android toolchain - develop for Android devices (Android SDK version 29.0.3)
    • Android SDK at /Users/sohyuyuan/Library/Android/sdk
    • Platform android-30, build-tools 29.0.3
    • Java binary at: /Applications/Android Studio.app/Contents/jre/jdk/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Xcode 12.4, Build version 12D4e
    • CocoaPods version 1.10.1

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 4.1)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 1.8.0_242-release-1644-b3-6915495)

[✓] VS Code (version 1.55.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.21.0

[✓] Connected device (1 available)
    • Chrome (web) • chrome • web-javascript • Google Chrome 89.0.4389.128

• No issues found!
```

</details>
Repository: opencv
Issue: VI_MAX_CAMERAS =20 limit is not enough in DShow backend for camera
Labels: incomplete,platform: win32

Hello, I want to make photos in short time with more than 25 cameras and I get the tips “OnReadsample() is called with error status...”. Then I find that "#define VI_MAX_CAMERAS  20" in cap_show.cpp and it seems that opencv does not allow more than 20 cameras working. So I change the VI_MAX_CAMERAS to 40, but some cameras lose connections after a few minutes. 
How can I make more cameras work well in long time?

##### System information (version)
<!-- Example
- OpenCV => 3.4.2
- Operating System / Platform => Windows 64 Bit
- Compiler => Visual Studio 2015
-->
Repository: pytorch
Issue: Please add a tab of "all" packages in `Docs` option
Labels: module: docs,triaged

## 📚 Documentation

<!-- A clear and concise description of what content in https://pytorch.org/docs is an issue. If this has to do with the general https://pytorch.org website, please file an issue at https://github.com/pytorch/pytorch.github.io/issues/new/choose instead. If this has to do with https://pytorch.org/tutorials, please file an issue at https://github.com/pytorch/tutorials/issues/new -->

I hope there is a tab of "all" packages in `Docs` option, which includes all the PyTorch packages including PyTorch, torchvision etc.
Because there may be a scene that I want to search a function of PyTorch, which belongs to an unknown package.   


cc @brianjo @mruberry
Repository: godot
Issue: default_bus_layout.tres is generated at old location after moved
Labels: bug,topic:editor

**Godot version:** 3.2.3 / 3.3 RC9 / master (c7a4e2196e)

**OS/device including version:** macOS 11.2.3 (not graphics-related)

**Issue description:**

After dragging `default_bus_layout.tres` into a subfolder, changing the bus layout still generates the layout file at old location.

Restarting the editor solves this issue.

**Steps to reproduce:**

1. Add a bus in the Audio tab so that `res://default_bus_layout.tres` appears in FileSystem.
2. Create a new folder `resources`, and drag `default_bus_layout.tres` into the folder.
    * The `audio/buses/default_bus_layout` in Project Settings is changed to `res://resources/default_bus_layout.tres`
3. Add another bus in the Audio tab
    * `res://default_bus_layout.tres` is generated again

**Minimal reproduction project:** Any empty project will do.
Repository: vscode
Issue: Webviews disables Alt key menu navigation
Labels: bug,help wanted,windows,webview

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->

Version: 1.55.2
Commit: 3c4e3df9e89829dce27b7b5c24508306b151f30d
Date: 2021-04-13T09:37:02.931Z
Electron: 11.3.0
Chrome: 87.0.4280.141
Node.js: 12.18.3
V8: 8.7.220.31-electron.0
OS: Linux x64 5.8.0-48-generic

Steps to Reproduce:

1. Open VS code.
2. Create markdown file and populate with simple text.
3. Open file preview with CTRL+SHIFT V.
4. Whilst in file preview, hold ALT --> no menu bar navigation.

<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Repository: create-react-app
Issue: Error: my-app@0.1.0 build: `react-scripts build`
Labels: needs triage,issue: bug report

I've just created a react app using npx create-react-app myapp. I works fine locally but then pushed it to my azure repo.
I got this error on the npm run build phase:

```
2021-04-15T10:08:54.2404580Z 13 verbose stack Error: new-story-map-react@0.1.0 build: `react-scripts build`
2021-04-15T10:08:54.2405489Z 13 verbose stack Exit status 1
2021-04-15T10:08:54.2405974Z 13 verbose stack     at EventEmitter.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\index.js:332:16)
2021-04-15T10:08:54.2406527Z 13 verbose stack     at EventEmitter.emit (events.js:315:20)
2021-04-15T10:08:54.2407649Z 13 verbose stack     at ChildProcess.<anonymous> (C:\Program Files\nodejs\node_modules\npm\node_modules\npm-lifecycle\lib\spawn.js:55:14)
2021-04-15T10:08:54.2408940Z 13 verbose stack     at ChildProcess.emit (events.js:315:20)
2021-04-15T10:08:54.2409389Z 13 verbose stack     at maybeClose (internal/child_process.js:1048:16)
2021-04-15T10:08:54.2409838Z 13 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:288:5)
2021-04-15T10:08:54.2410219Z 14 verbose pkgid new-story-map-react@0.1.0
2021-04-15T10:08:54.2410522Z 15 verbose cwd D:\a\1\s
2021-04-15T10:08:54.2410810Z 16 verbose Windows_NT 10.0.14393
2021-04-15T10:08:54.2411249Z 17 verbose argv "C:\\Program Files\\nodejs\\node.exe" "C:\\Program Files\\nodejs\\node_modules\\npm\\bin\\npm-cli.js" "run" "build"
2021-04-15T10:08:54.2411691Z 18 verbose node v14.16.1
2021-04-15T10:08:54.2412465Z 19 verbose npm  v6.14.12
2021-04-15T10:08:54.2412759Z 20 error code ELIFECYCLE
2021-04-15T10:08:54.2413498Z 21 error errno 1
2021-04-15T10:08:54.2413833Z 22 error new-story-map-react@0.1.0 build: `react-scripts build`
2021-04-15T10:08:54.2414175Z 22 error Exit status 1
2021-04-15T10:08:54.2414498Z 23 error Failed at the new-story-map-react@0.1.0 build script.
2021-04-15T10:08:54.2414912Z 23 error This is probably not a problem with npm. There is likely additional logging output above.
2021-04-15T10:08:54.2415281Z 24 verbose exit [ 1, true ]
```
What's wrong ?
Repository: godot
Issue: ViewportTexture in duplicated instanced scene still refer to old viewport
Labels: bug,topic:core,needs testing

**Godot version:** 3.2.3 / 3.3 RC9

**OS/device including version:** macOS 11.2.3 (not graphics-related)

**Issue description:**

I have a scene that contains a `Viewport` and a `Sprite`. The `Sprite` uses a `ViewportTexture` that references the viewport.

![tree](https://user-images.githubusercontent.com/372476/114866090-b99d3b80-9e25-11eb-9b4a-b3fc12a5b47d.png)

The scene is instanced in another scene. After the instanced scene is duplicated (CTRL-D), both the `ViewportTexture`s show the content of the original viewport (the one inside first `Scene` node). They correctly refer to their own viewport after reopening the `Main` scene.

![instanced](https://user-images.githubusercontent.com/372476/114866153-cde13880-9e25-11eb-8cd1-ba1fa0469481.png)

Setting up `ViewportTexture` on current master (c7a4e21) generates a `Condition "proxy.is_valid()" is true` error, and the `ViewportTexture` is all black. So I failed to test this on it.

**Steps to reproduce:**

1. Open the `Main.tscn` in MRP
    * There is a red godot icon in the scene
2. Duplicate the node called `Scene`, and move the node down
    * Now, there are two red godot icons
3. Change the `Color` script variable of `Scene2` to white via the inspector.
    * Nothing changes, both the icons are red
4. Change the `Color` script variable of `Scene` to green via the inspector.
    * Both the icons become green
 5. Save & close the scene, then reopen it
    * The color of icons are correct: `Scene` is green, and `Scene2` is white

**Minimal reproduction project:** [ViewportTexture.zip](https://github.com/godotengine/godot/files/6317675/ViewportTexture.zip)
Repository: godot
Issue: CPUParticles2D wrong color from color_ramp on frames when node transform is updated in _process()
Labels: bug,topic:2d,topic:particles

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version: 3.3 RC 8**
<!-- Specify commit hash if using non-official build. -->
It doesn't happen in `3.1.1-stable`, but **does** happen in `3.1.2-stable`

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 10 64bit
Core i5-2400
GTX 750
happens on both GLES2 and GLES3

**Issue description:**
<!-- What happened, and what was expected. -->
What expected:
Particles spawn and update their color from color_ramp throughout their life

What happened:
At frames when transform of CPUParticles2D node was updated then all particles would show wrong color from color_ramp, as though instead of particles changing their color, it's the emitter that changes color(see GIF). That only happens when I play the scene, not in editor, and not if transform is updated in `_physics_process()`, and only after at all particles were emitted.

Here particles move from left to right, bottom one display the correct and expected behaviour, the top one actual behaviour
The particles on the top don't change color throughout their life, they just spawn with different colors
![screenshot](https://user-images.githubusercontent.com/5873735/114875420-f0fbf000-9e05-11eb-9a82-2e3d62faea39.png)
also GIF
![video-gif](https://user-images.githubusercontent.com/5873735/114873332-d9bc0300-9e03-11eb-95a0-42ee95d54f7d.gif)

**Steps to reproduce:**
1) Create 2d scene
2) Add CPUParticles2D (Particles2D work fine) with local coords off, lifetime draw order, scale 60, 0 spread, 0 gravity, intial velocity 250 and color_ramp with just 2 different colors like red/blue
3) Add script that updates transform of that CPUParticles2D node (or of its parent, or its parent's parent, etc) in `_process()`
4) Play, as it doesn't happen in editor
5) Wait until ALL particles are emitted (until particles die and respawn) as that starts to happen only after that moment

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[CPUParticles2dBug.zip](https://github.com/godotengine/godot/files/6317637/CPUParticles2dBug.zip)
Play project scene
It contains 3 instances of CPUParticles2D with top one being updated every frame, botton one not updated at all, and middle one toggling between updated and not updated every half a second
Repository: godot
Issue: CenterContainer loses RectSize when UseTopLeft is set (C# & gdscript)
Labels: bug,topic:gui

**Godot version:**
master (33333f168) & 3.2.3


**OS/device including version:**
Windows 10


**Issue description:**
Setting UseTopLeft on a CenterContainer sets size to 0.0.  One would expect size to be retained.


**Steps to reproduce:**
Run attached.  Console output shows size as 0,0.
Turn off UseTopLeft and re-run.  Console shows correct size.


**Minimal reproduction project:**
[CenterContainer.UseTopLeft (cs & gd).zip](https://github.com/godotengine/godot/files/6318338/CenterContainer.UseTopLeft.cs.gd.zip)
Repository: go
Issue: x/sys/unix: request for Ioctl*Int32 functions
Labels: NeedsInvestigation,FeatureRequest,compiler/runtime

One very relevant usage of `ioctl` functions (at least on Linux) is for querying extended attributes in files. As seen in https://man7.org/linux/man-pages/man2/ioctl_iflags.2.html , 

> The type of the argument given to the FS_IOC_GETFLAGS and
       FS_IOC_SETFLAGS operations is int *, notwithstanding the
       implication in the kernel source file include/uapi/linux/fs.h
       that the argument is long *.

What this means is that the `attr` field in  `ioctl(fd, FS_IOC_GETFLAGS, &attr);` and `ioctl(fd, FS_IOC_SETFLAGS, &attr);` is always a 32-bit signed integer. This means that using the `IoctlGetInt` and `IoctlSetPointerInt` functions is wrong for these values, because Go's `int` will be 32-bit or 64-bit, depending on the platform's pointer width. It happens to work on little endian platforms, but it will definitely be wrong on 64-bit big endian platforms (so at least ppc64 and some mips, maybe aarch64be? not sure go supports that).

x/sys/unix does provide `IoctlGetUint32`, but that has the wrong sign, unfortunately.

There is a workaround, which is using `IoctlGetUint32` and converting to an `int32`, and using `IoctlSetInt(fd, req, int(uintptr(unsafe.Pointer(attr)))` instead of `IoctlSetPointerInt`, but these are hardly ergonomic.

Therefore, I would suggest providing `IoctlGetInt32`, `IoctlSetPointerInt32` and `IoctlSetInt32` functions. If homogenous coverage is desirable, a `*Uint32` set could be added as well.
Repository: go
Issue: spec: consolidate the definition of "defined types"
Labels: NeedsInvestigation

# Situation

[The spec](https://golang.org/ref/spec) says:

> A type definition creates a new, distinct type with the same underlying type and operations as the given type, and binds an identifier to it.

```ebnf
TypeDef = identifier Type .
```

> The new type is called a defined type. It is different from any other type, including the type it is created from.

https://golang.org/ref/spec#Type_definitions

Also, whenever "defined type(s)" appears in the spec, it is linked to the definition above.

# Problem

A reader may wrongly think that all defined types are created by [type definition](https://golang.org/ref/spec#Type_definitions). But this is not true, because types such as [`bool`](https://golang.org/ref/spec#Boolean_types), [`int`](https://golang.org/ref/spec#Numeric_types), and [`string`]( https://golang.org/ref/spec#String_types) are defined types that are not created by type definition.

And if a reader wants to fully understand what defined types are, the reader has to read all sections below.

- https://golang.org/ref/spec#Type_definitions
- https://golang.org/ref/spec#Boolean_types
- https://golang.org/ref/spec#Numeric_types
- https://golang.org/ref/spec#String_types

The problem is that the definition of "defined types" is not contained in one place of the spec.

# Proposal

Adding a section or a paragraph just for the definition of "defined types" would help readers to understand the concept correctly and easily.

I would suggest adding a section "Defined types" before the section ["Type identity"](https://golang.org/ref/spec#Type_identity) so that the new section belongs to [Properties of types and values](https://golang.org/ref/spec#Properties_of_types_and_values) and [Type identity](https://golang.org/ref/spec#Type_identity) section can naturally refer to "defined types".

The new section should look like this. I don't think this is good enough, but I just wanted to show my idea clearly.

```
## Defined types

A type is a defined type if and only if one of the following conditions applies:

- The type is created by type definition.
- The type is the predeclared `bool` type.
- The type is a predeclared numeric type such as `int` or `float64`.
- The type is the predeclared `string` type.
```

Also, I suggest

```diff
- The new type is called a defined type.
+ The new type is a defined type.
```

to reduce the misunderstanding that "the new type" is the definition of "a defined type".
Repository: tensorflow
Issue: Introduce ability to clear GPU memory in Tensorflow 2
Labels: stat:awaiting tensorflower,type:feature,comp:gpu,TF 2.4

<em>Please make sure that this is a feature request. As per our [GitHub Policy](https://github.com/tensorflow/tensorflow/blob/master/ISSUES.md), we only address code/doc bugs, performance issues, feature requests and build/installation issues on GitHub. tag:feature_template</em>


**System information**
- TensorFlow version (you are using): 2.3.1, 2.4.1
- Are you willing to contribute it (Yes/No): No

**Describe the feature and the current behavior/state.**
Currently there is no way to completely free the (once) allocated GPU RAM. 
For example, i want to use tensorflow in the context of 3d visualization which is made next to impossible by this behavior. Standard solutions like `tf.config.experimental.set_memory_growth(gpus[0], True)` are unfortunately not sufficient, because the once allocated RAM cannot be released again.

In #36465 (https://github.com/tensorflow/tensorflow/issues/36465#issuecomment-818742876), it is mentioned that by using `GPUProcessState::TestOnlyReset` and `ProcessState::TestOnlyReset` the option to release GPU memory exists, but is just not exposed or for testing purposes only.

It would be very nice for applications using tensorflow to have proper access to gpu ram release functions.

**Will this change the current api? How?**
Introduce a new (experimental) function to reset the current session/graph/device/... - state and thus free the GPU RAM completely.

**Who will benefit with this feature?**
People who use Tensorflow in their application in conjunction with other GPU-RAM critical operations such as 3D rendering.
Repository: rust
Issue: #[cfg(target_thread_local)] is `true` for WebAssembly targets without `atomics` enabled
Labels: O-wasm

This compiler-internal and unstable `#[cfg]` is currently per-target rather than per-target-configuration. This means that thread locals purportedly work on the wasm target when in fact (I think) they only work on the wasm target with the `atomics` feature enabled.

Ideally the compiler would conditionally define this `cfg` on wasm (depending on other target features enabled), and then this could enable cleaning up the definitions of thread locals in libstd a bit by relying more on `target_thread_local` and not special-casing wasm so much.

This came out of a discussion in https://github.com/rust-lang/rust/pull/83416
Repository: react
Issue: DevTools React recommendations UI / architecture
Labels: Type: Discussion,Component: Developer Tools

Up until this point, DevTools has generally presented information without making specific recommendations. For example, the Profiler shows which components are faster or slower, relative to each other, but makes no recommendations about how slow is too slow or when/where memoization should be added.

Some overall architecture and UX for this would probably be good to consider adding to DevTools.

Ideas for things DevTools might warn about:
* `undefined` return value (could indicate an accidental early return)
* Components that render "too slow" (above some threshold)
* When there is a sync update (e.g. recommend `useTransition`)
* When memoization (e.g. `React.memo` or `useMemo`) might be helpful
* Multi-pass renders

Perhaps we could add an audit mode to check a specific component (or the whole tree) for problems like the ones above.
Repository: PowerToys
Issue: Override "Windows Snap" with the mouse on the edges of the screen ? (like "Override Windows Snap hotkeys")
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones

## 📝 Provide a description of the new feature

I would like to be able to activate the same behavior as "Override Windows Snap hotkeys" but with "Windows Snap Drag & Drop".
With that, they will use the same layout as if I use Windows + Arrow.

https://support.microsoft.com/en-us/windows/snap-your-windows-885a9b1e-a983-a3b1-16cd-c531795e6241#:~:text=Select%20the%20window%20you%20want,a%20corner%20after%20snapping%20it.

Merci !

---

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: pytorch
Issue: Addition/subtraction/multiplication/division of bool variables are not supported in JIT
Labels: oncall: jit

## 🐛 Bug

Addition/subtraction/multiplication/division of bool variables are not supported in JIT

## To Reproduce

Steps to reproduce the behavior:

```
import torch

def fun(a: bool, b: bool):
    return a + b

scripted_fn = torch.jit.script(fun)
print(fun(True, False))  # Works in Eager
print(scripted_fn(True, False)) # Fails with `RuntimeError`
```
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
Should compile successfully and return 1

This is one of rough edges found during testing Profile Directed Typing

cc @gmagogsfm
Repository: TypeScript
Issue: Move `AbortController`/`AbortSignal` to isolated lib file to share definitions between DOM and NodeJS
Labels: Domain: lib.d.ts

NodeJS [introduced a global `AbortController`/`AbortSignal`](https://nodejs.org/dist/latest-v15.x/docs/api/globals.html#globals_class_abortcontroller) in Node 15.x. It would be helpful if NodeJS could share the definitions from the DOM using `/// <reference lib="abortcontroller" />` comment.

This was mentioned in https://github.com/DefinitelyTyped/DefinitelyTyped/pull/52357/files#diff-2696281f8832b1227bb41483a7525a8ccd9399bb4b1704f69c8c54bb1346d8edR315

Related:  https://github.com/DefinitelyTyped/DefinitelyTyped/pull/52357