sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: react-native
Issue: `ScrollView` `contentContainerStyle`'s `flexGrow` doesn't account for `contentInsetAdjustmentBehavior` or `automaticallyAdjustKeyboardInsets`
Labels: Issue: Author Provided Repro,Component: ScrollView,API: Keyboard

### Description

This is a reopen of https://github.com/facebook/react-native/issues/25282 which is still reproducible in the latest React native version.



### Steps to reproduce

1. Create a `ScrollView` with `contentInsetAdjustmentBehavior="automatic"` and `contentContainerStyle={{flexGrow: 1}}`.
2. Observe that the content container grows larger than the ScrollView's height, while the height is expected to match, because safe area insets would be accounted for.

See the Expo snack

### React Native Version

0.75.3

### Affected Platforms

Runtime - iOS

### Output of `npx react-native info`

```text
N/A — easy to reproduce
```


### Stacktrace or Logs

```text
N/A
```


### Reproducer

https://snack.expo.dev/@louay/scrollview-layout-contentinset-issue

### Screenshots and Videos

<p float="left"><img src="https://user-images.githubusercontent.com/349850/59601225-5512d780-90fb-11e9-94fb-59ff24c9a24e.PNG" width=300/> <img src="https://user-images.githubusercontent.com/349850/59601229-56dc9b00-90fb-11e9-8ce3-4d3afa639ba4.PNG" width=300/></p>
Repository: tensorflow
Issue: Segmentation fault (core dumped) in `tf.profiler.experimental.Profile`
Labels: stat:awaiting tensorflower,type:bug,comp:ops,2.17

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

2.18.0-dev20240925

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04.3 LTS (x86_64)

### Mobile device

_No response_

### Python version

3.9.13

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific inputs, tf.profiler.experimental.Profile triggered a crash.

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

profiler_options = tf.profiler.experimental.ProfilerOptions(
    host_tracer_level=999,
    python_tracer_level=-1,
    device_tracer_level=10,
    delay_ms=None
)

with tf.profiler.experimental.Profile(None, options=profiler_options):
    a = tf.constant(1)
    b = tf.constant(2)
    c = a + b
    print(c.numpy())
