sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: yt-dlp
Issue: [docs] Improve downloader documentation
Labels: docs/meta/cleanup,core:downloader

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I'm running yt-dlp version **2023.10.13** ([update instructions](https://github.com/yt-dlp/yt-dlp#update)) or later (specify commit)
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Provide a description that is worded well enough to be understood

Currently external downloader behavior and configuration is poorly documented (See discussion in https://github.com/yt-dlp/yt-dlp/pull/8332). The readme/wiki could be improved to better explain the handling of these downloaders:
- [ ] `aria2c` (@CrendKing)
- [ ] `wget`
- [ ] `ffmpeg`
- [ ] `curl`
- [ ] `httpie`
- [ ] `axel`

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_
Repository: godot
Issue: Switch mode `AtEnd` ,is not transitioning at the end if there is an xfade time
Labels: bug,topic:animation

### Godot version

4.1.2

### System information

Godot v4.1.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 980 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (8 Threads)

### Issue description

When using animation state if the next animation has a long xfade, transition doesn't wait until the end, and starts immediately after first transition ends.

![Transition](https://github.com/godotengine/godot/assets/61533529/4bdf9632-61fb-444e-9f86-6e03ea2d759a)

First two images are how I think animations with `AtEnd` switch mode are working.
Last one how I would expect it to work. With 3 animations, let s say first one's transition is Switch mode is `Immidiate` with some xfade, and second to third transition is `AtEnd` 
Green colored areas are animation without transitions.
Purple colored areas are animation with transitions.
Blue colored areas is the transtion that copies last frame prior animtion and makes blends out of that and new animation.

Last image is how I would expect the transtions to work with `AtEnd` switch mode; Waiting until current animation to end and using it's last frame to blend second animation.


### Steps to reproduce

I think this would be easily reproduceable, as it is how it regularly works. If I'm not mistaken, or there is another bug in my project.

### Minimal reproduction project

You can check my project here, while it is not minimal, it is not that complex either. And has a few stuff that makes cheking this easier, by pressing 5 game stops and by pressing 6 it goes forward one fps, if mouse input is not involved.

I'm currently seing this problem in the transition between THBE_COM-Run_StepA to THBE_COM-Run_StepB , but I think i will be seing it other places too, If I won't, I will update this.

https://github.com/elXill/Belial
Repository: rust
Issue: Tracking Issue for AArch64 TME intrinsics
Labels: T-libs-api,C-tracking-issue,O-AArch64

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_aarch64_tme)]`

This is a tracking issue TME intrinsics on AArch64.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::aarch64

pub const _TMSTART_SUCCESS: u64;
pub const _TMFAILURE_REASON: u64;
pub const _TMFAILURE_RTRY: u64;
pub const _TMFAILURE_CNCL: u64;
pub const _TMFAILURE_MEM: u64;
pub const _TMFAILURE_IMP: u64;
pub const _TMFAILURE_ERR: u64;
pub const _TMFAILURE_SIZE: u64;
pub const _TMFAILURE_NEST: u64;
pub const _TMFAILURE_DBG: u64;
pub const _TMFAILURE_INT: u64;
pub const _TMFAILURE_TRIVIAL: u64;

pub unsafe fn __tstart() -> u64;
pub unsafe fn __tcommit();
pub unsafe fn __tcancel<const IMM16: u64>();
pub unsafe fn __ttest() -> u64;
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: rust
Issue: Tracking Issue for AArch64 prefetch intrinsic
Labels: T-libs-api,C-tracking-issue,O-AArch64

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_aarch64_prefetch)]`

This is a tracking issue for the AArch64 `_prefetch` intrinsic.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::aarch64

pub const _PREFETCH_READ: i32;
pub const _PREFETCH_WRITE: i32;
pub const _PREFETCH_LOCALITY0: i32;
pub const _PREFETCH_LOCALITY1: i32;
pub const _PREFETCH_LOCALITY2: i32;
pub const _PREFETCH_LOCALITY3: i32;

