sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [Proposal] AppBar `leadingWidth` should be available in `AppBarTheme`
Labels: c: new feature,framework,f: material design,waiting for PR to land (fixed),c: proposal,P3,team-design,triaged-design

### Use case

In `AppBarTheme` I can provide the `toolbarHeight`.
But since app bar leading width uses the constant `kToolbarHeight` by default it is no longer a square because toolbar height is changed in the theme.


On Design Device (toolbar height `56`):
<img width="402" alt="Screenshot 2025-01-08 at 14 21 40" src="https://github.com/user-attachments/assets/a197ffd0-fe52-411e-a383-6ffe305f3143" />

On iPad 13inch (toolbar height scaled to `90` based on custom logic):
<img width="632" alt="Screenshot 2025-01-08 at 14 21 30" src="https://github.com/user-attachments/assets/ab13fdda-9fc9-4e51-b1be-ce7ce2fcf40b" />


### Proposal

1. Either `leadingWidth` should use toolbar height from theme internally
2. Or I should be able to provide `leadingWidth` in `AppBarTheme` along with `toolbarHeight`
Repository: kubernetes
Issue: Report event or record error/info log when drop podUpdates message
Labels: sig/node,kind/feature,needs-triage

### What would you like to be added?

In  func (p *podWorkers) UpdatePod(options UpdatePodOptions) (pod_worker.go): 
	select {
	case podUpdates <- struct{}{}:
	default:
	}
podUpdates buffer is 1, if the previous update message not finish, the new message will drop without any warning.
User cannot get any idea about this. Event or error/info log should added for debugging.

### Why is this needed?

The update pod message drop without any warning.
It is better to add some debug log.
Repository: svelte
Issue: Untrack documentation is difficult to understand
Labels: documentation

### Describe the problem

The documentation for `untrack` showcases usage of a function `save` which does not exist, so its hard to understand how or what it showcases in my opinion

https://svelte.dev/docs/svelte/svelte#untrack

### Describe the proposed solution

Write a bit more thorough explanation of what it does

### Importance

would make my life easier
Repository: rust
Issue: Performance regression on toy problem, but not for opt-level=1.
Labels: A-LLVM,I-slow,P-low,T-compiler,regression-untriaged,C-optimization

<!--
Thank you for filing a regression report! 🐛 A regression is something that changed between versions of Rust but was not supposed to.

Please provide a short summary of the regression, along with any information you feel is relevant to replicate it.
-->
I tried this code:

```rust
fn hanoi_int_inner(n : usize, start: usize, end : usize, aux : usize) -> usize {
    if n == 0 {
        0
    } else {
        let mut out = hanoi_int_inner(n-1, start, aux, end);
        out += 1;
        out += hanoi_int_inner(n-1, aux, end, start);
        out
    }
}

fn hanoi_int(n: usize) -> usize {
    hanoi_int_inner(n,0,1,2)
} 
```

I expected compiling with `rustc -C opt-level=3` to be faster than `rustc -C opt-level=1`. I have not seen any resources online giving a recommendation for `opt-level=1` or any downside to more optimization other than binary size. 

However, only with `opt-level=1` does rustc figure out that `start`, `end`, and `aux` are useless and combine the two recursive calls. Combining the two recursive calls results in linear time complexity vs exponential so it is immediately noticeable even without any tight timing (> minutes vs milliseconds).

Previous versions correctly compile this toy code into non-exponential machine code. It seems to have broken around 1.70 and is currently broken on both stable and nightly.

I am totally willing to investigate this, but I would need some guidance because I have never looked deeply into LLVM's or Rust's optimization passes.


### Version it worked on

<!--
Provide the most recent version this worked on, for example:

It most recently worked on: Rust 1.47
-->

It most recently worked on `rustc --version --verbose`:

```
rustc 1.69.0 (84c898d65 2023-04-16)
binary: rustc
commit-hash: 84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc
commit-date: 2023-04-16
host: x86_64-unknown-linux-gnu
release: 1.69.0
LLVM version: 15.0.7
```

### Version with regression

