sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: electron
Issue: [Bug]: app.setLoginItemSettings({ openAtLogin: true }) doesnt work in APPX after publishing it.
Labels: platform/windows,bug :beetle:,30-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

30.0.1

### What operating system are you using?

Windows

### Operating System Version

Windows 10 / 11

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

The next code should add my app to the TaskManager / StartUp List.

`app.setLoginItemSettings({ openAtLogin: true })`

### Actual Behavior

`app.setLoginItemSettings({ openAtLogin: true })` is no working with APPX apps after publishing it.
It is working well in MAS, but not APPX... I was checking that you guys fixed the same problem with MAS a few months ago. So it could be a bug too.

![screen](https://github.com/electron/electron/assets/195716/d9c262b3-58db-44a2-90ca-1e2a52473d08)

You can verify and test with the next app 
https://apps.microsoft.com/detail/9n052x4kr94s?hl=en-us&gl=US

Let me know if you need extra info, Thanks... And I also invite you guys to try this new app if you like :)...


### Testcase Gist URL

_No response_

### Additional Information

_No response_
Repository: node
Issue: Programmatic SEA blob generation API
Labels: feature request,single-executable

Currently, CLI commands and many files are involved in generating a SEA using Javascript.

For example:
```js
import { execSync } from 'node:child_process';
import { copyFileSync, readFileSync, writeFileSync } from 'node:fs';
import { inject } from 'postject';

const blobPath = 'path/to/sea.blob',
	configPath = 'path/to/sea.json',
	outputPath = 'path/to/executable';

writeFileSync(
	configPath,
	JSON.stringify({
		main: 'path/to/main.js',
		output: blobPath,
		disableExperimentalSEAWarning: true,
	})
);
execSync('node --experimental-sea-config ' + configPath, { stdio: 'inherit' });
copyFileSync(process.execPath, outputPath);
await inject(outputPath, 'NODE_SEA_BLOB', readFileSync(blobPath), {
	machoSegmentName: 'NODE_SEA',
	sentinelFuse: 'NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2',
});

```

It would be nice if Node.js provided a Javascript API for generating SEA blobs. This would eliminate extra file creation and streamline the SEA creation process. I propose adding a function to the `node:sea` module/API (Typescript used for clarity):

```ts
/**
 * Configuration options for generating a SEA blob
 * @see https://nodejs.org/api/single-executable-applications.html#generating-single-executable-preparation-blobs
 */
interface BlobConfiguration {
	main: string;
	disableExperimentalSEAWarning?: boolean;
	useSnapshot?: boolean;
	useCodeCache?: boolean;
	assets?: Record<string, string>;
}

/**
 * Generates a SEA blob to be injected into an executable
 * @param config configuration options for the blob
 * @returns The blob contents in a buffer
 */
function generateBlob(config: BlobConfiguration): Buffer;
```

This new function in the SEA API would allow for more streamlined and readable code:
```js
import { copyFileSync } from 'node:fs';
import { generateBlob } from 'node:sea';
import { inject } from 'postject';

const outputPath = 'path/to/executable';

const blob = generateBlob({
	main: 'path/to/main.js',
	disableExperimentalSEAWarning: true,
});
copyFileSync(process.execPath, outputPath);
await inject(outputPath, 'NODE_SEA_BLOB', blob, {
	machoSegmentName: 'NODE_SEA',
	sentinelFuse: 'NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2',
});
```

Which could even be inlined:
```js
import { copyFileSync } from 'node:fs';
import { generateBlob } from 'node:sea';
import { inject } from 'postject';

const outputPath = 'path/to/executable';

copyFileSync(process.execPath, outputPath);
await inject(
	outputPath,
	'NODE_SEA_BLOB',
	generateBlob({
		main: 'path/to/main.js',
		disableExperimentalSEAWarning: true,
	}),
	{
		machoSegmentName: 'NODE_SEA',
		sentinelFuse: 'NODE_SEA_FUSE_fce680ab2cc467b6e072b8b5df1996b2',
	}
);
```

