sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Need package/description check for UWP exports in can_export()
Labels: bug,topic:editor,topic:porting,platform:uwp

**Godot version:** Godot 3.2.1.stable Windows 64 (non-mono)

**OS/device including version:** 
Microsoft Windows [Version 10.0.19041.207] (build 2004) 64bit

**Issue description:**
When creating a new export configuration for UWP, there are a number of fields that are indicated as required or invalid before you can export. Currently there is a discrepancy between these checks and reality, where you can not install a signed APPX file if the description length is 0. Therefore, there should be an additional check added to **platform/uwp/export/export.cpp:can_export()** that checks that the "package/description" field length is greater than zero.

**Steps to reproduce:**

1. Create a do nothing project with a single node scene. Create an export configuration that satisfies all the settings while keeping the description blank.
2. Export UWP/APPX
3. Sign the APPX with signtool as indicated by the Godot documentation
4. Install the APPX via Powershell: `Add-AppxPackage C:\path\project.appx`

This description requirement can be seen enforced (via XML schema verification) in the Powershell Add-AppxPackage cmdlet:
```
Add-AppxPackage : Deployment failed with HRESULT: 0x80080204, The Appx package's manifest is invalid.
error 0xC00CE169: App manifest validation error: The app manifest must be valid as per schema: Line 19, Column 147,
Reason: '' violates minLength constraint of '1'.
The attribute 'Description' with value '' failed to parse.
NOTE: For additional information, look for [ActivityId] 25eed3ef-1376-0005-5d5c-81267613d601 in the Event Log or use
the command line Get-AppPackageLog -ActivityID 25eed3ef-1376-0005-5d5c-81267613d601
At line:1 char:1
+ Add-AppxPackage C:\projects\playground\NullProject\NullProject.appx
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (C:\projects\pla...ullProject.appx:String) [Add-AppxPackage], Exception
    + FullyQualifiedErrorId : DeploymentError,Microsoft.Windows.Appx.PackageManager.Commands.AddAppxPackageCommand
```
Repository: vue
Issue: In Firefox, radiobuttons with `required` and `v-model` are marked as invalid immediately
Labels: browser quirks

### Version
2.6.11

