sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Distracting additional information when `u64` is passed to the `.pow()` method of another `u64`
Labels: A-diagnostics,T-compiler,D-papercut,D-verbose

### Code

```Rust
fn test() {
    let x = 2_u64.pow(1 as u64);
}
```

([Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=0bfc9be186ab150c42dead7f5c593bbb))

### Current output

```Shell
error[E0308]: mismatched types
   --> example.rs:2:23
    |
2   |     let x = 2_u64.pow(1 as u64);
    |                   --- ^^^^^^^^ expected `u32`, found `u64`
    |                   |
    |                   arguments to this function are incorrect
    |
note: associated function defined here
   --> /home/username_censored/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:927:5
    |
927 | /     uint_impl! { u64, u64, i64, NonZeroU64, 64, 18446744073709551615, 12, "0xaa00000000006e1", "0x6e10aa",
928 | |     "0x1234567890123456", "0x5634129078563412", "0x6a2c48091e6a2c48",
929 | |     "[0x56, 0x34, 0x12, 0x90, 0x78, 0x56, 0x34, 0x12]",
930 | |     "[0x12, 0x34, 0x56, 0x78, 0x90, 0x12, 0x34, 0x56]",
931 | |     "", "", ""}
    | |_______________^
    = note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info)
help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit
    |
2   |     let x = 2_u64.pow((1 as u64).try_into().unwrap());
    |                       +        +++++++++++++++++++++
```


### Desired output

```Shell
error[E0308]: mismatched types
   --> example.rs:2:23
    |
2   |     let x = 2_u64.pow(1 as u64);
    |                   --- ^^^^^^^^ expected `u32`, found `u64`
    |                   |
    |                   arguments to this function are incorrect
    |
help: you can convert a `u64` to a `u32` and panic if the converted value doesn't fit
    |
2   |     let x = 2_u64.pow((1 as u64).try_into().unwrap());
    |                       +        +++++++++++++++++++++
```


### Rationale and extra context

The part about `uint_impl!` is a bit distracting and doesn't seem helpful in this case.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"11happy"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: HelloGitHub
Issue: 【工具推荐】一个灵活的 Node.js 多功能爬虫库 —— x-crawl
Labels: JavaScript 项目

## 推荐项目

<!-- 这里是 HelloGitHub 月刊推荐项目的入口，欢迎自荐和推荐开源项目，唯一要求：请按照下面的提示介绍项目。-->


<!-- 点击上方 “Preview” 立刻查看提交的内容 -->


<!--仅收录 GitHub 上的开源项目，请填写 GitHub 的项目地址-->
- 项目地址：https://github.com/coder-hxl/x-crawl

<!--请从中选择（C、C#、C++、CSS、Go、Java、JS、Kotlin、Objective-C、PHP、Python、Ruby、Rust、Swift、其它、书籍、机器学习）-->
- 类别：TypeScript

<!--请用 20 个左右的字描述它是做什么的，类似文章标题让人一目了然 -->
- 项目标题：一个灵活的 Node.js 多功能爬虫库 —— x-crawl

<!--这是个什么项目、能用来干什么、有什么特点或解决了什么痛点，适用于什么场景、能够让初学者学到什么。长度 32-256 字符-->
- 项目描述：x-crawl 是一个灵活的 Node.js 多功能爬虫库。灵活的使用方式和众多的功能可以帮助您快速、安全、稳定地爬取页面、接口以及文件。

<!--令人眼前一亮的点是什么？类比同类型项目有什么特点！-->
- 亮点：
  - **🔥 异步同步** - 只需更改一下 mode 属性即可切换异步或同步爬取模式。
  - **⚙️ 多种用途** - 支持爬动态页面、静态页面、接口数据、文件以及轮询操作。
  - **⚒️ 控制页面** - 爬取动态页面支持自动化操作、键盘输入、事件操作等。
  - **🖋️ 写法灵活** - 同种爬取 API 适配多种配置，每种配置方式都非常独特。
  - **⏱️ 间隔爬取** - 无间隔、固定间隔以及随机间隔，产生或避免高并发爬取。
  - **🔄 失败重试** - 避免因短暂的问题而造成爬取失败，自定义重试次数。
  - **➡️ 轮换代理** - 配合失败重试，自定义错误次数以及 HTTP 状态码自动轮换代理。
  - **👀 设备指纹** - 零配置或自定义配置，避免指纹识别从不同位置识别并跟踪我们。
  - **🚀 优先队列** - 根据单个爬取目标的优先级可以优先于其他目标提前爬取。
  - **🧾 爬取记录** - 对爬取进行记录，并在终端使用彩色字符串提醒。
  - **🦾 TypeScript** - 拥有类型，通过泛型实现完整的类型。

