sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: `FocusScopeNode.descendantsAreFocusable` set to false after disabling and enabling `canRequestFocus`
Labels: a: tests,framework,f: focus,has reproducible steps,P2,team-framework,triaged-framework,found in release: 3.19,found in release: 3.22

Happens with current main (3.22.0-16.0.pre.26).

Widget test to reproduce:
```dart
  testWidgets('FocusScope descendantsAreFocusable', (WidgetTester tester) async {
    final focusScopeNode = FocusScopeNode();
    await tester.pumpWidget(
      FocusScope(
        node: focusScopeNode,
        child: const SizedBox.shrink(),
      ),
    );
    expect(focusScopeNode.descendantsAreFocusable, isTrue);

    focusScopeNode.canRequestFocus = false;
    expect(focusScopeNode.descendantsAreFocusable, isFalse);
 
    focusScopeNode.canRequestFocus = true;
    expect(focusScopeNode.descendantsAreFocusable, isTrue);

    // Disabling canRequestFocus and updating the widget will permanently disable descendantsAreFocusable.
    focusScopeNode.canRequestFocus = false;

    // After this pump, setting canRequestFocus back will not restore
    // descendantsAreFocusable to true.
    await tester.pumpWidget(
      FocusScope(
        node: focusScopeNode,
        child: const SizedBox.shrink(),
      ),
    );

    focusScopeNode.canRequestFocus = true;

    // Test failure:
    // This should be back to true, but in FocusNode state didUpdateWidget the 
    // descendantsAreFocusable on the focusScopeNode got set to false.
    expect(focusScopeNode.descendantsAreFocusable, isTrue);
  });
```

This break focus in `_ModalScopeState` which sets `canRequestFocus` on the scope node and then rebuilds widget, which in turns sets the `descendantsAreFocusable` to false.

@gspencergoog, any thoughts? The focus code is quite convoluted, in this case the `_FocusState.didUpdateWidget` actually overrides property on `FocusScopeNode`, which is quite surprising.
Repository: excalidraw
Issue: `History` improvements
Labels: initiative,history

Similarly to #7914, this initiative encapsulates follow-ups for `History` related functionalities after a large rewrite in #7348.



```[tasklist]
### Tasks
- [ ] https://github.com/excalidraw/excalidraw/issues/7944
- [ ] https://github.com/excalidraw/excalidraw/issues/7936
- [ ] https://github.com/excalidraw/excalidraw/issues/7937
- [ ] https://github.com/excalidraw/excalidraw/issues/1473
- [ ] https://github.com/excalidraw/excalidraw/issues/7948
- [ ] https://github.com/excalidraw/excalidraw/issues/7933
- [ ] https://github.com/excalidraw/excalidraw/issues/7938
- [ ] https://github.com/excalidraw/excalidraw/issues/7934
- [ ] https://github.com/excalidraw/excalidraw/issues/7924
- [ ] https://github.com/excalidraw/excalidraw/issues/7940
- [ ] https://github.com/excalidraw/excalidraw/issues/5714
- [ ] https://github.com/excalidraw/excalidraw/issues/5437
```
Repository: PowerToys
Issue: Enabling Color Picker Causes White Box on Screen
Labels: Issue-Bug,Area-Quality,Area-User Interface,Product-Color Picker

### Microsoft PowerToys version

0.80.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

ColorPicker

### Steps to reproduce

If I enable the Color Picker module a small white box appears on the screen. It's completely empty, unable to be moved or closed in any way. If I disable the Color Picker module, the white box goes away.

https://github.com/microsoft/PowerToys/assets/70973855/fd876d67-e8db-4a85-80ee-3e7fb058143b



### ✔️ Expected Behavior

The white box should not appear.

### ❌ Actual Behavior

White box appears.

### Other Software

_No response_
Repository: terminal
Issue: `"commandPalette", "launchMode": "commandLine"` doesn't work from the command palette
Labels: Help Wanted,Issue-Bug,Product-Terminal,Priority-3,Area-CmdPal

From: https://github.com/MicrosoftDocs/terminal/issues/578

