sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Create a reproducible build for LibTorch x64 on VS2022
Labels: module: windows,triaged

### 🚀 The feature, motivation and pitch
VS2022 has ARM64 support and our goal is to establish a reference point for comparing our ARM64 and x64 results on VS2022.
 
By meaning VS2022, we're aiming to generate x64 binaries with Version 17.x Build Tools (MSVC v143).
 
Dependency - Configuration For the Build:
- Enable CUDA
- Enable MKL
- Not use other configurations
 
Some helpful resources regarding versions:
- [History VS2022](https://learn.microsoft.com/en-us/visualstudio/releases/2022/release-history)
- [History VS2019](https://learn.microsoft.com/en-us/visualstudio/releases/2019/history)
- [C++ Tools and Features in Visual Studio Editions](https://learn.microsoft.com/en-us/cpp/overview/visual-cpp-tools-and-features-in-visual-studio-editions?view=msvc-170)
 
This ticket involves building **LibTorch** x64 using VS2022.
 
The tasks we aim to complete within this ticket are as follows.
 
1. Evaluate the present state of VS2022 x64 generation
   1. Detect any problems and formulate appropriate solutions.
1. Confirm the functionality of the local build
   1. Unit tests should be successful as production build
   1. Execute tests based on real-world scenarios
1. Maintain an "off-upstream" CI that aligns with the upstream version of PyTorch repository and monitors stability
   1. The goal of the off-upstream CI should be to produce builds as stable as the local build


### Alternatives

_No response_

### Additional context

_No response_
Repository: godot
Issue: Animation is stuttered when the editor tooltip appears
Labels: bug,topic:rendering,topic:editor,confirmed,performance

### Godot version

v4.2.rc2.official [1ba920fad]

### System information

Windows 11, Intel Core i5 10300H, nVidia GTX 1650

### Issue description

When previewing AnimationPlayer animations in editor, the animation shows a hiccup that's not part of the animation. The hiccup happens around half a second after the animation starts. Even when playing the animation backwards, the hiccup happens at the first half second (which would be the last half second since it's backwards).

This hiccup doesn't happen while running the game, even in debug builds.

I first noticed this bug in 4.2 RC1. The bug persists in 4.2 RC2.

### Steps to reproduce

- Create a 3D scene
- Add some visual nodes, like cubes, that you can animate
- Add an AnimationPlayer node
- Create a new animation of around two seconds
- Keyframe your visual node moving somewhere
- Play this animation while in editor
- The animation should stutter a little inside the editor, but works fine while in game

### Minimal reproduction project

[animation_player_bug_sample.zip](https://github.com/godotengine/godot/files/13468802/animation_player_bug_sample.zip)

This is just the 3d_scaling project from the demo projects. Open the cubes.tscn scene and play the animation I added.

In case the stutter doesn't happen in a test environment, here's a video of the stutter happening for me.

https://github.com/godotengine/godot/assets/1204296/b22e4b97-6525-41bd-888d-3a88f307d15b
Repository: rust
Issue: trait implementation conflicts depending on source crate with generic_const_exprs
Labels: A-trait-system,T-compiler,C-bug,F-generic_const_exprs,requires-incomplete-features

I tried this code:

crate foo
```rust
#![allow(incomplete_features)]
#![feature(generic_const_exprs)]

pub trait KnownSize: Sized {
    const N: usize = core::mem::size_of::<Self>();
}
impl<T: Sized> KnownSize for T {}

pub trait SizeIs<const N: usize> {}
impl<T: KnownSize> SizeIs<{ T::N }> for T {}

struct X(u32);

// Uncommenting either of these lines breaks due to conflict with blanket impls above
// impl KnownSize for X {}
// impl SizeIs<4> for X {}

```

crate bar
```
use foo::*;

struct X(u32);

// Uncommenting this line breaks due to conflict with blanket impl in `foo`
// impl KnownSize for X {}

// However this line works! (and is required if I want to use the `X: SizeIs<4>` impl)
impl SizeIs<4> for X {}
```

I expected to see this happen: 
`impl SizeIs<4> for X {}` should work in both `foo` and `bar`, or in neither.
`impl KnownSize for X {}` and `impl SizeIs<4> for X {}` should either both work or neither work (in `bar`).

### Meta

`rustc --version --verbose`:
```
rustc 1.76.0-nightly (6b771f6b5 2023-11-15)
binary: rustc
commit-hash: 6b771f6b5a6c8b03b6322a9c77ac77cb346148f0
commit-date: 2023-11-15
host: x86_64-unknown-linux-gnu
release: 1.76.0-nightly
LLVM version: 17.0.5
```

</details>
Repository: go
Issue: runtime/pprof: compatibility guarantees for pgo file format
Labels: Documentation,NeedsInvestigation,compiler/runtime

Hi!

We are evaluating using [Profile-Guided Optimization (PGO)](https://go.dev/doc/pgo) with Go. Right now the Go compiler stores the profile as a file, that later can be reused. However, I cannot find the information about the backward/forward compatibility guarantees of the `pprof` format (the format used by the Go compiler) and how the Go compiler deals with it. For us, it's important to know because right now we cannot understand whether will it be possible to use PGO profiles from the older compiler with a newer Go version or not (and vice versa).

In LLVM PGO infrastructure we already [met](https://github.com/llvm/llvm-project/issues/52683) some problems with that - the Clang/LLVM documentation also [hasn't](https://discourse.llvm.org/t/profile-guided-optimization-pgo-related-questions-and-suggestions/75232/2) this information yet. We want to avoid such problems with Go in the future. A similar situation is with GCC: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112717

The original issue was created here: https://github.com/google/pprof/issues/821 but originally I chose the wrong place for that.

@aalexand friendly ping as you asked :)
Repository: pytorch
Issue: inconsistency on torch.clamp
Labels: module: cuda,triaged,module: NaNs and Infs

### 🐛 Describe the bug

```python
import torch
import torchvision
import torchvision.transforms as transforms
import torch.nn as nn
import os
import torch.nn.functional as F
gpu_device = torch.device("cuda")
cpu_device = torch.device("cpu")
class PreprocessAndCalculateModel(nn.Module):
    def __init__(self):
        super().__init__()
    def forward(self, x):
        output = torch.clamp(x, min=0, max=1)
        return output


x = torch.tensor([-0.])
model = PreprocessAndCalculateModel()
output_gpu = model.to(gpu_device)(x.cuda())
output_cpu = model.to(cpu_device)(x.cpu())
print(output_gpu)
print(output_cpu)

### Versions

```python
tensor([0.], device='cuda:0')
tensor([-0.])


cc @ptrblck @frank-wei @jgong5 @mingfeima @XiaobingSuper @sanchitintel @ashokei @jingxu10
Repository: ant-design
Issue: popover组件placement属性为bottom时，箭头与内容之间存在缝隙，能透出背景颜色
Labels: Inactive,improvement

### Reproduction link

[https://ant-design.antgroup.com/components/popover-cn#popover-demo-placement](https://ant-design.antgroup.com/components/popover-cn#popover-demo-placement)

### Steps to reproduce

通过控制台，将code-box-demo设置background: red;然后鼠标悬浮到Bottom，发现弹出的popover组件箭头与内容之间存在缝隙，中间能看到一条红线。注，在codepen（https://codepen.io/Railgun-S_/pen/jOdpEox?editors=0110）中确没有复现，因此没有提供重现链接

### What is expected?

popover组件placement属性为bottom时，箭头与内容之间紧密贴合

### What is actually happening?

popover组件placement属性为bottom时，箭头与内容之间存在缝隙

| Environment | Info |
| --- | --- |
| antd | 5.11.2 |
| React | 18 |
| System | Windows 10 专业教育版-22H2-19045.3693 |
| Browser | Google Chrome 119.0.6045.160 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->

![image](https://github.com/ant-design/ant-design/assets/22837283/474969b0-fb50-46ac-9684-adaad50836f2)
Repository: pytorch
Issue: inconsistency between nan cast to int32 on CPU and GPU
Labels: module: cuda,triaged,module: NaNs and Infs

### 🐛 Describe the bug

```python
import torch
import torchvision
import torchvision.transforms as transforms
import torch.nn as nn
import os
import torch.nn.functional as F
gpu_device = torch.device("cuda")
cpu_device = torch.device("cpu")
class PreprocessAndCalculateModel(nn.Module):
    def __init__(self):
        super().__init__()
    def forward(self, x):
        output1 = x.clone().type(torch.bool)
        output2 = x.clone().type(torch.float32)
        output3 = x.clone().type(torch.float64)
        output4 = x.clone().type(torch.int8)
        output5 = x.clone().type(torch.int32)
        output6 = x.clone().type(torch.int64)

        return [output1,output2,output3,output4,output5,output6]

x = torch.tensor(float('nan'))
model = PreprocessAndCalculateModel()
output_gpu = model.to(gpu_device)(x.cuda())
output_cpu = model.to(cpu_device)(x.cpu())
print(output_gpu)
print(output_cpu)

### Versions

```python
[tensor(True, device='cuda:0'), tensor(nan, device='cuda:0'), tensor(nan, device='cuda:0', dtype=torch.float64), tensor(0, device='cuda:0', dtype=torch.int8), tensor(0, device='cuda:0', dtype=torch.int32), tensor(-9223372036854775808, device='cuda:0')]
[tensor(True), tensor(nan), tensor(nan, dtype=torch.float64), tensor(0, dtype=torch.int8), tensor(-2147483648, dtype=torch.int32), tensor(-9223372036854775808)]

cc @ptrblck
Repository: pytorch
Issue: In version 2.1, libtorch needs to be woken up every time it is called after the model is initialized, which means that every time the model is called, it is very slow to predict the first picture.
Labels: needs reproduction,module: cpp,triaged

### 🐛 Describe the bug

In version 2.1, libtorch needs to be woken up every time it is called after the model is initialized, which means that every time the model is called, it is very slow to predict the first picture.

### Versions

2.1, libtorch 

cc @jbschlosser
Repository: pytorch
Issue: DISABLED test_schema_correctness_nn_functional_conv3d_cuda_complex64 (__main__.TestSchemaCheckModeOpInfoCUDA)
Labels: oncall: jit,module: flaky-tests,skipped

Platforms: linux, slow, win, windows



This test was disabled because it is failing in CI. See [recent examples](https://hud.pytorch.org/flakytest?name=test_schema_correctness_nn_functional_conv3d_cuda_complex64&suite=TestSchemaCheckModeOpInfoCUDA) and the most recent trunk [workflow logs](https://github.com/pytorch/pytorch/runs/19037355476).

Over the past 3 hours, it has been determined flaky in 2 workflow(s) with 4 failures and 2 successes.

**Debugging instructions (after clicking on the recent samples link):**
DO NOT ASSUME THINGS ARE OKAY IF THE CI IS GREEN. We now shield flaky tests from developers so CI will thus be green but it will be harder to parse the logs.
To find relevant log snippets:
1. Click on the workflow logs linked above
2. Click on the Test step of the job so that it is expanded. Otherwise, the grepping will not work.
3. Grep for `test_schema_correctness_nn_functional_conv3d_cuda_complex64`
4. There should be several instances run (as flaky tests are rerun in CI) from which you can study the logs.


Test file path: `test_schema_check.py`

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Repository: ant-design
Issue: Collapsed inline menu overflow page
Labels: Inactive,improvement

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/p/sandbox/collapsed-inline-menu-antd-5-11-4-forked-yhdspr?file=%2Fdemo.tsx%3A45%2C32)

### Steps to reproduce

![v5 menu bug](https://s5.gifyu.com/images/SRF6F.gif)

From the v5 fork repo, see that the menu popup sometimes overflow.
If it overflows at top, then some menu item is hidden and inaccessible.
If it overflows at bottom, then it increases the body height.

### What is expected?

[v4 menu fork](https://codesandbox.io/p/sandbox/collapsed-inline-menu-antd-4-24-15-forked-pfvg3w?file=%2Fdemo.tsx%3A60%2C32)
^In this v4 fork repo, I tried using the same data and no menu item overflows the page.
Expect v5 menu item to also not overflow the page whether top or bottom.

![v4 menu no bug](https://s5.gifyu.com/images/SRF6o.gif)

### What is actually happening?

Collapsed menu item popup will overflow and clipped off the page

| Environment | Info |
| --- | --- |
| antd | 5.11.4 |
| React | 18 |
| System | Window |
| Browser | Chrome |

---
It seems to only happen at a particular breakpoint / item combination.
It *sometimes* fixes itself when I zoom in or when I changes the `items` prop.

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: flutter
Issue: Export _NavigationDestinationInfo as public API
Labels: framework,f: material design,c: proposal,P3,has partial patch,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

The [Material 3 NavigationBar's file](https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/navigation_bar.dart) provides with the necessary for having a fully featured [Metrial 3 NavigationBar spec](https://m3.material.io/components/navigation-bar) implemented out of the box with Flutter. But what happens when you need to do a slightly different NavigationBar like this one:  
![image](https://github.com/flutter/flutter/assets/1907844/8e76f3b2-8c38-4f43-99c6-0bae5d82416d)  

Maybe it's not an official [spec](https://m3.material.io/components/navigation-bar/specs), but the [Flutter code](https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/navigation_bar.dart) counts with all the necessary for allowing us to accomplish the task with minimal efforts. It just needs to be published to external libraries by removing some classes _underscores.

### Proposal

The proposal consists on removing the underscores of at least [_NavigationDestinationInfo](https://github.com/flutter/flutter/blob/984dc1947b574a51d5493e9c3b866a8218c69192/packages/flutter/lib/src/material/navigation_bar.dart#L561) and maybe [_NavigationBarDestinationLayout](https://github.com/flutter/flutter/blob/984dc1947b574a51d5493e9c3b866a8218c69192/packages/flutter/lib/src/material/navigation_bar.dart#L787) and also providing a way of using them on [NavigationBar](https://github.com/flutter/flutter/blob/984dc1947b574a51d5493e9c3b866a8218c69192/packages/flutter/lib/src/material/navigation_bar.dart#L86) and/or [NavigationDestination](https://github.com/flutter/flutter/blob/984dc1947b574a51d5493e9c3b866a8218c69192/packages/flutter/lib/src/material/navigation_bar.dart#L295) attributes (or maybe even an static property).


PS: Why is [NavigationIndicator](https://github.com/flutter/flutter/blob/984dc1947b574a51d5493e9c3b866a8218c69192/packages/flutter/lib/src/material/navigation_bar.dart#L679) not underscored? How can it be properly used up to how the code is now?
Repository: pytorch
Issue: Flawed testing of onesidedness in istft
Labels: triaged,module: fft

### 🐛 Describe the bug

The `torch.istft` function relies on explicit user input to determine whether the output sequence should be one-sided or not.  However, if the `onesided` flag is not defined the results can be wrong and it returns a real-valued output even when the input frequencies imply a complex-valued output.

```
import torch

# Define an FFT size and a dummy input
sz = 32
x = torch.randn( (1,sz*8))

# This works as expected, returning a real-valued output for a real-valued input
f = torch.stft( x, n_fft=sz, return_complex=True)
z = torch.istft( f, n_fft=sz)
print( torch.is_complex( z)) # returns False

# Same code for a complex-valued input fails to return a complex-valued output
# despite the size of f implying a complex-valued output
f = torch.stft( x-1j*x, n_fft=sz, return_complex=True)
z = torch.istft( f, n_fft=sz)
print( torch.is_complex( z)) # returns False, but should be True

# But it works right if we explicitly ask for a complex-valued output
z = torch.istft( f, n_fft=sz, return_complex=True)
print( torch.is_complex( z)) # returns True

# But does not raise an error if we ask for a real-valued output
z = torch.istft( f, n_fft=sz, return_complex=False)
print( torch.is_complex( z)) # returns False and doesn't see the clash between input size and return_complex
```

In the above calls the input tensor size to `torch.istft` should be enough to determine onesidedness, however the function relies on accurate flag settings instead.  If the input has `n_fft` frequencies, if unset, `return_complex` or `onesided` need to be set to `True`, or at least a warning should be shown.

### Versions

Collecting environment information...
PyTorch version: 2.1.1
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 14.1.1 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-1500.0.40.1)
CMake version: version 3.26.4
Libc version: N/A

Python version: 3.11.6 | packaged by conda-forge | (main, Oct  3 2023, 10:37:07) [Clang 15.0.7 ] (64-bit runtime)
Python platform: macOS-14.1.1-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: True

CPU:
Apple M1

Versions of relevant libraries:
[pip3] numpy==1.25.2
[pip3] pytorch-model-summary==0.1.2
[pip3] torch==2.1.1
[pip3] torchaudio==2.1.1
[pip3] torchinfo==1.8.0
[pip3] torchvision==0.16.1
[conda] numpy                     1.25.2                   pypi_0    pypi
[conda] pytorch-model-summary     0.1.2                    pypi_0    pypi
[conda] torch                     2.1.1                    pypi_0    pypi
[conda] torchaudio                2.1.1                    pypi_0    pypi
[conda] torchinfo                 1.8.0                    pypi_0    pypi
[conda] torchvision               0.16.1                   pypi_0    pypi


cc @mruberry @peterbell10
Repository: godot
Issue: Value of export property in child scene not preserved when scene closed and reopened
Labels: bug,discussion,topic:editor,needs testing

### Godot version

v4.2.rc2.official [1ba920fad]

### System information

Godot v4.2.rc2 - macOS 14.1.1 - GLES3 (Compatibility) - ANGLE (Intel, ANGLE Metal Renderer: Intel(R) UHD Graphics 630, Version 14.1.1 (Build 23B81)) - Intel(R) Core(TM) i7-8700B CPU @ 3.20GHz (12 Threads)

### Issue description

I have a scene with a Sprite2D and a tool mode script with an export texture property. This export texture property gets and sets the child Sprite2D's texture. A default texture is assigned in the scene. Lets call this scene a SpriteContainer.

I have another scene that contains a SpriteContainer. Lets call this scene a SpriteContainerContainer.

In the SpriteContainerContainer scene, I can change the SpriteContainer's sprite texture through its export variable and see the change immediately. When I save, close, and reopen the SpriteContainerContainer though I see the original sprite texture in the SpriteContainer.

### Steps to reproduce

Create a scene with this structure:

- Node2D (SpriteContainer)
  - Sprite2D

![Screenshot 2023-11-27 at 12 17 02 AM](https://github.com/godotengine/godot/assets/33398493/a0e094e9-5586-486b-b13e-e7a14950357f)

Add a script to the root node with this code:
```
@tool
class_name SpriteContainer
extends Node2D


@export var texture: Texture2D:
	get:
		return _sprite.texture
	set(value):
		if _sprite:
			_sprite.texture = value


@onready var _sprite: Sprite2D = $Sprite2D
```

In the scene's root node, assign a texture to the `texture` property (in the attached project it's the "blue.png" file). Save the scene as "sprite_container.tscn".

![Screenshot 2023-11-27 at 12 23 41 AM](https://github.com/godotengine/godot/assets/33398493/fc7f1fab-0b59-439c-a038-4b9b71b448e0)

Create a second scene with this structure:

- Node2D (SpriteContainerContainer)
  - SpriteContainer (the scene created earlier)

![Screenshot 2023-11-27 at 12 20 14 AM](https://github.com/godotengine/godot/assets/33398493/172bbe4e-9580-4764-b4f3-c94c50f3e908)

Save the scene as "sprite_container_container.tscn".

![Screenshot 2023-11-27 at 12 24 25 AM](https://github.com/godotengine/godot/assets/33398493/dcb2cd46-80c9-470b-8574-298fec5f5ba6)

In the SpriteContainerContainer scene, select the SpriteContainer and set its `texture` export property to a different texture (e.g. "red.png" in the attached project). The new texture is refected in the SpriteContainer's sprite.

![Screenshot 2023-11-27 at 12 25 21 AM](https://github.com/godotengine/godot/assets/33398493/b30c5367-1adb-417d-b682-dda46c3eecf8)

Save the SpriteContainerContainer scene, then reopen it.

**Expected Result:** The texture just assigned to the SpriteContainer node is still there.
**Actual Result:** The SpriteContainer still has its old default texture.

### Minimal reproduction project

[SpritePropertyTest.zip](https://github.com/godotengine/godot/files/13470033/SpritePropertyTest.zip)
Repository: godot
Issue: Long error message crashes editor
Labels: bug,topic:editor,needs testing,crash

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Windows 10, Mobile

### Issue description

While trying to debug a GLSL shader, I tried to print out the compilation error message using the push_error() command.  If you do this and mouse over the long error message in the output window, this will cause the Godot editor to hand indefinitely.  This has also bricked my entire system and caused me to reboot a few times.

### Steps to reproduce

Run the attached project.  It creates a long error message and calls push_error().  If you mouse over the error message in the output window, Godot will hang.

### Minimal reproduction project

[longErrorMessage.zip](https://github.com/godotengine/godot/files/13470727/longErrorMessage.zip)
Repository: storybook
Issue: [Bug]: A11y: contrast checks never complete
Labels: bug,addon: a11y,sev:S2

### Describe the bug

I have a hunch that it's related to canvas not being usable. I tired to run `axe-core` on Vitest based test, and got similar results.

### To Reproduce

1. Create a story that has a contrast issue. For example: `<a href="/foo" style="color: blue; background-color: blue">Foo</a>`.
2. Start Storybook and see the story. Accessibility tab shows contrast check as incomplete.

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.1.1
    CPU: (8) arm64 Apple M2
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.10.0 - ~/.nvm/versions/node/v20.10.0/bin/node
    Yarn: 1.22.21 - ~/.nvm/versions/node/v20.9.0/bin/yarn
    npm: 10.2.3 - ~/.nvm/versions/node/v20.10.0/bin/npm <----- active
    pnpm: 8.10.0 - ~/.nvm/versions/node/v20.9.0/bin/pnpm
  Browsers:
    Safari: 17.1
  npmPackages:
    @storybook/addon-a11y: 7.5.3 => 7.5.3 
    @storybook/addon-essentials: 7.5.3 => 7.5.3 
    @storybook/addon-interactions: 7.5.3 => 7.5.3 
    @storybook/addon-links: 7.5.3 => 7.5.3 
    @storybook/addon-onboarding: 1.0.8 => 1.0.8 
    @storybook/blocks: 7.5.3 => 7.5.3 
    @storybook/manager-api: 7.5.3 => 7.5.3 
    @storybook/react: 7.5.3 => 7.5.3 
    @storybook/react-vite: 7.5.3 => 7.5.3 
    @storybook/theming: 7.5.3 => 7.5.3 
    eslint-plugin-storybook: 0.6.15 => 0.6.15 
    storybook: 7.5.3 => 7.5.3
```


### Additional context

Default enabled rules should be enough. No need to configure the a11y plugin.