### Reproduction link
[https://jsfiddle.net/t1po5sdh/](https://jsfiddle.net/t1po5sdh/)







### Steps to reproduce
In Firefox 75.0, I get the two radio buttons marked as invalid (i.e. surrounded by a red border) immediately on pageload. This does not happen if I either remove `required` or `v-model`

### What is expected?
The radios should only be marked as invalid after form submission - as with other required input controls.

### What is actually happening?
See above

---
I've been observing this for years already.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: neovim
Issue: UX: ":edit *.js" should suggest :next
Labels: enhancement,complexity:low,core

### Actual behaviour
When simply trying to edit some additional files I often type `:e *.js` or something similar; this almost ALWAYS results in `E77: Too many file names`.

### Expected behaviour

It's pretty clear what the user wants in this situation; they want to open the files as buffers! I'm sure there are legacy reasons for this error, but it's a pretty poor experience these days that probably doesn't need to stick around. (at least with `set hidden` enabled)

I've learned I can run `:next *.js` which has the behaviour I want, but `next` is a pretty unintuitive name and I don't really see a reason to have more than one command for this functionality.

In the worst case, perhaps we could simply add a note saying `Maybe you meant to use :next` to the error message? It took a bit of digging to find that solution and I'd love it if others didn't need to do the same.

Thanks for all your work everyone!
Repository: three.js
Issue: TransformControls accelerate if the camera moves while transforming
Labels: Needs Investigation

I first noticed this when scaling things, where the effect magnitude is insane (the box I was scaling was pushing the player away, the camera reacted to player moving, and the feedback caused TransformControls to blow the box up). However, the similar effect happens to positioning - see [here](https://jsfiddle.net/03uvag65/): the camera follows x, if you move he box in y direction, it is fine, but if you move in x direction - the light speed is no longer the limit.

Not sure if this counts as bug; if it does not - what do I do, @arodic ?
Repository: PowerToys
Issue: Add current folder to PATH
Labels: Help Wanted,Idea-New PowerToy

### Summary of the new feature/enhancement
It would be nice to have a context menu button to the current folder to the Windows PATH.

### Proposed technical implementation details (optional)

https://stackoverflow.com/questions/31269312/adding-a-shell-context-menu-item-so-that-i-can-add-folder-to-path-by-right-click/48414700#48414700
Repository: youtube-dl
Issue: add easyload.io
Labels: site-support-request

<!--

######################################################################
  WARNING!
  IGNORING THE FOLLOWING TEMPLATE WILL RESULT IN ISSUE CLOSED AS INCOMPLETE
######################################################################

-->


## Checklist

<!--
Carefully read and work through this check list in order to prevent the most common mistakes and misuse of youtube-dl:
- First of, make sure you are using the latest version of youtube-dl. Run `youtube-dl --version` and ensure your version is 2020.03.24. If it's not, see https://yt-dl.org/update on how to update. Issues with outdated version will be REJECTED.
- Make sure that all provided video/audio/playlist URLs (if any) are alive and playable in a browser.
- Make sure that site you are requesting is not dedicated to copyright infringement, see https://yt-dl.org/copyright-infringement. youtube-dl does not support such sites. In order for site support request to be accepted all provided example URLs should not violate any copyrights.
- Search the bugtracker for similar site support requests: http://yt-dl.org/search-issues. DO NOT post duplicates.
- Finally, put x into all relevant boxes (like this [x])
-->

- [x] I'm reporting a new site support request
- [x] I've verified that I'm running youtube-dl version **2020.03.24**
- [x] I've checked that all provided URLs are alive and playable in a browser
- [x] I've checked that none of provided URLs violate any copyrights
- [x] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

- Single video: https://easyload.io/f/xRlPG65Nq7/index_mp4_mp4



## Description

<!--
Provide any additional information.
If work on your issue requires account credentials please provide them or explain how one can obtain them.
-->

please add easyload.io
Repository: svelte
Issue: outroing if_blocks cannot receive updates
Labels: bug,temp-stale,transition/animation

outroing if_blocks will not receive any update from the tick they get outroed on
`render_simple` :
https://svelte.dev/repl/3abed636ab2d456882e49b1db35c677f?version=3.20.1
`render_compound` :
https://svelte.dev/repl/5e950ff7951f4afc9b627aa9832fae5b?version=3.20.1

`render_simple` does have the following comment in the compiler
```
// no `p()` here — we don't want to update outroing nodes,
// as that will typically result in glitching
```
it's been there since the initial commit 2 years ago

~~I don't really see why it couldn't be fixed, might give it a try in a few days~~
Repository: PowerToys
Issue: [Run] Intro / exit animations
Labels: Idea-Enhancement,Product-PowerToys Run,Area-User Interface,External Dependency-WinUI 3,Status-Blocked

right now it is Visible / not visible.  We need a quick, fade in / out.  

Same should be list results. 

1. Guessing, .66 sec for fade in / out.  Snappy but not slow.
2. This has to be handled on WPF side due to WinUI transparency issues.
Repository: rust
Issue: unwrap branches are not optimized away.
Labels: A-LLVM,I-slow,T-compiler,C-bug,E-needs-mcve

When creating a structure which has a variant type, and that this type is wrapped as an `Option<T>`, the `unwrap` branch cannot be removed by LLVM, even after proving that the only path reachable is the `Some(…)` case and never the `None` case.

I tried this code:

https://github.com/mozilla-spidermonkey/jsparagus/blob/330722aaa4f7c6f39422b7daae7084ea8cbcbead/crates/parser/src/queue_stack.rs#L141-L153

Calling the previous function as:

```
assert!(self.top != 0);
let v = self.pop().unwrap();
```

This hint LLVM that the `self.top == 0` branch does not need to be generated. However, the unwrap condition remains as the `None` value is folded within the variant and that LLVM does not know about it.

I think the Rust compiler should give range analysis information that the `None` value would never be part of the variant, and as such let LLVM remove the unwrapping condition from the generated code.

### Meta
Tested with both `rustc --version --verbose`:
```
rustc 1.42.0 (b8cedc004 2020-03-09)
binary: rustc
commit-hash: b8cedc00407a4c56a3bda1ed605c6fc166655447
commit-date: 2020-03-09
host: x86_64-unknown-linux-gnu
release: 1.42.0
LLVM version: 9.0
```

and

```
rustc 1.44.0-nightly (7f3df5772 2020-04-16)
binary: rustc
commit-hash: 7f3df5772439eee1c512ed2eb540beef1124d236
commit-date: 2020-04-16
host: x86_64-unknown-linux-gnu
release: 1.44.0-nightly
LLVM version: 9.0
```
Repository: rust
Issue: Duplicate crate macros failing to differentiate
Labels: E-needs-test,A-macros,T-compiler,C-bug

Here is a reproduction:

https://github.com/LucioFranco/rustc-duplicate-macro-bug/

I've added comments on how to trigger the bug. But it looks like if we have one crate but two versions imported into the same project. Aka using cargo's rename feature, then rust picks up that if we use one of the macros that the other one even if its from a different version is the same. Commenting out the tower01 `assert_request_eq` allows the second one to compile properly. If its not commented out the `tower03` version will fail to compile because it is attempting to use the `tower01` version which doesn't await the inner future.

### Meta

This happens currently on `rustc 1.42.0 (b8cedc004 2020-03-09)` but not on a newer nightly `cargo 1.44.0-nightly (390e8f245 2020-04-07)`. So this has probably been fixed but I couldn't find any issue for this specific problem.

</p>
</details>
Repository: electron
Issue: Clipboard: improved support for reading images
Labels: enhancement :sparkles:

Some context: I'm writing a note-taking app, and one of the most requested feature for it has been to be able to paste images that were copied in the clipboard directly into notes.

I'd like to implement this feature as perfectly as I can, but as far as I can tell the current set of related APIs that Electron provides have a few limitations that don't allow me to implement this very well.

### Issue 1 - `clipboard.readImage` - Non existent image

Even if there are no images in the clipboard, `clipboard.readImage` still returns a `NativeImage` instance.

I don't see for what reason anyone would ever want one of these useless images returned when the clipboard contains no images, but more importantly this behavior seems to be undocumented in the docs, that mention that this function returns "The image content in the clipboard.".

I think this method should instead return either `null` or `undefined` when there are no images in the clipboard. If this can't be changed for whatever reason then it should be mentioned in the docs that a 0x0 image will be returned if no actual image has been found in the clipboard.

### Issue 2 - `NativeImage.toDataURL` - Unexpected conversion

`NativeImage` objects have a bunch of `.toFORMAT` methods, but only one `toDataURL` method, and the docs say that `toDataURL` returns "The data URL of the image", so given how any image can be encoded in a data url I would have expected the image-specific format would have been preserved, e.g. "the" data url of a gif should begin with `data:image/gif`, but instead it begins with `data:image/png` according to this method, basically this function is converting images to pngs regarding of their original format, so for any gif the returned data url is not the data url that encodes that image at all, but the data url of a possible way to convert that image to png, which is not what I was expecting.

### Issue 3 - `clipboard.readImage` - Preserving original data

It should be possible to retrieve the raw buffer that encodes the image found in the clipboard in order not to loose any information or alter the image in any way.

Most notably there are no methods for retrieving copied images as GIF or SVG, which makes it fundamentally impossible right now, as of Electron v8.2.2, for animated gifs or vector images to be copied in any reasonable way.

The provided methods for converting to PNG and JPG are also problematic, I don't want to convert a PNG image the user copied in the clipboard to JPG or viceversa, in order to not introduce any artifacts and in general in order to not alter the copied image at all. Additionally the `toJPEG` method asks me for a quality factor, I just want the image in the original quality, that doesn't seem possible today.

---

TL;DR: I would really like a function that just returns the extension, mime type and buffer of the image copied in the clipboard, with no alterations whatsoever, if these information is available.
Repository: go
Issue: proxy.golang.org: sometimes rate limits @master package refreshes beyond documented "one minute"
Labels: Documentation,NeedsInvestigation,proxy.golang.org

https://proxy.golang.org/ says:

> After one minute for caches to expire, the go command will see that tagged version. If this doesn't work for you, please file an issue.

It's been minutes since I tagged a new version of `inet.af/netaddr` but it's not showing up:

```
$ go get inet.af/netaddr@v0.1
go get inet.af/netaddr@v0.1: no matching versions for query "v0.1"
$ go get inet.af/netaddr@0.1
go get inet.af/netaddr@0.1: inet.af/netaddr@0.1: invalid version: unknown revision 0.1
$ git ls-remote git@github.com:inetaf/netaddr
f9e5bcc2d6eadfc6fd7937983711a17b511b954f        HEAD
f9e5bcc2d6eadfc6fd7937983711a17b511b954f        refs/heads/master
...
f9e5bcc2d6eadfc6fd7937983711a17b511b954f        refs/tags/v0.1
```

Am I holding it wrong?

https://godoc.org/inet.af/netaddr is updated at least. Its refresh is instant.

/cc @hyangah @heschik
Repository: godot
Issue: GLES2 - shadows does not work
Labels: bug,platform:android,topic:rendering,topic:3d

Godot Engine v3.2.2.beta.custom_build.4e70279b5
Android 4.4 GPU VideoCore IV HW

```
GLES: Broadcom, VideoCore IV HW, OpenGL ES 2.0
GL_EXT_debug_marker GL_OES_compressed_ETC1_RGB8_texture GL_OES_compressed_paletted_texture GL_OES_texture_npot GL_OES_depth24 GL_OES_vertex_half_float GL_OES_EGL_image GL_OES_EGL_image_external GL_EXT_discard_framebuffer GL_OES_rgb8_rgba8 GL_OES_depth32 GL_OES_packed_depth_stencil GL_EXT_texture_format_BGRA8888 GL_APPLE_rgb_422
EGL:
EGL_KHR_image EGL_KHR_image_base EGL_KHR_image_pixmap EGL_KHR_vg_parent_image EGL_KHR_lock_surface EGL_ANDROID_image_native_buffer EGL_ANDROID_swap_rectangle EGL_ANDROID_image_native_buffer

```
On device log gives 

```
**ERROR**: Directional shadow framebuffer status invalid
   At: drivers\gles2\rasterizer_scene_gles2.cpp:4026:initialize() - Directional shadow framebuffer status invalid
```

**Issue description:**
When lights have no shadows enabled, then scene is rendered ok.
When lights shadows are enabled then everything turns very dark.

**Steps to reproduce:**
Use example project attached, turn shadow option in light node's on and off

**Minimal reproduction project:**
[VideoCore-1.zip](https://github.com/godotengine/godot/files/4495433/VideoCore-1.zip)
Repository: go
Issue: cmd/vet: flag use of .Timeout() after Set*Deadline()
Labels: NeedsDecision,Analysis

In #31449 it was decided to make deadline expiration return a newly-defined error, as checking `net.OpError.Timeout()` also detects keepalive failures. Keepalives were enabled by default for TCP clients in 1.12 and servers in 1.13, breaking some code setting deadlines longer than the keepalive period (which varies with platform).

This means that .Timeout() use after Set*Deadline() should be changed to look for the new error, since that is not a reliable way to check for deadline-expired.

I suggest _go vet_ flag use of .Timeout() after Set*Deadline(). That will generate reports for existing code, but perhaps that's better than leaving code broken due to the keepalive problem.

Triage: milestone should be 1.15
@gopherbot add NeedsDecision
Repository: rust
Issue: Consider removing `ProjectionElem::Index`
Labels: C-cleanup,T-compiler,A-MIR

It is the only projection element that uses another local besides the place's base local, and requires special care in many circumstances. All other `ProjectionElem`s perform static operations that do not depend on runtime values.

In https://github.com/rust-lang/rust/pull/71003, I initially did not handle this special case, which would have resulted in an unsound optimization. The visitor logic for them was also broken (fixed in https://github.com/rust-lang/rust/pull/71013) because it was missing a special case.

I'm not sure what to adequately replace them with. It seems like `Rvalue::Index` would be a reasonable choice, but it might have other drawbacks.

cc @rust-lang/wg-mir-opt
Repository: godot
Issue: Undeterministic AtlasTexture Ordering in Saved Scene File With Multiple Row Spritesheets
Labels: bug,confirmed,topic:import

**Godot version:**
3.2.1

**OS/device including version:**
Windows 10

**Issue description:**
When having AtlasTextures in a scene, the regions and/or ordering of them in the scene file gets changed on every save whether or not anything has been changed. This only seems to occur if a sprite sheet has multiple vertical rows. The saving behaviour seems to be non deterministic. 

![atlastexture_1](https://user-images.githubusercontent.com/630329/79619109-dbc18800-8103-11ea-8d34-27e51e6340a1.PNG)
![atlastexture_2](https://user-images.githubusercontent.com/630329/79619113-de23e200-8103-11ea-8012-f79bbfb3de09.PNG)

This causes issues with version control as a file will change irregardless of if anyone has actually made a change to the scene, and is a big headache when it comes to merge conflicts.

**Steps to reproduce:**
Open reproduction project, save, and close.

**Minimal reproduction project:**
[AtlasTextureText.zip](https://github.com/godotengine/godot/files/4495546/AtlasTextureText.zip)

This project contains a git repository showing the changes that occur over three commits.
Repository: PowerToys
Issue: [KBM] Some character keys have the same display name but different codes
Labels: Product-Keyboard Shortcut Manager

An example of this is `/`. There are two keys which display `/` on the UI now (on the keyboard one is near RShift and the other is on the numpad). We should try adding some identifier to distinguish them like `NumPad /` for example. The issue with hardcoding that in is that it may not translate well to other languages.
Repository: go
Issue: runtime: support SSE2 memmove on older amd64 hardware
Labels: Performance,NeedsInvestigation,compiler/runtime

**Background**
In pursuit of some database work I've been doing, I encountered a strange corner of Go. Inserting into packed segments of memory can be expensive due to the special, backwards `runtime.memmove` call required. (eg: `copy(x[n:], x); copy(x[:n], newdata)`

When compared to a similar C++/glibc implementation of the same operation, the glibc one was about twice as fast on my hardware (a Xeon E5 v1, Sandy Bridge) to the Go implementation.

Come to find out, that while the Xeon E5v1s have AVX instructions, they have a slower per-cycle data path. That explains why Go 1.14 has the following code restriction for Intel "Bridge families":
https://github.com/golang/go/blob/go1.14.2/src/runtime/cpuflags_amd64.go#L23

This hardware issue was present until Haswell Xeons (E5v3) which happily (and quickly) use the AVX.

glibc concurs. In a `perf` report of the C++ insertion logic, it's using GNU's __memcpy_sse2_unaligned.

Which is interesting -- because Go doesn't have the equivalent. `gccgo` will use glibc and get the same performance as C++/glibc. 

**Proposal**
Add an SSE2-optimized path for `runtime.memmove`, at least when backwards copying. This would only affect/benefit older hardware (roughly, Xeons from [Nehalem, Haswell) ). Newer systems wouldn't notice at all.

I went ahead and implemented it; but the README said to file an issue for inclusion first, so here we are (my first issue!)

**Measurements**
I wrote a test package and harness to try a bunch of copy methods. Using SSE2 for the forward path as well didn't gain much over the baseline currently in Go 1.14, but for the backward path it was substantially faster. 

Forcing AVX on Sandy Bridge functioned, and varied in speed, but was slower than expected (and slower than SSE2-paths)  and especially slower when the non-temporal moves got involved.

The biggest win came in the backwards path alone.

So I implemented the backwards path only on my branch of the Go runtime and here's some preliminary highlights:

```
...
MemmoveUnalignedDstBackwards/256-32   20.6GB/s ±22%   19.9GB/s ±14%      ~     (p=0.753 n=11+4)
MemmoveUnalignedDstBackwards/512-32   7.22GB/s ±31%  23.39GB/s ±21%  +223.72%  (p=0.001 n=11+4)
MemmoveUnalignedDstBackwards/1024-32  11.3GB/s ±21%   28.1GB/s ±16%  +149.36%  (p=0.001 n=11+4)
MemmoveUnalignedDstBackwards/2048-32  13.6GB/s ±17%   28.5GB/s ±12%  +108.86%  (p=0.001 n=11+4)
MemmoveUnalignedDstBackwards/4096-32  16.7GB/s ±19%   35.3GB/s ±16%  +110.93%  (p=0.001 n=11+4)
```

I figured compiling and benchmarking other packages from the wild with my patch would be interesting, and sure enough...

Using [bbolt](https://github.com/etcd-io/bbolt) 's B-Tree write benchmark:

```
$ ./bbolt-orig bench -write-mode rnd -count 100000
# Write	11.688323313s	(116.883µs/op)	(8555 op/sec)
# Read	1.002042799s	(36ns/op)	(27777777 op/sec)

$ ./bbolt-sse2 bench -write-mode rnd -count 100000
# Write	8.114154792s	(81.141µs/op)	(12324 op/sec)
# Read	1.002062417s	(36ns/op)	(27777777 op/sec)
```