> The setting:
> `{ "command": "commandPalette", "launchMode": "commandLine", "keys": "" }` does not work for my current version of the terminal (Windows Terminal Version: 1.14.2281.0)

Well, that kinda makes sense. If you're already in the command palette, then toggling the command palette will close it, rather than change the mode (which is what's expected here).

FWIW, binding this to a key does work:

```json
        {
            "command":
            {
                "action": "commandPalette",
                "launchMode": "commandLine"
            }, 
            "keys": "ctrl+shift+."
        },
```

I suppose technically, this should move to be a bug on the Terminal repo - the `commandPalette` action with a different mode than the current one should clear the input and switch to that mode. That makes sense. 

But alternatively, you could just backspace the `>`, and _presto_, command-line mode.
Repository: PowerToys
Issue: File resizer, name per preset
Labels: Idea-Enhancement,Product-Image Resizer,Needs-Triage

### Description of the new feature / enhancement

You can insert name per preset output. Take the "filename format" and attach it to every preset editing popup.

### Scenario when this would be used?

I wish you could set a output file name, per preset, I use it to generate different thumbnails, but the naming scheme is different between projects. It's very cumbersome to change the name all the time and remember which had which.

### My proposed solution

![file-resizer-update](https://github.com/microsoft/PowerToys/assets/6534252/b535509f-4582-4ede-9b0e-7b8fcb7f6e7b)
Repository: go
Issue: x/vuln: TestGoModTidy failures
Labels: NeedsInvestigation,vulncheck or vulndb

```
#!watchflakes
default <- pkg == "golang.org/x/vuln" && test == "TestGoModTidy"
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/d0a28709f0e506ee14890ce8a9a8c0afb19f434d)):

    --- FAIL: TestGoModTidy (30.07s)
        all_test.go:107: /workdir/go/bin/go mod tidy: exit status 1
            go: github.com/google/go-cmdtest@v0.4.1-0.20220921163831-55ab3332a786 requires
            	github.com/google/go-cmp@v0.3.1: Get "http://gk3-services-nap-jetxd907-8f582974-j8rl.c.symbolic-datum-552.internal:30157/github.com/google/go-cmp/@v/v0.3.1.mod": dial tcp 10.128.0.12:30157: i/o timeout


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: pytorch
Issue: Scatter_add limitation when accumulate beyond 2^24 under float32 precision
Labels: triaged,module: scatter & gather ops

### 📚 The doc issue

Current `scatter_add_` function has an internal limitation that it cannot accumulate beyond $2^{24}$ under the `float32` precision. It took me a while to isolate and figure out the root cause. To reproduce the result, see the following code snippet and screenshot. You will find that the 0-dimension in tensor `a` no longer accumulate when it hit $2^{24} = 16,777,216$.
```
a = torch.zeros(2, device='cuda')
b = torch.zeros(14453120, device='cuda', dtype=torch.int64)
b[:1147240] = 1
print(a, a.sum())
a.scatter_add_(0, b, a.new_ones(14453120))
print(a, a.sum())
a.scatter_add_(0, b, a.new_ones(14453120))
print(a, a.sum())
a.scatter_add_(0, b, a.new_ones(14453120))
print(a, a.sum())
```
![image](https://github.com/pytorch/pytorch/assets/35260835/30aa0bee-d89b-413e-b4b5-d1b0453c0c70)
However, the workaround is to simply use `float64` precision:
![image](https://github.com/pytorch/pytorch/assets/35260835/80fae002-589d-411b-b184-4ec318d59659)

Right now, this behavior is not documented under [scatter_add doc](https://pytorch.org/docs/stable/generated/torch.Tensor.scatter_add_.html). I think it can be further improved and mentioned to let users be aware of this behavior and choose to use higher precision when necessary.


### Suggest a potential alternative/fix

Mention this behavior in the doc to let users be aware of this behavior and choose to use higher precision when necessary.
Repository: excalidraw
Issue: Keep appState in sync with elements
Labels: UX/UI,history

> Not solely related to `History` component, but it's indirectly causing empty undos / redo, so tying it here for now.

Keeping deleted elements inside (observed) `appState`, such as inside `selectedElementIds`, `selectedGroupIds`, `editingLinearElement` causes empty undos / redos when elements got deleted in the meantime, as the applying logic does not (and should not) expect to deal with such leftovers - it could get unnecessarily complex.

Instead, we should ensure that when deleting elements (explicitly with deletion, implicitly during undo/redo, on both local and remote updates) we also clean the related `appState`, such that there are no appState data pointing to deleted elements (both soft deleted with `isDeleted` flag and force deleted from the scene).

```[tasklist]
### Tasks
- [ ] Cleanup related (observed) `appState` on any type of element deletion
- [ ] Consider doing it generically for any element-related `appState`, potentially a part in the form of a subscription/dependency
```
Repository: excalidraw
Issue: Persist undo / redo stacks between sessions
Labels: UX/UI,history

Partly related to #7928, though we might consider doing this much sooner. The motivation is not to lose undo/redo steps due to unintentional reloads and local data recovery possibilities. However, there are negative impacts to consider as well, which include:

- grow-only in-memory stacks might eventually be hitting memory limits (lazy-loading of certain depth might be necessary)
- users preferring to prune memory (due to memory consumption above, in case of unexpected issues caused by applying increments, etc.)
- invalidating stacks on new deployments could still lead to loss of data, as users now expect the stack to stay between sessions - unless we could perform migrations as stated in #7926
- browsers are in charge and could still eventually prune the data

```[tasklist]
### Tasks
- [ ] Based on the pros and cons, consider persisting the stacks in a lightweight form of #7928 
- [ ] Consider the idea of persisting the stacks for the same users but between different devices
```
Repository: rust
Issue: std::fs::create_dir_all will stack overflow with big paths
Labels: C-bug,T-libs,A-io

<!--
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
std::fs::create_dir_all(big_path);
```

I expected to see this happen: doesn't stack overflow

Instead, this happened:
`std::fs::create_dir_all` with a big path with many uncreated directories will stack overflow on Windows. The max path is [32767](https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry), which can technically result in ~16383 recursive calls, which will stack overflow the 1mb default stack on Windows.

### 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.77.1 (7cf61ebde 2024-03-27)
binary: rustc
commit-hash: 7cf61ebde7b22796c69757901dd346d0fe70bd97
commit-date: 2024-03-27
host: x86_64-pc-windows-msvc
release: 1.77.1
LLVM version: 17.0.6
```


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"xTachyon"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: [flutter_tool] Documentation on Base configurations in XCode with and without CocoaPods 
Labels: platform-ios,tool,d: api docs,t: xcode,P2,team-tool,triaged-tool

### Steps to reproduce

1. flutter create flutter_20240424 --platforms ios
2. add the following to pubspec.yml (probably any packages requiring cocoapods will do)

```
  cloud_firestore: any
  firebase_auth: any
  firebase_messaging: any
  firebase_storage: any
  app_links: any
  firebase_analytics: any
  flutter_barcode_scanner: any
```
3. flutter pub get
4. cd ios
5. pod install



### Actual results

you will see :

```
[!] CocoaPods did not set the base configuration of your project because your project already has a custom config set. In order for CocoaPods integration to work at all, please either set the base configurations of the target `Runner` to `Target Support Files/Pods-Runner/Pods-Runner.profile.xcconfig` or include the `Target Support Files/Pods-Runner/Pods-Runner.profile.xcconfig` in your build configuration (`Flutter/Release.xcconfig`).
```

The issue is that the Runner Profile configuration is set to the Release configuration. Setting it to Pods-Runner.profile makes the error go away, but I don't know what it should be.

This is my modified (and seemingly correct) configuration :

<img width="992" alt="image" src="https://github.com/flutter/flutter/assets/28285/26dfc543-8c34-4e0d-be51-aae6a343b82b">

These base configurations cause a lot of trouble for flutter development, and I have not seen any official advice or documentation online. In my main project I've had #140845 / #138795 holding me up for days. Older articles advised selecting Pods-Runner.xxx directly, which means not including Generated which causes the  #138795 "Null check operator" error (Debug & Release are only 2 lines - they include Pods-Runner.xxx and Generated, and Generated contains the environment variables required by xcode_backend.dart).

Adding packages that require CocoaPods makes the situation more confusing as there are many more configurations in the list. 

I believe some official documentation including screenshots of what the base configurations in XCode should look like with and without CocoaPods would be very helpful. Even if the generated project is fixed, it would still help people with existing projects.


### Logs

<details open>
<summary>Logs</summary>

```console

<!-- Paste your logs here -->

```

</details>


### Flutter Doctor output

<details open>
<summary>Doctor output</summary>

```console

Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel beta, 3.22.0-0.2.pre, on macOS 14.4.1 23E224 darwin-x64, locale en-AU)
[✓] Android toolchain - develop for Android devices (Android SDK version 33.0.2)
[✓] Xcode - develop for iOS and macOS (Xcode 15.3)
[✓] Chrome - develop for the web
[✓] Android Studio (version 2023.2)
[✓] Android Studio (version 2022.2)
[✓] IntelliJ IDEA Ultimate Edition (version 2024.1)
[✓] VS Code (version 1.87.2)
[✓] Connected device (2 available)            
[✓] Network resources