- 示例代码：

以每天自动获取世界各地的经历和房间的一些照片为例：

```js
// 1.导入模块 ES/CJS
import xCrawl from 'x-crawl'

// 2.创建一个爬虫实例
const myXCrawl = xCrawl({ maxRetry: 3, intervalTime: { max: 2000, min: 1000 } })

// 3.设置爬取任务
// 调用 startPolling API 开始轮询功能，每隔一天会调用回调函数
myXCrawl.startPolling({ d: 1 }, async (count, stopPolling) => {
  // 调用 crawlPage API 来爬取页面
  const pageResults = await myXCrawl.crawlPage({
    targets: [
      'https://www.airbnb.cn/s/*/experiences',
      'https://www.airbnb.cn/s/plus_homes'
    ],
    viewport: { width: 1920, height: 1080 }
  })

  // 通过遍历爬取页面结果获取图片 URL
  const imgUrls = []
  for (const item of pageResults) {
    const { id } = item
    const { page } = item.data
    const elSelector = id === 1 ? '.i9cqrtb' : '.c4mnd7m'

    // 等待页面元素出现
    await page.waitForSelector(elSelector)

    // 获取页面图片的 URL
    const urls = await page.$$eval(`${elSelector} picture img`, (imgEls) =>
      imgEls.map((item) => item.src)
    )
    imgUrls.push(...urls.slice(0, 6))

    // 关闭页面
    page.close()
  }

  // 调用 crawlFile API 爬取图片
  await myXCrawl.crawlFile({ targets: imgUrls, storeDirs: './upload' })
})
```


运行效果:

<div align="center">
  <img src="https://raw.githubusercontent.com/coder-hxl/x-crawl/main/assets/run-example.gif" />
</div>

**注意:** 请勿随意爬取，爬取前可查看 **robots.txt** 协议。网站的类名可能会有变更，这里只是为了演示如何使用 x-crawl 。

## 更多

更多内容可查看：https://github.com/coder-hxl/x-crawl
Repository: create-react-app
Issue: Can't resolve 'web-vitals' in react-Project/src
Labels: needs triage,issue: bug report



### i just get started with react and as soon as i create new react app using create-react-app tool it gives an error without any modification of the project code
Repository: rust
Issue: error[[E0401]] and errors with constants
Labels: A-trait-system,T-lang,T-compiler

So I was trying to use the `static_assertions` crate when I ran into a weird compiler error. I kept simplifying down until I got this:

```rust
struct X {}
impl X{
    const CHECK: bool = false;
    fn new()->Self {
        const _: bool = Self::CHECK;
        Self {}
     }
}
```

This provided the error:

```
error[[E0401]](https://doc.rust-lang.org/stable/error_codes/E0401.html): can't use generic parameters from outer function
 --> src/lib.rs:5:26
  |
2 | impl X{
  | ---- `Self` type implicitly declared here, by this `impl`
...
5 |         const _: bool = Self::CHECK;
  |                         ^^^^^^^^^^^
  |                         |
  |                         use of generic parameter from outer function
  |                         use a type here instead
  ```