```


### Relevant log output

```shell
2024-09-28 20:07:36.902909: I tensorflow/core/util/port.cc:153] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.2024-09-28 20:07:36.966049: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:485] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-09-28 20:07:36.998027: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:8454] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-09-28 20:07:37.002984: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1452] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered2024-09-28 20:07:37.055864: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.To enable the following instructions: SSE4.1 SSE4.2 AVX AVX2 AVX512F AVX512_VNNI AVX512_BF16 AVX512_FP16 AVX_VNNI AMX_TILE AMX_INT8 AMX_BF16 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
Segmentation fault (core dumped)
```
Repository: kubernetes
Issue: [Flaking Test] [sig-network] Conformance-EC2-arm64-master - Service is not reachable within 2m0s timeout
Labels: sig/network,kind/flake,priority/important-longterm,triage/accepted

### Which jobs are flaking?
- master-informing
[Conformance-EC2-arm64-master](https://testgrid.k8s.io/sig-release-master-informing#Conformance%20-%20EC2%20-%20arm64%20-%20master)

### Which tests are flaking?

- Kubernetes e2e suite.[It] [sig-network] Services should be able to change the type from ExternalName to NodePort [Conformance], [Prow](https://prow.k8s.io/view/gs/kubernetes-jenkins/logs/ci-kubernetes-ec2-arm64-conformance-latest/1839326641159933952), [Triage](https://storage.googleapis.com/k8s-triage/index.html?test=Services%20should%20be%20able%20to%20change%20the%20type%20from%20ExternalName%20to%20NodePort)
- Kubernetes e2e suite.[It] [sig-network] Services should be able to create a functioning NodePort service [Conformance], [Triage](https://storage.googleapis.com/k8s-triage/index.html?test=Services%20should%20be%20able%20to%20create%20a%20functioning%20NodePort%20service)
- Kubernetes e2e suite.[It] [sig-network] Services should be able to switch session affinity for NodePort service [LinuxOnly] [Conformance], [Triage](https://storage.googleapis.com/k8s-triage/index.html?test=Services%20should%20be%20able%20to%20switch%20session%20affinity%20for%20NodePort%20service)
- Kubernetes e2e suite.[It] [sig-network] Services should have session affinity work for NodePort service [LinuxOnly] [Conformance], [Triage](https://storage.googleapis.com/k8s-triage/index.html?test=Services%20should%20have%20session%20affinity%20work%20for%20NodePort%20service)

### Since when has it been flaking?

These tests failed multiple times since September. View Triage Links above for more context.

### Testgrid link

https://testgrid.k8s.io/sig-release-master-informing#Conformance%20-%20EC2%20-%20arm64%20-%20master

### Reason for failure (if possible)

Same error messages, only different on endpoint
```
{ failed [FAILED] service is not reachable within 2m0s timeout on endpoint 172.31.6.192:30233 over TCP protocol
In [It] at: k8s.io/kubernetes/test/e2e/network/service.go:1278 @ 09/26/24 16:31:40.542
}
```

### Anything else we need to know?

N/A

### Relevant SIG(s)

/sig network
@kubernetes/release-team-release-signal
Repository: godot
Issue: Successive calls to `CanvasItem.draw_primitive()` disregard the texture
Labels: bug,confirmed,regression,topic:gui

### Tested versions

Master as of writing: v4.4.dev.custom_build [76a135926]
See 'Issue description' for details.

### System information

Godot v4.4.dev2 - Windows 10.0.22631 - OpenGL 3 (Compatibility) - NVIDIA GeForce RTX 4090 (NVIDIA; 31.0.15.3699) - AMD Ryzen 9 7950X 16-Core Processor (32 Threads)

### Issue description

After merging #92797 (bisected) successive calls to `CanvasItem.draw_primitive()` and `RenderingServer.canvas_item_add_primitive()` in the RD-renderers keep using the texture of the first call. Adding other draw commands between the calls fixes the issue as it disables batching. The same issue is and has been present in the Compatibility renderer.

### Steps to reproduce

Draw primitives with the same point count (otherwise they're not batched) with different textures in succession, and observe that the second call uses the texture of the first.
```gdscript
draw_primitive(points, colors, uvs, texture_a)
draw_primitive(points, colors, uvs, texture_b)
```

### Minimal reproduction project (MRP)

[drawcalltest.zip](https://github.com/user-attachments/files/17174396/drawcalltest.zip)
Repository: tensorflow
Issue: Floating point exception (core dumped) in `tf.nn.depth_to_space`
Labels: stat:awaiting tensorflower,type:bug,comp:ops,2.17

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

2.18.0-dev20240925

### Custom code

Yes

### OS platform and distribution

Linux Ubuntu 22.04.3 LTS (x86_64)

### Mobile device

_No response_

### Python version

3.9.13

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

Under specific inputs, tf.nn.depth_to_space triggered a crash.

### Standalone code to reproduce the issue

```shell
import tensorflow as tf
try:
    # Create an empty tensor
    arg_0_tensor = tf.zeros([0, 2, 3, 12], dtype=tf.float32)
    # arg_0 = tf.identity(arg_0_tensor)
    arg_1 = 536870912
    out = tf.nn.depth_to_space(arg_0_tensor, arg_1)
except Exception as e:
    print("Error:", str(e))
```


### Relevant log output

```shell
2024-09-28 20:41:05.888017: I tensorflow/core/util/port.cc:153] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
2024-09-28 20:41:05.950498: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:485] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-09-28 20:41:06.028236: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:8454] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-09-28 20:41:06.052072: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1452] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-09-28 20:41:06.111011: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: SSE4.1 SSE4.2 AVX AVX2 AVX512F AVX512_VNNI AVX512_BF16 AVX512_FP16 AVX_VNNI AMX_TILE AMX_INT8 AMX_BF16 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
2024-09-28 20:41:11.970896: I tensorflow/core/common_runtime/gpu/gpu_device.cc:2021] Created device /job:localhost/replica:0/task:0/device:GPU:0 with 2704 MB memory:  -> device: 0, name: NVIDIA GeForce RTX 4090, pci bus id: 0000:1f:00.0, compute capability: 8.9
2024-09-28 20:41:11.973176: I tensorflow/core/common_runtime/gpu/gpu_device.cc:2021] Created device /job:localhost/replica:0/task:0/device:GPU:1 with 1724 MB memory:  -> device: 1, name: NVIDIA GeForce RTX 4090, pci bus id: 0000:d4:00.0, compute capability: 8.9
Floating point exception (core dumped)
```
Repository: tensorflow
Issue: Aborted (core dumped) in `tf.io.encode_png`/`tf.compat.v1.image.encode_png`
Labels: stat:awaiting tensorflower,type:bug,comp:ops,2.17

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

source

### TensorFlow version

2.18.0-dev20240925

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

3.9.13

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

The crash was triggered when an illegal image was passed to tf.io.encode_png/tf.compat.v1.image.encode_png

### Standalone code to reproduce the issue

```shell
import tensorflow as tf

