sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Web worker + barrel files can give JIT errors
Labels: area: packaging

### Which @angular/* package(s) are the source of the bug?

core

### Is this a regression?

No

### Description

In a project I have a web worker that runs some functions that are imported using a barrel file (an `index.ts`). The compiled web worker seems to also include all other files the barrel exports, while they are not being used in the web worker. In this case, that barrel file also re-exports a service that injects the `HttpClient`. This results in the web worker failing with a `JIT compiler unavailable` error when running the compiled `dist` folder using `http-server` for example (the error does not occur when using `ng serve`).

The error vanishes when:
- the function used in the web worker is imported directly from the function file instead of using the barrel file; or
- the service does not inject the `HttpClient`.

I think the main problem here is that no tree-shaking is happening to the web worker?

### Please provide a link to a minimal reproduction of the bug

https://github.com/tijsmoree/webworker-jit-error

### Please provide the exception or error you saw

```true
Error: JIT compiler unavailable
```

### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 19.0.2
Node: 20.16.0
Package Manager: pnpm 9.14.2
OS: linux x64

Angular: 19.0.1
... animations, common, compiler, compiler-cli, core
... platform-browser

Package                      Version
------------------------------------------------------
@angular-devkit/architect    0.1900.2 (cli-only)
@angular-devkit/core         19.0.2 (cli-only)
@angular-devkit/schematics   19.0.2 (cli-only)
@angular/build               19.0.2
@angular/cli                 19.0.2
@schematics/angular          19.0.2 (cli-only)
rxjs                         7.8.1
typescript                   5.6.3
zone.js                      0.15.0
```

### Anything else?

_No response_
Repository: neovim
Issue: Wrong ANSI colors in terminal
Labels: bug,terminal

### Problem

Terminal shows incorrect ANSI escapes for values 37 (bright white foreground) and 40 (black background). The black background seems to always be treated as background, even if particular color scheme uses a light color (here white). See `$PSStyle` output below, left are correct colors from regular terminal, right are values from terminal running inside Neovim.

![Image](https://github.com/user-attachments/assets/ecd30976-846c-4c67-8d05-05cf49db9121)


### Steps to reproduce

> $PSStyle
> nvim -c 'term pwsh -c "$PSStyle"'

### Expected behavior

Colors match

### Nvim version (nvim -v)

NVIM v0.9.5, v0.10.2, v0.11.0

### Vim (not Nvim) behaves the same?

Yes

### Operating system/version

Microsoft Windows Version 23H2 (OS Build 22631.4460)

### Terminal name/version

Windows Terminal 1.21.3231.0

### $TERM environment variable

xterm-256color

### Installation

winget install -e Neovim.Neovim --version 0.9.5
Repository: vscode
Issue: R&D Workspace features for ai
Labels: feature-request

<!-- ⚠️⚠️ 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. -->

Integrating AI capabilities into Visual Studio Code (VS Code) are becoming phenomenal developments. Whereas especially tools like GitHub Copilot. Recently introducing features that enhance workflows. Also come with significant considerations regarding the frontier of software development emergent challenges.  
   In preference, integrations of Test, Evaluation, Validation, and Verification (TEVV) methodologies, concurrent with Software Assurance frame working (SwA), are proven to drive innovation at work. Although the issues I have realized are individually preferred but not yet adopted generally. Therefore, the proposal is not as urgent in status.

Furthermore, ongoing resolution. I think advancing workspace actions are essential to enable copilot workflow. To produce accordingly to project specific requirements or otherwise "needs" . And those requirements are workspace analysis, workflow TEVV and additionally a greater ai scope in Software assurance
Repository: react-native
Issue: requestAnimationFrame callback order is nondeterministic
Labels: Bug

### Description

In my experience, the order of rAF callbacks is always deterministic on web. It [seems](https://stackoverflow.com/a/34905490) like it's deterministic per spec. In other words, this:

```js
requestAnimationFrame(() => {
  console.log('1')
})

requestAnimationFrame(() => {
  console.log('2')
})

