sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tensorflow
Issue: Aborted (core dumped) in `tf.raw_ops.SparseConcat`
Labels: stat:awaiting tensorflower,type:bug,comp:ops,2.17

### Issue type

Bug

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

Yes

### Source

source

### TensorFlow version

tf2.17.0 tf2.16.1

### Custom code

Yes

### OS platform and distribution

Ubuntu 20.04

### Mobile device

_No response_

### Python version

3.11

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific inputs, `SparseConcat` triggered a crash.

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

indices1 = tf.constant(2, shape=[3,3], dtype=tf.int64)
values1 = tf.constant("aaaabaaacaaadaaaeaaafaaagaaahaaaiaaajaaakaaalaaamaaanaaaoaaapaaaqaaaraaasaaataaauaaavaaawaaaxaaayaaazaabbaabcaabdaabeaabfaabgaabhaabiaabjaabkaablaabmaabnaaboaabpaabqaabraabsaabtaabuaabvaabwaabxaabyaabzaacbaaccaacdaaceaacfaacgaachaaciaacjaackaaclaacmaacnaacoaacpaacqaacraacsaactaacuaacvaacwaacxaacyaac",
    shape=[3], dtype=tf.string)
shapes1 = tf.constant([5, 2, 2147483647], dtype=tf.int64)

indices2 = tf.constant(-2, shape=[4,3], dtype=tf.int64)
values2 = tf.constant(" ", shape=[4], dtype=tf.string)
shapes2 = tf.constant([5,1879048192,536870912], dtype=tf.int64)

concat_dim = 1
tf.raw_ops.SparseConcat(
    indices=[indices1, indices2], values=[values1, values2], shapes=[shapes1, shapes2], concat_dim=concat_dim, name=None
)
```


### Relevant log output

```shell
2024-11-24 06:36:10.994508: F tensorflow/core/framework/tensor_shape.cc:607] Non-OK-status: RecomputeNumElements() status: INVALID_ARGUMENT: Shape [5,1879048194,2147483647] results in overflow when computing number of elements
Aborted (core dumped)
```
Repository: pytorch
Issue: [Dynamo] Keep weak reference of parameters instead of accessing them by attributes
Labels: triaged,oncall: pt2,module: dynamo,vllm-compile

### 🚀 The feature, motivation and pitch

For this code:

```python
import torch

class DummyModule(torch.nn.Module):
    def __init__(self):
        super(DummyModule, self).__init__()
        self.a = torch.nn.ModuleDict(
            {
                "b": torch.nn.ModuleDict(
                    {
                        "c": torch.nn.ModuleDict(
                            {
                                "d": torch.nn.ModuleDict(
                                    {
                                        "e": torch.nn.Linear(10, 10, bias=False)
                                    }
                                )
                            }
                        )
                    }
                )
            }
        )
    def forward(self, x):
        return self.a.b.c.d.e(x)

model = DummyModule()
opt_model = torch.compile(model)
x = torch.randn(10, 10)
opt_model(x)
```

Dynamo will compile it to be:

```python
def __transformed_code_0_for_forward(self, x):
    __temp_2, = __compiled_fn_1(self._modules['a']._modules['b']._modules['c'].
        _modules['d']._modules['e']._parameters['weight'], x)
    return __temp_2
```

Note that the tensor is accessed via a series of python attribute access.

For real-world models, we can have hundreds of weight parameters, and every parameter needs several layers of accessing. This overhead cannot be removed, even if we use cudagraph.

One potential optimization is: during Dynamo compilation time, we keep a weak reference of the tensor for the parameters, and during forward time, we directly use the saved tensors.

Or we can save all parameters in the top-level `self` object.

Ideal compiled bytecode from Dynamo:

```python
def __transformed_code_0_for_forward(self, x):
    l_self_a_b_c_d_e_weight = self._all_states[0]
    __temp_2, = __compiled_fn_1(l_self_a_b_c_d_e_weight, x)
    return __temp_2
```

This can be even faster than PyTorch's eager mode. We are really doing some compilation time computation and removing the overhead during runtime.

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames @zou3519 @anijain2305 

### Alternatives

_No response_

### Additional context

_No response_
Repository: react-native
Issue: boxShadow on TextInput alternates visible/hidden with each key typed on Android
Labels: Stale,Component: TextInput,Platform: Android,Needs: Author Feedback,Needs: Version Info

### Description

Very simple - when typing in a TextInput on Android, each alternate keypress seems to enable/disable the boxShadow style on the TextInput. This behaviour is not seen on iOS; there, the boxShadow stays visible as expected. 
This affects Expo 52/React Native 0.76. 

### Steps to reproduce

Run the Snack in Android 

### React Native Version

0.76.3

### Affected Platforms

Runtime - Android

### Output of `npx react-native info`

```text
info Fetching system and libraries information...
System:
  OS: Windows 11 10.0.22631
  CPU: (16) x64 Intel(R) Core(TM) i7-9800X CPU @ 3.80GHz
  Memory: 105.98 GB / 127.71 GB
