sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Update import/export specifier sort on rename
Labels: Suggestion,Help Wanted,Experience Enhancement

### 🔍 Search Terms

organizeImports import sort rename

### ✅ Viability Checklist

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

### ⭐ Suggestion

Renaming an exported function that is imported as one of many named imports can make that list of import specifiers become unsorted. When we execute auto-imports, we try to detect how/whether an existing list of named imports is currently sorted and insert the new specifier in the correct spot. We could do something similar when updating an import or export specifier during a Rename command.

### 📃 Motivating Example

We have an eslint rule that enforces import sort order. I just renamed a function `impliedNodeFormatForEmit` to `getImpliedNodeFormatForEmit`, and afterwards I had to go fix the eslint rule failure in 6 different files. It would be nice not to have to do that.

### 💻 Use Cases

1. **What do you want to use this for?** Easier refactoring that doesn't make linters mad
2. **What shortcomings exist with current approaches?** They require me to do a lot of tedious clicking around
3. **What workarounds are you using in the meantime?** A lot of tedious clicking around
Repository: rust
Issue: on eBPF a Rust fn should handle more than 5 args
Labels: A-LLVM,A-codegen,P-low,T-compiler,C-bug,A-ABI,S-needs-repro,O-eBPF

By default, eBPF only supports a 5-argument register calling convention. This is the only "standardized" ABI. In practice, compilers support stack-passing calling conventions for further arguments, and Rust is not required to follow a standard ABI for Rust to Rust calls. Nonetheless, because 5 args is the only standard, reputedly 5 args is what LLVM implements and the rest must be implemented by the frontend. We should be supporting argument-passing on the stack for `extern "Rust"` on eBPF if we're going to bother supporting `bpfe{l,b}-unknown-none` at all.

I'm opening this in advance of assembling a full repro before I forget it. It is possible this is no longer an issue and we only need an assembly test to verify we can handle 10 args on eBPF. h/t @saleemrashid
Repository: flutter
Issue: [macOS] Add multi-view runner APIs
Labels: platform-mac,a: desktop,P2,a: multi window,team-macos,triaged-macos

Do all the macOS stuffs in https://flutter.dev/go/desktop-multi-view-runner-apis
Repository: tauri
Issue: [bug] v2 custom http client connection is silently dropped after 60 seconds timeout on MacOS
Labels: type: bug,status: needs triage

### Describe the bug

tauri version: `2.0.0-beta.11`

I'm using a Grpc-web client (which uses fetch) over http1 for server-streaming over Grpc endpoints. 

Everything is working, except that under Tauri, and only under Tauri, **a streaming connection will be silently dropped after exact 60 seconds.** 

For other descriptions, please see https://github.com/connectrpc/connect-es/issues/1044

I tested in other environment: serving Tauri frontend in browsers (Chrome, Safari) without Tauri instance connecting directly to the server, or connect with a local client such Postman. All these work without encountering the 60s timeout.

Under Tauri, everything works within 60 seconds. But the connection will timeout exactly after that. 

If I set a shorter timeout ms on my client request, the shorter timeout will be respected, but not anything longer than 60s. 

**The request `user-agent` under Tauri:**
> "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko)"

**Sample request `user-agent` under other working environments (this example from under Safari):**
>  "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.1.2 Safari/605.1.15"

### Reproduction

_No response_

### Expected behavior

A connection will respect client and server timeouts, not unknown environment timeout under Tauri.

### Full `tauri info` output