requestAnimationFrame(() => {
  console.log('3')
})
```

should produce

```
1
2
3
```

That *is* the case on the web, but it's not in React Native.

Instead, on React Native, it's seemingly non-deterministic

### Steps to reproduce

See this snack: https://snack.expo.dev/PsXPlo457DmfjCIEzRIsp?platform=ios

Expected:

```
1,2,3
```

Actual:

<img width="435" alt="Screenshot 2024-11-28 at 14 16 09" src="https://github.com/user-attachments/assets/82824338-b2d7-40e3-a495-fd72fd13da25">

<img width="411" alt="Screenshot 2024-11-28 at 14 16 31" src="https://github.com/user-attachments/assets/2bd7ed08-2908-420a-8757-4d9f818bcf07">

I believe this is the case for:

- Both platforms on 0.74.*
- Seemingly, only for Android on 0.76.* (maybe due to New Architecture being a default?)

### React Native Version

0.76.0

### Affected Platforms

Runtime - Android, Runtime - iOS

### Output of `npx react-native info`

```text
System:
  OS: macOS 14.6.1
  CPU: (16) arm64 Apple M3 Max
  Memory: 60.87 GB / 128.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.8.0
    path: /opt/homebrew/bin/node
  Yarn:
    version: 1.22.22
    path: /opt/homebrew/bin/yarn
  npm:
    version: 10.8.2
    path: /opt/homebrew/bin/npm
  Watchman:
    version: 2024.09.09.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /opt/homebrew/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 23.5
      - iOS 17.5
      - macOS 14.5
      - tvOS 17.5
      - visionOS 1.2
      - watchOS 10.5
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2412.12266719
  Xcode:
    version: 15.4/15F31d
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.12
    path: /usr/bin/javac
  Ruby:
    version: 2.6.10
    path: /usr/bin/ruby
npmPackages:
  "@react-native-community/cli": Not Found
  react:
    installed: 18.2.0
    wanted: 18.2.0
  react-native:
    installed: 0.74.1
    wanted: 0.74.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: false
iOS:
  hermesEnabled: true
  newArchEnabled: false