This error is fairly bizarre, as it seems to imply that you can't use a `const` value inside a different scope? Obviously that's not true, as you can replace that line with a standard `assert!(Self::CHECK);`. However, as addressed in [this post](https://github.com/rust-lang/rust/issues/108850#issue-1613000506) there's an entirely separate bug involving that. Regardless, it seems that you can't use an `impl`-scoped `const` to define a `fn`-scoped `const`. 

All of this started because I wanted to produce a compile-time error when a const generic parameter was outside a given range, but as far as I can tell there's currently no way to do this short of writing a custom procedural macro.

### Meta
This applies to both the stable and nightly versions of `rustc`.
Repository: tensorflow
Issue: Please bring back native Windows CUDA support!
Labels: type:build/install,stale,subtype:windows,TF 2.11

<details><summary>Click to expand!</summary> 
 
 ### Issue Type

Others

### Have you reproduced the bug with TF nightly?

Yes

### Source

binary

### Tensorflow Version

2.11

### Custom Code

Yes

### OS Platform and Distribution

Windows 10

### Mobile device

_No response_

### Python version

3.9

### Bazel version

_No response_

### GCC/Compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current Behaviour?

I am very disappointed and sad that native Windows CUDA support was simply dropped. 

The replacement with WSL2 is not sufficient for processes and systems that are not able to use WSL2 because, for example, if they are also Windows-native applications and the port is too expensive. So we can only use version 2.10 (of both the Python and C APIs) and are stuck with it, which is a shame because it prevents us from benefiting from and participating in new developments. We also see a performance loss of about 5% in WSL2, which leads to higher power consumption and thus has a direct impact on our climate, which can make a big difference in our already very compute-intensive business. In addition, the Windows Direct-ML-Plugin interface is not sufficient, since the performance does not yet reach CUDA and optimizations like XLA and others are not supported. Also, you lose all your highly optimized and expensively developed TF CUDA Custom Ops.

It is also clear that the native CUDA feature on Windows is much needed, see here in the following issues other people are looking for exactly the native CUDA feature on Windows:

-  #https://github.com/tensorflow/tensorflow/issues/58629
-  #https://github.com/tensorflow/tensorflow/issues/58933
-  #https://github.com/tensorflow/tensorflow/issues/59905
-  #https://github.com/tensorflow/tensorflow/issues/59119
-  #https://github.com/tensorflow/tensorflow/issues/59016
-  #https://github.com/tensorflow/tensorflow/issues/58985
-  #https://github.com/tensorflow/tensorflow/issues/58729

**All this leads to the simple exclusion and virtual discrimination of a large part of the Tensorflow community that uses CUDA Windows natively.**

Why has support been dropped? You could at least keep support for CUDA Windows Native in custom builds.
I hope and ask that you bring back Windows native CUDA support and let people decide for themselves if they want to use native CUDA or WSL2.

Thank you for the development of Tensorflow! My favourite DL framework! :)


### Standalone code to reproduce the issue

```shell
import tensorflow as tf
print("Num GPUs Available: ", len(tf.config.list_physical_devices('GPU')))
```


### Relevant log output

_No response_</details>
Repository: pytorch
Issue: `ld: error: unknown argument '-force_load'` when linking libtorch on Android
Labels: module: build,oncall: mobile

### 🐛 Describe the bug

What I did:
1. Built PyTorch 1.13.1 from source by running `scripts/build_android.sh -DUSE_LITE_INTERPRETER_PROFILER=OFF` for arm64-v8a (it builds as static libraries this way).
2. Linked against the resulting installation in CMake roughly like so:
```cmake
find_package(Torch REQUIRED PATHS "${torch_SOURCE_DIR}/share/cmake/Torch")
target_link_libraries(my_lib PRIVATE ${TORCH_LIBRARIES})
target_include_directories(my_lib PRIVATE ${TORCH_INCLUDE_DIRS})
```
3. Tried to build my Android app that uses `my_lib` though JNI.

