sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: [Bug]: Cannot kill utilityProcess right after creation
Labels: platform/macOS,bug :beetle:,has-repro-gist,component/utilityProcess,32-x-y,33-x-y

### 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 bug report that matches the one I want to file, without success.

### Electron Version

32.1.2

### What operating system(s) are you using?

macOS

### Operating System Version

macOS Sonoma 14.7

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

Utility processes can be killed immediately after starting them, e.g. in error handling logic like the following:

```js
const proc = utilityProcess.fork("utility.js")

try {
  // Failing synchronous code
} catch (err) {
  proc.kill()
}
```

### Actual Behavior

`UtilityProcess.kill()` will return `false`, indicating that killing the process was not successful. The process won't be killed.

### Testcase Gist URL

https://gist.github.com/nikwen/e459685745a8f17c13c38852499d430b

### Additional Information

CC @deepak1556
Repository: go
Issue: cmd/go: TestScript/cgo_long_cmd failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "cmd/go" && test == "TestScript/cgo_long_cmd"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8735615552937511233)):

    === RUN   TestScript/cgo_long_cmd
    === PAUSE TestScript/cgo_long_cmd
    === CONT  TestScript/cgo_long_cmd
        script_test.go:139: 2024-09-27T19:29:36Z
        script_test.go:141: $WORK=/home/swarming/.swarming/w/ir/x/t/cmd-go-test-3329550913/tmpdir263970715/cgo_long_cmd2600984664
        script_test.go:163: 
            PATH=/home/swarming/.swarming/w/ir/x/t/cmd-go-test-3329550913/tmpdir263970715/testbin:/home/swarming/.swarming/w/ir/x/w/goroot/bin:/home/swarming/.swarming/w/ir/x/w/goroot/bin:/home/swarming/.swarming/w/ir/x/w/goroot/bin:/home/swarming/.swarming/w/ir/cache/tools/bin:/home/swarming/.swarming/w/ir/bbagent_utility_packages:/home/swarming/.swarming/w/ir/bbagent_utility_packages/bin:/home/swarming/.swarming/w/ir/cipd_bin_packages:/home/swarming/.swarming/w/ir/cipd_bin_packages/bin:/home/swarming/.swarming/w/ir/cache/cipd_client:/home/swarming/.swarming/w/ir/cache/cipd_client/bin:/home/swarming/.swarming/cipd_cache/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
            HOME=/no-home
            CCACHE_DISABLE=1
            GOARCH=ppc64le
    ...
            [condition not met]
            # Generate a file with a very long #cgo LDFLAGS line.
            # This used to cause "go build" to fail with "argument list too long". (0.336s)
            > go generate
            # Build with the generated file. (0.281s)
            > go build
            [stderr]
            cgolongcmd: invalid flag in #cgo LDFLAGS: 
        script_test.go:163: FAIL: testdata/script/cgo_long_cmd.txt:12: go build: exit status 1
    --- FAIL: TestScript/cgo_long_cmd (0.62s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: rust
Issue: unrelated trait bound being reported as not satisfied
Labels: A-diagnostics,T-compiler

### Code
```rust
trait Foo {
    type Assoc;
}

trait Bar {}

impl<T> Foo for T where T: Bar {
    type Assoc = ();
}

struct Test {
    field: <() as Foo>::Assoc, 
}
```
### Current output
```
error[E0277]: the trait bound `(): Bar` is not satisfied
  --> src/lib.rs:12:12
   |
12 |     field: <() as Foo>::Assoc, 
   |            ^^^^^^^^^^^^^^^^^^ the trait `Bar` is not implemented for `()`, which is required by `(): Foo`
   |
help: this trait has no implementations, consider adding one
  --> src/lib.rs:5:1
   |
5  | trait Bar {}
   | ^^^^^^^^^
note: required for `()` to implement `Foo`
  --> src/lib.rs:7:9
   |
7  | impl<T> Foo for T where T: Bar {
   |         ^^^     ^          --- unsatisfied trait bound introduced here

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` (lib) due to 1 previous error
```
### Desired output
```
error[E0277]: the trait bound `(): Foo` is not satisfied
  --> src/lib.rs:12:12
   |
12 |     field: <() as Foo>::Assoc, 
   |            ^^^^^^^^^^^^^^^^^^ the trait `Foo` is not implemented for `()`
   |
help: this trait has no implementations, consider adding one
  --> src/lib.rs:5:1
   |
5  | trait Foo {
   | ^^^^^^^^^

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` (lib) due to 1 previous error
```
### Rationale and extra context

the problem is exceptionally bad when the error arises in macro generated code, where the `as Foo` cannot be seen in the diagnostic. the real trait bound is also hidden further when using `diagnostic::on_unimplemented`:
```rust
#[diagnostic::on_unimplemented(message = "foo", label = "not foo")]
trait Foo {
    type Assoc;
}

#[diagnostic::on_unimplemented(message = "bar", label = "not bar")]
trait Bar {}

impl<T> Foo for T where T: Bar {
    type Assoc = ();
}

struct Test {
    field: <() as Foo>::Assoc, 
}
```
gives:
```
error[E0277]: bar
  --> src/lib.rs:14:12
   |
14 |     field: <() as Foo>::Assoc, 
   |            ^^^^^^^^^^^^^^^^^^ not bar
   |
   = help: the trait `Bar` is not implemented for `()`, which is required by `(): Foo`
help: this trait has no implementations, consider adding one
  --> src/lib.rs:7:1
   |
7  | trait Bar {}
   | ^^^^^^^^^
note: required for `()` to implement `Foo`
  --> src/lib.rs:9:9
   |
9  | impl<T> Foo for T where T: Bar {
   |         ^^^     ^          --- unsatisfied trait bound introduced here

For more information about this error, try `rustc --explain E0277`.
error: could not compile `playground` (lib) due to 1 previous error
```

### Other cases

_No response_

### Rust Version

latest stable and nightly, but noticed in my own machine using the following version:
rustc 1.83.0-nightly (6c6d21008 2024-09-22)
binary: rustc
commit-hash: 6c6d210089e4589afee37271862b9f88ba1d7755
commit-date: 2024-09-22
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0

### Anything else?

_No response_
Repository: godot
Issue: `AudioServer.get_bus_peak_volume_left_db()` does not work in Web export for samples
Labels: bug,platform:web,topic:audio

### Tested versions

Issue is present in v4.3.stable.official [77dcf97d8]
Issue was not present in v4.2.2.stable.official [15073afe3]

### System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3070 (NVIDIA; 31.0.15.3623) - AMD Ryzen 5 3600X 6-Core Processor (12 Threads)

### Issue description

This is a video of the minimal reproducible example working in-editor:

https://github.com/user-attachments/assets/0fbdd409-2593-44a7-9fb7-70e0c28fdf98

The following is a photo, but the video would look exactly the same since the value does not update when exported to Web.

![Untitled](https://github.com/user-attachments/assets/887245b6-9a51-4e00-9b01-20d9b1a52c2a)

### Steps to reproduce

Export to web. Doesn't seem to matter which rendering mode is used.

### Minimal reproduction project (MRP)
This project uses three nodes:
A sound playing on a loop
A label updating with the value of AudioServer.get_bus_peak_volume_left_db(0,0)
A circle redrawing with size depending on the value of AudioServer.get_bus_peak_volume_left_db(0,0).

[repro.zip](https://github.com/user-attachments/files/17169218/repro.zip)
Repository: vscode
Issue: source control Revert(>)/Stage(+) change buttons no longer work, or are aligned ot the changed block
Labels: bug,diff-editor


Type: <b>Bug</b>

When using Source Control to view unstaged changed, the Revert(>)/Stage(+) change buttons no longer work, or are aligned ot the changed block.

I used to be able to revert a change with the > button.

Now, nothing happens when I click the > button.

VS Code version: Code 1.93.1 (38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40, 2024-09-11T17:20:05.685Z)
OS version: Windows_NT x64 10.0.22635
Modes:

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz (8 x 3302)|
|GPU Status|2d_canvas: enabled<br>canvas_oop_rasterization: enabled_on<br>direct_rendering_display_compositor: disabled_off_ok<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>opengl: enabled_on<br>rasterization: enabled<br>raw_draw: disabled_off_ok<br>skia_graphite: disabled_off<br>video_decode: enabled<br>video_encode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled<br>webgpu: enabled<br>webnn: disabled_off|
|Load (avg)|undefined|
|Memory (System)|31.84GB (5.99GB free)|
|Process Argv|--crash-reporter-id 23e2bccf-b91f-4850-af1e-24dd3f1afe30|
|Screen Reader|yes|
|VM|0%|
</details><details><summary>Extensions (29)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-sidebar|Acr|1.2.3
Bookmarks|ale|13.5.0
LinkCheckMD|bla|0.3.1
vscode-markdownlint|Dav|0.56.0
docs-article-templates|doc|1.0.7
docs-authoring-pack|doc|1.0.2
docs-images|doc|1.0.4
docs-linting|doc|0.0.13
docs-markdown|doc|1.0.11
docs-metadata|doc|1.0.9
docs-preview|doc|1.0.9
docs-scaffolding|doc|1.0.8
docs-visual-areas|doc|0.2.1
docs-yaml|doc|1.0.5
copilot|Git|1.234.0
copilot-chat|Git|0.20.3
Learn-Training-AI-Assistant|Lea|1.1.50
vscode-azurefunctions|ms-|1.15.4
vscode-azureresourcegroups|ms-|0.9.5
vscode-dotnet-runtime|ms-|2.1.6
data-workspace-vscode|ms-|0.5.0
mssql|ms-|1.24.0
sql-bindings-vscode|ms-|0.4.0
sql-database-projects-vscode|ms-|1.4.3
remote-wsl|ms-|0.88.4
azure-account|ms-|0.12.0
powershell|ms-|2024.2.2
vscode-yaml|red|1.15.0
code-spell-checker|str|3.0.1

(1 theme extensions excluded)

</details><details>
<summary>A/B Experiments</summary>

```
vsliv368cf:30146710
vspor879:30202332
vspor708:30202333
vspor363:30204092
vscod805:30301674
binariesv615:30325510
vsaa593cf:30376535
py29gd2263:31024239
c4g48928:30535728
azure-dev_surveyone:30548225
a9j8j154:30646983
962ge761:30959799
pythongtdpath:30769146
welcomedialog:30910333
pythonnoceb:30805159
asynctok:30898717
pythonmypyd1:30879173
2e7ec940:31000449
pythontbext0:30879054
accentitlementsc:30995553
dsvsc016:30899300
dsvsc017:30899301
dsvsc018:30899302
cppperfnew:31000557
dsvsc020:30976470
pythonait:31006305
dsvsc021:30996838
0ee40948:31013168
a69g1124:31058053
dvdeprecation:31068756
dwnewjupyter:31046869
impr_priority:31102340
nativerepl2:31139839
refactort:31108082
pythonrstrctxt:31112756
flighttreat:31134774
wkspc-onlycs-t:31132770
nativeloc2:31134642
wkspc-ranged-t:31125599
fje88620:31121564
iacca1:31138162
notype1cf:31143046

```

</details>

<!-- generated by issue reporter -->
Repository: ui
Issue: [bug]: npx shadcn init doesn't work when variables are in tailwind.config.js
Labels: bug

### Describe the bug

When running `npx shadcn@latest` in a project which has variables within the tailwind.config.js theme.extend, it fails to run with:

```Error replacing tree: The children of the old and new trees were expected to have the same count (8:21).```

There's an issue with ts-morph.

E.g. with:
```
const defaultTheme = require('tailwindcss/defaultTheme');

export default {
    content: ['./src/**/*.{astro,html,js,jsx,md,mdx,svelte,ts,tsx,vue}'],
    theme: {
        extend: {
            fontFamily: {
                sans: ['Plus Jakarta Sans Variable', ...defaultTheme.fontFamily.sans],
                mono: ['Silkscreen', ...defaultTheme.fontFamily.sans]
            },
    plugins: [require('tailwindcss-motion')]
};
```

The ...defaultTheme is causing it to fail. I imagine the parser isn't accounting for variables inside the config, but I think it's quite a common setup

### Affected component/components

N/A

### How to reproduce

1. Use above config
2. Run npx shadcn init

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
MacOS / Warp terminal / Cursor
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: rust
Issue: Unhelpful error message "ambiguous lifetime bound, explicit lifetime bound required"
Labels: A-diagnostics,A-lifetimes,T-compiler,D-terse,A-trait-objects

### Code

```rs
trait MyTrait<'a, 'b> where Self: 'a + 'b {}

pub struct Foo<'a, 'b> {
    expr: Box<dyn MyTrait<'a, 'b>>,
}
// Fix:
pub struct Bar<'all, 'a, 'b> where 'all: 'a, 'all: 'b {
    expr: Box<dyn MyTrait<'a, 'b> + 'all>,
}
```
### Current output
```
error[E0227]: ambiguous lifetime bound, explicit lifetime bound required
 --> src/lib.rs:4:15
  |
4 |     expr: Box<dyn MyTrait<'a, 'b>>,
  |               ^^^^^^^^^^^^^^^^^^^
```
For more information about this error, try `rustc --explain E0227`.

### Desired output

_No response_

### Rationale and extra context

_No response_

### Other cases

_No response_

### Rust Version
```
$ rustc -Vv
rustc 1.81.0 (eeb90cda1 2024-09-04)
binary: rustc
commit-hash: eeb90cda1969383f56a2637cbd3037bdf598841c
commit-date: 2024-09-04
host: x86_64-unknown-linux-gnu
release: 1.81.0
LLVM version: 18.1.7
```
### Anything else?

_No response_
Repository: electron
Issue: [Feature Request]: Calling `UtilityProcess.kill()` on a killed process should return `true`
Labels: enhancement :sparkles:,platform/macOS,component/utilityProcess,32-x-y

### 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 bug report that matches the one I want to file, without success.

### Electron Version

32.1.2

### What operating system(s) are you using?

macOS

### Operating System Version

macOS Sonoma 14.7

### What arch are you using?

arm64 (including Apple Silicon)

### Last Known Working Electron version

_No response_

### Expected Behavior

If I call `UtilityProcess.kill()` on a process that has already been killed, `kill()` should return `true`, indicating that the process is gone.

### Actual Behavior

If I call `UtilityProcess.kill()` on a process that has already been killed, it returns `false`, indicating that killing it failed.

### Testcase Gist URL

https://gist.github.com/e29f65a5a72296f1bff6a72d2c5b00bf

### Additional Information

#### Why this is important

At some places in your code, you might not know if your utility process is still alive or not.  
It would be helpful to get confirmation whether it's gone when we call `kill()` a second time.
Repository: pytorch
Issue: emulate_precision_casts not implemented for cpu
Labels: triaged,oncall: pt2,module: inductor,oncall: cpu inductor

### 🐛 Describe the bug

```
(/home/ezyang/local/c/pytorch-env) [ezyang@devgpu005.nha1 ~/local/c/pytorch (a55aa71b)]$ python t.py
tensor([9.7422], dtype=torch.float16) tensor([9.7344], dtype=torch.float16)
(/home/ezyang/local/c/pytorch-env) [ezyang@devgpu005.nha1 ~/local/c/pytorch (a55aa71b)]$ cat t.py
import torch
import torch._inductor.config

torch._inductor.config.emulate_precision_casts = True

def fn(x, y):
    return x * y.to(dtype=torch.float16)

fn_opt = torch._dynamo.optimize("inductor")(fn)

x = torch.tensor([9.734375], dtype=torch.float16)
y = torch.tensor(1.00048828125, dtype=torch.float32)
print(fn_opt(x, y), fn(x,y))
```

### Versions

main

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: flutter
Issue: No logic in `createRenderObject()`
Labels: framework,P3,team-framework,triaged-framework

Considering the test class from #155699:

```dart
class ThemedCard extends SingleChildRenderObjectWidget {
  const ThemedCard({super.key}) : super(child: const SizedBox.expand());

  @override
  RenderPhysicalShape createRenderObject(BuildContext context) {
    final CardThemeData cardTheme = CardTheme.of(context).data;

    return RenderPhysicalShape(
      clipper: ShapeBorderClipper(shape: cardTheme.shape ?? const RoundedRectangleBorder()),
      clipBehavior: cardTheme.clipBehavior ?? Clip.antiAlias,
      color: cardTheme.color ?? Colors.white,
      elevation: cardTheme.elevation ?? 0.0,
      shadowColor: cardTheme.shadowColor ?? Colors.black,
    );
  }

  @override
  void updateRenderObject(BuildContext context, RenderPhysicalShape renderObject) {
    final CardThemeData cardTheme = CardTheme.of(context).data;

    renderObject
      ..clipper = ShapeBorderClipper(shape: cardTheme.shape ?? const RoundedRectangleBorder())
      ..clipBehavior = cardTheme.clipBehavior ?? Clip.antiAlias
      ..color = cardTheme.color ?? Colors.white
      ..elevation = cardTheme.elevation ?? 0.0
      ..shadowColor = cardTheme.shadowColor ?? Colors.black;
  }
}
```

It's pretty great having the ability to hook up a `RenderObjectWidget` straight to an `InheritedWidget`, but having a single source of truth would help to mitigate future bugs.

<br>

## Proposal: make `RenderObject` constructor arguments optional

```dart
class ThemedCard extends PhysicalShape {
  const MyWidget({super.key});

  @override
  void updateRenderObject(BuildContext context, RenderPhysicalShape renderObject) {
    // single source of truth!
  }
}
```

I should probably reiterate that this isn't strictly necessary for us to do, but it'd still be wonderful.
Repository: rust
Issue: add std and core to nightly-rustc docs
Labels: C-feature-request,C-discussion

[the rustc internal api docs](https://doc.rust-lang.org/nightly/nightly-rustc/) differ from the main `std` docs in two major ways:
1. documenting different crates
2. showing private items

being able to see std-internal items would be quite handy for anyone developing the standard library.
Repository: rust
Issue: impl-trait-overcaptures cannot be applied, missing parens
Labels: A-diagnostics,T-compiler,A-suggestion-diagnostics,D-papercut,D-invalid-suggestion

<!--
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:
` rustc ./tests/ui/impl-trait/dyn-trait-elided-two-inputs-ref-assoc.rs  --force-warn impl-trait-overcaptures`
```rust
// Test that we don't get an error with `dyn Bar` in an impl Trait
// when there are multiple inputs.  The `dyn Bar` should default to `+
// 'static`. This used to erroneously generate an error (cc #62517).
//
//@ revisions: current next
//@[next] compile-flags: -Znext-solver
//@ ignore-compare-mode-next-solver (explicit revisions)
//@ check-pass

trait Foo {
    type Item: ?Sized;

    fn item(&self) -> Box<Self::Item> { panic!() }
}

trait Bar { }

impl<T> Foo for T {
    type Item = dyn Bar;
}

fn is_static<T>(_: T) where T: 'static { }

fn bar(x: &str) -> &impl Foo<Item = dyn Bar> { &() }

fn main() {
    let s = format!("foo");
    let r = bar(&s);
    is_static(r.item());
}

```
```
warning: `impl Foo<Item = (dyn Bar + 'static)>` will capture more lifetimes than possibly intended in edition 2024
  --> ./tests/ui/impl-trait/dyn-trait-elided-two-inputs-ref-assoc.rs:24:21
   |
24 | fn bar(x: &str) -> &impl Foo<Item = dyn Bar> { &() }
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^
   |
   = warning: this changes meaning in Rust 2024
   = note: for more information, see <https://doc.rust-lang.org/nightly/edition-guide/rust-2024/rpit-lifetime-capture.html>
note: specifically, this lifetime is in scope but not mentioned in the type's bounds
  --> ./tests/ui/impl-trait/dyn-trait-elided-two-inputs-ref-assoc.rs:24:11
   |
24 | fn bar(x: &str) -> &impl Foo<Item = dyn Bar> { &() }
   |           ^
   = note: all lifetimes in scope will be captured by `impl Trait`s in edition 2024
   = note: requested on the command line with `--force-warn impl-trait-overcaptures`
help: use the precise capturing `use<...>` syntax to make the captures explicit
   |
24 | fn bar(x: &str) -> &impl Foo<Item = dyn Bar> + use<> { &() }
   |                                              +++++++
```

this does not build:

```
error: ambiguous `+` in a type
  --> ./tests/ui/impl-trait/dyn-trait-elided-two-inputs-ref-assoc.rs:24:21
   |
24 | fn bar(x: &str) -> &impl Foo<Item = dyn Bar> + use<> { &() }
   |                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   |
help: try adding parentheses
   |
24 | fn bar(x: &str) -> &(impl Foo<Item = dyn Bar> + use<>) { &() }
   |                     +                                +
```

### 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.83.0-nightly (2bd1e894e 2024-09-26)
binary: rustc
commit-hash: 2bd1e894efde3b6be857ad345914a3b1cea51def
commit-date: 2024-09-26
host: x86_64-unknown-linux-gnu
release: 1.83.0-nightly
LLVM version: 19.1.0
```
Repository: PowerToys
Issue: Add Shortcut Feature
Labels: Needs-Triage

### Description of the new feature / enhancement

# Adding Shortcuts

I'm here to ask for a feature that helps users add shortcuts to different tools. For example, in the taskbar, start menu or desktop.

![Captura de pantalla 2024-09-27 183427](https://github.com/user-attachments/assets/d24d84d2-cf30-4ed0-b5c2-99f245f8d7fb)

**The previous image was an example and does not work, every time I click on these "shortcuts" they just play the executing animation (pop in and out) and that's all.**

### Scenario when this would be used?

This would be extremely useful as a power user that works a lot with colour picking and Power Run. Having them on my taskbar would help me use them straight away without having to memorize a specific combination of keys.

### Supporting information

_No response_