Binaries:
  Node:
    version: 20.10.0
    path: C:\Program Files (x86)\Nodist\bin\node.EXE
  Yarn: Not Found
  npm:
    version: 10.2.3
    path: C:\Program Files (x86)\Nodist\bin\npm.EXE
  Watchman: Not Found
SDKs:
  Android SDK: Not Found
  Windows SDK: Not Found
IDEs:
  Android Studio: AI-242.23339.11.2421.12550806
  Visual Studio: Not Found
Languages:
  Java: 17.0.13
  Ruby: Not Found
npmPackages:
  "@react-native-community/cli":
    installed: 15.1.2
    wanted: latest
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.3
    wanted: 0.76.3
  react-native-windows: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: Not found
  newArchEnabled: Not found
iOS:
  hermesEnabled: Not found
  newArchEnabled: Not found


```


### Stacktrace or Logs

```text
No error - see the Snack.
```


### Reproducer

https://snack.expo.dev/@albertsokol/android-boxshadow-bug-on-textinput

### Screenshots and Videos

_No response_
Repository: rust
Issue: Confusing diagnostic for stray lifetime in type
Labels: A-diagnostics,A-parser,T-compiler,D-confusing

### Code

```Rust
struct Bar;
pub struct Foo<'a>('a, Bar);
```

### Current output

```Shell
error: lifetime in trait object type must be followed by `+`
 --> src/lib.rs:2:20
  |
2 | pub struct Foo<'a>('a, Bar);
  |                    ^^

error[E0224]: at least one trait is required for an object type
 --> src/lib.rs:2:20
  |
2 | pub struct Foo<'a>('a, Bar);
  |                    ^^
```

### Rationale and extra context

[Playground link](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=8784d44966d845deb0f24c469eb86de8)

### Rust Version

Tested on playground so latest stable and nightly at the time of writing (1.82.0 stable)
Repository: godot
Issue: Adding a Window node disables the default cursor shape of sibling Control nodes
Labels: bug,confirmed,topic:gui

### Tested versions

- Reproducible in: 4.3.stable

### System information

Windows 10 - Godot v4.3.stable.steam - Vulkan (Forward+)

### Issue description

Normally, changing the default cursor shape of a control node will change the cursor shape while hovering that node.
However, adding a Window node to the scene will disable that behavior and hovering any control node will only show the default arrow cursor until clicking the node, after which, the nodes start behaving normally again.

This seems to be a focus issue, because setting the window to unfocusable will make the mouse cursor transform normally while hovering control nodes.

### Steps to reproduce

1. Add a button to the scene with the `Mouse > Default Cursor Shape` property set to `Pointing Hand`.
2. Run the game. Hover the button. The cursor should be a pointing hand.
3. Add a Window node to the scene.
4. Run the game. Hover the button. The cursor is now the default arrow head.
5. Click the button. The cursor now transforms into what it is supposed to be: a pointing hand.

### Minimal reproduction project (MRP)

[MRP.zip](https://github.com/user-attachments/files/17892685/MRP.zip)
Repository: rust
Issue: apple-m3 detected as the native CPU for nightly rustc on apple-m4
Labels: A-LLVM,T-compiler,O-AArch64,llvm-fixed-upstream,O-apple,C-external-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 the following code with the latest nightly toolchain on a MacBook Pro M4 Max device:

```bash
$ rustup run nightly rustc --print target-cpus | head -n2
```

I expected to see this happen: 

The output is expected to be as follows, indicating that the detected CPU is `apple-m4`.

```
Available CPUs for this target:
    native          - Select the CPU of the current host (currently apple-m4).
```

Instead, this happened: 

The output indicates that the detected CPU is `apple-m3`, not `apple-m4`.

```
Available CPUs for this target:
    native          - Select the CPU of the current host (currently apple-m3).
```

The latest nightly rustc does recognize `apple-m4` as a valid target-cpu, though:

```bash
$ rustup run nightly rustc --print=cfg -C target-cpu=apple-m4 | grep feature
target_feature="aes"
target_feature="bf16"
target_feature="bti"
...
target_feature="wfxt"
```

### 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.
-->


```bash
$ rustup run nightly rustc --version --verbose 