During the build I got `ld: error: unknown argument '-force_load'` -- this flag is set [here](https://github.com/pytorch/pytorch/blob/12ab4f08b77e1f2685ff15e7cd2a07d15ed80a43/cmake/TorchConfig.cmake.in#L32) in `TorchConfig.cmake`.

Full error message:
```
FAILED: <project dir>/build/intermediates/cxx/Debug/4m2x1c2x/obj/arm64-v8a/libmy_lib.so 
cmd.exe /C "cd . && C:\Users\<my username>\AppData\Local\Android\Sdk\ndk\23.1.7779620\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=aarch64-none-linux-android21 --sysroot=C:/Users/<my username>/AppData/Local/Android/Sdk/ndk/23.1.7779620/toolchains/llvm/prebuilt/windows-x86_64/sysroot -fPIC -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fexceptions -frtti -stdlib=libc++ -g  -fno-limit-debug-info  -Wl,--build-id=sha1 -Wl,--no-rosegment -Wl,--fatal-warnings -Qunused-arguments -Wl,--no-undefined -shared -Wl,-soname,libmy_lib.so -o <other .o and .a/.so files>  -pthread  -ldl  -Wl,-force_load <project dir>/.cxx/Debug/4m2x1c2x/arm64-v8a/_deps/torch-src/lib/libtorch.a  -Wl,-force_load <project dir>/.cxx/Debug/4m2x1c2x/arm64-v8a/_deps/torch-src/lib/libtorch_cpu.a  _deps/torch-src/lib/libc10.a  _deps/torch-src/lib/libnnpack.a  _deps/torch-src/lib/libpytorch_qnnpack.a  _deps/torch-src/lib/libXNNPACK.a  _deps/torch-src/lib/libcpuinfo.a  _deps/torch-src/lib/libclog.a  _deps/torch-src/lib/libpthreadpool.a -static-libstdc++ -latomic -lm && cd ."
ld: error: unknown argument '-force_load'
ld: error: unknown argument '-force_load'
clang++: error: linker command failed with exit code 1 (use -v to see invocation)
ninja: build stopped: subcommand failed.
```

### Versions

- Windows 11 x64
- Android NDK 23.1.7779620 (also tried 25.2.9519653)
- CMake 3.22.1
- PyTorch built from sources, `v1.13.1` git tag as described above

cc @malfet @seemethere
Repository: node
Issue: Missing import trace from error stack when loading a module throws an error
Labels: feature request,esm

### Version

v16.16.0

### Platform

Linux 5.4.0-139-generic #<!-- -->156-Ubuntu SM x86_64 GNU/Linux

### Subsystem

modules

### What steps will reproduce the bug?

Consider:

```js
// foo.mjs
import './bar.mjs';
```

```js
// bar.mjs
throw new Error('bar failed');
```

Run `node foo.mjs`.

### How often does it reproduce? Is there a required condition?

Always.

### What is the expected behavior?

The stack trace from the error should include a reference to `foo.mjs` line 1 showing where bar was imported from.

### What do you see instead?

```console
file:///.../bar.mjs:1
throw new Error('bar failed');
      ^

Error: bar failed
    at file:///.../bar.mjs:1:7
    at ModuleJob.run (node:internal/modules/esm/module_job:198:25)
    at async Promise.all (index 0)
    at async ESMLoader.import (node:internal/modules/esm/loader:385:24)
    at async loadESM (node:internal/process/esm_loader:88:5)
    at async handleMainPromise (node:internal/modules/run_main:61:12)
```

Note that the stack trace does not mention `foo` anywhere. This is not helpful, especially if the error is specifically about how and when `bar` is imported. For example, it might be a singleton and you're mistakenly creating a duplicate by loading it from both `import` and `require`, or it might need something else to be set up on the global first and you're loading it in the wrong order.

The above stack is from node 16. Node 18 produces a shorter but similarly lacking stack:

```console
file:///.../bar.mjs:1
throw new Error('bar failed');
      ^

Error: bar failed
    at file:///.../bar.mjs:1:7
    at ModuleJob.run (node:internal/modules/esm/module_job:194:25)
```

### Additional information

I am aware that `import()` and top-level await complicates this, since modules may be effectively loading in parallel (asynchronously behind the scenes). However, it is **absolutely essential** that this information is made available somehow.

If the output ends up being a list of all modules trying to load the offending module then great, as long as this list is in the order the imports were encountered then that should allow debugging this kind of thing.

At the moment when this occurs it's simply impossible to debug. Since `import` gets hoisted by the language you can't even add `console.log` statements around the place to trace what's happening like you can with `require`. Literally the only option to debug this is to comment out all the imports and re-enable one-by-one (recursively) until you locate the problem. And in practice this inevitably breaks something else, so it's completely unworkable.
Repository: storybook
Issue: [Bug]: Module not found: Can't resolve '@testing-library/dom'
Labels: bug,has workaround,addon: interactions

### Describe the bug

Module not found: Can't resolve '@testing-library/dom' in '/home/<username>/projects/oss/storybook-react-design-system/node_modules/@testing-library/user-event/dist'
node_modules/@testing-library/user-event/dist/click.js


### To Reproduce

1. Created a React app using `create-react-app`
2. Run `npx storybook init` like in the [Guides](https://storybook.js.org/docs/react/get-started/install).
3. Run `npm run storybook`, then I got the error logs

### System

```shell
Environment Info:

  System:
    OS: Linux 5.15 Ubuntu 22.04.1 LTS 22.04.1 LTS (Jammy Jellyfish)
    CPU: (16) x64 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz
  Binaries:
    Node: 18.14.2 - ~/.nvm/versions/node/v18.14.2/bin/node
    Yarn: 1.22.19 - ~/.nvm/versions/node/v18.14.2/bin/yarn
    npm: 9.5.0 - ~/.nvm/versions/node/v18.14.2/bin/npm
  npmPackages:
    @storybook/addon-actions: ^6.5.16 => 6.5.16 
    @storybook/addon-essentials: ^6.5.16 => 6.5.16 
    @storybook/addon-interactions: ^6.5.16 => 6.5.16 
    @storybook/addon-links: ^6.5.16 => 6.5.16 
    @storybook/builder-webpack5: ^6.5.16 => 6.5.16 
    @storybook/manager-webpack5: ^6.5.16 => 6.5.16 
    @storybook/node-logger: ^6.5.16 => 6.5.16 
    @storybook/preset-create-react-app: ^4.1.2 => 4.1.2 
    @storybook/react: ^6.5.16 => 6.5.16 
    @storybook/testing-library: ^0.0.13 => 0.0.13 
```


### Additional context

Not really it's quite simple.

However it's no problem once you install `@testing-library/dom`.
Repository: vscode
Issue: Git - Problem with Placeholder in settings.json using git.path
Labels: bug,git

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No YES

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version:  1.75.1
- OS Version: Windows 10.0.19044 x64

Steps to Reproduce:

1. Install GIT to default Location "C:\Program Files\Git\"
2. Extract another newer portable GIT Version to "C:\temp\portablegit"
3. Extract VSCode as Portable Version to "c:\temp\VSCode-win32-x64" (Create data-Folder unter VSCode installation)
4. Create start-up command (see attached files: VSCodeStart.cmd.txt")
5. Config settings.json maually outside from VSCode. Set git.path (see attached files: setting.json.txt)
6. Start VSCode with start-up command
7. Open Git.log output (see attached files: git-failed.log)

VSCode use the default GIT Installation, not the defined in settings.json, why?

This only happens when I use placeholder in the settings.json. When I remove GIT from "C:\Program Files\Git\" then it also work fine with the placeholder. (see attached files: git-fine.log)

I believe the sequence to search for GIT is wrong. When I correctly interpred the log. VSCode search first with the string of the placeholder (not the value of them), then with some default pahts, (wherever these are defined), and at last with the current value of the placeholder.

[git-failed.log](https://github.com/microsoft/vscode/files/10908480/git-failed.log)
[git-fine.log](https://github.com/microsoft/vscode/files/10908481/git-fine.log)
[VSCodeStart.cmd.txt](https://github.com/microsoft/vscode/files/10908488/VSCodeStart.cmd.txt)
[settings.json.txt](https://github.com/microsoft/vscode/files/10908495/settings.json.txt)
Repository: rust
Issue: rustc will emit code for const-eval false branches
Labels: A-codegen,T-compiler,C-bug,A-const-prop

I tried this code:

```rust
#![feature(inline_const)]

use std::mem;

const fn is_elegible<T>() -> bool {
    mem::size_of::<T>() <= mem::size_of::<[u64; 4]>()
}

fn logic_a<T>(_v: &mut [T]) {
    println!("{}", std::any::type_name::<T>());
}

fn logic_b<T>(v: &mut [T]) {
    use std::sync::atomic::{AtomicBool, Ordering};

    static VAL: AtomicBool = AtomicBool::new(false);

    if v.len() > 2 {
        VAL.store(true, Ordering::Release);
    }
}

fn do_some_logic<T>(v: &mut [T]) {
    if const { is_elegible::<T>() } {
        logic_a(v);
    } else {
        logic_b(v);
    }
}

pub fn main() {
    do_some_logic(&mut [3, 5, 6]);

    // struct BigThing([u64; 20]);
    // do_some_logic(&mut [BigThing([0; 20])]);
}
```

I expected to see this happen:

Looking at the LLVM-IR and generated code, it generates code for `logic_b` despite `const { is_elegible::<T>() }` evaluating to `true`, which means only `logic_a` should be passed to the code-gen backend.

Instead, this happened:

Before LLVM-IR or any other backend IR is generated if an expression is forced to be evaluated inline via an inline cost block, it must be evaluated and pruned.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.69.0-nightly (5243ea5c2 2023-02-20)
binary: rustc
commit-hash: 5243ea5c29b136137c36bd773e5baa663790e097
commit-date: 2023-02-20
host: x86_64-unknown-linux-gnu
release: 1.69.0-nightly
LLVM version: 15.0.7
```

This has been discussed before, and I was told the expected behavior is the current behavior https://internals.rust-lang.org/t/why-does-a-const-eval-not-taken-branch-still-generate-llvm-ir/18378/15 and it is for some cases but not reliably.

### Motivation

When building large complex abstractions such as sort implementations it can be valuable to limit certain code to specific types. There are other places in the standard library that also do such heuristics eg. https://github.com/rust-lang/rust/blob/e58621a4a30db1ae7fcc041e108042c1ce14d3bd/library/core/src/slice/rotate.rs#L74
The conversation seemed to show no consensus whether `if const_fn()` should be const evaluated, but it using `if const { const_fn() }` seems to imply that we can rely on the condition being const evaluated. Without such a construct certain optimizations can't be done without sacrificing compile times, which is problematic eg. https://github.com/rust-lang/rust/pull/108662

What I'd like to se would be consistent behavior or a new abstraction that provides that behavior if inline const expressions are deemed to be the wrong tool.
Repository: godot
Issue: Performance greatly decreases if characters are animated in 4.0 and later
Labels: discussion,topic:rendering,topic:2d,performance

### Godot version

4.0

### System information

Windows 10, i7, nvidia 840m 8gb, forward+, mobile and compatibility

### Issue description

Since I was interested to shift to 4.0 from 3.5.1 I made a test scene to test 4.0 performances and well the results were bad.
My characters are made of multiple poligons with puppet-like animations, now if an enemy is not animated I can populate the test scene with more than 500 enemies, if it's animated only 31.

EDIT:
in comparison in 3.5.1 a mostly complete test level with environment, functioning player, various functioning enemies with ai, attack, physics etc can handle more than 60 enemies on screen.


### Steps to reproduce

-If you want to start from zero:
Make a character made of multiple sprites or polygons, animate it and make a test scene that adds as many copies of characters until the fps go lower than 60fps, try one time with the character animated and another time with the character not animated and you will see a big difference in performance(or at least it's what happens to me).

-if you want to start from my minimal project:
there are only 2 scenes, test and enemy_pol, enemy_pol has only the "walk" animation in the AnimationPlayer, check or uncheck the autoplay button depending if you want test enemy_pol animated or not and then run the main scene(test).
In the bottom left corner of the test scene you will see how many enemies are on screen and the fps. 

PS:
Don't judge the blank character, i wasn't ready to share the still unfinished version lol!

### Minimal reproduction project

[issue.zip](https://github.com/godotengine/godot/files/10908837/issue.zip)