```


### Stacktrace or Logs

```text
N/A
```


### Reproducer

https://snack.expo.dev/vZ6_gSpj6iB6z0tpgDnsw?platform=android

### Screenshots and Videos

_No response_
Repository: godot
Issue: SpinBox seemingly randomly crashes the whole Editor
Labels: bug,crash,topic:gui

### Tested versions

Reproducible in: v4.3.stable.official [77dcf97d8]
(didnt test more versions since it takes so much time to get results)

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3060 Ti (NVIDIA; 32.0.15.6094) - 13th Gen Intel(R) Core(TM) i5-13400 (16 Threads)

### Issue description

While I was testing my plugin's UI the whole editor suddenly crashed. I was able to repruduce the crash multiple times but its very inconsistent.

I stripped away as much stuff from my plugin as possible and left the project as a minimal repro project below. (Thats why the variable names and the labels have those not so generic texts)

Honestly, I couldnt figure out what is truly causing the crash since its so random and I cant get a crash log or anything. I tried launching the editor with --verbose but nothing gets printed when crashing.
And the even more weird thing is, I recorded my mouse inputs with a software and played back the whole thing after crashing and even this way i couldnt get a consistent result, I crashed a bit later.

I have left a video of me reproducing the crash but it well takes around 2-10 minutes to get a crash. It was really hard for me to test this since I was just guessing what might cause the crash and I cant even make sure that after like 10 minutes of trying this and not getting a crash wouldnt have caused a crash after like 15 minutes of trying.

All I can say is, doing the steps I list below on the minimal repro project WILL EVENTUALLY cause the editor to crash.


### Steps to reproduce

1. Click the `Add limb` button on the 3D toolbar.
2. Click the `Select tip bone` button
3. Click randomly around on the `SpinBox arrows` and maybe in the `input field` too for some time.
4. Click on the `Select` button.
5. Go back to step 2. and repeat a couple of times.
6. Click away from the PopupPanel and repeat the whole thing until the editor freezes and crashes at some point.

[editor_crash.zip](https://github.com/user-attachments/files/17949309/editor_crash.zip)



### Minimal reproduction project (MRP)

[plugin-bug-test.zip](https://github.com/user-attachments/files/17948584/plugin-bug-test.zip)
Repository: rust
Issue: Docs & `rustdoc`: Mark traits that have indirect and synthetic impls
Labels: T-rustdoc,C-enhancement,A-rustdoc-ui,T-rustdoc-frontend

There's a lot of implicit stuff going on behind the scenes in Rust that's dictated by the very nature of the trait-based type systems. However, that doesn't change the fact that hidden complexity makes it difficult to understand other people's code and write your own, let alone learn the language for newbies.

One example of such complexity is side effects of importing traits from other modules, when seemingly familiar types can suddenly acquire new methods and even [operational semantics](https://doc.rust-lang.org/1.82.0/reference/special-types-and-traits.html#operator-traits). But since we can declare the use of elements without naming each of them individually, with [asterisk wildcard syntax](https://doc.rust-lang.org/1.82.0/reference/items/use-declarations.html), these methods begin to look like as though they came out of nowhere. And sometimes this approach is even preferable and officially recommended - see e.g. [`std::io::prelude`](https://doc.rust-lang.org/1.82.0/std/io/prelude/index.html).

This problem could be greatly mitigated if such traits were distinctly marked out on overview pages. This includes:

- Traits that have blanket implementations. The most prominent example here is [`Any`](https://doc.rust-lang.org/1.82.0/std/any/trait.Any.html).
- Traits that have implementations on foreign types, along with generic (i.e. [covered](https://doc.rust-lang.org/reference/glossary.html#uncovered-type)) ones. A good illustration of it is [`zerocopy::Unaligned`](https://docs.rs/zerocopy/0.8.11/zerocopy/trait.Unaligned.html#foreign-impls).
- [Auto traits](https://doc.rust-lang.org/1.82.0/reference/special-types-and-traits.html#auto-traits): as of 1.82.0, it's [`Send`](https://doc.rust-lang.org/1.82.0/core/marker/trait.Send.html), [`Sync`](https://doc.rust-lang.org/1.82.0/core/marker/trait.Sync.html), [`Unpin`](https://doc.rust-lang.org/1.82.0/core/marker/trait.Unpin.html), [`UnwindSafe`](https://doc.rust-lang.org/1.82.0/core/panic/unwind_safe/trait.UnwindSafe.html), [`RefUnwindSafe`](https://doc.rust-lang.org/1.82.0/core/panic/unwind_safe/trait.RefUnwindSafe.html), [`Freeze`](https://doc.rust-lang.org/1.82.0/std/marker/trait.Freeze.html) (unstable) and [`Sized`](https://doc.rust-lang.org/1.82.0/std/marker/trait.Sized.html).
  They don't quite fit the stated criterion, but are close to it in spirit, so I think it would be nice to also highlight them from the general mass.
Repository: godot
Issue: Unnecessary precision loss in compressed animation tracks
Labels: bug,topic:animation

### Tested versions

Reproducible in Godot v4.4.dev [bbc54692c].

### System information

Windows 10.0.19045. Compiled with MSVC.

### Issue description

Compressed animation tracks are losing half of their precision due to the choice of rounding in unorm conversion. The visual impact is very small in most cases, but the fix is simple so I hope it's worth considering.

In `Animation::_compress_key`, the various conversions to unorm are done with `int32_t(float_value * 65535.0)`. This rounds towards zero, so an input of 0.999999 will be encoded as 65534 and decompressed to 0.999985 (difference: \~0.000014).

Changing the conversions to `int32_t((float_value * 65535.0) + 0.5f)` would make them round to nearest, doubling the precision. So an input of 0.999999 would be encoded as 65535 and decompressed to 1.0 (difference: \~0.000001). In case it's relevant, this is the conversion used by most graphics APIs (e.g. [DirectX](https://learn.microsoft.com/en-us/windows/win32/direct3d10/d3d10-graphics-programming-guide-resources-data-conversion#:~:text=Convert%20to%20integer.,directly%20to%20an%20integer)).

I can make a PR if desired. Note that I've also filed a separate bug that involves the same unorm code (https://github.com/godotengine/godot/issues/99794). I will roll both fixes into the same PR unless advised otherwise.

And some bonus notes:

- The unorm compress/uncompress triggers an unnecessary double <-> float conversion because the scaling constant is a double literal.
	- ~~Changing it to float is probably a negligible performance improvement, but seems like a safe change that can be folded into the other changes.~~
	- EDIT: On second thoughts, it's not quite clear if this is true when real_t is double. 
- There's a few other cases of unorm conversions with rounding towards zero, including mesh vertex compression.
	- I haven't tested these yet to confirm if they have the same precision loss.
	- I can file these as separate issues if desired.

### Steps to reproduce

I don't have a good repro as the visual difference is very subtle.

In case it's useful, https://github.com/greeble-dev/godot/commit/30a5e9afbe27a87e3a033b8053fa889765ed369d is a hacky code change I used to test a few values with the original conversion and proposed fix. If the change is applied, reimporting any compressed animation should trigger this debug output:

```
scene\resources\animation.cpp:4776 - Original: 1.000000 quantizes to 1.000000 (unorm 65535)
scene\resources\animation.cpp:4782 - Updated: 1.000000 quantizes to 1.000000 (unorm 65535)
scene\resources\animation.cpp:4776 - Original: 0.999999 quantizes to 0.999985 (unorm 65534)
scene\resources\animation.cpp:4782 - Updated: 0.999999 quantizes to 1.000000 (unorm 65535)
scene\resources\animation.cpp:4776 - Original: 0.000014 quantizes to 0.000000 (unorm 0)
scene\resources\animation.cpp:4782 - Updated: 0.000014 quantizes to 0.000015 (unorm 1)
```

### Minimal reproduction project (MRP)

N/A
Repository: transformers
Issue: Replace all torch.FloatTensor by torch.Tensor
Labels: Feature request

### Feature request

I think `torch.FloatTensor` dtype should be replace by `torch.Tensor` now. torch.FloatTensor is quite anoying as it trigger warning most of the time, and force users to manually cast type to avoid such warning.

It seems that FloatTensor is not really use anymore in Torch. torch.FloatTensor and torch.cuda.FloatTensor are still available to ensure backward compatibility

### Motivation

Fix typing warnings

### Your contribution

Replace every occurence of torch.FloatTensor by torch.Tensor. Including docstrings
Repository: electron
Issue: Request for official rpm package
Labels: enhancement :sparkles:

### Preflight Checklist

- [x] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [x] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [x] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Request for a proper fedora apm to be uploaded to the rpm repo following the guidelines in 
https://docs.fedoraproject.org/en-US/packaging-guidelines/ and 
https://docs.fedoraproject.org/en-US/packaging-guidelines/Node.js/

### Proposed Solution

.

### Alternatives Considered

have an option for source code in npm

### Additional Information

_No response_
Repository: node
Issue: WebAssembly source phase imports
Labels: esm,wasm,web-standards

TC39 proposal [source phase imports](https://github.com/tc39/proposal-source-phase-imports) reached to stage 3 and has been implemented in V8 (starting from M131).

```js
import source FooModule from "./foo.wasm";
FooModule instanceof WebAssembly.Module; // true
```

The feature requires Node.js integration to support WebAssembly source phase imports. TLDR, if a SourceTextModule imports a source-phase WebAssembly module, create a module source object with `v8::WasmModuleObject::Compile` and return the `WebAssembly.Module` object from `v8::Module::ResolveSourceCallback`, and `v8::HostImportModuleWithPhaseDynamicallyCallback`.

> See [design doc](https://docs.google.com/document/d/1yetUlxl_yHk0ooT-hg9ylJeQ6Q77_Ttm777tHbclwqg/edit?tab=t.0#heading=h.uzscwod1dpgu) for details.

WPT: https://github.com/web-platform-tests/wpt/blob/master/wasm/webapi/esm-integration/source-phase.tentative.html

/cc @guybedford
Repository: PowerToys
Issue: clipboard didn't function well, when I come back to my pc's and the Screensaver are on then I can't open the second pc, and after that the mouse don't even comes back...
Labels: Issue-Bug,Product-Mouse Without Borders

### Microsoft PowerToys version

v0.86.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Mouse Without Borders, FancyZones, Awake, General

### Steps to reproduce

x

### ✔️ Expected Behavior

x

### ❌ Actual Behavior

nothing 

### Other Software

_No response_
Repository: next.js
Issue: Next.js 14 `loading.tsx` bug
Labels: bug,Navigation,Lazy Loading

### Link to the code that reproduces this issue

https://github.com/jelius-sama/loading-bug-nextjs-14.git

### To Reproduce

1. Start the dev server.
2. Do a hard refresh to make sure nothing is cached in the browser.
3. From the index route ("/"), navigate to "art page" by clicking the link an observe the bordered section.

### Current vs. Expected behavior

1. Following the steps, the loading UI looks to be incorrect (look into the code: "src/app/[artist]/[art]/loading.tsx" for the actual UI verses what was rendered).
2. The loading UI should've been "Loading art page..." instead we get to see "Loading artist page..."

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Home Single Language
  Available memory (MB): 5990
  Available CPU cores: 8
Binaries:
  Node: 20.10.0
  npm: N/A
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.5 // An outdated version detected (latest is 15.0.3), upgrade is highly recommended!
  eslint-config-next: 14.2.5
  output: N/A
 ⚠ An outdated version detected (latest is 15.0.3), upgrade is highly recommended!
   Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
   Read more - https://nextjs.org/docs/messages/opening-an-issue
```


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