image = tf.cast(tf.tile([[[0, 0, 0, 1]], [[0, 0, 1, 0]]], [0, 0, 1]), tf.uint8)

encoded_image = tf.compat.v1.image.encode_png(image) # crash
tf.io.encode_png(image, compression=-1, name=None) #crash
```


### Relevant log output

```shell
2024-09-28 20:48:36.270008: I tensorflow/core/util/port.cc:153] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
2024-09-28 20:48:36.332972: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:485] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
2024-09-28 20:48:36.411391: E external/local_xla/xla/stream_executor/cuda/cuda_dnn.cc:8454] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
2024-09-28 20:48:36.428306: E external/local_xla/xla/stream_executor/cuda/cuda_blas.cc:1452] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2024-09-28 20:48:36.438336: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: SSE4.1 SSE4.2 AVX AVX2 AVX512F AVX512_VNNI AVX512_BF16 AVX512_FP16 AVX_VNNI AMX_TILE AMX_INT8 AMX_BF16 FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.2024-09-28 20:48:41.296886: I tensorflow/core/common_runtime/gpu/gpu_device.cc:2021] Created device /job:localhost/replica:0/task:0/device:GPU:0 with 3114 MB memory:  -> device: 0, name: NVIDIA GeForce RTX 4090, pci bus id: 0000:1f:00.0, compute capability: 8.92024-09-28 20:48:41.297450: I tensorflow/core/common_runtime/gpu/gpu_device.cc:2021] Created device /job:localhost/replica:0/task:0/device:GPU:1 with 1724 MB memory:  -> device: 1, name: NVIDIA GeForce RTX 4090, pci bus id: 0000:d4:00.0, compute capability: 8.9
2024-09-28 20:48:41.475588: F tensorflow/core/lib/png/png_io.cc:350] 'image' Must be non NULL
Aborted (core dumped)
```
Repository: PowerToys
Issue: Plz Add CapsLock shortkey！！！make capsLock usful during my coding
Labels: Issue-Docs,Needs-Triage

### Provide a description of requested docs changes

like：capsLock + S = left。capsLock+F = right。
Repository: next.js
Issue: Template strings are incorrectly converted during building, lead to JSON.parse errors at production runtime.
Labels: bug,SWC

### Link to the code that reproduces this issue

https://github.com/Innei/next-bundle-regexp-repro

### To Reproduce

1. clone my repro
2. run build
3. next start and see prod page

![CleanShot 2024-09-28 at 9  01 11@2x](https://github.com/user-attachments/assets/aa1519f8-4f77-4d75-a399-3230f58119c1)


### Current vs. Expected behavior

The product of the build has changed in structure from the third party's original file, specifically, the template string of the third party's original file has been converted incorrectly, resulting in a JSON parse error.

1. The third party original code:

(It's too long. I've cut off part of it.
![CleanShot 2024-09-28 at 9  03 11@2x](https://github.com/user-attachments/assets/284bd72f-0e2b-42a4-98d5-275a931f049a)

I run the code, works

![CleanShot 2024-09-28 at 9  04 09@2x](https://github.com/user-attachments/assets/59d4d971-4649-4884-ab04-996ee45920b2)

2. next The compiled product, the template string is converted to a normal string, and throw an error.

![CleanShot 2024-09-28 at 9  06 25@2x](https://github.com/user-attachments/assets/5173ebf4-8389-4f1c-a013-13e0d500677e)

And copy the JSON.parse part code and run in console. Error.

![CleanShot 2024-09-28 at 9  07 23@2x](https://github.com/user-attachments/assets/d6d601b5-2758-4fab-80fd-51928c8c3af2)


And in the actual run, the reported error is the same

![CleanShot 2024-09-28 at 9  08 02@2x](https://github.com/user-attachments/assets/0f1f5813-b15d-497d-b7c0-1e1e211a8c55)


I was expecting that. next.js should not be converting template strings. Not only is the conversion incorrect here, but it also doesn't respect browserlist, even though I've set the browserlist target to the last 1 chrome version.

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 24.0.0: Mon Aug 12 20:52:12 PDT 2024; root:xnu-11215.1.10~2/RELEASE_ARM64_T6020
  Available memory (MB): 32768
  Available CPU cores: 12
Binaries:
  Node: 22.3.0
  npm: 10.2.4
  Yarn: 1.22.21
  pnpm: 9.11.0
Relevant Packages:
  next: 14.2.13 // Latest available version is detected (14.2.13).
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.6.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

SWC

### Which stage(s) are affected? (Select all that apply)

next build (local)

### Additional context

_No response_
Repository: angular
Issue: Add an alternative NoInferFormBuilder
Labels: area: forms

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

forms

### Description

Currently form builder supports multiple form creation options and due to that and typescript issues some patterns are really problematic to use. For example:
```ts
// Infers string - fails
formBuilder.group<{a: FormGroup<{a: FormControl<'a' | 'b'>}>}>({a: formBuilder.group({a: formBuilder.control('a')})});
// Fails to infer array type
formBuilder.group<{a: FormArray<FormControl<boolean>>}>({a: formBuilder.array([])});
// Incorrect auto complete here (in ...) - k has unknown type
formBuilder.group<{g: FormGroup<{k: FormGroup<{a: FormControl<number>}>}>}>({g: formBuilder.group({...})});
```

### Proposed solution

Create a new form builder variation which is oriented to cases when you provide the form type yourself. The new form builder will use `NoInfer` for parameter so the inference will be strictly from the return type which will solve the problems above.
An example implementation that will solve all the issues above:
```ts
export class NoInferFormBuilder {
  control<T>(
    formState: NoInfer<T | FormControlState<T>>,
    validatorOrOpts?:
      | ValidatorFn
      | ValidatorFn[]
      | AbstractControlOptions
      | null,
    asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null
  ) {
    return new FormControl<T>(formState, validatorOrOpts, asyncValidator);
  }