• No issues found!

```

</details>
Repository: flutter
Issue: Add the Autosubmit Metrics dashboard to the 'Flutter Infra Metrics Dashboard'
Labels: team-infra,P1,triaged-infra

### Type of Request

infra task

### Infrastructure Environment

Autosubmit

### What is happening?

Add the already created autosubmit metrics dashboard to the 'Flutter Infra Metrics Dashboard' so that it is publicly viewable.

### Steps to reproduce

Step 1:
Step 2:
..
Step n:


### Expected results

I expect to see X when Y is finished.
Repository: go
Issue: go/format: line comment not indented properly after indented statement
Labels: NeedsInvestigation

### Go version

go version go1.22.2 darwin/arm64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='arm64'
GOBIN=''
GOCACHE='/Users/will/Library/Caches/go-build'
GOENV='/Users/will/Library/Application Support/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='arm64'
GOHOSTOS='darwin'
GOINSECURE=''
GOMODCACHE='/Users/will/Library/Application Support/go/pkg/mod'
GONOPROXY='github.com/FrontRowXP,github.com/frontrowxp'
GONOSUMDB='github.com/FrontRowXP,github.com/frontrowxp'
GOOS='darwin'
GOPATH='/Users/will/Library/Application Support/go'
GOPRIVATE='github.com/FrontRowXP,github.com/frontrowxp'
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/opt/homebrew/Cellar/go/1.22.2/libexec'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/opt/homebrew/Cellar/go/1.22.2/libexec/pkg/tool/darwin_arm64'
GOVCS=''
GOVERSION='go1.22.2'
GCCGO='gccgo'
AR='ar'
CC='cc'
CXX='c++'
CGO_ENABLED='1'
GOMOD='/Users/will/Developer/work/backend/go.mod'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -arch arm64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -ffile-prefix-map=/var/folders/bx/qk0phsxd265fqj512dnnpg080000gp/T/go-build2316146393=/tmp/go-build -gno-record-gcc-switches -fno-common'
```


