sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Saved resources will preserve default exported variable values
Labels: bug,topic:core

### Godot version

3.6 beta 2

### System information

Windows 10 gtx 1060 6gb intel i5 4690k

### Issue description

When you save a custom resource with exported vars, it will write the default value to the .tres file

![Screenshot 2023-08-22 09-40-31](https://github.com/godotengine/godot/assets/83078010/6d6295d9-686b-4342-bac6-6713d26f7031)



Comparing to the Animation class
![Screenshot 2023-08-22 09-45-46](https://github.com/godotengine/godot/assets/83078010/f7c4045f-0a69-4145-bbf6-dbb4580e965f)

Only when you set a new value is that value written to file...

This also happens when you extend a Godot class, ie extends Animation, all new properties will have their default values written, but all the original ones belonging to the parent class will still function normally...

This adds a size + loading penalty for adding export vars.

### Steps to reproduce

1. Create a new custom resource
2. Give the custom resource several exported vars
3. Change none of their values
4. Give a class name to the resource
5. Save the resource using ResourceSaver.save(), and save as a .tres
6. Open the file in a text editor, and you will see that the default values are written to file.

### Minimal reproduction project

[PropertySize.zip](https://github.com/godotengine/godot/files/12409324/PropertySize.zip)
Repository: pytorch
Issue: masked_fill_ outputs incorrect results for 'mps' tensor after transpose
Labels: triaged,module: correctness (silent),module: mps

### 🐛 Describe the bug

I found a bug with 'mps' backend tensor, which results in incorrect output for `masked_fill_` operation after `transpose`
The following cod reproduces the behavior on my mac
```py
import torch

x = torch.tensor([[
         False, False,  True,  True,],
        [True,  True,  True,  True]], device='mps:0')

def transform(x):
    return torch.zeros_like(x, dtype=torch.float32).masked_fill_(x, 1.0)

print(x)
print(transform(x))

print(x.t())
print(transform(x.t()))
```

The output I get from the script is
```
tensor([[False, False,  True,  True],
        [ True,  True,  True,  True]], device='mps:0')
tensor([[0., 0., 1., 1.],
        [1., 1., 1., 1.]], device='mps:0')
tensor([[False,  True],
        [False,  True],
        [ True,  True],
        [ True,  True]], device='mps:0')
tensor([[0., 1.],
        [1., 1.],
        [0., 1.],
        [1., 1.]], device='mps:0')
```

`transform(x)` works as expected, but `transform(x.t())` results in incorrect output.

### Versions

Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.3 (clang-1403.0.22.14.1)
CMake version: version 3.25.1
Libc version: N/A

Python version: 3.11.4 (main, Jul 25 2023, 17:36:13) [Clang 14.0.3 (clang-1403.0.22.14.1)] (64-bit runtime)
Python platform: macOS-13.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] numpy==1.25.2
[pip3] torch==2.0.1
[conda] No relevant packages

cc @kulinseth @albanD @malfet @DenisVieriu97 @jhavukainen @razarmehr @abhudev
Repository: pytorch
Issue: New variables in torch._ops.py pollute the torch.ops namespace
Labels: triaged,module: library

### 🐛 Describe the bug

e.g. torch.ops.dl_open_guard is a thing, and prevents people from creating operators under a "dl_open_guard" namespace (e.g. torch.ops.dl_open_guard.my_conv2d.default)

### Versions

main

cc @anjali411
Repository: vscode
Issue: Allow "Apply Extension to all Profiles" also applies to included extensions in pack
Labels: feature-request,user-profiles

When make an extension pack "Apply Extension to all Profiles", its containing extensions aren't applied to all profiles. For example, I've make *GitHub Markdown Preview* "Apply Extension to all Profiles", 

![image](https://github.com/microsoft/vscode/assets/93167100/0d4ccaa4-0c56-42d3-8967-6662542c37de)

But these extensions are not.

![image](https://github.com/microsoft/vscode/assets/93167100/78432d82-0af1-4796-b9cf-6fb89321c024)

In my opinion it should be consistent. Thanks for you!

_Originally posted by @Eitheages in https://github.com/microsoft/vscode/issues/157492#issuecomment-1665137123_
Repository: next.js
Issue: Hot reload does not work with intercepted routes 
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000
    Binaries:
      Node: 18.13.0
      npm: 8.19.3
      Yarn: 1.22.19
      pnpm: 7.33.3
    Relevant Packages:
      next: 13.4.20-canary.2
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.1.6
    Next.js Config:
      output: N/A
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

App Router

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/tgroutars/next-repro

### To Reproduce

Clone the reproduction repo and run `npm run dev`

Open `/foo`

Click the "BAR" link. This will be intercepted and open an aside

Modify `globals.css`. For example, change the `gap` in `.wrapper` from `16px` to `8px`

You will get the following error

```
Error: Could not find the module "[...]/src/app/foo/layout.tsx#" in the React Client Manifest. This is probably a bug in the React Server Components bundler.
``` 

### Describe the Bug

Next throws an error when modifying code while a route is intercepted in development.

This makes it very hard to work with intercepted route, since every time you make a change, you have to reload the page to get rid of the error. Reloading actually leads to the actual route and not the intercepted route, so you then have to go back and reopen the intercepted route

### Expected Behavior

Hot relaoding should work with intercepted routes

### Which browser are you using? (if relevant)

Chrome 115.0.5790.170

### How are you deploying your application? (if relevant)

_No response_
Repository: pytorch
Issue: index.Tensor_out & index_put.out errors or segfaults with indices list containing only null tensors 
Labels: high priority,triaged,module: advanced indexing

### 🐛 Describe the bug

Indicies with **only** null tensors causes an error or segfault.
This doesn't happen if `indices` contains other tensors that aren't null

```python
import torch

input = torch.tensor([[1, 2], [3, 4]], dtype=torch.float)
indices = [None]
values = torch.tensor([10, 20], dtype=torch.float)
out = torch.tensor([[0, 0], [0, 0]], dtype=torch.float)

# Run any of the following two lines
torch.ops.aten.index.Tensor_out(input, indices, out=out)
torch.ops.aten.index_put.out(input, indices, values, False, out=out)
```

sometimes it segfaults:
```
zsh: segmentation fault
```
sometimes it throws this error:
```
RuntimeError: ntensor >= 3 INTERNAL ASSERT FAILED at "/Users/runner/work/pytorch/pytorch/pytorch/aten/src/ATen/native/cpu/IndexKernelUtils.h":10, please report a bug to PyTorch.
```

### Versions

Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.6 (default, Oct 18 2022, 12:41:40)  [Clang 14.0.0 (clang-1400.0.29.202)] (64-bit runtime)
Python platform: macOS-13.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.1
[conda] Could not collect

cc @ezyang @gchanan @zou3519
Repository: pytorch
Issue: where.self_out doesn't fail gracefully when inputs have different dtypes
Labels: triaged,module: type promotion,module: advanced indexing,module: edge cases

### 🐛 Describe the bug

This error seems to happen every time that `input`, `other` and `out` don't have the same dtype

```python
import torch

cond = torch.zeros(2, dtype=torch.bool)
input = torch.zeros(2, dtype=torch.int)
other = torch.zeros(2, dtype=torch.long)
out = torch.zeros(2, dtype=torch.int)

torch.ops.aten.where.self_out(cond, input, other, out=out)
```

Throws this error:
```
RuntimeError: !needs_dynamic_casting<func_t>::check(iter) INTERNAL ASSERT FAILED at "/Users/runner/work/pytorch/pytorch/pytorch/aten/src/ATen/native/cpu/Loops.h":310, please report a bug to PyTorch.
```

### Versions

Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.6 (default, Oct 18 2022, 12:41:40) [Clang 14.0.0 (clang-1400.0.29.202)] (64-bit runtime)
Python platform: macOS-13.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.1
[conda] Could not collect

cc @ezyang @gchanan @zou3519 @nairbv @mruberry
Repository: pytorch
Issue: arange.out produces incorrect output when out tensor has dtype long
Labels: triaged,module: python frontend

### 🐛 Describe the bug

```python
import torch

print(torch.ops.aten.arange.out(2.3, out=torch.tensor([], dtype=torch.uint8)))
print(torch.ops.aten.arange.out(2.3, out=torch.tensor([], dtype=torch.int8)))
print(torch.ops.aten.arange.out(2.3, out=torch.tensor([], dtype=torch.int16)))
print(torch.ops.aten.arange.out(2.3, out=torch.tensor([], dtype=torch.int32)))
print(torch.ops.aten.arange.out(2.3, out=torch.tensor([], dtype=torch.int64)))
```

Outputs:
```
tensor([0, 1, 2], dtype=torch.uint8)
tensor([0, 1, 2], dtype=torch.int8)
tensor([0, 1, 2], dtype=torch.int16)
tensor([0, 1, 2], dtype=torch.int32)
tensor([0, 1])
```

### Versions

Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.6 (default, Oct 18 2022, 12:41:40) [Clang 14.0.0 (clang-1400.0.29.202)] (64-bit runtime)
Python platform: macOS-13.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.1
[conda] Could not collect

cc @albanD
Repository: material-ui
Issue: [material-next] Enforce default prop value classes are added to component
Labels: on hold

As discussed in https://github.com/mui/material-ui/issues/40733, default prop values should add classes to the component.

This should be enforced and tested.
Repository: pytorch
Issue: Inconsistencies when handling scalars that are out of the range relative to the input tensor's dtype
Labels: triaged,module: int overflow

### 🐛 Describe the bug


```python
import torch

# Both should fail, or both should output 3.
# However ATen converts -129 to 127 uint8, applying that as the min. But it fails if the dtype is int8

torch.ops.aten.clamp.out(torch.tensor([3], dtype=torch.uint8), -129, None, out=torch.tensor([], dtype=torch.uint8))
# tensor([127], dtype=torch.uint8)

torch.ops.aten.clamp.out(torch.tensor([3], dtype=torch.int8), -129, None, out=torch.tensor([], dtype=torch.int8))
# RuntimeError: value cannot be converted to type int8_t without overflow
```



### Versions

Collecting environment information...
PyTorch version: 2.0.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 13.5 (arm64)
GCC version: Could not collect
Clang version: 14.0.0 (clang-1400.0.29.202)
CMake version: Could not collect
Libc version: N/A

Python version: 3.9.6 (default, Oct 18 2022, 12:41:40) [Clang 14.0.0 (clang-1400.0.29.202)] (64-bit runtime)
Python platform: macOS-13.5-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1 Pro

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] torch==2.0.1
[conda] Could not collect
Repository: go
Issue: testing: Coverage() returns different values in 1.21 than 1.19.X
Labels: NeedsInvestigation

<!--
Please answer these questions before submitting your issue. Thanks!
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.19.12 linux/amd64

</pre>

### Does this issue reproduce with the latest release?

yes

### 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/leo/.cache/go-build"
GOENV="/home/leo/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/leo/.gvm/pkgsets/go1.19.12/global/pkg/mod"
GONOPROXY="github.ibm.com"
GONOSUMDB="github.ibm.com"
GOOS="linux"
GOPATH="/home/leo/.gvm/pkgsets/go1.19.12/global"
GOPRIVATE="github.ibm.com"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/home/leo/.gvm/gos/go1.19.12"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/home/leo/.gvm/gos/go1.19.12/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.19.12"
GCCGO="/usr/bin/gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/leo/Code/gateway/go.mod"
GOWORK=""
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 -Wl,--no-gc-sections -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build470846844=/tmp/go-build -gno-record-gcc-switches"

</pre></details>

### What did you do?
Call testing.Coverage() and comparing the resulting value with the expected vaue that is working in 1.19.X

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on go.dev/play is best.
-->



### What did you expect to see?
testing.Coverage() to return the same value as 1.19.X. 

I did not update to 1.20.X due to https://github.com/golang/go/issues/59590, testing.Coverage() was totally broken in 1.20.X and in principle it was fixed for 1.21.0 but the return value is not the same as 1.19.X, it is quite lower


### What did you see instead?

Different values:

```
coverage: 89.1% of statements
Tests passed but coverage at  55.0% <  88.3%

coverage: 73.5% of statements
Tests passed but coverage at  49.1% <  76.3%

coverage: 90.0% of statements
Tests passed but coverage at  25.0% <  80.0%

coverage: 94.4% of statements
Tests passed but coverage at  39.3% <  92.6%

coverage: 96.7% of statements
Tests passed but coverage at  54.8% <  94.5%
```
Repository: pytorch
Issue: Hardtanh docs are inaccurate/incomplete, since hardtanh behaves like clamp
Labels: module: docs,triaged

### 📚 The doc issue

The issue is more evident when `input` < `max_val` < `min_val`, for example:

```python
import torch

torch.ops.aten.hardtanh(torch.tensor(2), min_val=4, max_val=3)
```
outputs:
```
tensor(3)
```

however, according to the [hardtanh docs](https://pytorch.org/docs/stable/generated/torch.nn.Hardtanh.html) it should return the `min_val`, i.e. 
```
tensor(4)
``` 

### Suggest a potential alternative/fix

The documentation should use `min` and `max`, like clamp's documentation. Something like:

```
HardTanh(x) = min(max(x, min_val), max_value)
```

cc @svekars @carljparker
Repository: TypeScript
Issue: Incorrect error message on invalid union type assignation
Labels: Suggestion,Help Wanted,Experience Enhancement

### 🔎 Search Terms

error message union type assignation

### 🕗 Version & Regression Information

- This is the behavior in every version I tried



### ⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.2.1-rc#code/MYewdgzgLgBMBcMDeAPGiDkBDDMA+MGARrvocBgL4wC8yK82VMAUKJLEYqpjtQT0IlqdYAG4gA

### 💻 Code

```ts
const c: {x : 'a' | 'b'  | 'c'} = {x:'c'} 
const b: {x: 'a'} | {x: 'b'} = c;
```


### 🙁 Actual behavior

The error message is

```
Type '{ x: "a" | "b" | "c"; }' is not assignable to type '{ x: "a"; } | { x: "b"; }'.
  Type '{ x: "a" | "b" | "c"; }' is not assignable to type '{ x: "b"; }'.
    Types of property 'x' are incompatible.
      Type '"a" | "b" | "c"' is not assignable to type '"b"'.
        Type '"a"' is not assignable to type '"b"'.(2322)
```

The problem starts with the line `  Type '{ x: "a" | "b" | "c"; }' is not assignable to type '{ x: "b"; }'.`. It is true that the types are incompatible, but it is not true that this is the source of the error.

In this simple case, it's easy to see where the actual problem is, but with large unions, it becomes hard to know where the error comes from.

### 🙂 Expected behavior

The actual problem is that **type 'c' is not assignable to 'a' | 'b'**, and the error message should mention it. Maybe the full trace should look like this:


```
Type '{ x: "a" | "b" | "c"; }' is not assignable to type '{ x: "a"; } | { x: "b"; }'.
    Types of property 'x' are incompatible.
      Type '"a" | "b" | "c"' is not assignable to type '"a" | "b"'.
        Type '"c"' is not assignable to type '"a" | "b"'.(2322)
```

### Additional information about the issue

When the unions are large and aliased, the misleading message makes errors hard to debug.
Repository: PowerToys
Issue: Allow color change for background of Preview Pane for .SVG files
Labels: Needs-Triage

### Description of the new feature / enhancement

Currently, the preview pane shows a white background for *.svg files. It would be beneficial to the user to be able to change the color of the background to best fit their use case.

### Scenario when this would be used?

When previewing *.svg files that have a lot of white in them, they appear invisible currently. With this feature, the user could change their background of the preview pane (to something like #222222) so that their icons can be seen easily at a glance. Attached is an example of what one of my icons looks like in the preview pane and what it looks like in inkscape:
![Icon in the .SVG Preview Pane](https://github.com/microsoft/PowerToys/assets/56653753/3cf3b0ab-a90b-452c-bbb4-190a35001fe9)

![The same icon in Inkscape](https://github.com/microsoft/PowerToys/assets/56653753/2c33265e-4d42-479e-bd36-c52905e9902a)



### Supporting information

_No response_
Repository: vscode
Issue: Terminal: your 131072x1 screen size is bogus. expect trouble (FYI)
Labels: bug,confirmation-pending,terminal-process

![image](https://github.com/microsoft/vscode/assets/3254987/2c0df5b1-ff95-4de8-9200-52ca3777afe1)

Same as #35798
It only happen once, so this is a FYI issue.


Version: 1.79.2 (user setup)
Commit: 695af097c7bd098fbf017ce3ac85e09bbc5dda06
Date: 2023-06-14T08:57:04.379Z
Electron: 22.5.7
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Windows_NT x64 10.0.22621
Repository: flutter
Issue: [engine] cant build for x86 Android emulator from m1 mac.
Labels: P3,team-engine,triaged-engine

Trying to build for an x86 emulator build from an m1 mac fails due to a compilation error in third_party/dart.

Specifically for the following gn config:

`./tools/gn --unopt --android-cpu=x86 --android`

This will eventually fail with:

```
In file included from ../../third_party/dart/runtime/bin/eventhandler.cc:5:
In file included from ../../third_party/dart/runtime/bin/eventhandler.h:8:
In file included from ../../third_party/dart/runtime/bin/builtin.h:13:
In file included from ../../third_party/dart/runtime/platform/assert.h:8:
../../third_party/dart/runtime/platform/globals.h:348:2: error: Mismatched Host/Target architectures.
#error Mismatched Host/Target architectures.
 ^
1 error generated.

```

Where the line in question is:

```
// Verify that host and target architectures match, we cannot
// have a 64 bit Dart VM generating 32 bit code or vice-versa.
#if defined(TARGET_ARCH_X64) || defined(TARGET_ARCH_ARM64) ||                  \
    defined(TARGET_ARCH_RISCV64)
#if !defined(ARCH_IS_64_BIT) && !defined(FFI_UNIT_TESTS)
#error Mismatched Host/Target architectures.
```

So it seems like there must be multiple architecture defines enabled (arm64 from m1 and x86 from build config). So perhaps there are some baked in assumptions in the dart config?
Repository: go
Issue: proposal: encoding/xml: ignore invalid characters when Decoder.Strict is false
Labels: Proposal

My particular problem would be solved by checking`Decoder.Strict` here:
https://github.com/golang/go/blob/282cd561bbfceef2e32847212cc535dc888143d9/src/encoding/xml/xml.go#L1140

Alternatively, all character validation (including UTF-8) could be ignored and let Go's `0xfffd` take over if a user ever wants a `string` from `StringData`.
https://github.com/golang/go/blob/282cd561bbfceef2e32847212cc535dc888143d9/src/encoding/xml/xml.go#L1133