rustc 1.85.0-nightly (a47555110 2024-11-22)
binary: rustc
commit-hash: a47555110cf09b3ed59811d9b02235443e76a595
commit-date: 2024-11-22
host: aarch64-apple-darwin
release: 1.85.0-nightly
LLVM version: 19.1.4
```

```
$ /usr/sbin/sysctl -n machdep.cpu.brand_string
Apple M4 Max
```


As was the case in the past similar issue, https://github.com/rust-lang/rust/issues/127448 (mis-detection of apple-m3 as apple-m2), this might be addressed by an upcoming update to the upstream LLVM.
This fix (https://github.com/llvm/llvm-project/pull/106599) in LLVM 19.x might be relevant.
Repository: vscode
Issue: The font of global search bar and search bar should be a monospace font.
Labels: bug,search

<!-- ⚠️⚠️ 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. -->

![Image](https://github.com/user-attachments/assets/3d650d90-77e2-4339-9d83-ad30d436c87d)

Can the search bar and the global search bar (and the results) be set to the same monospace font as the workspace?
This is because the content we enter in the search bar is also part of the code itself.

Cheers,
Lu
Repository: ui
Issue: [feat]: Add "Copy Link" Variant to Button Component
Labels: area: request

### Feature description

I’d like to request adding a new variant to the Button component called "Copy Link." This variant would enable users to easily copy a link by clicking the button, with an animation or visual change to indicate the link has been copied successfully. The animation could show a "Copied" state, providing users with clear feedback that the action was successful. This would improve usability and create a more familiar experience for users, as copying links is a common functionality.Currently, the "Copy Link" button in the shadcn examples only have a hover effect but lack any confirmation or feedback to indicate whether the link has been successfully copied. It would be helpful to add a visual indication (like changing the button text to "Copied" or an animation) once the link is copied. This would provide clear feedback to users and enhance the overall user experience, ensuring they know the action was successful.


### Affected component/components

Button

### Additional Context

Additional details here...

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs
Repository: storybook
Issue: [Bug]: Angular signal inputs that are aliased don't work properly
Labels: bug,help wanted,angular,sev:S3

### Describe the bug

Angular allows to alias inputs, for example when kebab-case attribute names are desired ([see here](https://angular.dev/guide/components/inputs#input-aliases)). When I do so and assign such attribute a value in the `args` list then it seems the signal isn't getting the correct value (`InputSignal<string>`) but the value itself directly.

Related to #25784 and PR #26413

### Reproduction link

https://stackblitz.com/edit/github-gh38gu

### Reproduction steps

1. Go to above link
2. Navigate to the story Example\Button\Works
3. Open Devtools' console which will **not** show errors about backgroundColor (which is aliased)
4. Navigate to the story Example\Button\Broken
5. In Devtools' console there will be error messages about backgroundColor only. The attribute foregroundColor is not mentioned and the only difference is it not being aliased in the component.

```
ERROR TypeError: ctx.backgroundColor is not a function
    at ButtonComponent_Template (template.html:6:3)
```

The broken story defines both attribute in the args, that seems to "activate" the difference.

### System

```bash
Storybook Environment Info:

  System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm <----- active
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    @storybook/addon-docs: ^8.5.0-alpha.10 => 8.5.0-alpha.10 
    @storybook/addon-essentials: ^8.5.0-alpha.10 => 8.5.0-alpha.10 
    @storybook/addon-interactions: ^8.5.0-alpha.10 => 8.5.0-alpha.10 
    @storybook/addon-onboarding: ^8.5.0-alpha.10 => 8.5.0-alpha.10 
    @storybook/angular: ^8.5.0-alpha.10 => 8.5.0-alpha.10 
    @storybook/blocks: ^8.5.0-alpha.10 => 8.5.0-alpha.10 
    @storybook/test: ^8.5.0-alpha.10 => 8.5.0-alpha.10 
    storybook: ^8.5.0-alpha.10 => 8.5.0-alpha.10
```

### Additional context

_No response_
Repository: flutter
Issue: When using workspaces the code coverage is broken
Labels: a: tests,framework,has reproducible steps,team-tool,found in release: 3.24,found in release: 3.27

### Steps to reproduce

1. Create a project with at least one test e.g. in `<root>/demo/test/test.dart`
2. Run `cd demo && flutter test --coverage`
3. The generated `<root>/demo/coverage/lcov.info` is not empty
4. Now add a [workspace](https://flutter.dev/go/pub-workspace)
5. Run `flutter test demo/test --coverage`
6. The generated `<root>/coverage/lcov.info` is empty

### Expected results

I expect coverage data when I run the tests

### Actual results

The coverage report file is empty

### Code sample

<!--details open><summary>Code sample</summary-->
See [my autologin_plugin commit](https://github.com/rekire/autologin_plugin/tree/2fdf7216f11860faf6f11ed4d0d96fb24690da39). I have right now no minimal sample. Check the CI output
<!--
```dart
[Paste your code here]
```>

</details-->

<!--
### Screenshots or Video

<details open>
<summary>Screenshots / Video demonstration</summary>

[Upload media here]

</details>
-->

### Logs

<details open><summary>Logs</summary>

```console
$ flutter test autologin/test --coverage       
00:01 +3: All tests passed!
$ du -k coverage/lcov.info
0       coverage/lcov.info
```

</details>


### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.24.5, on macOS 15.1.1 24B91 darwin-arm64, locale de-DE)
[✓] Android toolchain - develop for Android devices (Android SDK version 35.0.0)
[✓] Xcode - develop for iOS and macOS (Xcode 16.1)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2024.2)
[✓] IntelliJ IDEA Community Edition (version 2024.3)
[✓] VS Code (version 1.92.2)
[✓] Connected device (3 available)
[✓] Network resources

• No issues found!
```

