sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Vulkan: Normals don't update on skinned meshes when transformed by scaling or translating
Labels: bug,topic:rendering,regression,topic:3d

### Godot version

4.0.dev.20211004.official.2e8cba0bd obtained from https://downloads.tuxfamily.org/godotengine/testing/4.0/4.0-dev.20211004/

### System information

Windows 10, Vulkan Clustered, GTX 1070ti, Nvidia 471.96 driver

### Issue description

If a model rigged with a skeleton has any of its bones translate or scale, the parts of the mesh affected by that bone will not update their normals, resulting in incorrect shading. Rotation doesn't seem to have this issue.

I didn't test other file types, but these models were imported as GLTF2 (.glb) files from blender 2.93.4.

Before moving the bone:
![untranslated](https://user-images.githubusercontent.com/42379432/136063706-6c37cdca-bfd3-4e20-9aac-42f7ef395446.jpg)

After moving:
![untranslated](https://user-images.githubusercontent.com/42379432/136063911-aed1e38e-6e25-4e10-8ad7-23332cb2ffca.jpg)

The view here was set to display the normal buffer, so the color on the plane should have been different on either side of the peak.

Scaling also has this issue when the scaling isn't equal on all 3 axes, here the sphere on the left was scaled almost flat using a bone, but the sphere on the right was scaled about the same using the editor scaling control, which works without issue:
![untranslated](https://user-images.githubusercontent.com/42379432/136064775-85110ad4-e414-4873-89f9-6577e677b2ef.jpg)

### Steps to reproduce

Open the attached project and switch the editor viewport to display the normal buffer. The two tscn files contain models with skeletons that have already been deformed, one for translation and the other for scaling.

Alternatively, import any mesh with multiple bones and move one of them so it introduces shearing - moving a character model's spine off to the side will show this quite well.

For scale - any round surface scaled flat, like a character's head, will end up keeping its original normals rather than updating them.

### Minimal reproduction project

[Normals Bug.zip](https://github.com/godotengine/godot/files/7287699/Normals.Bug.zip)
Repository: rust
Issue: Diagnostics: confusing terminology when moves occur due to `?` operator
Labels: A-diagnostics,T-compiler

I was assisting someone new to Rust and they were confused by an error message. I've simplified the code for this issue but the error message is exactly the same. This is the code they had written:

```rust
use std::fs;
use std::io;

fn main() -> io::Result<()> {
    for entry in fs::read_dir(".")? {
        let file_type = entry?.file_type()?;
        if file_type.is_dir() {
            dbg!(entry?.file_name());
        }
    }
    
    Ok(())
}
```

Using rustc 1.55.0 (c8dfcfe04 2021-09-06) and rustc 1.57.0-nightly (f03eb6bef 2021-10-02), the compiler outputs the following error ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=9b6a02fee7cd7cebbb2fb34b5018a26c)):

```
error[E0382]: use of moved value: `entry`
   --> src/main.rs:8:18
    |
5   |     for entry in fs::read_dir(".")? {
    |         ----- move occurs because `entry` has type `Result<DirEntry, std::io::Error>`, which does not implement the `Copy` trait
6   |         let file_type = entry?.file_type()?;
    |                         ------ `entry` moved due to this method call
7   |         if file_type.is_dir() {
8   |             dbg!(entry?.file_name());
    |                  ^^^^^ value used here after move
    |
note: this function takes ownership of the receiver `self`, which moves `entry`

For more information about this error, try `rustc --explain E0382`.
```

This error message is correct — `entry?` on line 6 moves `entry`, so it can't be used again on line 8. However, we had trouble interpreting it.

The first part of the hint ("`entry` moved due to this method call") was misunderstood to mean that it was the `file_type()` method call that was moving the value, rather than the `?` operator. I don't personally think of `?` as a "method call", nor a "function", though I can see why the compiler thinks of it as one. Unlike the `try!` macro, though, you can't easily view the expanded version of the code to see if there's a method call or a function under the hood.

Secondly, the wording of the note tripped us up too: "this function" was misunderstood to refer to `main`, which doesn't even use `self` anywhere, rather than `?`. I've seen this note a bunch of times before, and I know what it means, but for some reason having almost all of the `main` function's code on the screen made me think it referred to `main` itself!

I think more specific error messages for when `?` moves a value would be useful here, maybe something like "some_variable moved due to use of `?` operator" and "the `?` operator takes ownership of the receiver `self`, which moves some_variable".
Repository: pytorch
Issue: JIT: empty_like doesn't support requires_grad
Labels: oncall: jit

It would be great to have some automated testing to make sure that JITed code accepts (and returns) the same arguments as not-JITed code.

```py
def fun(x: torch.Tensor) -> torch.Tensor:
    return x * torch.empty_like(x, requires_grad=False)
```

> 
> aten::empty_like(Tensor self, *, int? dtype=None, int? layout=None, Device? device=None, bool? pin_memory=None, int? memory_format=None) -> (Tensor):
> E       Keyword argument requires_grad unknown.
Repository: vscode
Issue: VSCode requests bluetooth access on startup
Labels: bug,upstream,linux,good first issue,electron

<!-- ⚠️⚠️ 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. -->
<!-- 🔧 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. -->
- VS Code Version: 1.60.2 (I'm using this package: https://aur.archlinux.org/packages/visual-studio-code-bin/)
- OS Version: Arch Linux `5.14.9-arch2-1`

Steps to Reproduce:

1. Disable and stop bluetooth.service: `sudo systemctl disable bluetooth.service`, `sudo systemctl stop bluetooth.service`
2. Open Visual Studio Code
3. Watch `journalctl -f` to see the output:

```
Oct 05 20:24:00 zjeffer dbus-daemon[497]: [system] Activating via systemd: service name='org.bluez' unit='dbus-org.bluez.service' requested by ':1.235' (uid=1000 pid=1745936 comm="/opt/visual-studio-code/code --disable-extensions ")
Oct 05 20:24:00 zjeffer dbus-daemon[497]: [system] Activation via systemd failed for unit 'dbus-org.bluez.service': Unit dbus-org.bluez.service not found.
```

As you can see, after opening visual studio code, it requests access to the bluez service. This seems unnecessary, I guess it's Electron's doing it by default.


This is the same issue as #59162, but the OP closed it because it was fixed for him (in 2019). The issue seems to have reappeared.
Repository: flutter
Issue: [flutter_tools] Refactor Flutter SDK to support installation in read-only directory
Labels: c: new feature,tool,customer: crowd,P3,team-tool,triaged-tool

This would support being installed by root by a package manager. This would require:

- Providing an upgrade mechanism that is not dependent on git
- Allow the tool to determine its version without calling git commands that may write to .git
- Provide Flutter SDK version resolution (e.g. `flutter --version`) not dependent on git tags
- Moving the Flutter cache directory outside of the repo
- Tracking the Flutter SDK version file outside the repo (perhaps in the cache?)
- Ensuring that pub does not try to write to the repo while doing `pub get`
Repository: flutter
Issue: Opacity widget's child should not be nullable
Labels: framework,waiting for PR to land (fixed),P2,team-framework,triaged-framework

/cc @goderbauer - this widget is pointless if it has no child.

We should also audit other proxy type widgets that don't make sense without children, although I can't think of any others off the top of my head.
Repository: pytorch
Issue: Cuda Out of Memory - MMDMatic
Labels: module: memory usage,triaged

RuntimeError: CUDA out of memory. Tried to allocate 36.00 MiB (GPU 0; 2.00 GiB total capacity; 1.18 GiB already allocated; 21.53 MiB free; 56.71 MiB cached)

The error should be reproducible after downloading the latest release from below. Setup.bat has to be run from Anaconda then run autotracevmd.bat. 

https://github.com/errno-mmd/mmdmatic

This project runs heavily on Pytorch. I am hoping you can give me some tips on how to resolve the issue.

I have also attached a copy of the messages before I get the RuntimeError. 

[MMDMaticError.txt](https://github.com/pytorch/pytorch/files/7289151/MMDMaticError.txt)
Repository: go
Issue: x/build: misc-compile TryBots are too slow again
Labels: Builders,NeedsInvestigation

https://farmer.golang.org/try?commit=178e9821 (for [CL 354149](https://golang.org/cl/354149)) was stuck running `misc-compile-mac-win` for over 25 minutes — it was the slowest builder of the lot. My understanding from #32632 is that we aim for TryBots to complete in about 5 minutes — or only ⅕ of that time.

It isn't obvious to me why that particular builder would have been so slow on this run.

CC @golang/release
Repository: TypeScript
Issue: Proposal: strictJsxAttributeChecks
Labels: Suggestion,Help Wanted,Experimentation Needed,Effort: Casual

When TypeScript checks if provided attributes match a given type, it exempts dashed attributes from being checked against things like index signatures.

```tsx
import React from 'react';

interface Props {
    [prop: string]: number;
}

function MyComponent(x: Props) {
    return <div />
}

// No error.
<MyComponent foo-bar={"hello"} />
```

This applies to all index signatures, even string pattern index signatures that match.

```tsx
import React from 'react';

interface Props {
    [prop: `data-${string}`]: number;
}

function MyComponent(x: Props) {
    return <div />
}

// No error.
<MyComponent data-bar={"hello"} />
```

Under this new `--strict` mode flag, these properties would be strictly checked in the presence of an index signature.

This issue is a possible alternative for https://github.com/microsoft/TypeScript/issues/44797. Instead of validating against a specific set of index signatures, this idea in this proposal is to tighten checking against *all* index signatures under a new strict-mode flag.

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
    * It **would** for `--strict` mode users.
* [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, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).

## 💻 Use Cases

One of the motivating examples for template string types was index patterns on object types. This was something that specifically came up in discussions with library authors of Fluent UI; however, this checking doesn't fully apply to JSX attributes, which seems like an unfortunate accident.
Repository: godot
Issue: AudioStreamPlayer doesn't seek() if set_stream() is used unless seeking after play()
Labels: bug,topic:audio

### Godot version

3.3.3 stable

### System information

Windows 7 64-bit

### Issue description

When using AudioStreamPlayer and setting the stream playback in code, you must use play() to begin playing the file before you seek to a position, or else you'll always play at the beginning. If you set the stream in the AudioStreamPlayer inspector, you may seek() before using play() and it'll work fine. 

### Steps to reproduce

```gdscript
onready var audiostream = $AudioStreamPlayer
var filelong
export (AudioStreamOGGVorbis) var soundfile

func _ready():
	var rng = RandomNumberGenerator.new()
	rng.randomize()
	audiostream.set_stream(soundfile)
	filelong = soundfile.get_length()
	audiostream.seek(rng.randf_range(0, filelong))
	audiostream.play()
	print(audiostream.get_playback_position())
```
This will print 0 every time, however:
```gdscript
	audiostream.play()
	audiostream.seek(rng.randf_range(0, filelong))
	print(audiostream.get_playback_position())
```
This will print the playback position at a random time.

### Minimal reproduction project

_No response_
Repository: rust
Issue: 1.53.0 broke ui/consts/const-eval/ub-*.rs tests on s390x (big-endian, 64-bit) (regression)
Labels: P-medium,regression-from-stable-to-stable,C-bug,O-SystemZ

Probably because s390x is 64-bit big-endian not little-endian, e.g.: 

[Debian build log, warning several MB](https://buildd.debian.org/status/fetch.php?pkg=rustc&arch=s390x&ver=1.53.0%2Bdfsg1-1%7Eexp1&stamp=1633466251&raw=0)

<details><summary>
sample
</summary>

~~~~
------------------------------------------
diff of 64bit.stderr:

6          |
7          = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
8          = note: the raw bytes of the constant (size: 8, align: 8) {
-                      01 00 00 00 00 00 00 00                         │ ........
+                      00 00 00 00 00 00 00 01                         │ ........
10                 }
11      
12      error[E0080]: it is undefined behavior to use this value

116        |
117        = note: The rules on what exactly is undefined behavior aren't clear, so this check might be overzealous. Please open an issue on the rustc repository if you believe it should not be considered undefined behavior.
118        = note: the raw bytes of the constant (size: 8, align: 4) {
-                      78 00 00 00 ff ff ff ff                         │ x.......
+                      00 00 00 78 ff ff ff ff                         │ ...x....
120                }
121     
122     error[E0080]: it is undefined behavior to use this value
~~~~
</details>

~~~~
test [ui] ui/consts/const-eval/ub-enum.rs ... FAILED
test [ui] ui/consts/const-eval/ub-int-array.rs ... FAILED
test [ui] ui/consts/const-eval/ub-nonnull.rs ... FAILED
test [ui] ui/consts/const-eval/ub-ref-ptr.rs ... FAILED
test [ui] ui/consts/const-eval/ub-uninhabit.rs ... FAILED
test [ui] ui/consts/const-eval/ub-wide-ptr.rs ... FAILED
~~~~

These tests were fine in 1.52 so the culprit is probably #76881 @hameerabbasi . I will revert it in Debian for now.
Repository: flutter
Issue: Better diagnostics for accessing elements after dispose
Labels: c: crash,framework,a: quality,a: error message,P3,team-framework,triaged-framework

Sometimes people run into exception like that in https://github.com/flutter/flutter/issues/90188.

In `Element`, the following getter throws if the object has been disposed, because then _widget is null:
```dart
  /// The configuration for this element.
  @override
  Widget get widget => _widget!;
  Widget? _widget;
```

In debug mode we could have a better error message for this kind of thing.

We could also have more docs.
Repository: flutter
Issue: [web] Enable WebGL 2.0 on Safari iOS 15+
Labels: c: new feature,engine,platform-web,e: OS-version specific,e: web_canvaskit,P2,browser: safari-ios,team-web,triaged-web

Filing a follow-up issue for https://github.com/flutter/flutter/issues/89655. The original issue is not reproducible, but the discussion led to a different bug:

When running on Safari 15 on iOS in WebGL 2.0 mode the app doesn't load. This applies to all apps. I am going to temporarily force WebGL 1 on iOS, but we need to investigate what's going on. We don't want to get stuck on old WebGL indefinitely.

To reproduce:

- `flutter create sampleapp`
- `flutter run -d web-server --web-renderer=canvaskit --web-port=8080`
- Open the app on an iOS 15 device

Classifying as a feature request as strictly speaking WebGL 1 works fine. Upgrading to 2.0 would be nice.
Repository: vscode
Issue: Support enabling "Open With Code" Windows Explorer integration post installation
Labels: feature-request,workbench-os-integration

<!-- ⚠️⚠️ 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. -->
Currently the "Open With Code" Windows Explorer content menu integration can only be enabled during install, which is annoying if you forgot to check it and impossible to do if installing via the Windows Store.

Given Windows holds the state for this (making the VSCode settings a poor home for the preference), perhaps a command palette item would be a better fit.
Repository: rust
Issue: Tracking Issue for `shuffle` and `shuffle-seed`
Labels: T-libs-api,A-libtest,C-tracking-issue

This is a tracking issue for unstable libtest options `--shuffle` and `--shuffle-seed`.

These options allow tests to be run in random order, as opposed to the default alphabetical order.

### Steps / History

- [X] Implementation: #89082
- [ ] Final comment period (FCP)
- [ ] Stabilization PR

### Unresolved Questions

- None yet.
Repository: deno
Issue: Using buffers with non-blocking FFI calls is unsound
Labels: bug,FFI

Recently non-blocking FFI was made possible with PR #12274, and the use of buffers with FFI was made possible with PR #12335. However, currently only non-shared `ArrayBuffer`s can be used with FFI (due to denoland/serde_v8#3), which means they can't be shared across threads. Given that non-blocking FFI is implemented with a tokio blocking task, which runs in a separate thread, it follows that using buffers with non-blocking FFI is automatically unsound.

See denoland/serde_v8#47 for why this did not cause any compilation errors.
Repository: rust
Issue: Warn if feature settings may break compilation
Labels: C-enhancement,A-lints,A-diagnostics,O-x86_64,T-compiler,A-ABI,A-target-feature,O-x86_32

Currently, if a user instructs the compiler to adjust the features for compilation, or uses `#[target_feature]` to set unusual feature settings for a function, or introduces a custom target, this can trigger miscompilations if the settings are improperly "aligned" with each other (to do correct parameter passing and so on). This mostly impacts x86, due to its particular architectural extensions, but it could affect other platforms.

Some examples we definitely want to warn on:
- [ ] Enabling soft floats and not disabling SSE/SSE2 and the x87 FPU. This came up with https://github.com/rust-lang/rust/issues/61721
- [ ] `"-sse"` but not `"-sse2"` for x86-64. I don't know how this even makes sense, honestly, but it also came up with https://github.com/rust-lang/rust/issues/61721
- [ ] Enabling SSE or SSE2 for single functions on x86-without-SSE2 platforms and calling into it and returning the float. See https://github.com/rust-lang/rust/issues/64609 for more.

Some of these issues are currently caught by LLVM, but Rust programmers often find underlying LLVM errors surfacing to be mysterious and cryptic, and in this case we can definitely detect them and warn about them ourselves.

In addition, due to the desire for binary floating point conformance per https://github.com/rust-lang/rust/issues/10087, we **probably** want to emit a warning for any build configuration such that, despite having an FPU we consider to be conformant and desirable, disables the ability to use such a floating point unit, such that it could introduce non-conformant floating point code. However, that can be extended into a future issue when all the known-100%-bad bases are covered.
Repository: nvm
Issue: travis-ci breaks due to LetsEncrypt SSL CA expiration
Labels: testing

 - Xenial can't connect to iojs.org (eg https://app.travis-ci.com/github/nvm-sh/nvm/builds/239205709)
 - Bionic fails to build a bunch of node versions (eg https://app.travis-ci.com/github/nvm-sh/nvm/jobs/541572426)
 
We'll need to find a way to fix one of them, or get the tests passing on Github Actions, or nvm can't cut a release (and one is needed imminently).
Repository: vscode
Issue: WSL: process explorer does not show CPU usage properly in remote
Labels: bug,WSL,remote,workbench-diagnostics,confirmed

Follow the steps from https://github.com/microsoft/vscode/issues/121854#issue-864138597 in Windows WSL Linux (I am on WSL1) and notice how `htop` in the remote shows high CPU for search and watch processes but nothing in our process explorer indicates that.
Repository: godot
Issue: Reflections from a probe look correct in scene editor but break / look scrambled in VR
Labels: bug,topic:rendering,topic:xr,topic:3d

### Godot version

3.3.4

### System information

Win 10, RX570, i5 4590

### Issue description

The reflections are not visible in VR while they are visible and accurate in Scene Editor:

Demonstration:
https://youtu.be/az9a_lbEIO0

Screenshots:
In Editor: 
![image](https://user-images.githubusercontent.com/52581279/136145173-beb946c7-fe3d-4112-93f8-e22203f161ae.png)
![image](https://user-images.githubusercontent.com/52581279/136145201-aba1f645-a862-4966-9875-3edd691f2027.png)

In VR:
![image](https://user-images.githubusercontent.com/52581279/136145262-b69fdb3c-7e3c-4d00-8638-642704c18fad.png)
![image](https://user-images.githubusercontent.com/52581279/136145304-d1b99378-ccbb-4c58-9b57-49f47018fa68.png)


### Steps to reproduce

Well I don't know how to reproduce what seems like a scrambled Reflection Probe Image.

### Minimal reproduction project

_No response_
Repository: PowerToys
Issue: Have Runner verify app dependencies
Labels: Area-Runner,Priority-3

### Microsoft PowerToys version

0.47.0

### Running as admin

- [ ] Yes

### Area(s) with issue?

General

### Steps to reproduce

If user for some reason decides to uninstall .NET Core Desktop Runtime 3.1.x, it would be great if PowerToys:

* Did not show 3 error messages, one per module/ program using this dependency.
![MicrosoftTeams-image](https://user-images.githubusercontent.com/6450056/136154758-9aed7731-b8fc-4e8c-9255-8a9762bd4fbc.png)
* If Windows reboot and PowerToys is set to auto start, do a check for the dependency and fail to start _any_ PowerToys program, and show one error, not 3.
  * Same if user tries to start PowerToys.

Maybe consider to build PowerToys with .Net Core built in/ self contained deployment?

* Yes, it will become bigger, but like the author of Paint.NET figured out, it's worth it vs. all the troubleshooting and scenarios one have to think about.
  * https://forums.getpaint.net/topic/118660-paintnet-43-is-now-available/

### ✔️ Expected Behavior

Graceful exit/ shutdown, with one error message.

### ❌ Actual Behavior

![MicrosoftTeams-image](https://user-images.githubusercontent.com/6450056/136155572-1eea4f4d-c9ed-48fd-9887-8137b3a63d0a.png)

And some parts of PowerToys continue running.

### Other Software

_No response_