pub unsafe fn _prefetch<const RW: i32, const LOCALITY: i32>(p: *const i8);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: next.js
Issue:  Opened on new page suddenly closing with iOS/iPadOS Safari gesture
Labels: bug,Navigation

### Link to the code that reproduces this issue

https://github.com/ramram1048/safari-new-tab-nextjs-issue-reproduction

### To Reproduce

1.    On iOS/iPadOS Safari, access _ANY_ nextjs app by new tab.
2.    Navigate into some other page, to stack page history
3.    Getting back to first history page, by using browser back button or swipe gesture
4.    **Swipe** to forward and tab is suddenly closed
    (not using forward button)

---

For example)

1. Open https://nextjs.org/ on new tab.
   This can be reproduced by any methods like:
    - Long-press `<a />` element and choose `Open in new tab` 
    - Press `<a target="_blank" />` element
    - Javascript `window.open(/** ... */, "_blank")`
2. Navigate into some other page.
   Saying that we press Get Started button and navigated to https://nextjs.org/docs.
3. Back to first page.
   Now we're on https://nextjs.org/ page and forward history.
4. Forward by swipe gesture, and tab is suddenly closed.

---

I uploaded simple app can test navigation things, but it's not the app specific issue, but all nextjs apps.


### Current vs. Expected behavior

Tab shouldn't closed unexpectedly.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
Binaries:
  Node: 16.17.0
  npm: 8.15.0
  Yarn: 1.22.19
  pnpm: 7.1.0
Relevant Packages:
  next: 13.5.6
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


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

Routing (next/router, next/navigation, next/link)

### Additional context

Confirmed on:
-    iOS Safari 17, 16 / iPadOS Safari 16 (not on macOS Safari.)
-    Next 13 App router
-    Next 12 Pages router
-    `next dev` / `next start`

---

I eventually found this issue on testing my services, and found that ALL other nextjs apps having same behavior.

Other pages, for example https://github.com/ or https://example.com/, are not suffering this issue.
(idk github is using nextjs or not, anyway)

Maybe related reason is, safari creates "close state" history for all new windows (screenshot below), to close the window by swipe back.
This history is removed on navigate to other pages, but not on nextjs router navigation.

![image](https://github.com/vercel/next.js/assets/48747221/ea92dd52-c0d4-4dc2-a0d5-a0791dc18df0)
Repository: rust
Issue: Tracking Issue for ARM hint intrinsics
Labels: O-Arm,T-libs-api,C-tracking-issue,O-AArch64

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_arm_hints)]`

This is a tracking issue for ARM and AArch64 hint intrinsics.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::{arm,aarch64}


pub unsafe fn __wfi();
pub unsafe fn __wfe();
pub unsafe fn __sev();
pub unsafe fn __sevl();
pub unsafe fn __yield();
pub unsafe fn __nop();
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: rust
Issue: Tracking Issue for ARM barrier intrinsics
Labels: O-Arm,T-libs-api,C-tracking-issue,O-AArch64

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(stdarch_arm_barrier)]`

This is a tracking issue for ARM and AArch64 barrier intrinsics.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::arch::{arm,aarch64}

pub unsafe fn __dmb<A>(arg: A);
pub unsafe fn __dsb<A>(arg: A);
pub unsafe fn __isb<A>(arg: A);

pub struct SY;
pub struct ST;
pub struct ISH;
pub struct ISHST;
pub struct NSH;
pub struct NSHST;
pub struct OSH;
pub struct OSHST;
pub struct LD;
pub struct ISHLD;
pub struct NSHLD;
pub struct OSHLD;
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: material-ui
Issue: [icons] Add a Passkey icon
Labels: waiting for 👍,package: icons

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

Hi there, passkeys are a new cross-environment alternative to passwords that's safer and more user-friendly.
There's a recommended icon for passkeys. It has already been added to Material Symbols:
https://fonts.google.com/icons?selected=Material+Symbols+Outlined:passkey:FILL@0;wght@400;GRAD@0;opsz@24&icon.query=passkey

You may consider adding it to the mui icons collections.
Thanks!

### Examples 🌈

_No response_

### Motivation 🔦

