sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Angular 17 New Control Flow | Allow more than one node at root @if, @else, @for, etc
Labels: feature,area: core,core: content projection,feature: votes required

### Which @angular/* package(s) are relevant/related to the feature request?

core

### Description

Allow multiple child nodes inside new control flow like bellow

```html
<app-box>
  @if (selected === 'fish'){
    <span header> Fish </span>
    <span main> 🐟 🐡 🐙 🐠  </span>
  } @else {
    <span header> Mammals </span>
    <span main> 🦍 🐅 🦬 🐫  </span>
  }
</app-box>
```

without throwing bellow error

Node matches the "[header]" slot of the "BoxComponent" component, but will not be projected into the specific slot because the surrounding @if has more than one node at its root. To project the node in the right slot, you can:

1. Wrap the content of the @if block in an <ng-container/> that matches the "[header]" selector.
2. Split the content of the @if block across multiple @if blocks such that each one only has a single projectable node at its root.
3. Remove all content from the @if block, except for the node being projected.

This check can be disabled using the `extendedDiagnostics.checks.controlFlowPreventingContentProjection = "suppress" compiler option.`

### Proposed solution

Make bellow snippet work

```html
<app-box>
  @if (selected === 'fish'){
    <span header> Fish </span>
    <span main> 🐟 🐡 🐙 🐠  </span>
  } @else {
    <span header> Mammals </span>
    <span main> 🦍 🐅 🦬 🐫  </span>
  }
</app-box>
```

### Alternatives considered

Since I am using projections I have to use multiple @if 

```html
<app-box>
@if (selected === 'fish'){
  <span header> Fish </span>
}    
@if (selected === 'mammals'){
  <span header> Mammals </span>
}
@if (selected === 'fish'){
  <span main> 🐟 🐡 🐙 🐠  </span>
}
@if (selected === 'mammals'){
  <span main> 🦍 🐅 🦬 🐫  </span>
}
</app-box>
```

but this approach is a pain in the *ss, more verbose and less readable
Repository: go
Issue: x/vuln: false positive call stack for GO-2023-2402 in Kubernetes
Labels: NeedsInvestigation,vulncheck or vulndb

```
$ govulncheck ./...
Scanning your code and 2016 packages across 204 dependent modules for known vulnerabilities...

Vulnerability #1: GO-2023-2402
    Man-in-the-middle attacker can compromise integrity of secure channel in
    golang.org/x/crypto
  More info: https://pkg.go.dev/vuln/GO-2023-2402
  Module: golang.org/x/crypto
    Found in: golang.org/x/crypto@v0.14.0
    Fixed in: golang.org/x/crypto@v0.17.0
    Example traces found:
      #1: test/e2e/framework/ssh/ssh.go:316:33: ssh.runSSHCommandViaBastion calls ssh.Client.Dial
      #2: test/e2e/framework/ssh/ssh.go:329:35: ssh.runSSHCommandViaBastion calls ssh.Client.NewSession
      #3: test/e2e/framework/ssh/ssh.go:301:32: ssh.runSSHCommandViaBastion calls ssh.Dial
      #4: test/e2e/framework/ssh/ssh.go:326:25: ssh.runSSHCommandViaBastion calls ssh.NewClient
      #5: test/e2e/framework/ssh/ssh.go:322:44: ssh.runSSHCommandViaBastion calls ssh.NewClientConn
      #6: test/e2e/framework/ssh/ssh.go:333:2: ssh.runSSHCommandViaBastion calls ssh.Session.Close
      #7: test/e2e/framework/ssh/ssh.go:339:22: ssh.runSSHCommandViaBastion calls ssh.Session.Run
      #8: test/e2e/framework/ssh/ssh.go:320:2: ssh.runSSHCommandViaBastion calls ssh.channel.Close
      #9: test/utils/harness/harness.go:54:14: harness.Harness.Close calls ssh.stdin, which calls ssh.channel.CloseWrite
      #10: cmd/kubeadm/app/preflight/checks.go:339:18: preflight.FileContentCheck.Check calls io.Copy, which eventually calls ssh.channel.Read
      #11: cmd/kubeadm/app/preflight/checks.go:544:13: preflight.SystemVerificationCheck.Check calls bufio.Writer.Flush, which calls ssh.channel.Write
      #12: cmd/kubeadm/app/preflight/checks.go:339:18: preflight.FileContentCheck.Check calls io.Copy, which eventually calls ssh.extChannel.Read

Your code is affected by 1 vulnerability from 1 module.

Share feedback at https://go.dev/s/govulncheck-feedback.
```