</details>
Repository: rust
Issue: Tracking Issue for asm_experimental_reg
Labels: A-inline-assembly,C-tracking-issue

<!--
NOTE: For library features, please use the "Library Tracking Issue" template instead.

Thank you for creating a tracking issue! 📜 Tracking issues are for tracking a
feature from implementation to stabilisation. Make sure to include the relevant
RFC for the feature if it has one. Otherwise provide a short summary of the
feature and link any relevant PRs or issues, and remove any sections that are
not relevant to the feature.

Remember to add team labels to the tracking issue.
For a language team feature, this would e.g., be `T-lang`.
Such a feature should also be labeled with e.g., `F-my_feature`.
This label is used to associate issues (e.g., bugs and design questions) to the feature.
-->

This tracks support for additional registers in architectures where inline assembly is already stable.
The feature gate for the issue is `#![feature(asm_experimental_reg)]`.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.
Discussion comments will get marked as off-topic or deleted.
Repeated discussions on the tracking issue may lead to the tracking issue getting locked.

### Steps
<!--
Include each step required to complete the feature. Typically this is a PR
implementing a feature, followed by a PR that stabilises the feature. However
for larger features an implementation could be broken up into multiple PRs.
-->

- [x] Implementation (https://github.com/rust-lang/rust/pull/131664)
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs
[nightly-style-procedure]: https://github.com/rust-lang/style-team/blob/main/nightly-style-procedure.md 
[Style Guide]: https://github.com/rust-lang/rust/tree/master/src/doc/style-guide

### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->

### Implementation history

<!--
Include a list of all the PRs that were involved in implementing the feature.
-->

- s390x: vreg input/output https://github.com/rust-lang/rust/pull/131664

Other candidates: 
- GPR pair on RISC-V (added in LLVM 20: https://github.com/llvm/llvm-project/commit/4615cc38f35d111f09073f51cc734e29c9211067), Arm, and s390x
- AArch64 SVE types
- RISC-V RVV types

@rustbot label +A-inline-assembly
Repository: stable-diffusion-webui
Issue: [Bug]:all I get is a grey box with nothing in it
Labels: bug-report

### Checklist

- [X] The issue exists after disabling all extensions
- [X] The issue exists on a clean installation of webui
- [ ] The issue is caused by an extension, but I believe it is caused by a bug in the webui
- [X] The issue exists in the current version of the webui
- [ ] The issue has not been reported before recently
- [ ] The issue has been reported before but has not been fixed yet

### What happened?

 no matter what I do all I get is a grey box with nothing in it. The image starts to form, gets slightly clearer and then vanishes into a solid grey box. Please help

### Steps to reproduce the problem


![Screenshot 2024-11-24 035238](https://github.com/user-attachments/assets/eb102cef-8663-4350-bd85-aac6d328f1de)

Tried multiple prompts and negative prompts always comes out the same.
Tried multiple settings samples and schedules

### What should have happened?

I'm pretty sure its supposed to give me a picture

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

Mozilla Firefox

### Sysinfo

[sysinfo-2024-11-24-11-19.json](https://github.com/user-attachments/files/17893015/sysinfo-2024-11-24-11-19.json)


### Console logs

```Shell
unfortunately I don't know how to do this
```


### Additional information

first time user
Repository: PowerToys
Issue: Customizable Key Shortcuts (with sane defaults) to Switch enable/disable a Toy / feature
Labels: Idea-Enhancement,Needs-Triage

### Description of the new feature / enhancement

As a User, I would like to have customizable key shortcuts (with sane defaults) to switch enable/disable a Toy / feature ;-) 

### Scenario when this would be used?

When users want to quickly turn on or off a feature / toy. 
For example I use Keyboard Manager, which I want it _Enabled_ when I type on my Laptop's German keyboard, but _disabled_ when I'm docking it. 

### Supporting information

_No response_