```text
Unhandled Promise Rejection: ConnectError: [deadline_exceeded] the operation timed out
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: rust
Issue: Consider using `llvm-strip`
Labels: O-linux,O-macos,A-codegen,T-compiler,T-infra,T-dev-tools,C-discussion,O-illumos

Historically, when handling issues like "the tools on the system we are delivering the toolchain to, for a particular target arch, have lots of individual quirks", Rust has had two primary moves:
- Allow the tools we use to be completely configured via flags
- Ship our own tool and teach the compiler to prefer that for that host/target

On ~~macOS~~ various systems, we are encountering reports in the wild of people having ~~bad~~ inadequately-built `strip` binaries in their PATH *that cannot support all Rust compiler use-cases*[^0][^1] (e.g. GNU binutils that is built with **only** host platform support).

In particular, this means:
- sometimes `cargo run --release` produces binaries that get SIGKILLed on macOS
- sometimes cross-compiled binaries, even between ELF/DWARF hosts and targets, have broken stacktraces, because the strip isn't aware it should be sensitive to the needs of that target platform's debugging infra.

We can try to work with Nix, Homebrew, *and apparently illumos and most Linux distros* to solve this problem, but if this is a persistent issue, and considering the somewhat mysterious errors that result, it may be most productive to simply ship our own copy of `strip` on these hosts. I believe `llvm-strip` gets everything right, as far as we are concerned, and would be the choice to "bless" accordingly.

Even if it has its own problems, it would be far easier to ship desired patches to binary support we control, or invite people to push fixes to upstream: we'd just need to cooperate with LLVM (or whoever else supplies this), rather than relying on every single distro cooperating perfectly with us. And I think that it's probably worth it: `llvm-strip` costs only about 175KB on my system, and probably a little bit of build infra, but pays for itself several times over, obviously: every Rust binary built with the toolchain, thanks to enabling `strip`, is a few MB lighter for its `--release` mode.

[^0]: On macOS this is especially bad. The local toolchain comes with `llvm-strip` which supports mach-o correctly, but in practice, no one uses the local toolchain exclusively. Yeah, XCode is the standard for merely building something, but in order to make a really complete development environment on macOS, you have to add something, like Homebrew, MacPorts, or Nix. So people on macOS are constantly injecting odd `strip` binaries into their PATH that can't even support the host, leading to us using one that is flawed. These tools try to compensate for the inevitable odd system configurations that result but do so imperfectly, resulting in erroneous behavior.
[^1]: By default, it seems e.g. Nix only builds with host support, because [the cost of all-targets support is about 60 more MB](https://github.com/NixOS/nixpkgs/issues/299606#issuecomment-2025319399). I'm sure they're not the only one. 'tis a very "don't pay for what you don't need" mindset to make you install every single cross-build target individually and pay a few dozen MB each time, instead of paying double, once.
Repository: PowerToys
Issue: Hide focused window
Labels: Idea-New PowerToy,Needs-Triage

### Description of the new feature / enhancement

basically the same behavior of `WIN + ,` but only on the focused app so we can see the windows behind

### Scenario when this would be used?

As a web developer. when I'm away from my second screen, I find it annoying to have to switch windows to be able to see results of any code changes. and splitting the windows isn't practical either. so if I have a shortcut that quickly hides the focused window (vscode), I can quickly check the window behind (the browser) and when I let go of the keys i go back to vscode to continue editing.

A+ if we can also edit the opacity of the focused window so we don't even need to click a shortcut and be able to see the changes all the time.

### Supporting information

something like `alt + tab` basically
Repository: vscode
Issue: macOS: state of native window tabs is not restored after restart
Labels: upstream,macos,electron,workbench-os-integration,workbench-window

Type: <b>Feature Request</b>

Hi,

I work on many microservices (cloud functions) at a time, and all are in different repos. It is easier to merge windows for all the related repositories and work on them in one mac window. Though the merge windows work great, it has a couple of issues - 
1. I cannot create a workspace that understands many projects and merged windows. So I cannot save my state for a group of projects.
2. Every time I have to restart VSCode (for updates, etc.), the restart does not remember the merged windows and their order.

Ideally, it would be nice to be able to create a workspace that includes merged windows and multiple projects, but if not, at least Vscode remembering the merge state when restarting should help.

Thanks,


VS Code version: Code 1.87.2 (Universal) (863d2581ecda6849923a2118d93a088b0745d9d6, 2024-03-08T15:21:31.043Z)
OS version: Darwin arm64 23.1.0
Modes:


<!-- generated by issue reporter -->
Repository: ui
Issue: [bug]: The select trigger error occurs to the click event in '@testing-library/react' and '@testing-library/user-event'.
Labels: bug

### Describe the bug

I would like to conduct a test of the select component.
I have written as shown in the code below, but an error occurs.

` TypeError: target.hasPointerCapture is not a function. (In 'target.hasPointerCapture(event.pointerId)', 'target.hasPointerCapture' is undefined)`

```
                <SelectTrigger
                  className='w-full focus:ring-1 focus:ring-gray-300'
                  data-testid= 'select-style-to-edit'
                >
                  <SelectValue placeholder='Select style to edit' />
                </SelectTrigger>