Passkey adoption is expected to pick up. 
By having this icon available in mui, you're making it easy for developers to use the same (and recommended) icon. This will help users transfer their learning of the icon's meaning across websites, which is needed considering passkeys are a new technology.
Repository: rust
Issue: Combining LTO + PGO + lib/cdylib crashes on LLVM assertion
Labels: I-crash,A-LLVM,T-compiler,C-bug,A-LTO

When compiling a cargo project with:
- LTO enabled (`LTO=thin/fat`)
- PGO (`-Cprofile-use`)
- Both `lib` and `dylib` targets for its library

Reproducer
```rust
// src/main.rs
use clap::Command;

fn main() {
    Command::new("a").about("a");
}
```

```toml
# Cargo.toml
[package]
name = "hello"
version = "0.1.0"
edition = "2021"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
clap = { version = "4.3.24" , default-features = false, features = ["std"]}

[profile.release]
lto = "thin"

[lib]
crate-type = ["lib", "cdylib"]
```

There also needs to be an empty `src/lib.rs` file. Here is a reproducer script for PGO:
```bash
#!/bin/bash

set -e

VERSION=${1:-1.71}

rustup install ${VERSION}
rustup component add llvm-tools-preview --toolchain ${VERSION}
rm -rf target
rm -rf /tmp/pgo
RUSTFLAGS="-Cprofile-generate=/tmp/pgo" cargo +${VERSION} build --release
./target/release/hello /tmp
`rustc +${VERSION} --print=sysroot`/lib/rustlib/x86_64-unknown-linux-gnu/bin/llvm-profdata merge -o merged-${VERSION}.profdata /tmp/pgo/*
RUSTFLAGS="-Cprofile-use=${PWD}/merged-${VERSION}.profdata" cargo +${VERSION} build --release
```

I expected to see this happen: the project compiles.

Instead, compilation fails with the following error:
```
module flag identifiers must be unique (or of 'require' type)
!"CG Profile"
LLVM ERROR: Broken module found, compilation aborted!
```

This was originally found in https://github.com/rust-lang/rust/issues/115344, which contains many examples of this problem in the wild. Here I sent a minimal example, I wasn't able to minimize it further (removing LTO, PGO, clap or lib/dylib) fixes the problem.

### Meta
`rustc --version --verbose`:
```
rustc 1.73.0 (cc66ad468 2023-10-03)
binary: rustc
commit-hash: cc66ad468955717ab92600c770da8c1601a4ff33
commit-date: 2023-10-03
host: x86_64-unknown-linux-gnu
release: 1.73.0
LLVM version: 17.0.2
```
I managed to reproduce this all the way back to `1.60.0` (although this specific example requires at least `1.70.0` due to `clap`).
Repository: next.js
Issue: Full refresh on uncompiled routes with Safari
Labels: Upstream,bug

### Link to the code that reproduces this issue

https://github.com/juliusn/uncompiled-routes-reproduction

### To Reproduce

1. Open Safari on Mac OS (tested on Safari 16.6).
2. Go to Settings/Search and turn off the "Preload Top Hit in the background" setting to prevent unwanted requests.
3. Run the development server: `npm run dev`
4. Open http://localhost:3000/
5. Change the URL to any of the static routes, for example `http://localhost:3000/static-1`.
6. Hit enter.

### Current vs. Expected behavior

Current behavior: 
Every first attempt to navigate to an uncompiled route fails to load. 

Expected behavior: 
Every request to any valid route should load. 

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:22:05 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6000
Binaries:
  Node: 18.18.0
  npm: 10.1.0
  Yarn: 3.3.1
  pnpm: 7.19.0
Relevant Packages:
  next: 13.5.7-canary.36
  eslint-config-next: N/A
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.1.3
Next.js Config:
  output: N/A
```


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

App Router, Operating System (Windows, MacOS, Linux)

### Additional context

The issue was reproduced with Safari 16.6 on Mac OS 13.5.2. The issue occurs only with the development server. The issue can be replicated by using `<a>` tags for navigation instead of manually altering the URL.