sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking Issue for maybe_uninit_fill
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(maybe_uninit_fill)]`

This is a tracking issue for ACP https://github.com/rust-lang/libs-team/issues/156

### Public API

```rust
// core::mem

impl<T> [MaybeUninit<T>] {
    // formerly `fill`
    pub fn write_filled<'a>(this: &'a mut [MaybeUninit<T>], value: T) -> &'a mut [T]
        where T: Clone

    // formerly `fill_with`
    pub fn write_with<'a, F>(this: &'a mut [MaybeUninit<T>], f: F) -> &'a mut [T]
        where F: FnMut() -> T;

    // formerly `fill_from`
    pub fn write_iter<'a, I>(this: &'a mut [MaybeUninit<T>], iter: I) -> (&'a mut [T], &'a mut [MaybeUninit<T>])
        where I: Iterator<Item = T>;
}
```

### Steps / History

- [ ] Implementation: https://github.com/rust-lang/rust/pull/117426
- [ ] Make slice methods inherent: https://github.com/rust-lang/rust/pull/129259
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

### Unresolved Questions

- Naming: these were originally named `fill`, `fill_with`, and `fill_from` to be consistent consistent with `slice::{fill_with,fill_from}`. Since changing to slice-inherent methods, these needed to be renamed to avoid conflict. Should we change to naming that keeps `fill`? Amanieu suggested `fill_init` at https://github.com/rust-lang/rust/pull/129259#issuecomment-2501783702.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: deno
Issue: Implement `node:wasi`
Labels: node compat,node API

`std/wasi` is being deprecated https://github.com/denoland/deno_std/pull/3732 and it would be nice to offer an alternative i.e `node:wasi` before it's removal.

Some ideas on perfomance:

- https://github.com/littledivy/fastwasi
- https://github.com/denoland/deno_core/pull/289
Repository: PowerToys
Issue: FancyZones - Move newly created windows to next available zone
Labels: Product-FancyZones,Needs-Triage

### Description of the new feature / enhancement

In FancyZones within the `Windows` section of settings please add a checkbox 'Move newly created windows to next available zone'.

_Function:_

By `available zone` I mean the next zone in sequence that has no window docked within it.

If all zones are filled the window should appear in either a `maximized` or a `normal` state, depending on user preference.

### Scenario when this would be used?

Creating new windows (e.g. `Start+E` to launch explorer).

### Supporting information

_No response_
Repository: PowerToys
Issue: PowerToys Run - Visual Studio Code Workspaces
Labels: Issue-Bug,Needs-Repro,Needs-Triage,Run-Plugin,Needs-Team-Response

### Microsoft PowerToys version

0.75.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

1. Invoke PowerToys Run with Keyboard shortcut
2. Enter direct activation command for Visual Studio Code Workspaces
3. Check the suggestions

### ✔️ Expected Behavior

See suggestions of workspaces, each workspace only once

### ❌ Actual Behavior

All workspaces appear twice
![image](https://github.com/microsoft/PowerToys/assets/69309597/d8474ef0-2fac-4157-a588-208ea45eb60c)


### Other Software

## Visual Studio Code
Version: 1.83.1 (user setup)
Commit: f1b07bd25dfad64b0167beb15359ae573aecd2cc
Date: 2023-10-10T23:48:05.904Z
Electron: 25.8.4
ElectronBuildId: 24154031
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.22621
Repository: rust
Issue: Sub-optimal layout of `Option<(u16, [u8; 15])>` (missed niche optimization)
Labels: C-enhancement,T-compiler,A-layout

I tried this code:

```rust
use std::mem::size_of;