Lazy Loading, Navigation

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

next dev (local), next start (local), Vercel (Deployed), Other (Deployed)

### Additional context

_No response_
Repository: react
Issue: Blocking the event loop spawnSync 
Labels: React 19

To avoid blocking event loop use **execSync** is best compare to **SpawnSync** this cause performance, when running multiple concurrent tasks in  React build pipeline

**Consider replacing `spawnSync` with `spawn` to prevent blocking**

```js
const sha = execSync('git rev-parse HEAD').slice(0, 8);
Repository: opencv
Issue: Integrate TEBLID efficient descriptor with ORB feature detector
Labels: feature,category: features2d,GSoC

### Describe the feature and motivation

[TEBLID](https://docs.opencv.org/4.x/dd/dc1/classcv_1_1xfeatures2d_1_1TEBLID.html) developed by @iago-suarez is a very efficient feature detector that is much better than [ORB](https://docs.opencv.org/4.x/db/d95/classcv_1_1ORB.html) current descriptor using the same pixel pair gray levels differences.

[TEBLID](https://docs.opencv.org/4.x/dd/dc1/classcv_1_1xfeatures2d_1_1TEBLID.html) selects pixel pairs using minimizing modern triplet loss (see [paper](https://docs.opencv.org/4.x/d0/de3/citelist.html#CITEREF_Suarez2021TEBLID)), while ORB descriptor uses simple correlation to select pixel pairs. The result is that in [AKAZE example](https://github.com/opencv/opencv/blob/4.x/samples/cpp/tutorial_code/features2D/AKAZE_match.cpp) with 10000 key points detected by [ORB](https://docs.opencv.org/4.x/db/d95/classcv_1_1ORB.html),  [TEBLID](https://docs.opencv.org/4.x/dd/dc1/classcv_1_1xfeatures2d_1_1TEBLID.html) obtains 621 inliers (75.2%) with 256 bits while  [ORB](https://docs.opencv.org/4.x/db/d95/classcv_1_1ORB.html) descriptor obtains only 493 inliers (63%).

In addition, TEBLID implementation in OpenCV's xfeatures3D is parallelized and runs faster than current ORB descriptor extraction.

With the advent of [OpenCV 5 features2D reorganization](https://github.com/opencv/opencv/issues/24999) to get a super fast local features and descriptor extractor we should have TEBLID descriptor integrated in the ORB detector along with the original BRIEF descriptor or removing it completely.

### Additional context

_No response_
Repository: PowerToys
Issue: Disabling Alt+Tab+1234567890
Labels: Issue-Bug,Product-Keyboard Shortcut Manager,Needs-Triage

### Microsoft PowerToys version

0.86.0

### Installation method

Microsoft Store

### Running as admin

Yes

### Area(s) with issue?

Keyboard Manager

### Steps to reproduce

To recreate: hold down Tab in WoW.exe and execute a macro (Alt+1).

This will open the Alt+Tab window, even when disabled in PowerTools and the Registry because Alt+Tab is disabled but not Alt+Tab+1 and a third modifier cannot be added through PowerTools. 

### ✔️ Expected Behavior

I would like the Alt+Tab+Number functionality to cease entirely, at least when I am gaming

### ❌ Actual Behavior

Even when Alt+Tab is disabled through PowerToys and the registry, I still have a problem with Alt+Tab+1, Alt+Tab+2, Alt+Tab+3, etc. opening up the 1st, 2nd, 3rd, windows that would be shown when Alt+Tab is normally pressed.

### Other Software

I use Tab for targeting in gaming as well as the Alt modifier for 48 of my abilities on my Logitech G600. 

Logitech G Hub V 2024.8.641856

WoW.exe Retail V 11.0.5.57689
Repository: rust
Issue: `no method named "fract" found for type "f64" in the current scope` when in `no_std`
Labels: T-libs-api,T-libs,C-discussion

I tried this code:

```rust
#![no_std]

fn get_fract(f: f64) -> f64 {
    f.fract()
}
```

I expected to see this happen: Compiles successfully

Instead, this happened: Fails to compile with `E0599` "no method named `fract` found for type `f64` in the current scope"

### Meta
`rustc --version --verbose`:
```
rustc 1.83.0 (90b35a623 2024-11-26)
binary: rustc
commit-hash: 90b35a6239c3d8bdabc530a6a0816f7ff89a0aaf
commit-date: 2024-11-26
host: x86_64-unknown-linux-gnu
release: 1.83.0
LLVM version: 19.1.1
```
Repository: rust
Issue: compiletest can explode due to cyclic auxiliaries
Labels: E-hard,T-bootstrap,C-bug,A-compiletest

Right now, compiletest does not forbid auxiliaries from declaring each other as auxiliaries, creating a cycle in the auxiliary build graph. This means that, e.g. for aux A requesting aux build of B, aux B can also request aux build of A.

This will eventually kaboom.

I can't find an existing issue for this, tried searching.