sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: softfloat support for GOARCH=wasm
Labels: Proposal

We are working on proving the execution of go-compiled WASM code using zero-knowledge (ZK) (see https://github.com/DelphinusLab/zkWasm).  However, the current zkWASM prover cannot support floating point instructions (f32.xxx/f64.xxx).  We tried to use `go build -gcflags=all=-d=softfloat` and we found most of the FP instructions are translated to INT ones except `f64.load`, `f64.store`, `f64.ceil`, `f64.floor`.

Q: Is there a way to support softfloat explicitly for WASM or any flags to fully support softfloat?

Test code (fp.go):
```
import "math"

func main() {
	a := 3.5
	b := 2.7
	println(math.Ceil(a))
	println(math.Floor(a))
	println(a / b)
}
```

Commands
```
$ go version
go version go1.21.0 linux/amd64
$ GOOS=js GOARCH=wasm go build -gcflags=all=-d=softfloat fp.go
$ wasm2wat fp | grep 'f32\.'
$ wasm2wat fp | grep 'f64\.'
    f64.load offset=8
    f64.floor
    f64.store offset=16
    f64.load offset=8
    f64.ceil
    f64.store offset=16
```
Repository: go
Issue: proposal: net/http: normalize comma-separated headers
Labels: Proposal

Consider the following [example](https://go.dev/play/p/KmFXvbBX16I):

```go
    // normally the headers arrive from untrusted sources, this is just for exposition
	h := http.Header{}
	h.Add("Accept", "bar, baz")
	h.Add("Accept", "foo")

	// Intuitively this should print: []string{"bar", "baz", "foo"}
	// instead of:                    []string{"bar, baz", "foo"}
	fmt.Printf("%#v\n", h.Values("Accept"))
```

I am not sure we can or want to modify the behaviour of `Values` but I would argue we should still offer a way to get a "normalized" list of values - as in any case if someone really receives a request with those headers they will definitely want to perform that normalization. This is especially important as not doing it (as the current functions "lead" to do) may lead to header-confusion issues.

Just to define "normalization", I am thinking of something like this:

```go
for _, s := range h.Values(key) {
	for _, v := range strings.Split(s, ",") {
		values = append(values, strings.Trim(v, " \t"))
	}
}
```

that, AFAICT, is compliant with [RFC 7230](https://datatracker.ietf.org/doc/html/rfc7230#section-3.2.2).

Assuming we don't want to change the behavior of the existing functions, this could be exposed (the name is a strawman) as

```go
func (h Header) ValuesParsed(k string) (values []string) {
	for _, s := range h.Values(k) {
		for _, v := range strings.Split(s, ",") {
			values = append(values, strings.Trim(v, " \t"))
		}
	}
	return
}
```

(a proper implementation will likely attempt to minimize overhead, so possibly something closer to this [example](https://go.dev/play/p/brnGkM5NAcw))

As a side note, it's a bit unfortunate that `Values` is already taken, as RFC 7230 uses the notation `#(values)` explicitly to mean a comma-separated list of values (that is semantically equivalent to having those values, in order, spread across multiple headers with the same name).

>   A sender MUST NOT generate multiple header fields with the same field
   name in a message unless either the entire field value for that
   header field is defined as a comma-separated list [i.e., #(values)]
   or the header field is a well-known exception (as noted below).
>
>   A recipient MAY combine multiple header fields with the same field
   name into one "field-name: field-value" pair, without changing the
   semantics of the message, by appending each subsequent field value to
   the combined field value in order, separated by a comma.  The order
   in which header fields with the same field name are received is
   therefore significant to the interpretation of the combined field
   value; a proxy MUST NOT change the order of these field values when
   forwarding a message.
Repository: next.js
Issue: Route Segment Config not working for `manifest.ts`
Labels: bug,Metadata

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/wizardly-smoke-rr6gst?file=%2Fapp%2Fmanifest.ts%3A9%2C5

### To Reproduce

1. Create a `manifest.ts` file that fetches data from the server
2. Set `dynamic` route segment config to `force-dynamic` for the manifest file
3. Run `yarn build`
4. Notice that the `manifest.ts` file builds statically
   <img width="501" alt="image" src="https://github.com/vercel/next.js/assets/8862273/2adeb3c1-20b6-4cc1-96c8-be1d0cfe2396">
5. Visit the `manifest.webmanifest` url and notice that the file doesn't change even if the server data changes.

### Current vs. Expected behavior

Currently, the manifest file ignores route segment config and will always render statically. This also means that `headers` and `cookies` cannot be used in this file.

I expect the `manifest.ts` file to behave exactly like a `manifest.webmanifest/route.ts` file with a `GET` handler does when route segment config attributes are set.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 16.17.0
  npm: 8.15.0
  Yarn: 1.22.19
  pnpm: 7.1.0
Relevant Packages:
  next: 13.4.20-canary.18
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router

### Additional context

_No response_
Repository: terminal
Issue: Changing conhost settings without writing them permanently to registry/shortcut
Labels: Issue-Feature,Product-Conhost,Area-UserInterface

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

Originally discussed [here](https://github.com/microsoft/terminal/issues/15458#issuecomment-1572902203).

# Description of the new feature/enhancement

In previous Windows versions, when you open console properties and change something, it was always asking you "Apply properties to current window only" / "Save properties for future windows with same title" / "modify shortcut that started this window":

![image](https://github.com/microsoft/terminal/assets/11453922/b843f31d-b66a-4d97-8862-490d4768fa8b)
![image](https://github.com/microsoft/terminal/assets/11453922/5657a39a-813b-482e-be68-185adef09d3b)

It was quite useful: if you need to experiment with console settings (and if you develop non-trivial console apps, affected by those settings - you do), you just choose "current window only", and all your silly experiments disappear when you close this console window.

But in newer Windows versions that useful confirmation was removed for unknown reasons and the properties are now always quietly saved as if "save for future windows with the same title" or "modify shortcut that started this window" was chosen, meaning that all your silly experiments are now persisted immediately and you have to undo them later manually like an idiot. It is no longer possible to make changes *for the current session only*.

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
"Modify" and "Save" actions should be clearly separated.
One option is to simply restore the feature from pre-Windows 7 codebase.
Another one is to rework it to make it more obvious.
Repository: deno
Issue: `deno install` Import map has different behavior between deno.jsonc and import_map.jsonc 
Labels: bug,cli

deno version: 1.36.4 (release, aarch64-apple-darwin)
os: macos 13.5.1

```typescript
// src/lib.ts
export function lib() {
  console.log('invoke lib successfully');
}
``` 
```typescript
// main.ts
import { lib } from '@/lib.ts';
lib();
```

```javascript
// deno.jsonc
{
  "tasks": {
    "install": "deno install --root=/usr/local --import-map=import_map.jsonc -f -n addd main.ts",
    "install2": "deno install --root=/usr/local -c deno.jsonc -f -n addd main.ts",
    "uninstall": "deno uninstall --root=/usr/local addd"
  },
  "imports": {
    "@/": "./src/"
  }
}
```

```js
// import_map.jsonc
{
  "imports": {
    "@/": "./src/"
  }
}
```

```bash
$ deno task install
Task install deno install --root=/usr/local --import-map=import_map.jsonc -f -n addd main.ts
✅ Successfully installed addd
/usr/local/bin/addd

$ addd
invoke lib successfully
```
```bash
$ deno task install2
Task install2 deno install --root=/usr/local -c deno.jsonc -f -n addd main.ts
✅ Successfully installed addd
/usr/local/bin/addd

$ addd
error: Module not found "file:///usr/local/bin/src/lib.ts".
    at file:///Users/ttaa/Desktop/test/main.ts:1:21
```
Repository: material-ui
Issue: [docs][Rating] Testing the component with @testing-library/user-event results in NaN
Labels: docs,good first issue,package: material-ui,component: rating,ready to take

### Steps to reproduce 🕹

Link to live example: https://codesandbox.io/p/sandbox/eloquent-breeze-7dtljr (run test task and scroll up for console log)

Steps:

1. Install @testing-library/user-event and setup a Rating component with an `onChange` handler
2. In a jest test use

```jsx
const user = userEvent.setup();

user.click(screen.getByLabelText('2 Stars'))
```

4. Observe the `onChange` handler is fired with `newRating` set to `NaN`


### Current behavior 😯

Due to the way user events simulates user interaction the `handleMouseMove` method in MUI's Rating is fired (since user event simulates the mouse movement before issuing the click event). This method however relies on `.getBoundingClientRect` which is not available in jest - or rather it is but all the values are set to 0 which means the `percent` calculation tries to divide by 0 (`(event.clientX - left) / (width * max)`)  which results in a NaN being set as the `hover` state.

In `onChange` since `hover` is set even though the `parseFloat(event.target.value)` parses correctly it is overridden by the `NaN` from hover.

### Expected behavior 🤔

Either this edge case is documented - I didn't find anything about this `handleMouseMove` behavior and how it takes precedence over the click when running the `onChange` callback in the Rating docs or the calculation is adjusted to take into account that `width` could potentially be 0 and the hover should not be set (or be set to -1) in this case - such that `onChange` still reports the `event.target.value` instead.

### Context 🔦

_No response_

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
System:
    OS: macOS 13.5
  Binaries:
    Node: 18.14.2 - ~/.asdf/installs/nodejs/18.14.2/bin/node
    Yarn: 1.22.19 - ~/.asdf/shims/yarn
    npm: 9.5.0 - ~/.asdf/plugins/nodejs/shims/npm
  Browsers:
    Chrome: 116.0.5845.140
    Edge: Not Found
    Safari: 16.6
  npmPackages:
    @emotion/react: 11.11.1 => 11.11.1
    @emotion/styled: 11.11.0 => 11.11.0
    @mui/base:  5.0.0-beta.0
    @mui/core-downloads-tracker:  5.12.2
    @mui/icons-material: 5.10.3 => 5.10.3
    @mui/lab: 5.0.0-alpha.73 => 5.0.0-alpha.73
    @mui/material: 5.10.3 => 5.10.3
    @mui/private-theming:  5.12.0
    @mui/styled-engine:  5.12.0
    @mui/system: 5.10.3 => 5.10.3
    @mui/types:  7.2.4
    @mui/utils: 5.10.3 => 5.10.3
    @mui/x-date-pickers: ^6.6.0 => 6.6.0
    @types/react: 18.2.13 => 18.2.13
    react: 18.2.0 => 18.2.0
    react-dom: 18.2.0 => 18.2.0
    typescript: 5.1.6 => 5.1.6
```
</details>
Repository: create-react-app
Issue: InterpolateHtmlPlugin lodash template bug
Labels: needs triage,issue: bug report

### Describe the bug
According to this [commit](https://github.com/facebook/create-react-app/commit/42140e59b2329bc525cfe2420e2f10bbd683117e), InterpolateHtmlPlugin will replace %MY_VARIABLE% after lodash template excuted.

It will cause this problem that if I write `<%= 'REACT_APP_VARIABLE_1' === 'TEST' %>` and set `"REACT_APP_VARIABLE_1=TEST"`, you can see the result is false.

It is strange, I think it is a bug.

### Reproducible demo
https://github.com/Emiya0306/interpolate-html-plugin-bug-report
https://github.com/Emiya0306/interpolate-html-plugin-bug-report/blob/master/public/index.html
Repository: flutter
Issue: Title should not be mandatory for Horizontal Stepper step class because label property is already available 
Labels: framework,f: material design,c: proposal,P3,team-design,triaged-design

### 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

Currently title is a required pram for stepper class, but if I'm trying to achieve the design same as   'Alternative labels' [material design stepper] (https://m1.material.io/components/steppers.html#steppers-types-of-steppers) then it's not possible because title is  required. 

And if I'm trying to pass emptywidget as title ,because title is a widget.
`title: const SizedBox.shrink(),`
 even though the title's default margin will be there.
or it can be update like this

```dart
_buildHorizontal(){
  .
  .
Container(
                margin: EdgeInsetsDirectional.only(start: widget.steps[i].title != null ? 12.0 : 0),
                child: _buildHeaderText(i),
              ),
``` 

### Proposal

this is very useful if it's implemented
Repository: Web-Dev-For-Beginners
Issue: when i click start code
Labels: no-issue-activity

when i click start code 
![2023-06-30](https://github.com/microsoft/Web-Dev-For-Beginners/assets/122432237/7d12acf9-3867-486e-917a-ff54770e2db1)


_Originally posted by @l3w4idiee3 in https://github.com/microsoft/Web-Dev-For-Beginners/issues/1153_
Repository: rust
Issue: Iterator inlining/optimization regression in 1.72 release
Labels: A-LLVM,P-medium,T-compiler,C-bug,I-heavy,regression-untriaged,C-optimization

<!--
Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to.

Please provide a short summary of the regression, along with any information you feel is relevant to replicate it.
-->

### Code

I tried this code to showcase zero-cost abstractions, and was quite surprised to see a whole bunch of asm as compared to hand-rolled version:

```rust
pub fn some_iterators_nonsense(z:&[i64])->i64{
    z.iter().map(| e| {
          e * e +3 
    }).filter(|e| {
        e % 2 ==0
    }).sum()  
}

```

In the hand-rolled version, the amount of generated asm is way less

```rust
pub fn some_nonsense(z:&[i64])->i64{
    let mut acc = 0;
    for e in z{
        let t = e * e+3 ;
        if t %2 ==0{
            acc += t;
        }
    }
    acc
}
```

According to godbolt, the amount of asm generated for the iterator version is ~3x more than hand-rolled version. Removing the map() operation or filter() operation (and updating the hand-rolled version) makes the issue go away.

### Version it worked on


It most recently worked on: Rust 1.71
It also appears to have worked for many releases before that as well.

### Version with regression

Regression observed on 

 * Rust 1.71
 * Rust 1.72
 * Rust nightly 

<!--
Did the compiler crash? If so, please provide a backtrace.
-->

### Godbolt
The exact code to reproduce is on Matt Godbolt's site:
https://godbolt.org/z/6jb8K3adK
Repository: TypeScript
Issue: Surprising excess property check with recursive generic constraint
Labels: Help Wanted,Possible Improvement

### 🔎 Search Terms

excess property check recursive generic contraint type variable inference

### 🕗 Version & Regression Information

- This is the behavior in every version I tried


### ⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.3.0-dev.20230906#code/C4TwDgpgBAysCGwIwMYAsIFt5QLxQG8AoKKAZwSTIH4AuKAJQhQHsAnAEwB4K2BLAHYBzADSxKydFngA+ANxEAvgqIdmAG3htoAMwCuAlMD4sBUFNsQQAsvHSCIXACoBhUzr5CoEAB5IBHGTiVqgY2DIAFCTm7p70rrGiRACU8W4CHkIqFhBWtvYCEBHEpBACwGwg9ADaBFCgkPQARDosLE1QigC6ItEUVmT0JaRQ8EPRI97llTV1DRDNAEZaHd29k4rrnb2KyQpAA

### 💻 Code

```ts
type StateSchema = {
  states?: Record<string, StateSchema>;
};

declare function createMachine<TConfig extends StateSchema>(
  config: TConfig,
): TConfig;

createMachine({
  entry: [{ type: "foo" }],
  states: {
    a: {
      entry: [{ type: "bar" }],
    },
  },
});
```


### 🙁 Actual behavior

At the nested `entry` property the error is raised:
```
Object literal may only specify known properties, and 'entry' does not exist in type 'StateSchema'.(2353)
```
but it isn't raised at the `entry` property at the root of this object.

### 🙂 Expected behavior

I'd expect no excess property error to be raised with a recursive constraint like this.

### Additional information about the issue

This particular case is somewhat easily fixable by adding `[k: string]: unknown` to `StateSchema`. I still find the reported behavior to be a problem though.
Repository: node
Issue: diagnostics_channel can't subscribe after unsubscribe
Labels: diagnostics_channel

### Version

v18.17.0

### Platform

Darwin JAMF-WMQ02G 22.5.0 Darwin Kernel Version 22.5.0: Thu Jun  8 22:22:20 PDT 2023; root:xnu-8796.121.3~7/RELEASE_ARM64_T6000 arm64

### Subsystem

diagnostics_channel

### What steps will reproduce the bug?

When using `diagnostics_channel` to subscribe to a channel with a handler, after calling `diagnostics_channel.unsubscribe` on that channel I'm unable to add any subsequent handlers to the channel.
Example below uses the `undici:request:create` channel, I'm also experiencing the same issue with the `undici:request:headers` channel.

```javascript
const listenToChannel = (handler) => {
  const undiciRequestCreateChannel = diagnostics_channel.channel('undici:request:create');

  if (!undiciRequestCreateChannel.hasSubscribers) {
    diagnostics_channel.subscribe('undici:request:create', handler);
  }

  return () => {
    diagnostics_channel.unsubscribe('undici:request:create', handler);
  };
};

const undiciRequestCreateChannel = diagnostics_channel.channel('undici:request:create');
const handler1 = () => {
  track('1');
};
const handler2 = () => {
  track('2');
};
const unsub1 = listenToChannel(handler1);

undiciRequestCreateChannel.publish({}); // triggers handler1 as expected
unsub1(); // unsubscribe handler 1

// undiciRequestCreateChannel.hasSubscribers is false here
listenToChannel(handler1); // re-subscribe handler 1
// undiciRequestCreateChannel.hasSubscribers is still false here
undiciRequestCreateChannel.publish({}); // handler1 is not triggered

// we also can't add any other handlers
listenToChannel(handler2); // subscribe handler 2
// undiciRequestCreateChannel.hasSubscribers is false here
undiciRequestCreateChannel.publish({}); // handler2 is not triggered
```

### How often does it reproduce? Is there a required condition?

Reproducible 100% of the time.

### What is the expected behavior? Why is that the expected behavior?

Expected behaviour is that we can add additional handlers to a diagnostics channel after unsubscribing.

### What do you see instead?

Additional handlers are not subscribed to a channel after unsubscribing.

### Additional information

_No response_
Repository: TypeScript
Issue: Intersected type variable with a recursive constraint fails to infer
Labels: Suggestion,Needs Proposal

### 🔎 Search Terms

intersection type variable parameter inference recursive constraint

### 🕗 Version & Regression Information

- This is the behavior in every version I tried

### ⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.3.0-dev.20230906#code/C4TwDgpgBAysCGwIGED2A7AZgSwOYB4AVAQQGNhsMoIAPJdAEwGcongAnbdXAPigF4oAbwBQUaug4gA-AC4oJcpXRjWCJEzlQAShFKp2DfG07cANLHUoMOAoooYePANwiAvq5GhIlxBBikABYQALbwAsKqbH6a8rr6hsYcXLgWcH4BwWEu7p4MegA28OzQmACu6EpUpCV+ALLwQVwQ+Kr2ytR0EIwsJilmbWhYeJ30zL5ImaHwAzwAFPrDuPKEQ7ZQAGQT1ktEZA7oPACU8gDa7RgWqzZ4ALqei2xQXJgQ7CUMAArF8CEsgjUIPVGoFmnNROJulJ5AAiTCoVAwgbiaIaeQQ8RQeDo1SYiTQqAwgBGxSRuKgbmRFIGbiOnhebw+33YvyYrgA9OyoAA9aQiIA

### 💻 Code

```ts
type StateConfig<TAction extends string> = {
  entry?: TAction
  states?: Record<string, StateConfig<TAction>>;
};

type StateSchema = {
  states?: Record<string, StateSchema>;
};

declare function createMachine<
  TAction extends string,
  TConfig extends StateSchema,
>(config: TConfig & StateConfig<TAction>): [TAction, TConfig];

const inferredParams = createMachine({
  entry: "foo",
  states: {
    a: {
      entry: "bar",
    },
  },
});

inferredParams; // ["foo" | "bar", StateSchema]
```


### 🙁 Actual behavior

`TConfig` gets inferred as its constraint

### 🙂 Expected behavior

I'd expect `TConfig` to infer successfully 

### Additional information about the issue

This is very related to the other issue I just created (see [here](https://github.com/microsoft/TypeScript/issues/55644)). The underlying problem of this particular example is the same. The `inferredType` for `TConfig` fails the `compareTypes` check in `getInferredType` [here](https://github.dev/microsoft/TypeScript/blob/6d520282878f87d381d5ce8cf465f1e16a54e797/src/compiler/checker.ts#L25737). This time there is no excess property errors apparent to the user because the excess properties are satisfied through the intersection. 

Despite the problem having the same root cause I think it's worth discussing this separately. The other issue could be closed as design limitation/working as intended but this one feels to me a lot closer to being an actual bug that would be worth fixing.
Repository: PowerToys
Issue: [Peek] Add ability to see git/svn diff if file is in git/svn repo
Labels: Idea-Enhancement,Needs-Triage,Product-Peek

### Description of the new feature / enhancement

When you peek a text/code file it would be nice to show diff with latest commit if there are any uncommited changes.



### Scenario when this would be used?

Mostly QoL.
Having lots of git/svn repos where some of them might have small diffs in several files. In order to check all of them you have to go through a bit longish path of RMB -> GIT/SVN (is it git or svn?) -> Show Log -> etc... for Tortoise Git, or you'd have to open Terminal in the folder, or do it through some other elaborate ways. Some times it's just annoying but having an ability to quickly check each file with a single hotkey sounds a bit faster doesn't it?


### Supporting information

_No response_