fn main() {
    println!("(u16, [u8; 14]) = {} bytes", size_of::<(u16, [u8; 14])>());
    println!("(u16, [u8; 15]) = {} bytes", size_of::<(u16, [u8; 15])>());
    
    println!("Option<(u16, [u8; 14])> = {} bytes", size_of::<Option<(u16, [u8; 14])>>());
    println!("Option<(u16, [u8; 15])> = {} bytes", size_of::<Option<(u16, [u8; 15])>>());
    
    let mut x: Option<(u16, [u8; 15])> = None;
    let bytes: [u8; 20] = unsafe { std::mem::transmute(x) };
    println!("None = {:02x?}", bytes);

    x = Some((0xffff, [0xee; 15]));
    let bytes: [u8; 20] = unsafe { std::mem::transmute(x) };
    println!("Some = {:02x?}", bytes);
}
```

I expected to see this happen:
- `(u16, [u8; 15])` has a size of 18 bytes, because there are 17 bytes of useful data and it is rounded up due to the alignment of 2 bytes.
- I expected `Option<(u16, [u8; 15])>` to also take 18 bytes due to a [niche optimization](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#niche).

Instead, this happened:
- `Option<(u16, [u8; 15])>` takes 20 bytes, and appears to be layout as:

```rust
struct Foo {
    discriminant: u16,
    x0: u16,
    x1: [u8; 15],
    padding: u8,
}
```

I expected the Option to leverage the byte of padding at the end of the struct to decide if it's `None` or `Some` instead of pre-pending a discriminant.

```
(u16, [u8; 14]) = 16 bytes
(u16, [u8; 15]) = 18 bytes
Option<(u16, [u8; 14])> = 18 bytes
Option<(u16, [u8; 15])> = 20 bytes
None = [00, 00, 00, 00, 54, d1, 5c, fc, b6, 7f, 00, 00, 05, 00, 00, 00, 00, 00, 00, 00]
Some = [01, 00, ff, ff, ee, ee, ee, ee, ee, ee, ee, ee, ee, ee, ee, ee, ee, ee, ee, f7]
```

### Meta

Tested on the playground: https://play.rust-lang.org/?version=stable&mode=release&edition=2021

---

This is inspired by the `tinyvec` crate, which is roughly layout as follows (https://docs.rs/tinyvec/latest/src/tinyvec/tinyvec.rs.html#97-103, https://docs.rs/tinyvec/latest/src/tinyvec/arrayvec.rs.html#103-107) - although the niche wouldn't apply in that case (and the `smallvec` crate has a better layout):

```rust
pub enum TinyVec<T, const N: usize> {
    Inline((u16, [T; N])),
    Heap(Vec<T>),
}
```
Repository: next.js
Issue: Next build not working if sharp is not installed
Labels: bug

### Link to the code that reproduces this issue

https://codesandbox.io/p/sandbox/admiring-surf-lsc2js

### To Reproduce

1. Run the project
2. Build a project

### Current vs. Expected behavior

Current

The build is not working

Expected

Build should working

### 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 23.0.0: Fri Sep 15 14:43:05 PDT 2023; root:xnu-10002.1.13~1/RELEASE_ARM64_T6020
Binaries:
  Node: 18.18.2
  npm: 9.8.1
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 14.0.0
  eslint-config-next: 14.0.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Additional context

_No response_
Repository: PowerToys
Issue: Privilege Elevation prevents using "Environment Variables" when using separate admin account
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response,Product-Environment Variables

### Microsoft PowerToys version

0.75.0

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Environment Variables

### Steps to reproduce

* launch "Environment variables"
* in the elevation prompt, type your credentials, different from your actual user.
* watch the app open showing variables from your elevated user instead of your session user

### ✔️ Expected Behavior

No elevation is required to view and modify user scoped environment variables.

### ❌ Actual Behavior

Elevation is required and the app is running as the wrong user

### Other Software

N/A
Repository: godot
Issue: `DisplayServer.is_touchscreen_available()` unexpectedly returns `true` on Windows without a touchscreen available
Labels: topic:porting,needs testing,topic:input

### Godot version

4.1.2 stable

### System information

Windows 11

### Issue description

**DisplayServer.is_touchscreen_available()** returns true even if the computer doesn't have any **touch screen** ability!!

**Exporting output** for Windows also makes **crash** during playing game!!

### Steps to reproduce

# OS.has_feature("touch") works fine but not this
func is_touch_available():
	return DisplayServer.is_touchscreen_available()

### Minimal reproduction project

It occurs in GDscript, but I don't know about C# version.
Repository: material-ui
Issue: [joy-ui][Drawer][Menu] `Menu` appears underneath `Drawer` component
Labels: bug 🐛,component: drawer,component: menu,package: joy-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/determined-carlos-glp97m?file=/src/Demo.tsx

Steps:

1. Add a Drawer
2. Add a Menu within that Drawer


### Current behavior 😯

Clicking the `MenuButton` appears to do nothing because the `Menu` will be rendered underneath the `Drawer`.

### Expected behavior 🤔

The `Menu` is listed on top of the `Drawer`.

### Context 🔦

_No response_

### Your environment 🌎

_No response_
Repository: TypeScript
Issue: Infinities as number literal types
Labels: Suggestion,In Discussion

### 🔎 Search Terms

infinity number literal

### 🕗 Version & Regression Information

- This changed in PR https://github.com/microsoft/TypeScript/pull/55268


### ⏯ Playground Link

https://www.typescriptlang.org/play?ts=5.3.0-dev.20231031#code/C4TwDgpgBACg9gZwJbCQNwgSQHYDMnYohQC8UAjBAJw0DcAUAPSNSsB6A-PaJFAHIQA5gENUGHPkKhSUALSUaVBs1ZRO9IA

### 💻 Code

```ts
type PositiveInfinity = 1e999;
//   ^?
type NegativeInfinity = -1e999;
//   ^?
```


### 🙁 Actual behavior

In TS 5.2 we get `NumberLiteralType`s with `Infinity` and `-Infinity` values.

In the upcoming TS 5.3 we get a number type in the of the `PositiveInfinity`

### 🙂 Expected behavior

I don't know. I created this issue to discuss exactly that. 

Should this part of the change be reverted and should `Infinity` be allowed as a literal number value? Or should `-Infinity` be aligned with `Infinity` and should it be converted~ to a `number` type as well?

### Additional information about the issue

I didn't see an `Infinity` as a literal type so I made this change while working in this area. @rbuckton commented [here](https://github.com/microsoft/TypeScript/pull/55268#discussion_r1284798293):
> I really hope no one is relying on this.

but it turns out that some try to rely on this. We can see it in [this issue](https://github.com/microsoft/TypeScript/issues/56270), cc @Max10240
Repository: PowerToys
Issue: Cannot add System and User Environment variables with the same name to one Profile in "Environment variables" Util
Labels: Issue-Bug,Needs-Triage,Product-Environment Variables

### Microsoft PowerToys version

0.75.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Environment Variables

### Steps to reproduce

1. Open "Environment variable" Util
2. Click (+) "New profile" button
3. Click (+) "Add variable" button
4. Switch to "Existing" tab
5. Try to select any pair of variables with the same name in different namespaces (e.g. System "Path" and User "Path" or System & User "TMP")

### ✔️ Expected Behavior

Variables in a single profile can have the same names if they belong to different namespaces. 
User can select any of existing variables to add them to a single profile regardless of variable names coincidence.

### ❌ Actual Behavior

Only one variable with unique name can be selected. 
User can not select second variable with the same name from another namespace.
![image](https://github.com/microsoft/PowerToys/assets/8080339/47833a3a-e685-4f12-8906-3353b60c2e42)


### Other Software

_No response_
Repository: godot
Issue: Window.popup_centered not centered on screen
Labels: bug,platform:linuxbsd,topic:gui

### Godot version

v4.1.2.stable.custom_build

### System information

Godot v4.1.2.stable (399c9dc39) - openSUSE Tumbleweed 20231023 - X11 - Vulkan (Compatibility)

### Issue description

The documentation for `Window.popup_centered` says:

> Popups the Window at the center of the current screen, with optionally given minimum size. If the Window is embedded, it will be centered in the parent Viewport instead.

This does not work for non-embedded windows. They open in the top left of the screen.


### Steps to reproduce

1. Set the project setting `embed_subwindows` to false
2. Create an empty UI scene with a button, add this pressed handler:

``` gdscript
func _on_button_pressed():
	var wnd := Window.new()
	var label := Label.new()
	label.text = "Hello from the window"
	wnd.add_child(label)
	add_child(wnd)
	
	wnd.popup_centered()
