sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Mesh duplication if import is configured to save meshes as separate files
Labels: bug,topic:editor

<!-- 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.2

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Windows 10

**Issue description:**
<!-- What happened, and what was expected. -->
When there's a 3D scene (gltf or glb in my case) in which the same mesh is used by multiple objects and the import process is configured to save meshes in separate files, this happens:
the shared mesh is correctly saved as a separate file **but inside the imported scene the saved mesh is referenced only by the first occurrence of the objects using that mesh.**

The other objects use a built-in resource instead, so, the imported mesh has been duplicated, one is saved as a file, the other is built-in inside the imported gltf/glb, even though they're the same exact mesh.

The issue doesn't occur if meshes are saved as built-in resources only.

**Steps to reproduce:**
1. Open the minimal reproduction project, it contains a test_cubes scene with 3 cubes, different scales, each using the same mesh.
2. Open the imported scene, notice how the CubeMesh node references the correct external mesh resource.
Cube002 and Cube003 reference a duplicated buit-in mesh instead.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
[ImportMeshTest.zip](https://github.com/godotengine/godot/files/5210244/ImportMeshTest.zip)
Repository: flutter
Issue: "Google testing" check on PR stuck on "Pending"
Labels: P2,team-release,triaged-release

A PR (https://github.com/flutter/flutter/pull/65313) has had the "Google testing" check stuck on "Pending" for 24 hours or so.  I'm going to tell the owner to merge in master and see if that gets it to do something, but I thought I should report it either way.

## Possible Workarounds

- Try rebasing your PR to the tip of tree (aim to be <50 commits behind)
- Push an empty commit. If the PR is not in the recent 100, it may have been marked as inactive
Repository: PowerToys
Issue: [KBM] Organize remapped keyboard shortcuts 
Labels: Idea-Enhancement,Product-Keyboard Shortcut Manager

## 📝 Provide a description of the new feature

Once you have 8 or more remapped shortcuts things get a little messy. Therefore, it would be nice to have the possibility to manually sort and/or group the mappings in the "Remap shortcuts" and "Remap keys" windows.

Automatically grouping the mappings with common target apps would also be a good addition.

If you'd like to see this feature implemented, add a 👍 reaction to this post.
Repository: vscode
Issue: Multiple Cursors - Preserve Case
Labels: help wanted,feature-request,editor-multicursor

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
**Use Case**
Take the following:
`const [value, setValue] = useState();`

I want to change it to:
`const [array, setArray] = useState();`

**Feature Ask**
It would be great to:
1. Select `value`.
2. Press `Ctrl+D`.
3. Type `array`.
4. See that both symbols have changed, while preserving their proper casing.

Right now, I need to conduct two edit operations to do this.  Alternatively, I can use a single Find & Replace operation, but that would be disproportionately time-consuming for this task, as well as less precise.
Repository: storybook
Issue: React PropTypes with spread object not generating controls or allowing argTypes overrides
Labels: question / support,react,block: argstable

**Describe the bug**
For one of my components, I import an object, and use Object.keys(obj) to create an array, and and attempt to spread the array onto one of my PropTypes function. With this setup, controls do not autogenerate and I'm unable to override the select options with argTypes. I've had to hardcode the array values which works but is not ideal. Wondering if there is a fix for this coming? 

**To Reproduce**
Steps to reproduce the behavior:

1. Convert object keys into array using Object.keys(obj)
2.  Spread the array onto the `.onOf` PropTypes function:
`position: PropTypes.oneOf([ ...array  ])`
3. View component controls to see a broken `select` control

**Expected behavior**
I expected Storybook to auto-generate the correct control select options from my array, with each item in the array an as an option. Instead it just listed `...objectKeys` as the only option in the select dropdown.

**Screenshots**
![Screen Shot 2020-09-11 at 12 27 21 PM](https://user-images.githubusercontent.com/15007255/92952621-47e3b600-f42e-11ea-8a2e-31ce914cef86.png)

**System:**
```
  System:
    OS: macOS 10.15.6
    CPU: (8) x64 Intel(R) Core(TM) i5-8279U CPU @ 2.40GHz
  Binaries:
    Node: 12.3.1 - ~/.nvm/versions/node/v12.3.1/bin/node
    Yarn: 1.22.5 - ~/Desktop/angelou/node_modules/.bin/yarn
    npm: 6.9.0 - ~/.nvm/versions/node/v12.3.1/bin/npm
  Browsers:
    Chrome: 85.0.4183.102
    Firefox: 80.0.1
    Safari: 13.1.2
  npmPackages:
    @storybook/addon-a11y: ^6.0.21 => 6.0.21
    @storybook/addon-actions: ^6.0.21 => 6.0.21
    @storybook/addon-controls: ^6.0.21 => 6.0.21
    @storybook/addon-docs: ^6.0.21 => 6.0.21
    @storybook/addon-info: ^5.3.21 => 5.3.21
    @storybook/addon-knobs: ^6.0.21 => 6.0.21
    @storybook/addon-links: ^6.0.21 => 6.0.21
    @storybook/addon-options: ^5.3.21 => 5.3.21
    @storybook/addon-viewport: ^6.0.21 => 6.0.21
    @storybook/addons: ^6.0.21 => 6.0.21
    @storybook/codemod: ^6.0.21 => 6.0.21
    @storybook/react: ^6.0.21 => 6.0.21
```

**Additional context**
It seems to be an issue with `Object.key(obj)` because I created a dummy array and spreading that array seemed to work fine...
Repository: three.js
Issue: Dual quaternion skinning
Labels: Enhancement

Hello!

Would Dual Quaternion Skinning (DQS) as [described in this paper](https://www.cs.utah.edu/~ladislav/kavan07skinning/kavan07skinning.pdf) and [showcased in this video](https://www.youtube.com/watch?v=LUOJccOZfWQ) be welcomed as a feature for Three.js? It seems to be reasonably simple while giving strong visual benefits.

![image](https://user-images.githubusercontent.com/446986/92956207-c65c4a00-f466-11ea-9a50-2c43b1b9e85d.png)

From what I've gathered, in Blender, DQS is exposed as a "Preserve Volume" option on the Armature modifier.

From reading the aforementioned paper, it seems like support would require:
* Storing object-space bone rotation and translation (encoded as dual quaternions) into 2x4 GLSL matrix uniforms instead of using 4x4 bone matrices directly
* Some math in the skinning vertex shader chunk to interpolate those rotations and translations separately, normalize the dual quaternions and then recreate the transform matrices from that (or alternatively apply the rotation & translation directly on the vertex).

I assume we'd need some kind of switch between regular Linear Blend Skinning (LBS) and DQS. Not sure where it would be most appropriate to put it? As a property on SkinnedMesh?

I might give it a stab if someone experienced with Three.js's design has pointers on how to approach it.
Repository: rust
Issue: Consider enabling debug logging by default for contributors
Labels: T-compiler,T-bootstrap,C-feature-request,A-contributor-roadblock

There was a lot of discussion in https://github.com/rust-lang/rust/pull/76588 about enabling logging and it was almost a [10% perf hit](https://perf.rust-lang.org/compare.html?start=22e6099330cde0e7b1529774fe27874f8326de7a&end=ededceef5651050bda1a2058af270da498bb1333) on some benchmarks. So as it stands, the tradeoff is probably not worth it, especially since most of the time you aren't looking at `debug!` logging.

However, having `debug!` completely compiled out is extremely confusing the first time you go to add a `debug!`. While rustc-dev-guide can work on making this more discoverable, ideally this would always be on so you don't have to worry about it. I would _love_ to get the perf impact low enough that this can be on by default (or even always on).

One possible way to work towards this is by moving the more verbose logging to `trace!` and compiling out _trace_ instead. This allows keeping the (truly stupendous) amount of logging currently, but still making `debug!` work by default. Since `trace!` is rarely used, I expect this to be much less confusing for new contributors.

_Originally posted by @jyn514 in https://github.com/rust-lang/rust/pull/76588#discussion_r486707633_
Repository: flutter
Issue: Swapping an EGL surface doesn't populate ImageReader right away
Labels: engine,dependency: android,P2,team-engine,triaged-engine

It's not clear why the following would fail:

## Case 1

1. C++ side: `eglSwapBuffers(display_, surface_);`
2. Java side:  `assertTrue(imageReader.acquireLatestImage() == null);`


## Case 2

1. C++ side: `eglSwapBuffers(display_, surface_);`
2. Java side:  `assertTrue(imageReader.acquireLatestImage() == null);`
3. C++ side: `eglSwapBuffers(display_, surface_);`
4. Java side:  `assertTrue(imageReader.acquireLatestImage() != null);`
Repository: node
Issue: cluster.fork() fails when called in repl (cluster.settings.exec undefined)
Labels: cluster

Running v14.4, I launched my script with cli dynamic import: 
`node -e 'import("./seed.js").then(({open})=>open());'`
and I get the following error on fork process creation: 
```
TypeError [ERR_INVALID_ARG_TYPE]: The "modulePath" argument must be of type string. Received undefined
    at validateString (internal/validators.js:121:11)
    at fork (child_process.js:63:3)
    at createWorkerProcess (internal/cluster/master.js:132:10)
    at EventEmitter.cluster.fork (internal/cluster/master.js:167:25)
    at file:///media/fuse/drivefs-fb63ac1d072197a08fd8e42d246fd29a/root/www.blikpatrik.net/Blik_2020_seed.js:40:58
    at Array.map (<anonymous>)
    at file:///media/fuse/drivefs-fb63ac1d072197a08fd8e42d246fd29a/root/www.blikpatrik.net/Blik_2020_seed.js:40:41
``` 
in internal/cluster/master.js:132, 
`createWorkerProcess(id,env)` function passes `cluster.settings.exec` down empty to `fork(modulePath)` 
after `cluster.setupMaster()` has it set from `process.argv[1]` 
(which is empty due to --eval usage) 
at internal/cluster/master.js:57. 

I see running code dynamically as an equally reasonable use case 
for forking processes so i suppose this is not intended. 

I wonder if import.meta.url could be utilised for a solution, at least as an optional argument. 

 Thanks for the attention! 

only related issue i found: 
#27039
Repository: electron
Issue: Infinite focus loop when focusing a window with a BrowserView whose focus handler focuses the BV when there are other such windows open
Labels: platform/windows,bug :beetle:,9-x-y,10-x-y

### Preflight Checklist
* [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
* [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
* [x] I have searched the issue tracker for an issue that matches the one I want to file, without success.

### Issue Details

* **Electron Version:** 10.1.1, 9.0.4, 6.0.0, 4.0.0
* **Operating System:** Windows 10

### Actual Behavior
closing out of devtools triggers infinite focus events for a secondary window when the window and the main window have focus event handlers that focus their respective browser view web contents

### Expected Behavior
I expect this not to happen.

Closing the *detached* devtools (has to be detached) puts focus in the main window which triggers the main window's focus handler which focuses the main window's browser view's webcontents. For some reason, doing that causes the focus event of the secondary window to fire, and we get left in a focus loop.

### To Reproduce
```
(async () => {
  const {app, BrowserWindow, BrowserView} = require("electron");

  await app.whenReady()

  const [window, browserView] = await setUpBrowserViewAndWindow();

  window.on("focus", () => {
    browserView.webContents.focus();
    // closing out of the devtools activates the main window which triggers this code, which seems to cause the secondary window's focus event to fire forever
  });
  
  browserView.webContents.openDevTools({ mode: "detach" });

  browserView.webContents.on("new-window", async (e, url) => {
    e.preventDefault();
    const [win, bv] = await setUpBrowserViewAndWindow();
    e.newGuest = win;

    win.on("focus", () => {
      bv.webContents.focus();
    });
  });

  async function setUpBrowserViewAndWindow() {
    const window = new BrowserWindow();
    const browserView = new BrowserView();

    window.setBrowserView(browserView);
    const contentBounds = window.getContentBounds();
    browserView.setBounds({ x: 0, y: 0, width: contentBounds.width, height: contentBounds.height });

    await browserView.webContents.loadURL("https://google.com");

    return [window, browserView];
  }
})();
```

### Screenshots
![electron_focus_issue](https://user-images.githubusercontent.com/6374473/92962763-158a8680-f437-11ea-80ef-e40ea71682a3.gif)

### Additional Information
It is important to close out of the devtools the normal way: click the X in the devtools window.

This isn't reproducible if you close out of devtools via the taskbar (hover over electron icon, find devtools window image, click X)
Repository: godot
Issue: ScrollContainer is not scrollable in Android via touch when filled with LineEdits
Labels: bug,platform:android,topic:input

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
v3.2.2.stable.offical

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
not graphic related

**Issue description:**
<!-- What happened, and what was expected. -->
It is not possible to scroll a ScrollContainer with a child node HBoxContainer that contains LineEdits only.

**Steps to reproduce:**
Here I explain the bug and a missing feature:
[Explanation Of A Feature.pdf](https://github.com/godotengine/godot/files/5211068/Explanation.Of.A.Feature.pdf)

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
I can create one as soon as it is requested but I hope the visual explanation displays it already.
Repository: go
Issue: x/tools/gopls: add a test for renaming a directory (that contains tests)
Labels: Testing,NeedsFix,gopls,Tools,gopls/workspace

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.15.2 linux/amd64
$ gopls version
version master, built in $GOPATH mode
</pre>

### Does this issue reproduce with the latest release?

Yes, this is the latest release.

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/aaron/.cache/go-build"
GOENV="/home/aaron/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/aaron/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/aaron/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/aaron/Code/boulder/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build588592972=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?

Install the "go" vscode extension. Use it to install gopls. Everything works as expected for a while.

In my project, rename a directory from "signer" to "issuance" (https://github.com/letsencrypt/boulder/pull/5085).

### What did you expect to see?

Everything continuing to wok as before.

### What did you see instead?

Now the extension constantly pops up messages saying:
> The code in the workspace failed to compile (see the error message below). If you believe this is a mistake, please file an issue: https://github.com/golang/go/issues/new. github.com/letsencrypt/boulder/signer [github.com/letsencrypt/boulder/signer.test] has no metadata

![Screenshot from 2020-09-11 13-08-12](https://user-images.githubusercontent.com/2474926/92968427-f2100d80-f42f-11ea-93be-05323256a3d0.png)

It makes sense that signer.test has no metadata, it doesn't exist anymore. I just haven't been able to convince gopls of that fact.
Repository: flutter
Issue: Pull perf metrics from FTL
Labels: a: tests,c: new feature,team,c: performance,team-infra,P3,triaged-infra

Firebase Test Lab records metrics of test runs. It would be very useful if we ingested those metrics into our perf DB.

e.g. 
https://firebase.google.com/u/0/project/flutter-infra/testlab/histories/bh.326ed5e885d72705/matrices/5546447312088374302/executions/bs.bda0231f8cbea746/performance (google only, sorry)

We should be able to access that perf data via 
https://toolresults.googleapis.com/$discovery/rest?version=v1beta3

/cc @liyuqian @kf6gpe @godofredoc
Repository: godot
Issue: Undocumented/Hardcoded keyboard shortcut ("V") means it cannot be assigned to other shortcuts in the 2D view
Labels: bug,topic:editor

<!-- 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.2 stable (from Flathub)

**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
Fedora 32

**Issue description:**
<!-- What happened, and what was expected. -->
I tried to assign the Move tool to "V". That didn't work and the tool didn't get selected. I found that "V" is hardcoded into canvas_item_editor_plugin.cpp as a pivot mover. Is this intentional (if so, I didn't find any documentation of it)? 

**Steps to reproduce:**
Try to assign the Move tool to "V" and test the new shortcut. The Move tool won't be selected instead the pivot of the selected node will be changed, if it has one (for ex. Sprite). If the selected node doesnt have a pivot, nothing happens.

**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Repository: flutter
Issue: [web] Run screenshot tests on Windows
Labels: a: tests,platform-web,P3,team-web,triaged-web

For Fluter for Web engine, the screenshot unit tests only run on Chrome Linux on LUCI. 

It might be better to extend this to Windows in the future, since Chrome unit tests also run on LUCI Windows bots.

Blocker: https://github.com/flutter/flutter/issues/63710
Repository: rust
Issue: borrowed value does not live long enough in closure
Labels: A-closures,C-bug

From Stackoverflow:

https://stackoverflow.com/questions/63856055/borrow-checker-complains-for-closure-inside-loop-if-type-not-provided-explicitly

I tried this code:

```rust
fn f1(v: &str) {
}

fn main() {
    let c = |v| f1(v);
    for _ in 0..1 {
        let s = String::new();
        c(&s);
    }
}
```

I expected to see this happen: Code compiles

Instead, this happened: Got below error:

```
   |
10 |         c(&s);
   |         - ^^ borrowed value does not live long enough
   |         |
   |         borrow later used here
11 |     }
   |     - `s` dropped here while still borrowed
```

But if I add explicit type to closure, code compiles `let c = |v: &str| f1(v);`

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
cargo 1.46.0 (149022b1d 2020-07-17)
release: 1.46.0
commit-hash: 149022b1d8f382e69c1616f6a46b69ebf59e2dea
commit-date: 2020-07-17
```
Repository: rust
Issue: Give a better error message for shared borrow treated as unique for purposes of lifetimes
Labels: A-diagnostics,A-lifetimes,T-compiler,C-bug,D-confusing

I tried this code:

```rust
#[derive(Default)]
struct Foo { i: i32, j: i32 }

impl Foo {
    fn modify_and_borrow(&mut self) -> &i32 { self.j += 1; &self.i }
}

fn main() {
    let mut foo = Foo::default();
    let mut refs = Vec::new();
    for _ in 0..2 {
        refs.push(foo.modify_and_borrow());
    }
}
```

I expected to see this happen:


The error should say something like, "cannot borrow `foo` as mutable while it is already borrowed as immutable."

Instead, this happened:

```
error[E0499]: cannot borrow `foo` as mutable more than once at a time
  --> src/main.rs:12:19
   |
12 |         refs.push(foo.modify_and_borrow());
   |                   ^^^ mutable borrow starts here in previous iteration of loop
```

### Meta

Playground link:

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=a6450c7200878a52ff8bf4466cb09f5f
Repository: rust
Issue: Adding a `take` method to `Default`
Labels: T-libs-api,C-feature-request

`std::mem::take` takes a mutable reference to a value with a type implementing `Default` and swaps it with the default value of that type.

It seems natural to me that `take` should therefore be a method on `Default`.

```rust
pub trait Default: Sized {
    fn default() -> Self;
    fn take(&mut self) -> Self { std::mem::take(self) }
}
```

A few points in favour:

- 'Taking' a value is a very common operation. I often see uglier and more verbose attempts at taking a value, such as the following, written by developers that do not know about the functions in `std::mem` or are scared to use them because they sound like low-level operations.

```rust
let y = x;
x = Default::default();
// use `y` for something else
```

- It's often quite awkward to import `std::mem::swap` and to use it like a prefix operator (in the same manner that `await!` was awkward to use before the `.await` operator.

- It supersedes `Option::take`

The disadvantage is that this is a breaking change, conflicting with existing methods on types implementing `Default`, such as `Cell::take` (although it's also trivial to disambiguate existing code).