There are doubts about the next three traces found

> calls io.Copy, which eventually calls ssh.channel.Read
> calls bufio.Writer.Flush, which calls ssh.channel.Write
> calls io.Copy, which eventually calls ssh.extChannel.Read

@neolit123 @dims 

xref: https://github.com/kubernetes/kubernetes/issues/122424
Repository: node
Issue: v8 test coverage in jest is incorrect when upgrading to 20.10.0
Labels: v8 engine,inspector

### Version

20.10.0

### Platform

Macbook Pro M1/M2 / Ubuntu 22.04 x64 (GitHub runner)

### Subsystem

V8

### What steps will reproduce the bug?

See https://github.com/jestjs/jest/issues/14766

### How often does it reproduce? Is there a required condition?

Found a consistent repro, but initially it was flaky because of the order jest was running tests.

### What is the expected behavior? Why is that the expected behavior?

20.9.0 just works
20.10.0 fails

So this is a regression.

### What do you see instead?

Coverage information is wrong in jest, unclear why, but based what we know Node is the place where this will most likely be fixed.

### Additional information

Based on https://nodejs.org/en/blog/release/v20.10.0, cc @joyeecheung as you might be interested/know what's wrong.

Based on https://github.com/jestjs/jest/issues/14764, cc @kwmhp as you experienced the same problem as us, and figure out the version upgrade is what triggers it.
Repository: ant-design
Issue: Using Typography is causing rc-field-form to be included in the bundle
Labels: Inactive,4.x,unconfirmed

### Reproduction link