```

3. Click the button. A dialog window opens but is placed in the top left of the current screen, not in the center.

### Minimal reproduction project

N/A
Repository: rust
Issue: `Vec.resize()`, `Vec.resize_with()` should be marked as panicking if the new capacity exceeds `isize::MAX` bytes
Labels: T-libs-api,A-docs

### Location

In the documentation for the following functions:

* [`alloc::vec::Vec.resize()`](https://github.com/rust-lang/rust/blob/ffb7ed9fa420e9bcd98d84b431b2009445b7b967/library/alloc/src/vec/mod.rs#L2387-L2420)
* [`alloc::vec::Vec.resize_with()`](https://github.com/rust-lang/rust/blob/ffb7ed9fa420e9bcd98d84b431b2009445b7b967/library/alloc/src/vec/mod.rs#L2184-L2222)

I noted some trait impls where they might want to be added (such as the `Extend` trait impls on `Vec`), but I'm unsure if it makes sense for the "Panics" notes to be added to them.

### Summary

These should be marked with the following:

```markdown
# Panics

Panics if the new capacity exceeds `isize::MAX` bytes.
```

as they all, in one way or another, call `Vec.reserve()`, which itself will panic if the new capacity exceeds `isize::MAX` bytes.

Because other functions that call `Vec.reserve()` (such as `Vec.push()` or `Vec::with_capacity()`) are marked with this "Panics" note, *not* marking these could result in confusion - namely, the user might think that these functions somehow allow bypassing the `isize::MAX` byte limit.
Repository: storybook
Issue: [Bug]: "../public" is always copied in the static build root even if I set it to go elsewhere
Labels: question / support,help wanted,build-storybook

### Describe the bug

I can put anything I like into the `staticDirs` config option, "../public" will always be copied at the root of the storybook-static folder during the last phase of the build.  
My problem is: "../public" contains data unrelated to Storybook (for instance pdf document to download in the app) and, more importantly, **"../public" contains an index.json file that will override the storybook generated index.json, breaking the build in the process** (because without the index, stories are not found).  

If it's working as intended, could someone point out how I can go over that and NOT copy `index.json` into "/storybook-static"?

### To Reproduce

1. Create a new app with storybook (for instance ` npm create vite@latest` then `npx storybook@latest init`)
2. Create a file `public/index.json` and put an empty JSON inside `{}`
3. Set the staticDirs to anything other than `../public`, for instance `staticDirs: [ { from: "../public", to: "/foo" } ],`
4. Run the storybook build `npm run build-storybook`
5. `storybook-static/index.json` doesn't contain the necessary data (should be something like `{ v:4, entries: {...`) but instead is set at whatever you put in the `public/index.json` file (in this example, it's `{}`)
6. `storybook-static/foo` contains a copy of whatever was in the `../public` folder (so the staticDirs property works BUT the copy is done twice, once at the root, once at the directory I asked it to use)

### System

_No response_

### Additional context

_No response_
Repository: neovim
Issue: Some highlights in `ModeChanged` autocommand for command-line mode don't get set immediately on trigger
Labels: highlight,events,cmdline-mode

### Problem

Some highlights groups don't get set through `ModeChanged` autocommand don't get set immediatly when entering command-line mode.

### Steps to reproduce

Use the following `init.lua`:

```lua
vim.o.cursorline = true
vim.o.number = true
vim.o.termguicolors = true

local augroup = vim.api.nvim_create_augroup('TestGroup', {})
vim.api.nvim_create_autocmd('ModeChanged', {
  callback = function()
    vim.api.nvim_set_hl(0, 'Normal', { bg = 'green' }) -- This gets set immediatly when pressing `:`
    vim.api.nvim_set_hl(0, 'CursorLineNr', { bg = 'red' }) -- This doesn't get set until leaving command-line mode
    vim.api.nvim_set_hl(0, 'CursorLine', { bg = 'blue' }) -- Same as above
  end,
  group = augroup,
})
```

1. `nvim --clean -u path/to/init.lua`
2. Press `:`, notice how `Normal`'s `bg` gets set to `green` but the other highlights don't trigger
3. Press `<Esc>`, notice how `CursorLineNr`'s and `CursorLine`'s new highlights get set

Originally when I found this error I had the latter highlights get set after I start typing in command-line mode, but with this minimal config they don't get set until I leave command-line mode.

I'm seeing the same behaviour in Vim 9.0.2002 with the following VimScript:

```vim
set number
set cursorline
set termguicolors

augroup TestGroup
  autocmd!
  autocmd ModeChanged * call s:ModeChanged()
augroup END

function! s:ModeChanged()
  highlight Normal guibg=green
  highlight CursorLineNr guibg=red
  highlight CursorLine guibg=blue
endfunction
```

![autocmd-cursorline-highlights](https://github.com/neovim/neovim/assets/15816726/6ad28f86-2273-41fb-b30a-82964d8fe415)

### Expected behavior

All three highlights (`Normal`, `CursorLineNr` and `CursorLine`) get set immediatly upon pressing `:`.


### Neovim version (nvim -v)

NVIM v0.10.0-dev-1e7e9ee

### Vim (not Nvim) behaves the same?

Yes, Vim 9.0.2002

### Operating system/version

Manjaro Linux x86_64

### Terminal name/version

Alacritty 0.8.0-dev (3ed0430)

### $TERM environment variable

tmux-256color

### Installation

AUR
Repository: godot
Issue: Dropcaps bbcode is incorrectly parsed internally, causing an error message
Labels: bug,topic:gui

### Godot version

4.1.2

### System information

Linux Mint 20.3

### Issue description

In a RichTextLabel, if [dropcaps] is used as bbcode, I will consistently get this error message:

E 0:00:00:0631   pop: Parameter "current->parent" is null.
  <C++ Source>   scene/gui/rich_text_label.cpp:3622 @ pop()

This appears to have something to do with the closing [/dropcaps]. If I replace this with any other bbcode, such as [i] or [b], it works fine. Somehow, the internal engine is not registering [dropcaps] in the bbcode tag stack.

### Steps to reproduce

Any scene with a RichTextLabel beginning with [dropcaps]{letter}[/dropcaps], example scene included, seems to do this on load.

Interestingly enough, it does present properly, though.

### Minimal reproduction project

[bug report richtextlabel.zip](https://github.com/godotengine/godot/files/13215376/bug.report.richtextlabel.zip)
Repository: PowerToys
Issue: Enviorment variable Enhancement with open Directory | move variable locally | Short Cut key 
Labels: Needs-Triage

### Description of the new feature / enhancement

I recently installed the PowerToys update and was thrilled to see the new Environment Variable Editor feature. However, I've noticed a few potential enhancements that could be considered

1. **Shortcut Key for Quick Access:** It would be great to have a keyboard shortcut to swiftly open the Environment Variable Editor. This would make it more convenient for developers who frequently need to manage environment variables.

2. **Gliding Tiles for Accessibility:** While this may be more personal, it's worth considering. Instead of scrolling to find the PATH variable, implementing a grid of gliding tiles could make it easier to navigate and access specific variables. This would enhance accessibility, especially for users who may not want to scroll through a lengthy list.

3. **Open Directory with File/Folder Selection:** Adding an option to open Windows File Explorer and select a file or folder directly from the Environment Variable Editor would save users time and effort.

4. **Right-Click "Add to Path Variable" Option:** A handy feature would be the ability to right-click on a directory and select "Add to Path Variable." This would allow users to quickly add the current directory to their path variable after navigating through the Environment Variable Editor.

I hope these suggestions are valuable in further improving the Environment Variable Editor. Your efforts in enhancing this feature are greatly appreciated. and yea Really love the feature💖

### Scenario when this would be used?

**Shortcut Key for Opening Environment Variables:** : Developers and users need to quickly access the Environment Variable Editor to resolve issues related to environment variables.

**Gliding Tiles for Environment Variables:** : To improve accessibility and efficiency, users want a visual grid of gliding tiles for environment variables to eliminate the need for scrolling and quickly access specific variables.

**Open Directory with File or Folder Selection:** : Users wish to open the Windows File Explorer with an option to select a file or folder directly from the Environment Variable Editor.

**Right-Click "Add to Path Variable" Option:** : Users want the ability to right-click on a directory and choose the "Add to Path Variable" option to conveniently add the current directory to their path variable.

### Supporting information

_No response_
```[tasklist]
### Tasks
```
Repository: ant-design
Issue: Does the Table component support virtual horizontal scrolling?
Labels: Inactive,🧶 Low Priority

### Reproduction link

[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/antd-reproduction-template-forked-dqjpvq?file=/index.js)

### Steps to reproduce

Setup a `Table` with `virtual=true` and `scroll.x` set.  All columns are rendered immediately, whereas would expect only a subset to be.

### What is expected?

That only a subset of columns are rendered initially, and as I scroll horizontally, more columns are rendered.

### What is actually happening?

All columns are rendered immediately.

| Environment | Info |
| --- | --- |
| antd | 5.10.3 |
| React | 18.2.0 |
| System | Linux 6.2 |
| Browser | Chrome  118.0.5993.117 |

---
Scrolling vertically works as expected.  I've add a `console.log` to the `Cell` renderer so that it's clear what is rendered when.  As you scroll vertically, new cells are rendered.  But as you scroll horizontally, everything is already rendered.

Is virtual horizontal scrolling supposed to work?  (ie is this a bug or would it be a new feature?)  
The [virtual table announcement](https://ant.design/docs/blog/virtual-table) gave me the impression that it was supported: "we also added horizontal scrolling support for it in this refactoring"

Thanks!

<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->