  group<
    T extends {
      [K in keyof T]: AbstractControl<any>;
    }
  >(
    controls: NoInfer<T>,
    validatorOrOpts?:
      | ValidatorFn
      | ValidatorFn[]
      | AbstractControlOptions
      | null,
    asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null
  ) {
    return new FormGroup<T>(controls, validatorOrOpts, asyncValidator);
  }

  array<T extends AbstractControl<any>>(
    controls: NoInfer<T[]>,
    validatorOrOpts?:
      | ValidatorFn
      | ValidatorFn[]
      | AbstractControlOptions
      | null,
    asyncValidator?: AsyncValidatorFn | AsyncValidatorFn[] | null
  ) {
    return new FormArray<T>(controls, validatorOrOpts, asyncValidator);
  }
}
```

### Alternatives considered

Get around those problems which can be annoying and repetitive or use form classes which helps to some extent or use untyped forms.
Repository: rust
Issue: Lint on FileCheck directives with missing colon
Labels: A-testsuite,C-enhancement,T-bootstrap,A-compiletest

In current compiletest -> FileCheck setup (e.g. codegen/assembly tests), if you forgor a colon `:` in one of the FileCheck directives, it gets silently ignored by both compilest and FileCheck, meaning that you aren't testing anything.

```rs
// tests/assembly/selftest.rs

//@ assembly-output: emit-asm

#![crate_type = "lib"]

