sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Spamming get_view_projection: Condition "!running" is true. Returning: false when VR headset doesn't output tracking info
Labels: bug,needs testing,topic:xr

### Godot version

4.1.stable

### System information

Godot v4.1.stable.mono - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 2070 SUPER (NVIDIA; 31.0.15.3118) - Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 Threads)

### Issue description

I'm using an Oculus Rift S. When the presence detection sensor doesn't detect it's on someone's head, it disables tracking and display output. This causes godot to spit out
```
E 0:00:01:0517   get_view_projection: Condition "!running" is true. Returning: false
  <C++ Source>   modules/openxr/openxr_api.cpp:1509 @ get_view_projection()
```
until the headset is put on.

### Steps to reproduce

Run any project in editor that uses OpenXR with an oculus headset, but not on your face.

### Minimal reproduction project

[ViewProjectionExample.zip](https://github.com/godotengine/godot/files/12036216/ViewProjectionExample.zip)
Repository: godot
Issue: In Tiles using terrain set mode "Match Side " DOES NOT correspond to 2x2 bitmap mode
Labels: discussion,topic:editor,documentation,topic:2d

### Godot version

4.1

### System information

Windows 11

### Issue description

In the official Godot 4.1 Tileset [documentation ](https://docs.godotengine.org/en/stable/tutorials/2d/using_tilesets.html#creating-terrain-sets-autotiling) it states that:
**
> Each terrain set is assigned a mode from Match Corners and Sides, Match Corners and Match sides. 

> Note
> The above modes correspond to the previous bitmask modes autotiles used in Godot 3.x: 2×2, 3×3 or 3×3 minimal.

** 

This is not true, **Match sides** mode DOES NOT correspond to a former 2×2 mode. This is a completely new mode without ANY documentation what so ever.

If the desired behaviour is not a bug then it would be nice if the official documentation at last states that this is mode breaks the compatibility with the old 2x2 mode and is a completely DIFFERENT mode. 

Right now it seems to me a vast number of existing assets is not easily usable with the new mode and I fail to see why was there a need to introduce such breaking changes without leaving the option to use the "old" 2x2 mode.

### Steps to reproduce

Open Godot 3.5 Tileset and use 2x2 bitmap mode.

Then open Godot 4.1 and use the Match sides mode.

### Minimal reproduction project

N/A
Repository: rust
Issue: Lint `conflicting_repr_hint` should explain how to update flagged code
Labels: A-lints,A-diagnostics,C-future-incompatibility,C-bug,L-conflicting_repr_hint

My app using `#[repr(C, u8)] enum` to FFI with a C++ `enum class : uint8_t {}` stopped compiling when updating the toolchain.

The warning produced does not explain how to update this code.
The warning points to: https://github.com/rust-lang/rust/issues/68585
In which this comment says that my code is the obvious way to do that: https://github.com/rust-lang/rust/issues/68585#issuecomment-580734733

The warning should explain how to update my code so that it continues working correctly.
Repository: rust
Issue: bootstrap.py does not support `--set`
Labels: T-bootstrap,C-bug

i tried this code:

```
; x suggest --set build.metrics=true
```

I expected to see this happen: bootstrap is rebuilt and `x suggest` panics because it can't be combined with build-metrics

Instead, this happened: bootstrap is not rebuilt `x suggest` works fine.

this is probably going to be annoyingly difficult to support because bootstrap.py doesn't have an actual toml parser.

### Meta

HEAD is branched from 33a2c2487ac5d9927830ea4c1844335c6b9f77db
Repository: stable-diffusion-webui
Issue: [Bug]: Graphics overload causes the motherboard burned
Labels: asking-for-help-with-local-system-issues

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

When I was using the 4090 to generate a big size pictures, then the computer automatically shut down due to overheating, and then could not turn on. The test found that the motherboard was burned. 

### Steps to reproduce the problem

NO WAY TO BURN IT AGAIN

### What should have happened?

Temperature detection should be added during operation and suspended if excessive temperature is detected. 
You can wait for a while to resume running, or simply stop the entire program.

### Version or Commit where the problem happens

Version: v1.4.0+ (Latest Version)

### What Python version are you running on ?

Python 3.10.x

### What platforms do you use to access the UI ?

Linux

### What device are you running WebUI on?

Nvidia GPUs (RTX 20 above)

### Cross attention optimization

xformers

### What browsers do you use to access the UI ?

Google Chrome

### Command Line Arguments

```Shell
only --xformers
```


### List of extensions

No app extensions

### Console logs

```Shell
null
```


### Additional information

_No response_
Repository: godot
Issue: Unexpected crash when using 'await' on the first frame with a default environment
Labels: bug,topic:rendering,needs testing,crash

### Godot version

4.1.stable

### System information

Godot v4.1.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 31.0.15.3598) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

### Issue description

When a default environment is set on _Project Settings -> Rendering -> Environment -> Default Environment_ and an _await_ is used on the first frame: whether it is on _ready(), _enter_tree() or _process() functions; the game always crashes and throws errors such as:

- Bad address index.
- Internal error setting  property
- The game window closes without any error shown.

The error is consistent within the same project: when removing the _default environment_ from _project settings_ or moving the 'await' calls to the second frame, it stops crashing.

The error seems to not be consistent across machines: when the error occurs on a machine, it occurs consistently but in several other machines it seems to not happen at all. From what I've gathered from my tests, it seems to always occur on AMD processors (tested on Ryzen 5000 series only) and not in Intel processors. All tests were done on Windows 10.

### Steps to reproduce

- Create a new project.
- Set up a basic scene with a script calling a 'await' on the first frame of the execution (_ready() works)
- Create an environment resource and set it as a default environment on _Project Settings -> Rendering -> Environment -> Default Environment_.
- Execute the scene

### Minimal reproduction project

[Min_reproduction_project_environment_crash.zip](https://github.com/godotengine/godot/files/12037840/Min_reproduction_project_environment_crash.zip)
Repository: go
Issue: cmd/compile: bounds check not needed
Labels: Performance,NeedsInvestigation,compiler/runtime


https://godbolt.org/z/EW16jnEG7
As you can see, there is panicIndex, on s[I + j]. But in golang, for i := 0; I < len(s); I++ doesn't go into panicIndex. Why does
```
for i := 0; i < len(s) - len(t); i++ {
    for j := 0; j < len(t); j++ {
         s[i + j]
    }
}
```
calls panicIndex? There is no need in this. Compiler sees that i + j is always in range [0, len(s)). Easy optimisation, probably not only in this case.
Repository: excalidraw
Issue: bound arrow to same rect, move rect, arrow goes wrong
Labels: bug,Arrow Binding

Steps to reproduce:
- bound arrow to same rect
-  move rect

https://github.com/excalidraw/excalidraw/assets/87802698/1a1b9e56-8a0f-4830-b4ff-58f64fba624b
Repository: storybook
Issue: [Bug]: In Vue 3 JSX or `h` renderer Controls won't cause re-render and update of the component
Labels: bug,vue3

### Describe the bug

## Setup

```ts
import type { Meta, StoryObj } from '@storybook/vue3';

import Button from './Button.vue';
import { h } from 'vue';

// More on how to set up stories at: https://storybook.js.org/docs/vue/writing-stories/introduction
const meta = {
  title: 'Example/Button',
  component: Button,
  // This component will have an automatically generated docsPage entry: https://storybook.js.org/docs/vue/writing-docs/autodocs
  tags: ['autodocs'],
  argTypes: {
    size: { control: 'select', options: ['small', 'medium', 'large'] },
    backgroundColor: { control: 'color' },
    onClick: { action: 'clicked' },
  },
  args: { primary: false, label: "Click me" }, // default value
} satisfies Meta<typeof Button>;

export default meta;
type Story = StoryObj<typeof meta>;
```

## Default render with template - WORKS

- Changing the value of `size` in the control causes a re-render of the canvas and the new size is displayed

```ts
export const Primary: Story = {
  args: {
    primary: true,
    label: 'Button',
  },
  render: (args) => ({
    components: { Button },
    setup() {
      return { args };
    },
    template: '<Button v-bind="args" />',
  })
};
```

## Render with JSX - DOESN'T WORKS

- Changing the value of `size` in the control won't update the canvas, unless clicking on "remount component" icon manually.

```tsx
export const Large: Story = {
  args: {
    label: 'Button',
    size: 'large',
  },
  // @ts-expect-error
  render: (args) => <Button {...args} />,
};

```

## Render with`h` renderer - DOESN'T WORKS

- Changing the value of `size` in the control won't update the canvas, unless clicking on "remount component" icon manually.

```ts
export const Secondary: Story = {
  args: {
    primary: false,
    label: 'Button',
  },
  render: (args) => h(Button, args),
};
```

### To Reproduce

https://github.com/floroz/storybook-vue3-renderer-bug/blob/main/src/stories/Button.stories.tsx

### System

```shell
System:
    OS: macOS 13.2
    CPU: (8) arm64 Apple M1 Pro
  Binaries:
    Node: 18.16.0 - ~/.nvm/versions/node/v18.16.0/bin/node
    npm: 9.5.1 - ~/.nvm/versions/node/v18.16.0/bin/npm
  Browsers:
    Chrome: 114.0.5735.198
    Edge: 114.0.1823.51
    Safari: 16.3
  npmPackages:
    @storybook/addon-essentials: ^7.0.27 => 7.0.27 
    @storybook/addon-interactions: ^7.0.27 => 7.0.27 
    @storybook/addon-links: ^7.0.27 => 7.0.27 
    @storybook/blocks: ^7.0.27 => 7.0.27 
    @storybook/testing-library: ^0.0.14-next.2 => 0.0.14-next.2 
    @storybook/vue3: ^7.0.27 => 7.0.27 
    @storybook/vue3-vite: ^7.0.27 => 7.0.27
```


### Additional context

_No response_
Repository: angular
Issue: FormGroup controls object prototype invalid behavior
Labels: area: forms

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

No

### Description

Due to check this.controls via index access we fail with FormControls with names from Object.prototype

```typescript
const formGroup = new FormGroup({
        constructor: new FormControl(),
        valueOf: new FormControl(),
      });
      console.log('initial constructor', formGroup.get('constructor'));
      console.log('initial valueOf', formGroup.get('valueOf'));

      const emptyFormGroup = new FormGroup({});
      console.log('empty', emptyFormGroup.get('constructor'));

      emptyFormGroup.addControl('constructor', new FormControl());
      console.log('add constructor', emptyFormGroup.get('constructor'));

      emptyFormGroup.addControl('valueOf', new FormControl());
      console.log('add valueOf', emptyFormGroup.get('valueOf'));
```

### Please provide a link to a minimal reproduction of the bug

_No response_

### Please provide the exception or error you saw

```true
I can add form controls via constructor, but fail via methods.
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
@angular/forms: '>15.0.0' at least
```


### Anything else?

_No response_
Repository: tensorflow
Issue: keras.models.load_model broken if custom objects present (.keras format)
Labels: stat:awaiting tensorflower,type:bug,comp:keras,comp:model,TF 2.13

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

No

### Source

binary

### TensorFlow version

tf2.13

### Custom code

Yes

### OS platform and distribution

All

### Mobile device

_No response_

### Python version

3.8

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Models do not load.  Errors vary, depending on the number of training samples being divisible by batch size or not.

### Standalone code to reproduce the issue

```shell
import keras
import numpy as np


class MyCustomLSTM(keras.layers.LSTM):
    """
    Custom LSTM
    """


model = keras.models.Sequential([MyCustomLSTM(32), keras.layers.Dense(1)])

model.compile(keras.optimizers.Adam(), keras.losses.mse)

x = np.zeros((1024, 300, 1))
y = np.zeros((1024, 1))

history = model.fit(x, y, batch_size=32, epochs=1)

model.save('test.keras')

model_loaded = keras.models.load_model('test.keras', custom_objects={'MyCustomLSTM': MyCustomLSTM})
# This throws:
# IndexError: list assignment index out of range

# If the number of samples is not divisible by the batch size (e.g. 1025 samples, instead of 1024), the error becomes:
# ValueError: as_list() is not defined on an unknown TensorShape.
```


### Relevant log output

_No response_
Repository: excalidraw
Issue: [feature request] zoom box
Labels: enhancement,discussion

In any design application I use – there is a zoom box feature. Holding Z + click and drag to make a rectangle for zooming. It's the only basic functionality that I'm missing in Excallidraw. Please consider adding it. It will improve my (and hopefully many others) experience drastically.
Repository: react-native
Issue: `borderBottomColor` does not override `borderColor` on Android (RN 0.72)
Labels: Issue: Author Provided Repro,Platform: Android,Bug

### Description

When using a `borderColor` and `borderBottomColor` with different values on the same `View`:

Expected result: 3 borders have the `borderColor` color, and 1 has the `borderBottomColor` color.

Actual result (on Android, with RN 0.72): the 4 borders have the `borderColor` color.

This seems to be a regression from RN 0.71.8, where the issue is not present.

### React Native Version

0.72.3

### Output of `npx react-native info`

```
System:
  OS: macOS 13.5
  CPU: (10) arm64 Apple M1 Pro
  Memory: 104.83 MB / 16.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 18.16.1
    path: ~/Library/Caches/fnm_multishells/21852_1689230437449/bin/node
  Yarn:
    version: 3.6.1
    path: /opt/homebrew/bin/yarn
  npm:
    version: 9.5.1
    path: ~/Library/Caches/fnm_multishells/21852_1689230437449/bin/npm
  Watchman:
    version: 2023.07.10.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.11.3
    path: /Users/matthieugicquel/.gem/ruby/3.1.0/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.0
      - iOS 17.0
      - macOS 14.0
      - tvOS 17.0
      - watchOS 10.0
  Android SDK:
    API Levels:
      - "33"
      - "33"
    Build Tools:
      - 30.0.3
      - 33.0.0
      - 33.0.2
    System Images:
      - android-33-ext5 | Google Play ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2022.1 AI-221.6008.13.2211.9619390
  Xcode:
    version: 15.0/15A5160n
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 11.0.19
    path: /usr/bin/javac
  Ruby:
    version: 3.1.4
    path: /opt/homebrew/opt/ruby@3.1/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.72.3
    wanted: 0.72.3
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false
```

### Steps to reproduce

Here are screenshots and a minimal example:

<img width="443" alt="Capture d’écran 2023-07-13 à 13 06 21" src="https://github.com/facebook/react-native/assets/10573690/342a198a-c508-4a8d-aa78-d348bf943fa3">

```tsx
const App = () => {
  return <View style={styles.buggy} />;
};

const styles = StyleSheet.create({
  buggy: {
    height: 100,
    width: 100,
    borderWidth: 1,
    backgroundColor: "lightgray",
    borderColor: "transparent",
    borderBottomColor: "blue",
  },
});
```


### Snack, code example, screenshot, or link to a repository

https://snack.expo.dev/@matthieugc/border-color-wrongly-combined

⚠️ snack doesn't provide expo SDK 49 so **you won't see the bug here for now**
Repository: rust
Issue: Wrong `cargo fix` output
Labels: A-diagnostics,T-compiler,C-bug,D-invalid-suggestion

I tried this code:

```rust
fn main() {
    let vec = Vec::<(usize,)>::new();
    let mut v: usize = 0;

    for (mut i,) in vec.iter() {
        foo(&mut v, i)
    }
}

fn foo<T>(_: &mut T, _: T) {}
```

Git repo for reproduction: https://github.com/SDesya74/rustfmt-err

I expected to see this happen: cargo removes `mut` and adds dereference to `i`.

Instead, this happened: `cargo fix` shows error:
<details><summary>Output</summary>
<p>

```
    Checking rustfmt-err v0.1.0 (/Users/me/dev/tests/rustfmt-err)
warning: failed to automatically apply fixes suggested by rustc to crate `rustfmt_err`

after fixes were automatically applied the compiler reported errors within these files:

  * src/main.rs

This likely indicates a bug in either rustc or cargo itself,
and we would appreciate a bug report! You're likely to see
a number of compiler warnings after this message which cargo
attempted to fix but failed. If you could open an issue at
https://github.com/rust-lang/rust/issues
quoting the full output of this command we'd be very appreciative!
Note that you may be able to make some more progress in the near-term
fixing code with the `--broken-code` flag

The following errors were reported:
error[E0308]: mismatched types
  --> src/main.rs:6:21
   |
6  |         foo(&mut v, i)
   |         ---         ^ expected `usize`, found `&usize`
   |         |
   |         arguments to this function are incorrect
   |
note: function defined here
  --> src/main.rs:10:4
   |
10 | fn foo<T>(_: &mut T, _: T) {}
   |    ^^^               ----
help: consider dereferencing the borrow
   |
6  |         foo(&mut v, *i)
   |                     +

error: aborting due to previous error

For more information about this error, try `rustc --explain E0308`.
Original diagnostics will follow.

warning: variable does not need to be mutable
 --> src/main.rs:5:10
  |
5 |     for (mut i,) in vec.iter() {
  |          ----^
  |          |
  |          help: remove this `mut`
  |
  = note: `#[warn(unused_mut)]` on by default

warning: `rustfmt-err` (bin "rustfmt-err") generated 1 warning (run `cargo clippy --fix --bin "rustfmt-err"` to apply 1 suggestion)
warning: `rustfmt-err` (bin "rustfmt-err" test) generated 1 warning (1 duplicate)
    Finished dev [unoptimized + debuginfo] target(s) in 0.58s
```

</p>
</details>

### 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`:
```
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: aarch64-apple-darwin
release: 1.70.0
LLVM version: 16.0.2
```
Repository: rust
Issue: rustc doesn't mention method candidates with better matching signatures
Labels: A-diagnostics,T-compiler,C-bug

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
trait Foo {
    fn foo(&mut self, x: u32, y: u32) -> u32;
}

struct A;

impl A {
    fn foo(&self, x: u32, y: u32, z: u32) -> u32 {
        x + y + z
    }
}

impl Foo for A {
    fn foo(&mut self, x: u32, y: u32) -> u32 {
        self.foo(x, y, 1)
    }
}

fn main() {
    let mut a = A {};
    let b: &mut dyn Foo = &mut a;
    
    println!("b.foo(2, 3) = {}", b.foo(2, 3))
}
```
this happened: compilation failed with the following error
```
error[E0061]: this function takes 2 arguments but 3 arguments were supplied
  --> src\main.rs:15:14
   |
15 |         self.foo(x, y, 1)
   |              ^^^       - argument of type `{integer}` unexpected
   |
note: associated function defined here
  --> src\main.rs:2:8
   |
2  |     fn foo(&mut self, x: u32, y: u32) -> u32;
   |        ^^^
help: remove the extra argument
   |
15 |         self.foo(x, y)
   |                 ~~~~~~

For more information about this error, try `rustc --explain E0061`.
error: could not compile `trait-test` due to previous error
```

### 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`:
```
rustc 1.66.1 (90743e729 2023-01-10)
binary: rustc
commit-hash: 90743e7298aca107ddaa0c202a4d3604e29bfeb6
commit-date: 2023-01-10
host: x86_64-pc-windows-msvc
release: 1.66.1
LLVM version: 15.0.2
```

Issue can be reproduced at https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=ecfd93556f9b1cfb4e25b2d23f542e5f (rustc version is 1.70.0)

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
error[E0061]: this function takes 2 arguments but 3 arguments were supplied
  --> src\main.rs:15:14
   |
15 |         self.foo(x, y, 1)
   |              ^^^       - argument of type `{integer}` unexpected
   |
note: associated function defined here
  --> src\main.rs:2:8
   |
2  |     fn foo(&mut self, x: u32, y: u32) -> u32;
   |        ^^^
help: remove the extra argument
   |
15 |         self.foo(x, y)
   |                 ~~~~~~

For more information about this error, try `rustc --explain E0061`.
error: could not compile `trait-test` due to previous error
```

</p>
</details>

rustc could note about the other method candidate, telling the user why it preferred the one with the wrong signature.
Repository: tauri
Issue: [feat] Disabling standard browser keyboard shortcuts
Labels: type: feature request

### Describe the problem

I didn't find a way to do this in **tauri.conf.json**. Perhaps this can be done in some other way.

List of browser keyboard shortcuts:

https://support.microsoft.com/en-us/microsoft-edge/keyboard-shortcuts-in-microsoft-edge-50d3edab-30d9-c7e4-21ce-37fe2713cfad

### Describe the solution you'd like

The ability to set up a keyboard shortcut in **tauri.conf.json** seems to me the most convenient way to solve the problem.

### Alternatives considered

For now, I'm assuming that this can only be achieved with **addEventListener** per combination.

### Additional context

_No response_
Repository: flutter
Issue: --update-goldens should fail the tests
Labels: a: tests,tool,c: proposal,P3,team-tool,triaged-tool

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

If `--update-goldens` flag is added to `flutter test` by accident, golden tests will never break on a mismatch. This can hide errors.

### Proposal

If `--update-goldens` flag is used, tests should fail after updating all goldens, if any.

Suggested by:
- @kevmoo in https://github.com/kevmoo/source_gen_test/pull/32#issuecomment-1633412332
- @btrautmann in https://github.com/kevmoo/source_gen_test/pull/32#issuecomment-1612012845