```

```
 const element = screen.getByTestId('select-style-to-edit')
    await userEvent.click(element, {
      pointerState: await userEvent.pointer({ target: element }),
    })
    

```

### Affected component/components

Select

### How to reproduce

1. get select trigger in test code.
2. add click event
3. error occurs.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
linux,chrome
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: godot
Issue: Window size not constant in borderless mode
Labels: bug,topic:core

### Tested versions

reproducible
- v3.6.beta.custom_build [02c02403e]
- v3.5.3.stable.official [6c814135b]

fixed in
- v4.3.dev5.official [c9c17d6ca]


### System information

Ubuntu 22.04.4 LTS, NVIDIA 535.161.07

### Issue description

Noticed not constant window size in **borderless mode** in **3.x**. But looks like this is **fixed in master**

```
sample output
(1024, 637)
(1024, 600)
(1024, 600)
(1024, 600)
(1024, 637)
(1024, 600)
```

### Steps to reproduce

1. run attachment
2. press any key
3. repeat until you get different results

or

1. make new project
2. enable borderless mode in project settings
3. add following script to main node

```gdscript
extends Node


func _ready() -> void:
	print(OS.window_size)


func _input(event: InputEvent) -> void:
	if event is InputEventKey:
		get_tree().quit()

```

### Minimal reproduction project (MRP)

[New Game Project.zip](https://github.com/godotengine/godot/files/14783548/New.Game.Project.zip)
Repository: TypeScript
Issue: Design Meeting Notes, 3/26/2024
Labels: Design Notes

# Format Types Consistently in Baselines and Underlining Type Node Generation

* https://github.com/microsoft/TypeScript/pull/57890
* https://github.com/weswigham/TypeScript/pull/69

* As we try to maximize node reuse, we realized we have no indication as to whether that is taking place apart from whitespace as a heuristic.
* Even then, preserving whitespace isn't always desirable.
* This PR adjusts type baselines to always apply the same formatting consistently.
* A separate PR adds an underline to indicate when a node was synthesized.
* What are we trying to catch here?
    * Lack of node reuse.
    * Could exhaustively check things, but better off using our current infrastructure.
* Kind of a pain to read these.
* Is it arguable that the underlines actually indicate that you *should* pay attention even if you only care about the types?
    * Maybe.
* Aside: do we need symbol baselines?

# `tsc --noCheck`

https://github.com/microsoft/TypeScript/pull/57934

* For TypeScript? Isn't that *weird*??
* Idea: allows people to perform a check and a build separately.
* Declaration emit actually *surprisingly* works here. Most of the information can be calculated lazily, and so it avoids a *full* check.
* Unfortunately, JavaScript emit actually calculates some information in the checker.
* This is *very surprisingly fast*.
* The only downside of using `--noCheck` for declaration emit is that it may differ in output from stuff like union ordering (which depends on types being assigned IDs, which is sensitive to check order).
* Our main goal is to be a type-checker.
* How does this work with syntax errors?
    * You *won't* get them.
* Unclear if it's a good idea to bring this in without making this possible for the JS side. We need to try decoupling JS emit to see what if anything regresses.
* Mixture of support for the concept of `--noCheck`, but if we can unlock this for `transpileModule` that would be a big win.
* Don't want to add a command line flag just yet.
* Bike-shed a name.
    * `skipCheck`?
    * `noCheck` to parallel `noEmit`?

# Respect `type` in `package.json` in more `module` modes

https://github.com/microsoft/TypeScript/pull/57896

* Some notable changes:
    * A `.cjs` module under `--module esnext` got emitted with ES syntax; no longer does.
    * People using `.cts` files under `--moduleResolution bundler --module esnext` (aside: nowadays `--module preserve` is what most of these people want), we would resolve with the `import` condition, now resolves with the `require` condition.
        * Kind of weird under `--preserve`, but 🤷‍♂️.
    * Under `--module preserve`, we issue something like `verbatimModuleSyntax` errors because it won't be interpreted the same way from a declaration file.
* Did *not* add logic to disallow CommonJS input files. Presumably a program-level error if we wanted to add it.
Repository: pytorch
Issue: ONNX melspectrogram export error
Labels: module: onnx,triaged

### 🐛 Describe the bug

import torch
import torchaudio
from torch import nn


class DataCov(nn.Module):
    def __init__(self):
        super(DataCov, self).__init__()

        self.transform = nn.Sequential(
            torchaudio.transforms.MelSpectrogram(sample_rate=48000, n_fft=1536, hop_length=768, f_min=20, f_max=20000)
        )

    def forward(self, x1):
        return self.transform(x1)

def export_datacov_onnx(path):
    model = DataCov()
    model.eval()
    model = torch.jit.script(model)
    x = torch.randn((1, 48000 * 12), requires_grad=True)
    args = (x,)
    torch.onnx.dynamo_export(model, args, path, export_params=True, opset_version=18)


if __name__ == '__main__':
    #export_datacov_script("DataCov.pt")
    #export_qanet_script("fun3.pth", "QANet.pt")
    export_datacov_onnx('DataCov.onnx')

### Versions

collect_env.py 
Collecting environment information...
PyTorch version: 2.4.0.dev20240326
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Microsoft Windows 10 专业版
GCC version: (Rev5, Built by MSYS2 project) 13.1.0
Clang version: Could not collect
CMake version: version 3.26.4
Libc version: N/A

Python version: 3.11.4 | packaged by Anaconda, Inc. | (main, Jul  5 2023, 13:47:18) [MSC v.1916 64 bit (AMD64)] (64-bit runtime)
Python platform: Windows-10-10.0.19045-SP0
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:










Revision=

Versions of relevant libraries:
[pip3] numpy==1.24.3
[pip3] onnx==1.14.0
[pip3] onnxruntime==1.15.1
[pip3] onnxscript==0.1.0.dev20240328
[pip3] torch==2.1.0.dev20230810+cpu
[pip3] torchaudio==2.1.0.dev20230810+cpu
[pip3] torchvision==0.16.0.dev20230810+cpu
[conda] blas                      1.0                         mkl    defaults
[conda] cpuonly                   2.0                           0    pytorch-nightly
[conda] mkl                       2021.4.0           haa95532_640    defaults
[conda] mkl-service               2.4.0           py311h2bbff1b_0    defaults
[conda] mkl_fft                   1.3.1           py311h743a336_0    defaults
[conda] mkl_random                1.2.2           py311heda8569_0    defaults
[conda] numpy                     1.24.4                   pypi_0    pypi
[conda] numpy-base                1.24.3          py311h877bb12_0    defaults
[conda] pytorch                   2.4.0.dev20240326    py3.11_cpu_0    pytorch-nightly
[conda] pytorch-mutex             1.0                         cpu    pytorch
[conda] torch                     2.1.0.dev20230810+cpu          pypi_0    pypi
[conda] torchaudio                2.1.0.dev20230810+cpu          pypi_0    pypi
[conda] torchvision               0.16.0.dev20230810+cpu          pypi_0    pypi
Repository: godot
Issue: Disable Proximity Fade in Compatibility will trigger "Condition "!texture_allocs_cache.has(p_id)" is true"
Labels: bug,topic:rendering,topic:3d

### Tested versions

Godot v4.3.dev (5d08c2631) 



### System information

Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA GeForce RTX 3060 (NVIDIA; 31.0.15.3619) - 11th Gen Intel(R) Core(TM) i7-11700K @ 3.60GHz (16 Threads)

### Issue description

When enable  Proximity Fade in Compatibility nothing will happen due to https://github.com/godotengine/godot/issues/89942, but disable it will trigger a error says "godot\drivers\gles3\storage/utilities.h:144 - Condition "!texture_allocs_cache.has(p_id)" is true."

![image](https://github.com/godotengine/godot/assets/8315986/6935953a-274a-4c68-81d1-00e22786aee2)

It doesn't happen in vulkan.

### Steps to reproduce

* Use Compatibility renderer.
* Add a cube on a plane.
* Apply a new standardMaterial3D to cube and enable Proximity Fade
* Disable it and observe

### Minimal reproduction project (MRP)

Open the DistanceFade.tscn and see the steps above.

[ProximityFade.zip](https://github.com/godotengine/godot/files/14784093/ProximityFade.zip)
Repository: transformers
Issue: SigLIP tokenizer not enforcing use_fast=True
Labels: Feature request,Good Difficult Issue

### System Info

- `transformers` version: 4.38.2
- Platform: Linux-4.18.0-477.27.1.el8_8.x86_64-x86_64-with-glibc2.28
- Python version: 3.10.13
- Huggingface_hub version: 0.21.4
- Safetensors version: 0.4.2
- Accelerate version: not installed
- Accelerate config: not found
- PyTorch version (GPU?): 2.2.1+cu121 (True)
- Tensorflow version (GPU?): not installed (NA)
- Flax version (CPU?/GPU?/TPU?): not installed (NA)
- Jax version: not installed
- JaxLib version: not installed
- Using GPU in script?: <fill in>
- Using distributed or parallel set-up in script?: <fill in>

### Who can help?

_No response_

### Information

- [X] The official example scripts
- [ ] My own modified scripts

### Tasks

- [X] An officially supported task in the `examples` folder (such as GLUE/SQuAD, ...)
- [ ] My own task or dataset (give details below)

### Reproduction

```
from transformers import AutoTokenizer
t=AutoTokenizer.from_pretrained('google/siglip-so400m-patch14-384', use_fast=True)
assert t.is_fast, 'tokenizer is not fast'
print('Success')
```

### Expected behavior

print 'Success' which indicates `use_fast=True`
Repository: storybook
Issue: Screen reader is not announcing the selection state of the "Violations"/"Passes"/"Incomplete" tab items in Accessibility Tab.
Labels: bug,good first issue,help wanted,accessibility,sev:S3

### Describe the bug

OS: Windows 11
OS version: 23H2 (OS Build 22631.3296)
Edge Version: 122.0.2365.80 (Official build) (64-bit)

### To Reproduce

1.Open the URL " [Overview - Docs ⋅ Storybook (windows.net)](https://nam06.safelinks.protection.outlook.com/?url=https:%2f%2fvivacommonstorybooktest.blob.core.windows.net%2f%24web%2findex.html?path%3D%2fdocs%2foverview--docs&data=05%7c02%7cv-subaku%40microsoft.com%7c1d03a870859b492ba99f08dbf6498987%7c72f988bf86f141af91ab2d7cd011db47%7c1%7c0%7c638374567927399114%7cUnknown%7cTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7c3000%7c%7c%7c&sdata=924Ca%2B3zJMJHXpDXaCwWOTu%2fHX1W%2fJ2TKRp6YoSBli8%3D&reserved=0)".
2.Navigate to the "Tab list" in the left pane and expand it.
3.Navigate to "default" and invoke it.
4.Navigate to "Accessibility" tab item and invoke it.
5.Navigate to the " violations, passes, incomplete tab items.
6.Observe the narrator announcement.

[b12dd9a1-4c07-4f73-8204-4a056297188d.webm](https://github.com/storybookjs/storybook/assets/93735775/32c849c4-9520-4964-89ac-16ac90928e5f)


### System

```bash
Actual Results: 

While navigating to the " violations, passes, incomplete tab items, narrator is not announcing the selected/unselected state.

Expected Results: 

While navigating to the " violations, passes, incomplete” tab items, narrator should announce the selected/unselected state.
```


### Additional context

_No response_