// CHECK-LABEL: foo:
//-- CHECK-LABEL: bar: # <- make sure this test is actually testing
// CHECK-NOT ret       # <- notice the missing `:`?
#[no_mangle]
pub fn foo(x: u8) {}
```

This test currently will just silently pass, even though we wanted to check `ret` doesn't exist (made-up example for illustration purposes). Realized while reviewing https://github.com/rust-lang/rust/pull/128018.

Example missing colon (real example): https://github.com/rust-lang/rust/pull/125626.

We should probably aim to lint on cases like this.
Repository: godot
Issue: GPUParticles3D linear acceleration doesn't respect velocity direction and causes particles to jitter.
Labels: bug,topic:particles

### Tested versions

4.3

### System information

Windows 11 - Vulkan - Nvidia RTX 4070 - intel i5 13600KF

### Issue description

Firstly, I don't know if this is a wrong behavior or not so I'm sorry in case I misunderstand how this should work.

1. If you don't set the initial velocity and only use a (!) positive (!) linear acceleration the particles always accelerate down no matter what velocity direction is set, since the acceleration doesn't have direction maybe it should use the velocity direction? (red particles in the MRP)
2. If you don't set the initial velocity and only use a (!) negative (!) linear acceleration the particles jitter (yellow particles in the MRP) - and sometimes go in a different directions too, in case of the MRP the yellow particles sometimes have some which goes down and not up as most of them. Jitter gets even worse if you do set a velocity to a non-zero value such as 1 for min + max.
**EDIT: Actually even if you have velocity set to a positive non-zero value the negative linear acceleration causes the particles to spasm as in the video.**


Note: Green particles in the MRP have a non-zero velocity (positive) to show how it normally works.

You can see everything in the video below:
https://github.com/user-attachments/assets/4d700e31-82a9-4b60-aeed-000c54efa02d

### Steps to reproduce

Use GPUParticles3D, set gravity and animated velocity to 0, set linear acceleration to a positive value, set velocity direction in different direction and observe no changes.
Do the above but this time set the linear acceleration to a negative value and observe the particles' jittered movement.

### Minimal reproduction project (MRP)

[LinearAccelerationTest.zip](https://github.com/user-attachments/files/17174823/LinearAccelerationTest.zip)
Repository: rust
Issue: Many Arm microcontoller target feature flags are missing
Labels: T-compiler,A-ABI,A-target-feature

@RalfJung asked me to open an issue listing all the useful Arm microcontroller feature flags that are currently entirely unsupported by Rust, not even unstably.

These are all listed at https://doc.rust-lang.org/nightly/rustc/platform-support/arm-none-eabi.html and the sub-pages, as modified by https://github.com/rust-lang/rust/pull/130987.

Selecting a CPU with `-C target-cpu=xxx` causes LLVM to enable *all* the optional features of that type of CPU. However, sometimes CPUs are sold without certain features (e.g. you can get a Cortex-M4 either with or without an FPU). So, we use these `-C target-feature=...` flags to *disable* some of the things that LLVM over-enthusiastically enabled for us when we selected a target-cpu. If you don't select a target-cpu, you don't need these flags because by default, only the architecture's baseline features are enabled and you never want to turn those off.

* [ ] `-fpregs` - don't emit FPU instructions
* [ ] `-fp64` - don't emit double precision FPU instructions
* [ ] `-mve` - don't emit Float or Integer M-Profile Vector Extension instructions
* [ ] `-mve.fp` - don't emit Float M-Profile Vector Extension instructions
* [ ] `-dsp` - don't emit DSP instructions
* [ ] `+mve` - do emit Integer M-Profile Vector Extension instructions (used with `-fpregs` because MVE uses registers shared with the FPU and those registers are present if you have Integer MVE but no FPU)

These are alongside the following target CPUs (`-C target-cpu=...`):

* `cortex-m0`
* `cortex-m0plus`
* `cortex-m3`
* `cortex-m4`
* `cortex-m7`
* `cortex-m33`
* `cortex-m35p`
* `cortex-m55`
* `cortex-m85`

If you don't want to use `-C target-cpu...` then the following additional flags can *enable* certain features. However, these aren't currently mentioned in the documentation (except `+mve` because it's listed above).

* `+mve` - M-Profile Vector Extensions (integer)
* `+mve.fp` - M-Profile Vector Extensions (floating point)
* `+dsp` - DSP extensions
* `+fp-armv8d16sp` - single precision FPU for Armv8-M
* `+fp-armv8d16` - double precision FPU for Armv8-M
* `+vfp4d16sp` - single precision FPU for Armv7E-M
* `+vfp4d16` - double precision FPU for Armv7E-M