`rustc --version --verbose`:
```
rustc 1.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-unknown-linux-gnu
release: 1.70.0
LLVM version: 16.0.2

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

rustc 1.86.0-nightly (ad211ced8 2025-01-07)
binary: rustc
commit-hash: ad211ced81509462cdfe4c29ed10f97279a0acae
commit-date: 2025-01-07
host: x86_64-unknown-linux-gnu
release: 1.86.0-nightly
LLVM version: 19.1.6
```

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-{channel} -regression-untriaged
-->
Repository: rust
Issue: Tracking Issue for nonnull_provenance
Labels: T-libs-api,C-tracking-issue

<!--
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(nonnull_provenance)]`

This is a tracking issue for some provenance functions on NonNull that were missed in the initial strict provenance stabilization.

<!--
Include a short description of the feature.
-->

### Public API



```rust
// core::ptr

impl<T> NonNull<T> {
    pub const fn without_provenance(addr: NonZero<usize>) -> Self;
    pub fn from_exposed_provenance(addr: NonZero<usize>) -> Self;
}
impl<T: ?Sized> NonNull<T> {
    pub fn expose_provenance(self) -> NonZero<usize>;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] ACP: https://github.com/rust-lang/libs-team/issues/518
- [ ] Implementation: https://github.com/rust-lang/rust/pull/135242
- [ ] 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: ant-design
Issue: Space.Compact 紧凑布局问题
Labels: 🐛 Bug,help wanted

### Reproduction link