### What did you do?

https://go.dev/play/p/R-pGjxggfGk

Press Format.

### What did you see happen?

```go
// You can edit this code!
// Click here and start typing.
package main

import "fmt"

func main() {
	// PageContainer
	pageContainerFull := client.PageContainer.Create().
		SetChannelID(channelID).
		SetLanguage(pagecontainer.LanguageEN).
		SetTitle("Page Container Title").
		SaveX(ctx)

		// LocalPageContainer
	client.LocalPageContainer.Create().
		SetChannelID(channelID).
		SetPageContainerID(pageContainerFull.ID).
		SetLanguage(localpagecontainer.LanguageDE).
		SetTitle("Lokaler Seitentitel").
		ExecX(ctx)

	fmt.Println("Hello, 世界")
}
```

Note the extra indent before `// LocalPageContainer`.

### What did you expect to see?

```go
// You can edit this code!
// Click here and start typing.
package main

import "fmt"

func main() {
	// PageContainer
	pageContainerFull := client.PageContainer.Create().
		SetChannelID(channelID).
		SetLanguage(pagecontainer.LanguageEN).
		SetTitle("Page Container Title").
		SaveX(ctx)

	// LocalPageContainer
	client.LocalPageContainer.Create().
		SetChannelID(channelID).
		SetPageContainerID(pageContainerFull.ID).
		SetLanguage(localpagecontainer.LanguageDE).
		SetTitle("Lokaler Seitentitel").
		ExecX(ctx)

	fmt.Println("Hello, 世界")
}
```
Repository: rust
Issue: Tracking Issue for `core::convert::absurd` function
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(convert_absurd)]`

This is a tracking issue for `core::convert::absurd` function, which turns `!` into any type.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::convert

pub const fn absurd<T>(x: !) -> T;
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #124311
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- [ ] How best to document the function (how to deal with mentions of fallback)?

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: electron
Issue: [Feature Request]: Event: 'did-change-theme-color'支持全量的css color (主要支持透明度),不解析也行,直接callback meta content
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

现在只支持 主题颜色格式为 '#rrggbb'
**我需要透明度**

### Proposed Solution

<meta name='theme-color' content='#ffffff'>
....rgba(0,0,0,0)
...transparent
callback 里面可以直接返回content内容,不解析,或者把解析后的,和解析前的都返回

### Alternatives Considered

无

### Additional Information

_No response_
Repository: godot
Issue: OptionButtons do not display tooltips correctly when scrolled downwards
Labels: bug,topic:gui

### Tested versions

Reproducible in v4.2.1.stable.official [b09f793f5]

### System information

Godot v4.2.1.stable - Windows 10.0.19045 - Vulkan (Mobile) - integrated Intel(R) Iris(R) Xe Graphics (Intel Corporation; 31.0.101.4953) - 12th Gen Intel(R) Core(TM) i5-1235U (12 Threads)

### Issue description

Option buttons that have very long lists of items will create a scrollbar on their own to display them all. However, the bounding boxes for item tooltips do not scroll correctly so hovering over an item will display the tooltip of the item several items above it when the bar is scrolled down. If the bar is not scrolled, tooltips display normally.

### Steps to reproduce

Create an option button as the root node.
Attach this script:

```
extends OptionButton
func _ready():
for i in range(100):
	add_item("Option " + str(i))
	set_item_tooltip(i, "Option " + str(i))