[https://statoscope.tech/](https://statoscope.tech/)
![Screenshot 2023-12-21 at 11 43 29 AM](https://github.com/ant-design/ant-design/assets/1579388/f7b39caa-4076-4fda-868d-f320fcba81d8)


### Steps to reproduce

Use Typography in any webpack project. Analyze the bundle and notice rc-field-form being included

### What is expected?

rc-field-form should not be in the bundle if the user is not using editable.

### What is actually happening?

Typography base is importing editable which import the rc-field-form.

| Environment | Info |
| --- | --- |
| antd | 4.24.15 |
| React | 18 |
| System | any |
| Browser | any |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: pytorch
Issue: [dynamo] Tests using `kstest` are being killed in CI
Labels: triaged,module: numpy,oncall: pt2,module: dynamo

### 🐛 Describe the bug

When run under dynamo, tests in `test/nn/test_init.py` which use `scipy.stats.kstest` to check statistical properties of randomly generated data are being killed in the CI runners and causing tests to fail. This seems to be related to this warning from the dynamo logs,
```python
  File "/opt/conda/envs/py_3.11/lib/python3.11/site-packages/torch/_dynamo/variables/builder.py", line 1126, in wrap_numpy_ndarray
    value.flags.writeable = True
    ^^^^^^^^^^^^^^^^^^^^^
torch._dynamo.exc.InternalTorchDynamoError: cannot set WRITEABLE flag to True of this array
```

Skipping these for now in #116263



### Error logs

Full logs are available in the hud:
https://hud.pytorch.org/failure?name=pull%20%2F%20linux-focal-py3.11-clang10%20%2F%20test%20(dynamo%2C%202%2C%207%2C%20linux.2xlarge)&jobName=undefined&failureCaptures=%5B%22RuntimeError%3A%20nn%2Ftest_init%202%2F3%20failed%22%5D

### Minified repro

_No response_

### Versions

[8fd1963](https://github.com/pytorch/pytorch/commit/8fd1963ae208765e4e7a16734b1735d33db854c7)

cc @mruberry @rgommers @ezyang @msaroufim @wconstab @bdhirsh @anijain2305 @zou3519 @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @aakhundov @kadeng
Repository: ollama
Issue: CLI display flickers in SSH session on pull
Labels: bug

When pulling occasionally I see the loading bar flicker during and after download. This can be seen more dramatically on a fast connection.

System details:
```
OS: Debian 11
Terminal: Warp
Ollama: v0.1.17
```

https://github.com/jmorganca/ollama/assets/5853428/ec9c2410-f5c0-4a41-a9ef-73bee50b99f2
Repository: material-ui
Issue: [material-ui][Accordion] First/Last of type styles do not work with other components as siblings
Labels: bug 🐛,component: accordion,package: material-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://codesandbox.io/p/sandbox/accordion-rounded-edges-issue-phdcxr?file=%2Fsrc%2FDemo.tsx%3A17%2C41

Steps: Add a `TextField` as a sibling of an `Accordion` with rounded edges - notice the rounded edges no longer exist.


### Current behavior 😯

When another component like a `TextField` is a sibling of an `Accordion`, the rounded edges and other styling from first/last-of-type styles no longer appear:

<img width="533" alt="Screenshot 2023-12-21 at 1 25 32 PM" src="https://github.com/mui/material-ui/assets/51122966/fb807978-8562-448d-a8c0-3289fd8be77e">

or

<img width="534" alt="Screenshot 2023-12-21 at 1 26 08 PM" src="https://github.com/mui/material-ui/assets/51122966/d326bb37-25ce-43be-a0cf-18c9f20a23ac">


### Expected behavior 🤔

I would expect those styles to be applied to the first and last Accordion even if there are other siblings around it like this:

<img width="543" alt="Screenshot 2023-12-21 at 1 28 08 PM" src="https://github.com/mui/material-ui/assets/51122966/9644df24-912b-4cfe-ade0-23590bf96396">


### Context 🔦

The workaround is to wrap the Accordions in a `div` to give them their own parent so this isn't a huge issue, but not sure if this is the intended behavior when rendered next to other components.

Thanks!
Repository: go
Issue: proposal: net/http: Server.ConnContext should be invoked *after* forking `go c.serve(...)`
Labels: Proposal

### Proposal Details

Code link: https://cs.opensource.google/go/go/+/refs/tags/go1.21.5:src/net/http/server.go;l=3077

Today, when an http.Server has a ConnContext function set, ConnContext is called inline in the accept loop, before forking off a separate goroutine to run the HTTP serving logic.

If ConnContext takes time, this ends up driving tail latency for all incoming connections in the accept queue behind the slow invocation.  We originally hit this while investigating high latency in GKE and ASM when using GKE Workload Identity; the flow involves a ConnContext function that looks up callers by IP to authenticate them).

If ConnContext were invoked as the first step *after* forking the goroutine, then long-running ConnContext calls would not block accept() for other incoming connections.  This would technically be a behavior change, which is why I'm submitting a proposal, but I don't really see how it could cause a problem.
Repository: vscode
Issue: [Feature Request] Distinguish between build vs language service diagnostics
Labels: feature-request,languages-diagnostics

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
This is a request to support additional squiggle colors/styles, to more clearly distinguish between build related and language-service related errors/warning. Perhaps add separate `BuildError` and `BuildWarning` values to `DiagnosticSeverity`?

We routinely receive feedback from users of the C/C++ extension complaining about needing to build their project in order for stale squiggles to be refreshed. The C/C++ extension does not refresh language-service diagnostics when builds occurs.  Users appear to be confusing problem-matcher results and `DiagnosticCollection`'s from build extensions, with language service results.
Repository: rust
Issue: llvm-tools/llvm-tools-preview is installed in a target-specific directory instead of target-agnostic directory
Labels: T-bootstrap,C-bug

On an x86-64 Linux system, I ran:
```sh
$ rustup toolchain install --component=llvm-tools-preview stable
$ find ~/.rustup -name "llvm-nm"
/home/whatever/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-nm
```

The problem: The LLVM tools are installed at in the target-specific directory library directory "lib/rustlib/x86_64-unknown-linux-gnu/" under the toolchain directory `~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu`. Instead they should be installed directly in the toolchain directory, so that the result above would be `~/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/bin/llvm-nm`.

When originally announced at https://internals.rust-lang.org/t/llvm-tools-a-new-rustup-component-for-binary-inspection-objdump-nm-size-and-profiling-profdata/7830, it was said that:
> The main advantage of these LLVM tools is that they support all the architectures that the Rust compiler supports. For example, llvm-objdump con disassemble object files containing machine code for architectures ranging from ARM Cortex-M (THUMB) all the way to WASM (*) and x86_64. OTOH, if you were to use the GNU tools you would have to install one set of binutils for each architecture you are working with (e.g. avr-binutils, arm-none-eabi-binutils, msp430-elf-binutils, etc.).

Thus, it seems to me that the tools should be per-host, not per-target.
Repository: PowerToys
Issue: PowerToys Image Resizer Does Not Auto Refresh After Resizing Pics
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.75.1

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Image Resizer

### Steps to reproduce

After resizing pictures in Win10 Explorer the reduced size does not automatically change to the new smaller size.  I have to hit F5 to refresh Explorer to see the new size.  I also use a program called Resize Pictures (which I believe may be an older version of Image Resizer).  When using it, after I resize the pics they automatically show the new size when done.  

### ✔️ Expected Behavior

Resize pictures and immediately refresh Explorer to show the new size with out having to use F5 key.

### ❌ Actual Behavior

After using Image Resizer the same large size does not update.

### Other Software

_No response_
Repository: go
Issue: cmd/compile: confusing error message for not implementing a pointer to an interface
Labels: NeedsInvestigation,compiler/runtime

### Go version

go1.21.4 (playground). Also any version since Go 1.18.

### What operating system and processor architecture are you using (`go env`)?

```shell
N/A
```


### What did you do?

https://go.dev/play/p/_OT3OvSlSeg
```
package main

type I interface{}
type T struct{ X *I }

var i I
var t = T{i}

func main() {}
```

Compile this code.

### What did you expect to see?

```
./i.go:7:11: cannot use i (type I) as type *I in field value:
	*I is pointer to interface, not interface
```
This is what Go 1.17 and before emit.

### What did you see instead?

```
./i.go:7:11: cannot use i (variable of type I) as *I value in struct literal: I does not implement *I (type *I is pointer to interface, not interface)
```
Specifically, it contains `I does not implement *I`. In the spec "implements" is only used for implementing an interface or a type constraint. There is no "implementing a pointer to an interface". So this `does not implement *I` is confusing. We probably want to remove it.
Repository: deno
Issue: `Deno.open()` does not support O_DIRECT for performing Direct I/O
Labels: suggestion

Direct I/O is important for disabling the kernel block-cache, in the event your application manages such caching itself.
Without O_DIRECT, you wind up with double-buffering.

```
       O_DIRECT (since Linux 2.4.10)
              Try to minimize cache effects of the I/O to and from this
              file.  In general this will degrade performance, but it is
              useful in special situations, such as when applications do
              their own caching.  File I/O is done directly to/from
              user-space buffers.  The O_DIRECT flag on its own makes an
              effort to transfer data synchronously, but does not give
              the guarantees of the O_SYNC flag that data and necessary
              metadata are transferred.  To guarantee synchronous I/O,
              O_SYNC must be used in addition to O_DIRECT.  See NOTES
              below for further discussion.

              A semantically similar (but deprecated) interface for
              block devices is described in raw(8).
```

I propose adding a new flag to `Deno.OpenOptions`, named `direct`.

On Linux, this should apply the `O_DIRECT` flag.
On Windows, this should apply `FILE_FLAG_WRITE_THROUGH` + `FILE_FLAG_NO_BUFFERING`:
- https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilea#caching_behavior

> The flags FILE_FLAG_WRITE_THROUGH and FILE_FLAG_NO_BUFFERING are independent and may be combined.
> 
> If FILE_FLAG_WRITE_THROUGH is used but FILE_FLAG_NO_BUFFERING is not also specified, so that system caching is in effect, then the data is written to the system cache but is flushed to disk without delay.
> 
> If FILE_FLAG_WRITE_THROUGH and FILE_FLAG_NO_BUFFERING are both specified, so that system caching is not in effect, then the data is immediately flushed to disk without going through the Windows system cache. The operating system also requests a write-through of the hard disk's local hardware cache to persistent media.
Repository: deno
Issue: Deno KV: Specify authentication token on `Deno.openKv()`
Labels: ext/kv

When there was only Deploy and local support for Deno KV, it was relatively easy to support a single environment variable `DENO_KV_ACCESS_TOKEN` to access remote stores. Now that there is `denokv` of where a script may want to connect to various `denokv` instances as well as Deno Deploy KV stores, it becomes a juggling act.

Currently for `kview` from within the script I swap out the environment tokens using `Deno.env.set()` and this works adequate, but it isn't very user friendly.

I can understand the desire to not encourage passing secrets in code, but it is quite common to provide an API that leave it up to the user how to securely manage their secrets.
Repository: react-native
Issue: AbortSignal, TypeError: AbortSignal.timeout is not a function
Labels: Issue: Author Provided Repro,Needs: Triage :mag:,Needs: Author Feedback

### Description

I want to abort a fetch request after 5 seconds. I am using following code:

```javascript
const getStatus = () => {
  fetch(`${URL}/api/status`, {
    signal: AbortSignal.timeout(5000)
  }).then(response => {
    console.log(response)
  })
  .catch(err => {
    console.error(err.name, err.code, err.message, err.cause);
  })
};
```

### Steps to reproduce

1. Install React-Native
2. Install newest node version

### React Native Version

0.73.1

### Affected Platforms

Runtime - Android

### Output of `npx react-native info`

```text
System:
    OS: Windows 10 10.0.19045
    CPU: (6) x64 Intel(R) Core(TM) i5-9600K CPU @ 3.70GHz
    Memory: 1.03 GB / 15.93 GB
  Binaries:
    Node: 21.5.0 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.19 - ~\AppData\Roaming\npm\yarn.CMD
    npm: 8.3.0 - ~\AppData\Roaming\npm\npm.CMD
    Watchman: Not Found
  SDKs:
    Android SDK: Not Found
    Windows SDK:
      AllowAllTrustedApps: Disabled
  IDEs:
    Android Studio: AI-212.5712.43.2112.8609683
    Visual Studio: Not Found
  Languages:
    Java: 17.0.8
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.1.0 => 18.1.0
    react-native: 0.73.1 => 0.73.1
    react-native-windows: Not Found
  npmGlobalPackages:
    *react-native*: Not Found
```


### Stacktrace or Logs

```text
TypeError: AbortSignal.timeout is not a function (it is undefined), js engine: hermes
```


### Reproducer

https://github.com/HenrikZabel/abortsignal-bug/

### Screenshots and Videos

_No response_
Repository: rust
Issue: Tracking Issue for `str_from_raw_parts`
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(str_from_raw_parts)]`

This is a tracking issue for [ACP#167], which adds `core::str::from_raw_parts[_mut]`.

<!--
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::str

pub const unsafe fn from_raw_parts<'a>(ptr: *const u8, len: usize) -> &'a str

pub const unsafe fn from_raw_parts_mut<'a>(ptr: *mut u8, len: usize) -> &'a mut str
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation (take 1): #107207
- [x] Implementation (take 2): #119466
- [ ] 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.
-->

- None yet.

[ACP#167]: https://github.com/rust-lang/libs-team/issues/167

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html