[https://codepen.io/sjzcxc/pen/KwPQwNp?editors=0010](https://codepen.io/sjzcxc/pen/KwPQwNp?editors=0010)

### Steps to reproduce

1、使用Space.Compact 紧凑布局，前部分是 Select，后部分是 TextArea，会导致圆角样式和高度都不对齐。
2、经过初步排查，TextArea 只要添加了 allowClear 属性，高度就会对不齐。



### What is expected?

期望圆角样式和高度能够对齐

### What is actually happening?

实际对不齐

| Environment | Info |
| --- | --- |
| antd | 5.23.0 |
| React | 18 |
| System | Mac |
| Browser | Chrome最新 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: rust
Issue: `x86_64-unknown-linux-musl` with `-Ctarget-feature=-crt-static` links to glibc
Labels: A-linkage,O-linux,T-compiler,O-musl,C-bug,A-target-feature

tested with rustc stable 1.83.0, on Arch Linux (kernel 6.6.69 LTS)

```
rustup install stable-x86_64-unknown-linux-gnu
rustup target add x86_64-unknown-linux-musl
cargo new musl-hm
cd musl-hm
cargo rustc --target x86_64-unknown-linux-musl -- -Ctarget-feature=-crt-static
ldd target/x86_64-unknown-linux-musl/debug/musl-hm
        linux-vdso.so.1 (0x00007ffc176a7000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x0000755e74d12000)
        libc.so.6 => /usr/lib/libc.so.6 (0x0000755e74b21000)
        /lib64/ld-linux-x86-64.so.2 => /usr/lib64/ld-linux-x86-64.so.2 (0x0000755e74dc4000)
```

The same thing happens with `cargo build` and `RUSTFLAGS` instead of `cargo rustc`.
This happens irrespective of whether a the musl system package is installed or not.

If you set `target.x86_64-unknown-linux-musl.linker = "musl-gcc"` then linking fails with `-Ctarget-feature=-crt-static` (complains about missing `libgcc_s`), and without `-Ctarget-feature`, the resulting binary crashes instantly (that's a duplicate of https://github.com/rust-lang/rust/issues/95926), but is dynamically linked to the musl library and loader.

I think rustc should error out on musl targets if attempting to disable `crt-static`, since anything else produces wrong or broken binaries. If the idea is that `-crt-static` works on targets where musl is the system libc (e.g. Alpine), then perhaps there should be something that detects whether the system libc is musl, and errors (or ignores `crt-static`) if not.
Repository: react-native
Issue: flexWrap wrapping unexpectedly with alignItems: 'flex-end'
Labels: Issue: Author Provided Repro,Newer Patch Available

### Description

This bug/issue seems to be **screen size dependent**. In the provided example with the used text the incorrect wrapping is visible on the Pixel 7 screen. The same issue is also on ios, but there I did not test which text + device causes the too early overflow. When the text is changed (shortened or lengthened) the overflow disappears until the correct overflow occurs. Maybe this has something to do with the way the Views are nested, but I still don't understand how this is expected behaviour.

**Pixel 7** the text wraps, but it should not yet and the backgroundColor is also only displayed on the top Text.

<img width="300" alt="Bildschirmfoto 2025-01-08 um 11 27 57" src="https://github.com/user-attachments/assets/0fd92712-1f5f-4020-b6e0-5d5eb9b994a8" />


**Pixel 4** the same text does not wrap:

<img width="308" alt="Bildschirmfoto 2025-01-08 um 11 26 01" src="https://github.com/user-attachments/assets/1d86d353-9094-4934-ad27-9be134062c6c" />


### Steps to reproduce

1. Locally run the code provided in the expo snack using a pixel 7 simulator or test it directly in expo snack

### React Native Version

0.76.1

### Affected Platforms

Runtime - Android

### Output of `npx react-native info`

```text
System:
  OS: macOS 14.6
  CPU: (16) x64 Intel(R) Core(TM) i9-9980HK CPU @ 2.40GHz
  Memory: 10.96 GB / 64.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 23.3.0
    path: /usr/local/bin/node
  Yarn: Not Found
  npm:
    version: 10.9.0
    path: /usr/local/bin/npm
  Watchman:
    version: 2024.12.02.00
    path: /usr/local/bin/watchman
Managers:
  CocoaPods:
    version: 1.15.2
    path: /usr/local/bin/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.2
      - iOS 18.2
      - macOS 15.2
      - tvOS 18.2
      - visionOS 2.2
      - watchOS 11.2
  Android SDK: Not Found
IDEs:
  Android Studio: 2024.1 AI-241.18034.62.2412.12266719
  Xcode:
    version: 16.2/16C5032a
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.13
    path: /usr/bin/javac
  Ruby:
    version: 3.3.5
    path: /usr/local/opt/ruby/bin/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 15.0.0
    wanted: 15.0.0
  react:
    installed: 18.3.1
    wanted: 18.3.1
  react-native:
    installed: 0.76.1
    wanted: ^0.76.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true
```


### Stacktrace or Logs

```text
No crash/failure occurs
```


### Reproducer

https://snack.expo.dev/@alex_p8/gnarly-orange-ramen

### Screenshots and Videos

<img width="300" alt="Bildschirmfoto 2025-01-08 um 11 27 57" src="https://github.com/user-attachments/assets/7270a417-c206-48ee-8a0e-48e8783a9513" />
Repository: rust
Issue: Item-bounds can be used to non-productively prove themselves
Labels: P-medium,A-associated-items,I-unsound,S-blocked,T-types

This issue has been discovered by @steffahn in https://github.com/rust-lang/rust/issues/135011#issuecomment-2574201519

> ```rust
> // We only check that GAT where-clauses of the *trait* while normalizing;
> // normalizing `<T as Trait<U>>::Proof` to `U` trivially succeeds.
> trait Trait<R>: Sized {
>     type Proof: Trait<R, Proof = Self>;
> }
> impl<L, R> Trait<R> for L {
>     // We prove that the impl item is compatible with the trait in the
>     // env of the trait, which is pretty much empty.
>     //
>     // `L: Trait<R>` is trivial
>     // `R: Trait<R, Proof = <L::Proof as Trait<R>>::Proof>` normalizes to
>     // `R: Trait<R, Proof = <R as Trait<R>>::Proof>` normalizes to
>     // `R: Trait<R, Proof = R>` is trivial
>     //
>     // Proving the item-bound holds assumes the *impl where-bounds*.
>     // For this we normalize the where-bound `R: Trait<R, Proof = <L::Proof as Trait<R>>::Proof>`
>     // by using the item-bound of `L::Proof`: `R: Trait<R, Proof = L>` 💀¹. Proving the
>     // item-bound of `<L as Trait<R>>::Proof` is now trivial.
>     type Proof
>         = R
>     where
>         L: Trait<R>,
>         R: Trait<R, Proof = <L::Proof as Trait<R>>::Proof>;
> }
> fn transmute<L: Trait<R>, R>(r: L) -> <L::Proof as Trait<R>>::Proof { r }
> fn main() {
>     let s: String = transmute::<_, String>(vec![65_u8, 66, 67]);
>     println!("{}", s); // ABC
> }
> ```
> What's happening at ¹ is that proving that the item-bounds of an associated type is able
> to assume the item-bounds of exactly that associated type. This is non-productive cyclic reasoning.
> 
> You've found a new way to exploit https://github.com/rust-lang/trait-system-refactor-initiative/issues/62, answering the question posed in https://github.com/rust-lang/trait-system-refactor-initiative/issues/116 😊 

 _Originally posted by @lcnr in [#135011](https://github.com/rust-lang/rust/issues/135011#issuecomment-2574766479)_
Repository: storybook
Issue: [Documentation]: Debugging in VSCode
Labels: documentation

### Describe the problem

Need to explain how to set `launch.json` to make vscode breakpoints work with storybook. 

### Additional context

https://github.com/storybookjs/storybook/issues/1754
https://github.com/storybookjs/storybook/discussions/26153
Repository: excalidraw
Issue: radix popup overflowing viewport issues
Labels: UX/UI

- arrowhead picker

  ![Image](https://github.com/user-attachments/assets/ab4e9358-da73-460a-9d2c-73a4cf8b0ede)

- color and font pickers should have max height so it's scrollable when they don't fit
  
  ![Image](https://github.com/user-attachments/assets/8a0df6a2-7cc5-481d-a1a9-76c6ab815f66)
Repository: vscode
Issue: Flag invalid engine version in package.json schema of extensions
Labels: feature-request,extensions

Right now extensions can put

```
"engines": {
    "vscode": "*"
  }
```

This is invalid per our docs https://code.visualstudio.com/api/references/extension-manifest

Can we flag this as a lint warning / error via JSON schema?
Repository: PowerToys
Issue: Guides on screen
Labels: Needs-Triage

### Description of the new feature / enhancement

One of the best and most useful features for developers and designers could be adding screen guides to help them build layouts without third-party tools.

Some useful actions: 

- create it vertically and horizontally, 
- lock it
- change the colours
- move it manually and with the keyboard

### Scenario when this would be used?

Build layout and measure directly in the browser
help manage spacing between contents
align contents visually

### Supporting information

https://xscopeapp.com/guide#guides
Repository: ant-design
Issue: Email validator allows hypens to be at the first and the last position in domain part
Labels: unconfirmed

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/p/sandbox/antd-reproduction-template-forked-w2ntkh)

### Steps to reproduce

1. Create a `Form` component with `Form.Item` having rules type email in it
2. Enter email with hyphens at the first and/or the last position of a domain part
3. Try to submit the form

### What is expected?

Validation isn't passed. `onFinish` is not triggered. `onFinishFailed` is triggered instead

### What is actually happening?

Validation is passed successfully. Form `onFinish` is triggered.

| Environment | Info |
| --- | --- |
| antd | 5.20.2 |
| React | 18.3.1 |
| System | MacOS |
| Browser | **Arc Version** 1.74.0 (57065); **Chromium Engine Version** 131.0.6778.205 |

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: Python
Issue: Error regarding imports in replit
Labels: awaiting triage

### What would you like to share?

My code in replit is throwing an error regarding the import itertools function. The error is that it is showing is that the import is unsorted or unformatted. What should I do?

### Additional information

_No response_
Repository: godot
Issue: Classes that inherit `PackedScene` do not store UIDs when serialized and do not have their script when reloaded
Labels: bug,topic:core,confirmed

### Tested versions

v4.4.dev7.official [46c8f8c5c]
master [d2ada64a03d2abdb97cafe8f10623db8a2ce1d4c]

### System information

Godot v4.4.dev7 - Fedora Linux 41 (KDE Plasma) on Wayland - X11 display driver, Multi-window, 1 monitor - Vulkan (Forward+) - integrated Intel(R) UHD Graphics 620 (KBL GT2) - Intel(R) Core(TM) i5-8250U CPU @ 1.60GHz (8 threads)

### Issue description

Scripts can inherit `PackedScene`, which I think is great for customizability!

However, due to how `PackedScene`s are saved, this means there is no script attached to the file when reloaded. Unlike other resources, which have a `[resource]` section where their `script` property is set, this does not have one, understandably. For some reason, it still references its script as an `ext_resource` even though it is never referenced in the file, and there are no UIDs referenced anywhere.

I'm not sure what the best way to fix this would be, but I think a warning when a script inherits `PackedScene` that the script will be lost when reloaded is required here, and a workaround would be to add the script after loading the resource.

### Steps to reproduce

Have a script that inherits `PackedScene` and add a `class_name`. Have a node that will initialize that script to a variable with the type of that script and pack itself, then save the resource. Then load the resource and set it to that same variable. It will fail because the resource is not of the type of that script.

You can also check the text file to see that the script is referenced as an `ext_resource`, yet never used, and that UIDs are non-existent for both the `PackedScene` header itself and the `ext_resource`s. It will be fixed when re-saved in the Godot Editor.

### Minimal reproduction project (MRP)

[packedsceneproblem2.zip](https://github.com/user-attachments/files/18346554/packedsceneproblem2.zip)
Repository: PowerToys
Issue: Version 0.87.1 disabled PC audio
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.87.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

General

### Steps to reproduce

I had version 0.80.0 installed on my work PC, with WIN11 (KB5048685). I did the automatic update in PowerTools UI, the update worked, but I didn't restart my PC immediately. The new version was 0.87.1.
Some time after the update, I noticed that all the audio outputs were not working, nor were the PC speakers, headset or bluetooth headphones.
I uninstalled PowerToys and restarted my PC a few times, but that didn't solve the problem.
After a few attempts, I decided to reinstall version 0.80.0 and, after restarting, the audio started working again.
Since it's my work PC, I don't have full administrator access to update or disable audio drivers (Realtek Audio), so I couldn't try other solutions.

The problem is solved for me now, but I think it was good to report this bug, since it was somehow caused by the update.

### ✔️ Expected Behavior

_No response_

### ❌ Actual Behavior

_No response_

### Other Software

_No response_
Repository: PowerToys
Issue: [Workspaces] Workspaces editor window opens outside the visible area if you have multiple monitor configurations
Labels: Issue-Bug,Resolution-Fix Committed,Product-Workspaces

### Microsoft PowerToys version

0.87.1

### Installation method

GitHub

### Running as admin

Yes

### Area(s) with issue?

Workspaces

### Steps to reproduce

Have two monitor settings:
- Set up the monitor to be to the left of the laptop monitor
- Open Workspaces' editor window
- Resize and move the window to the monitor in the left
- Close it
- Set up the monitor to be to the right of the laptop monitor
- Try opening the Workspaces' editor window
- It will be hidden

Some extra details: these two setups are completely separate. So I turn the PC on either on one setup or in the other depending on where I'm working at. My home setup has it to the left with an ultra-wide monitor, while at the office I have a normal monitor to the right. All three are 1080p 100% zoom, but have varying pixel densities (bigger or smaller monitors in cm, but in pixels they are equivalent to 1080p)

### ✔️ Expected Behavior

If the top left edge of the window is in a negative position, position it at 0:0 (I don't really know how this works. I'm assuming it works like this)

### ❌ Actual Behavior

The window gets hidden:

![Image](https://github.com/user-attachments/assets/5e1b6646-6ffc-4da4-9f16-d5420eff3252)


### Other Software

_No response_
Repository: go
Issue: runtime/pprof: mechanism to show runtime frames in heap profiles
Labels: NeedsDecision,compiler/runtime,BugReport

runtime/pprof [hides "runtime" frames](https://cs.opensource.google/go/go/+/master:src/runtime/pprof/protomem.go;l=39;drc=b50ccef67a5cd4a2919131cfeb6f3a21d6742385) in heap profiles, so allocations in maps appear at the map assignment location in the calling code, but not in `runtime.mapassign` itself.

Personally I find this behavior frustrating because it makes it much more difficult to look at the overall impact of maps in general on the heap, since there is no common frame to look at. I think it would be nice to have a mechanism to keep runtime frames in heap profiles. Perhaps something like `GODEBUG=heapprofileruntimeframes=1`.

I broke the runtime frame hiding in 1.24 (#71174) and discovered the bug because @bboreham mentioned that they liked the change!