```

Run the project and try hovering over the options to see the names. Once you start scrolling, the will begin to be incorrect. Keep scrolling and they stop appearing.

### Minimal reproduction project (MRP)

[MRE.zip](https://github.com/godotengine/godot/files/15084223/MRE.zip)
Repository: godot
Issue: CSG shapes get culled (double?)
Labels: bug,topic:rendering,topic:3d

### Tested versions

I suspect it's a doubles problem but investigating. I'm posting it here to keep track of the investigation. I can't tell if it's our fork or master.

- Not Reproducible in https://github.com/godotengine/godot/commit/c7f56d327d265fa7b2541fe7c5e6cc1730661749
- https://github.com/V-Sekai/godot/commit/45f07c4be4ab6007233a2ffb73d05747f018d834 (doubles)
- Not reproducible in 4.2

### System information

Mac Mini, Apple Silicon, M2 Pro

### Issue description

CSG shapes get culled. It's somehow related to occlusion.

https://www.youtube.com/watch?v=gQND11TyH-4

### Steps to reproduce

1. open res://game/sandbox.tscn in the editor
2. move around 
3. see the csg vehicles disappear

### Minimal reproduction project (MRP)

[godot-crappy-contraptions-main.zip](https://github.com/godotengine/godot/files/15084447/godot-crappy-contraptions-main.zip)