[Discussion](https://github.com/nodejs/single-executable/discussions/92)
[Issue on nodejs/single-executable](https://github.com/nodejs/single-executable/issues/93)
Repository: deno
Issue: `trailers`/`Deno.trailers` support for `Deno.serve` and `fetch`
Labels: web,ext/fetch,ext/http

The [WhatWG discussion on trailers in requests and responses](https://github.com/whatwg/fetch/issues/981) is picking up a bit and it looks like CloudFlare is interested in implementing this as well.

We should implement trailers support for requests and responses behind a Deno-specific symbol that we can then swap out for the full API when standardized:

 - We add an --unstable only `Deno.trailers` unique symbol.
 - We add support for this symbol to `Response`, `Request` and the associated `*Init` objects. The field value would be `Promise<Headers>` or `Promise<HeadersInit>`, respectively
 - If we get support for this in the standard, `Deno.trailers` can be turned from a symbol into a string with the value trailers and marked as deprecated.
- If a promise was provided in `RequestInit` for `fetch`or `ResponseInit` for `Deno.serve`, we'd await that promise before finalizing the associated HTTP transaction.

Initially this would only be supported for HTTP/2, however we could attempt to push support upstream to hyper for HTTP/1. I don't think that will be necessary, however.

This would allow for something like this to work:

```ts
Deno.serve(req => {
  const bodyHash = sha256(req.body);
  const hash = (await req[Deno.trailers])["SHA1-Of-Body"];
  validateBody(hash, bodyHash);
  const { stream, streamHash } = streamResponse(req.url);
  return new Response({ body: stream, [Deno.trailers]: (async () => ({ "SHA1-Of-Body": await streamHash }))() });
});
```
Repository: rust
Issue: When `#![no_main]` is set, `#[start]` is silently ignored
Labels: C-enhancement,P-low,T-compiler

This came up in https://github.com/rust-lang/miri/issues/3498: a user wrote code roughly like this
```rust
#![no_main]
#![feature(start)]

#[start]
fn main() {}
```
and then was surprised that the resulting program didn't have a start function.

The `start` attribute seems to be entirely ignored, because usually there would be an error that the signature is wrong.

The combination of no_main and the `start` attribute should probably emit a suitable diagnostic, instead of silently ignoring the attribute.
Repository: go
Issue: net/netip: FuzzParse failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "net/netip" && test == "FuzzParse"
```

Issue created automatically to collect these failures.

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

    --- FAIL: FuzzParse (0.02s)
        --- FAIL: FuzzParse/seed#53 (0.00s)
            fuzz_test.go:333: netip.AddrPort round trip identity failure: s="[::ffff:192.0.2.128%eth0]:1" x=netip.AddrPort{ip:netip.Addr{addr:netip.uint128{hi:0x0, lo:0xffffc0000280}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(0x40000b89d8)}}, port:0x1} y=netip.AddrPort{ip:netip.Addr{addr:netip.uint128{hi:0x0, lo:0xffffc0000280}, z:unique.Handle[net/netip.addrDetail]{value:(*netip.addrDetail)(0x400000e018)}}, port:0x1}


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: PowerToys
Issue: [File Explorer Preview] Add support for Dockerfile 
Labels: Idea-Enhancement,Product-File Explorer,Needs-Triage,Product-Peek

### Description of the new feature / enhancement

Since yml extensions are already implemented, it's possible to visualize docker-compose.yml file. It would be good to add also the support for Dockerfile

### Scenario when this would be used?

...

### Supporting information

![image](https://github.com/microsoft/PowerToys/assets/56314144/1ab3cb18-7628-4cb1-8592-5c4c14037a03)
Repository: TypeScript
Issue: [ID] `--isolatedDeclarations` disallows `const` initialized with a regex literal
Labels: Bug,Help Wanted,Domain: Isolated Declarations

### 🔍 Search Terms

- isolatedDeclarations
- isolated declaration

### ✅ Viability Checklist

- [X] This wouldn't be a breaking change in existing TypeScript/JavaScript code
- [X] This wouldn't change the runtime behavior of existing JavaScript code
- [X] This could be implemented without emitting different JS based on the types of the expressions
- [X] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
- [X] This isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

I an unsure if it is a bug or a feature request...

An exported `const` without type annotation and initialized with a regex literal triggers the following error `error TS9010: Variable must have an explicit type annotation with --isolatedDeclarations.` in isolated declaration mode.

If I understand correctly, isolated declaration should allow unannotated `const` initialized with any literal?

### 📃 Motivating Example

See an [example on the playground](https://www.typescriptlang.org/play/?isolatedDeclarations=true&ts=5.5.0-beta#code/KYDwDg9gTgLgBAYwgOwM7wBpwLxwPQCGeQA).

### 💻 Use Cases

This could avoid a trivial type annotation.
Repository: TypeScript
Issue: Icons are completely messed up in Visual Studio member list
Labels: Needs Investigation

### 🔎 Search Terms

icon
icon completion

### 🕗 Version & Regression Information

VS 17.10.0 P6

### ⏯ Playground Link

_No response_

### 💻 Code

_No response_

### 🙁 Actual behavior

Icon of Properties is displayed for Parameters:

![image](https://github.com/microsoft/TypeScript/assets/9047283/6194c058-ae2b-455d-ae70-b5e7a8f131f4)

Sometimes it works:

![image](https://github.com/microsoft/TypeScript/assets/9047283/25df35c0-7617-4d15-b808-35757a0ff5d1)

Icon of Parameters is displayed for Classes/Interfaces:

![image](https://github.com/microsoft/TypeScript/assets/9047283/a649c167-536c-4a0c-b310-3001a4827988)

Icon of Parameters is displayed for Local Variables:

![image](https://github.com/microsoft/TypeScript/assets/9047283/7c4c7330-1793-49b3-9b8a-10e4372943b6)




### 🙂 Expected behavior

Correct icons are displayed in the member list.

### Additional information about the issue

_No response_
Repository: ui
Issue: [bug]: block-toolbar component on blocks page stops working if you click the currently active toggle again
Labels: bug

### Describe the bug

The ToggleGroup component on the blocks page stops working if you click the currently active toggle again. 
This is because we pass an empty string to the parseInt function, when the value doesn't change. 
Fixing only requires checking if there is a value.
See here in the radix documentation:
https://www.radix-ui.com/primitives/docs/components/toggle-group#ensuring-there-is-always-a-value

### Affected component/components

-

### How to reproduce

1. Go to Blocks page
2. chose a size
3. click that size again

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Windows, Firefox/Chrome
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: three.js
Issue: Stencil params getting out of sync.
Labels: Browser Issue

### Description

Calls to stencil functions like gl.stencilFunc, gl.stencilOp or gl.stencilMask are ignored when gl.STENCIL_TEST is not enabled. ~~That's  how it works in webgl~~ (Edit: no it doesn't, I was mislead by AI which lead me to a long state cache modifying misadventure and the real issue is in the comments). Regardless of that WebGLState.js is caching these values as current. preventing them from being set correctly when the stencil buffer is enabled afterwards and the value is the same as cached.

### Reproduction steps

Rendering an empty scene should be enough to reproduce the issue.
Renderer clears the frame and calls this.state.buffers.stencil.setMask( 0xffffffff );

At this point the cached currentStencilMask will be set to 0xffffffff but the native call to gl.stencilMask is ignored because gl.STENCIL_TEST is not enabled. The state is now out of sync and subsequent calls with the same value will be ignored because currentStencilMask will match them.

1. in WebglState.js under line `currentStencilMask = stencilMask;` add a new line `console.log('Stencil mask cached correctly', gl.getParameter(gl.STENCIL_WRITEMASK) === currentStencilMask)`
2. Create a basic scene, run and look in the console

### Code

```js
```


### Live example

No live example, requires core modification

### Screenshots

_No response_

### Version

164

### Device

Desktop

### Browser

Chrome

### OS

Windows
Repository: rust
Issue: Wrong suggestion with macro returning no expression
Labels: A-diagnostics,T-compiler

### Code

```Rust
// https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=aa236bae17b94446cb3d4cfd5fa13c5b

macro_rules! m {
    () => {};
}

fn main() {
    let _ = m![];
}
```


### Current output

```Shell
error: macro expansion ends with an incomplete expression: expected expression
 --> src/main.rs:6:13
  |
2 |     () => {};
  |           -- in this macro arm
...
6 |     let _ = m![];
  |             ^^^^ expected expression
  |
  = note: the macro call doesn't expand to an expression, but it can expand to a statement
help: add `;` to interpret the expansion as a statement
  |
6 |     let _ = m![];;
  |                 +
```


### Desired output

```Shell
error: macro expansion ends with an incomplete expression: expected expression
 --> src/main.rs:6:13
  |
2 |     () => {};
  |           -- in this macro arm
...
6 |     let _ = m![];
  |             ^^^^ expected expression
  |
  = note: the macro call doesn't expand to an expression, but it can expand to a statement
help: return an expression from the macro expansion
  |
2 |     () => { /* expression */ };
  |           ~++++++++++++++++++~
```


### Rationale and extra context

The current suggestion adds a semicolon before the existing semicolon, which should at least be detected and, in that case, the current `help:`-line should be suppressed. One could add a specialized help-suggestion as in the desired output above, but that's not really that relevant. So:
if there is a macro assigned to a `let`, I would alter the existing suggestion as mentioned above.

### Other cases

<details>
    <summary>Suggestion if there is a missing semicolon</summary>
Interestingly, the suggestion is kind of correct, if the code is invalid (missing semicolon):

```rust
macro_rules! m {
    () => {};
}

fn main() {
    let _ = m![]
}
```
But even then, the actual suggestion is not that helpful:
```
error: expected `;`, found `}`
 --> src/main.rs:6:17
  |
6 |     let _ = m![]
  |                 ^ help: add `;` here
7 | }
  | - unexpected token

error: macro expansion ends with an incomplete expression: expected expression
 --> src/main.rs:6:13
  |
2 |     () => {};
  |           -- in this macro arm
...
6 |     let _ = m![]
  |             ^^^^ expected expression
  |
  = note: the macro call doesn't expand to an expression, but it can expand to a statement
help: add `;` to interpret the expansion as a statement
  |
6 |     let _ = m![];
  |                 +
```

</details>


### Rust Version

```Shell
$ rustc --version --verbose
rustc 1.77.2 (25ef9e3d8 2024-04-09)
binary: rustc
commit-hash: 25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04
commit-date: 2024-04-09
host: x86_64-unknown-linux-gnu
release: 1.77.2
LLVM version: 17.0.6
```


### Anything else?

_No response_
Repository: kubernetes
Issue: As of go 1.22, there's no need to use the unsafe package for string to bytes conversion
Labels: sig/api-machinery,kind/feature,triage/accepted

### What would you like to be added?

As of go 1.22, for string to bytes conversion, we can replace the usage of `unsafe.Slice(unsafe.StringData(s), len(s))` with type casting `[]bytes(str)`, without the worry of losing performance.

As of go 1.22, string to bytes conversion `[]bytes(str)` is faster than using the `unsafe` package. Both methods have 0 memory allocation now.


I saw at least two places in the codebase still using the `unsafe` way:
+ https://github.com/kubernetes/kubernetes/blob/e342ab05bb903519350cedac784898529eaef06b/staging/src/k8s.io/apiserver/pkg/authentication/token/cache/cached_token_authenticator.go#L277-L286

+ https://github.com/kubernetes/kubernetes/blob/e342ab05bb903519350cedac784898529eaef06b/staging/src/k8s.io/apiserver/pkg/storage/value/encrypt/envelope/kmsv2/envelope.go#L511-L520

Here's my benchmark results, comparing two ways of conversion:

```bash
╰─○ go test -v -run=none -bench=. -benchmem=true
goos: darwin
goarch: amd64
pkg: example.com/m/v2
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
BenchmarkStringToBytesUnsafe
BenchmarkStringToBytesUnsafe-12         1000000000               0.5636 ns/op          0 B/op          0 allocs/op
BenchmarkStringToBytesCasting
BenchmarkStringToBytesCasting-12        1000000000               0.2548 ns/op          0 B/op          0 allocs/op
PASS
ok      example.com/m/v2        1.448s
```

My test code:
```
package main

import (
	"testing"
	"unsafe"
)

const (
	str = "some random string"
)

func toBytes(s string) []byte {
	// unsafe.StringData is unspecified for the empty string, so we provide a strict interpretation
	if len(s) == 0 {
		return nil
	}
	// Copied from go 1.20.1 os.File.WriteString
	// https://github.com/golang/go/blob/202a1a57064127c3f19d96df57b9f9586145e21c/src/os/file.go#L246
	return unsafe.Slice(unsafe.StringData(s), len(s))
}

func toBytesRaw(s string) []byte {
	return []byte(s)
}

func BenchmarkStringToBytesUnsafe(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = toBytes(str)
	}
}

func BenchmarkStringToBytesCasting(b *testing.B) {
	for i := 0; i < b.N; i++ {
		_ = toBytesRaw(str)
	}
}
```


### Why is this needed?

+ Kubernetes as of now is built with go 1.22, in go 1.22 type casting is faster than unsafe, regarding **only** string to bytes conversion
+ We can make string to bytes conversion faster with type casting
+ We don't need to be 'unsafe' anymore
Repository: rust
Issue: hide panic internals in short backtraces
Labels: A-runtime,C-enhancement,T-libs

right now, nearly all `foo.expect("bar")` backtraces start like this:
```
stack backtrace:
   0: rust_begin_unwind
             at /rustc/7f2fc33da6633f5a764ddc263c769b6b2873d167/library/std/src/panicking.rs:652:5
   1: core::panicking::panic_fmt
             at /rustc/7f2fc33da6633f5a764ddc263c769b6b2873d167/library/core/src/panicking.rs:72:14
   2: core::panicking::panic_display
             at /rustc/7f2fc33da6633f5a764ddc263c769b6b2873d167/library/core/src/panicking.rs:256:5
   3: core::panicking::panic_str
             at /rustc/7f2fc33da6633f5a764ddc263c769b6b2873d167/library/core/src/panicking.rs:231:5
   4: core::option::expect_failed
             at /rustc/7f2fc33da6633f5a764ddc263c769b6b2873d167/library/core/src/option.rs:1994:5
   5: core::option::Option<T>::expect
             at /rustc/7f2fc33da6633f5a764ddc263c769b6b2873d167/library/core/src/option.rs:895:21
```

this is not super useful. it doesn't add any information, other than maybe the very last frame which says you called `expect()`. it would be nice to omit anything in the `core::panicking` module from the backtrace; and maybe `expect_failed` and the `core::ops::function::FnOnce::call_once` that show up at the end of the backtrace as well. people can always opt back in with RUST_BACKTRACE=full.

the code for this lives in https://github.com/rust-lang/rust/blob/378a43a06510f3e3a49c69c8de71745e6a884048/library/std/src/sys_common/backtrace.rs#L77-L81

@rustbot label +T-libs +A-runtime
Repository: PowerToys
Issue: Fancy Zone enhancement with Magnifier, that "Locks" a magnification! 
Labels: Needs-Triage

### Description of the new feature / enhancement

**Won't let you move outside the Quadrant that is Magnified to full screen, when you move the mouse to interact with items on the edges of the Quadrant.** 

Being able to bring a "Grid" full screen using the Magnifier, and interact with that Grid only, without the Mouse movement moving the magnification.  

See the Grid Type on my main 4k monitor. See resolution. 

![image](https://github.com/microsoft/PowerToys/assets/8594492/b46a43c6-28b2-4511-8d64-9241f8e7b401)

See the All my windows in the 4 quadrants displayed here. 

![image](https://github.com/microsoft/PowerToys/assets/8594492/1a008182-796d-4133-b031-f9e7ee0cfd72)

See the upper Quadrant as full screen on my 4k monitor

![image](https://github.com/microsoft/PowerToys/assets/8594492/0e51cd08-a951-421d-9f00-0388ea34b23b)


With the current scenario, if I move my mouse toward the bottom left of  the screen to click on Receive a Fax, it will move the magnification out of the Top Quadrant. 

![image](https://github.com/microsoft/PowerToys/assets/8594492/11aca569-fdec-4022-9e8f-3b7f58cd9557)

I would like to create a Fence through PowerToys, that will allow a Quadrant to be full screened with magnification, that would allow the interaction with that full screen, but without the movement of the Magnification to other Quadrants/Screens, when the mouse gets to the edges! 

### Scenario when this would be used?

It would be used in every day work. Allowing greater efficiency of Large Monitors. 

This feature would greatly improve, **Focusing** on a particular task, without the need of "Resizing" Text Fonts in a window! 

**Another GREAT use case** would be RDP into multiple computers/servers. I could use this feature to bring that RDP session full screen, and be able to see it easily, versus squinting at the 4K monitor, or changing the settings of the RDP session. 

I think this would be an awesome PowerToy! 

I think this feature would be used everyday for Focusing! 

### Supporting information

1) here is a picture of the Quadrant Magnified @ 195%

![image](https://github.com/microsoft/PowerToys/assets/8594492/9a118eea-3c24-4d62-a75c-7c67248ef426)

2) here is a picture of the WebPage in Quadrant upper left, with the window "Maxime"

![image](https://github.com/microsoft/PowerToys/assets/8594492/f1d1c541-549e-4f36-8f1a-6cb10239ee26)


See how much better it would be to interact with 1) versus 2)? 
With 2) I would have to change the Font Size/Zoom on the Browser...if I was doing RDP, that would be impossible...