sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: llvm noalias data gets lost when passing large structs
Labels: T-compiler,A-ABI,C-optimization

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

https://godbolt.org/z/b8as1TxdP

```rust
#[repr(C)]
pub struct Big<'a>(&'a mut u64, &'a mut u64, usize);

#[inline(never)]
pub unsafe fn bad(a: Big) -> u64 {
    *a.0 = 0;
    *a.1 = 1;
    *a.0
}

#[repr(C)]
pub struct Good<'a>(&'a mut u64, &'a mut u64);

#[inline(never)]
pub unsafe fn good(a: Good) -> u64 {
    *a.0 = 0;
    *a.1 = 1;
    *a.0
}
```

```asm
example::bad::h15eeefb1851d2a2e:
        mov     rax, qword ptr [rdi]
        mov     qword ptr [rax], 0
        mov     rcx, qword ptr [rdi + 8]
        mov     qword ptr [rcx], 1
        mov     rax, qword ptr [rax]
        ret

example::good::h034657cbabb42f00:
        mov     qword ptr [rdi], 0
        mov     qword ptr [rsi], 1
        xor     eax, eax
        ret
```

i expected the functions to emit similar codegen, but the bad one doesn't get the noalias on the references themselves because llvm thinks they're passed by pointer since the struct is large.

maybe [alias.scope](https://llvm.org/docs/LangRef.html#id2005) can help with this?

### 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.84.0-nightly (3ed6e3cc6 2024-10-17)
binary: rustc
commit-hash: 3ed6e3cc69857129c1d314daec00119ff47986ed
commit-date: 2024-10-17
host: x86_64-unknown-linux-gnu
release: 1.84.0-nightly
LLVM version: 19.1.1
Compiler returned: 0
```
Repository: storybook
Issue: [Bug]: @storybook/addon-actions v7.6.* is missing @storybook/preview-api from dependencies
Labels: bug,core,won't fix

### Describe the bug

It's only listed as a devDependency, but is required at runtime. 

https://github.com/storybookjs/storybook/blob/d43ced4f6d1efc7d352f4dc9528d29dfe72dd336/code/addons/actions/package.json#L78
- https://github.com/storybookjs/storybook/blob/ac09301a97648ef72a21fbfeb6b5e2b2a8da81ef/code/addons/actions/src/runtime/action.ts#L2
- https://github.com/storybookjs/storybook/blob/ac09301a97648ef72a21fbfeb6b5e2b2a8da81ef/code/addons/actions/src/decorator.ts#L1

### Reproduction link

https://github.com/search?q=repo%3Astorybookjs%2Fstorybook+path%3A%2F%5Ecode%5C%2Faddons%5C%2Factions%5C%2Fsrc%5C%2F%2F+preview-api+language%3ATypeScript&type=code&l=TypeScript

### Reproduction steps

_No response_

### System

Not relevant

### Additional context

_No response_
Repository: godot
Issue: SpriteFrames.get_frame_texture() return the whole spritesheet instead of one frame texture
Labels: discussion,topic:rendering,documentation

### Tested versions

- Reproductible in v4.3.stable.official [77dcf97d8], v4.2.2.stable.official [15073afe3], v4.2.1.stable.official [b09f793f5]

### System information

Windows 10 - Godot v4.2.2.stable.official [15073afe3] | Forward+

### Issue description

I used the "Add frames from sprite sheet" option in a SpriteFrames to add 4 frames, like this :

![Content of the SpriteFrames](https://github.com/user-attachments/assets/cb3eb550-2f03-4cfe-8542-e84bb7d87ce9)

I expect `sp.get_frame_texture("default", 2)` to return only the frame 2 (the green "3") but it returns instead the whole spritesheet.

![Spritesheet](https://github.com/user-attachments/assets/3bff3c19-bac6-4d10-bf9a-548774bbb395)

### Steps to reproduce

- Create a SpriteFrame
- Use a spritesheet to create frames
- Create a debug MeshInstance3D pointed by a camera
- Use a script to set the debug mesh texture to the result of `get_frame_texture()` at game start
- Check that the displayed texture is not a tile texture, but the whole spritesheet texture

### Minimal reproduction project (MRP)

[Proof that SpriteFrames is busted.zip](https://github.com/user-attachments/files/17440689/Proof.that.SpriteFrames.is.busted.zip)
Repository: godot
Issue: Detail mask only applies UV1 even when set to UV2
Labels: bug,topic:rendering,topic:3d

- *Production edit: Related to https://github.com/godotengine/godot/issues/54644.*

### Tested versions

v4.3.stable.steam [77dcf97d8]

### System information

Windows 10

### Issue description

Just trying to get a hang of material importing in Godot and I think I found a really annoying bug. I was making a road texture with the road lines as a detail texure on top. The asphalt and the roadlines have 2 seperate UVs that both imported properly

I used the detail section of the material to put the roadlines on top and set it to UV2. The roadlines need a mask to mask out just the roadlines.

Everything works fine without the mask:
![godot bug](https://github.com/user-attachments/assets/dba675c7-6742-43f0-b175-41a55365e9c6)

But when I add the (obviously needed) mask to the detail section it reverts to UV1 even though its still set to UV2
![godot bug 2 png ](https://github.com/user-attachments/assets/48d73469-b5ab-41ea-b101-f5e75109eb27)



### Steps to reproduce

Take a mesh with two UV maps.

enable Detail in material, Set Detail to UV2, add Detail Mask

### Minimal reproduction project (MRP)

[detailmask_bugreport.zip](https://github.com/user-attachments/files/17440750/detailmask_bugreport.zip)

all you have to do is go into the surface 0 material on the included model and under Detail/Mask add the Roadlines_mask.png 

before you add that mask you can see UV2 is working properly. After you add the mask you can see it's still using UV1
Repository: excalidraw
Issue: Option to Disable AI?
Labels: enhancement,ai

I work for a school district that restricts the use of AI in instructional technology tools online. Is there an option to disable the AI functionality of Excalidraw? If there is not an option, is that something that could be added to the service?
Repository: PowerToys
Issue: Text Extractor Shortcut is not working properly.
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

v0.85.1

### Installation method

PowerToys auto-update

### Running as admin

None

### Area(s) with issue?

TextExtractor

### Steps to reproduce

Text Extractor Shortcut (```Win + Shift + T```) is not working properly.
I tried different custom shortcut options. Unfortunately, the result is same (not working)

### ✔️ Expected Behavior

Pressing the ```WIN + SHIFT + T``` opens up a prompt for selecting some text from an image.

### ❌ Actual Behavior

Nother is happening.

### Other Software

_No response_
Repository: ui
Issue: [feat]: Document use of aliases 'components' and 'utils'
Labels: area: request

### Feature description

First of all, thanks a lot for your work on `shadcn/ui`!

The [documentation for `components.json` aliases](https://ui.shadcn.com/docs/components-json#aliases) doesn't explain the purpose of the `components` and `utils` aliases. I would particularly like to know how they differ from the `ui` and `lib` aliases.

To figure out how these paths are used, I ran the command `npx shadcn@latest init` (to create a Next.js project on an empty folder), followed by `npx shadcn@latest add --all` to add all components.

Files were created in `@/lib`, `@/hooks` and `@ui`, but not for the `components` and `utils` aliases. This makes me wonder if those other aliases are used at all currently.

I think any clarification here would help users better understand the project structure. Thanks for your time!

**Note:** A clue about the `component` vs `ui` aliases might be this phrase found in the changelog:
> The add command is now much more capable. You can now add UI components but also import more complex components (coming soon).
Repository: godot
Issue: SubViewportContainer is rendered only once the first frame and never updates the drawing on Safari
Labels: bug,platform:ios,topic:rendering,confirmed

### Tested versions

IOS 18.0.1 

Chrome:
<img width="682" alt="image" src="https://github.com/user-attachments/assets/e56c9bad-b976-499f-bcde-89f4b257d785">


Safari: 
<img width="282" alt="image" src="https://github.com/user-attachments/assets/04b9578d-830d-44c9-9d59-315620a9f02f">

- Reproducible in 4.2, 4.2.2, 4.3, 4.3.dev1

### System information

Godot v4.3.stable - macOS 15.0.1 - GLES3 (Compatibility) - Apple M1 - Apple M1 (8 Threads)

### Issue description

All of my Godot games crashed in the cloud on my iPhone and Mac after I upgraded both. I found the issue after a week of figuring. My Linux (20.04), Windows (8, 10, 11), and other Macs (older versions which is 14.3) don't have this issue. The Mac I'm using right now, where I'm typing to you, is already upgraded to the latest version, which is 15.0.1. I can't see my project due to a SubViewportContainer issue. There are no error logs in HTML5. I was able to see it in Chrome but not in Safari. My iPhone couldn't see the data either. See the video:

https://drive.google.com/file/d/1B40qT4eeABohT4miUnMhjiavpCuOUWfe/view?usp=sharing

The right browser is Chrome, and the left browser is Safari. 

There are two lines that I can reproduce, and I have this in a zip file as well.

```gdscript
var white_rectangle = $SubViewportContainer/SubViewport/ColorRect # BUG HERE
# var white_rectangle = $ColorRect # WORKING
```

If you comment out the first line and uncomment the second, you will see it working in Safari. However, when you comment out the second line and uncomment the first, you will see the bug without any error logs.

First line is inside the node called subviewport node. The second line is outside of the node called SubViewPort. 



### Steps to reproduce

1) run HTML tester in safari on 15.0.1 Mac OS only
2) comment the first line out and uncomment the second line and then re-run html5 export.


### Minimal reproduction project (MRP)

[rendering_bug.zip](https://github.com/user-attachments/files/17441266/rendering_bug.zip)
Repository: ui
Issue: [feat]: Copy "style" info from changelog to `components.json` docs.
Labels: area: request

### Feature description

The most detailed information about the "style" configuration is currently available only on the [changelog page](https://ui.shadcn.com/docs/changelog#styles). For better discoverability, I think it would be useful to copy that into the [`components.json` docs, into the "style" section](https://ui.shadcn.com/docs/components-json#style).

Based on [this discussion](https://github.com/shadcn-ui/ui/discussions/2930), I think some people were confused about "style", and would have benefited from seeing the information which is currently on the changelog.

Thanks!

### Affected component/components

_No response_

### Additional Context

Additional details here...

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs
Repository: flutter
Issue: [video_player_android] Use `handlesCropAndRotation` to detect the `SurfaceTexture` Impeller backend
Labels: platform-android,p: video_player,P2,a: plugins,team-android,triaged-android

When `handlesCropAndRotation` implemented in https://github.com/flutter/engine/pull/55434 makes it to stable, we should replace the logic implemented in https://github.com/flutter/packages/pull/7846 to detect  the `SurfaceTexture` Impeller backend with `Build.VERSION.SDK_INT < 29` with it.
Repository: ui
Issue: [feat]: Clarify need for `tailwindcss-animate` on the `new-york` style.
Labels: area: request

### Feature description

The [changelog](https://ui.shadcn.com/docs/components-json#style) seems to suggest that `tailwindcss-animate` is not used in the `new-york` style:

>The `default` style is the one you are used to. It's the one we've been using since the beginning of this project. It uses `lucide-react` for icons and `tailwindcss-animate` for animations.
>
>The `new-york` style is a new style. It ships with smaller buttons, cards with shadows and a new set of icons from [Radix Icons](https://icons.radix-ui.com/).

However, running `npx shadcn@latest init` and selecting the `new-york` style, results in the installation of `tailwindcss-animate`:

```bash
$ npx shadcn@latest init
✔ The path ~/shadcnui does not contain a package.json file. Would you like to start a new Next.js project? … yes
✔ What is your project named? … my-app
✔ Creating a new Next.js project.
✔ Which style would you like to use? › New York
✔ Which color would you like to use as the base color? › Neutral
✔ Would you like to use CSS variables for theming? yes
✔ Writing components.json.
✔ Checking registry.
✔ Updating tailwind.config.ts
✔ Updating app/globals.css
✔ Installing dependencies.
✔ Created 1 file:
  - lib/utils.ts

Success! Project initialization completed.
You may now add components.

$ grep tailwindcss-animate my-app/package.json
  "tailwindcss-animate": "^1.0.7"

```

### Affected component/components

_No response_

### Additional Context

Additional details here...

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs
Repository: flutter
Issue: [Flutter GPU] Add RenderPass.setScissor.
Labels: engine,P2,team-engine,triaged-engine,flutter-gpu

The scissor can be used to efficiently clip draws to an integer rectangle on the framebuffer.

Allow the user to set the scissor on the `RenderPass` by passing in a `Scissor` class that just stores an integer rectangle.

There is no need to add functionality to "disable" the scissor. By default, the scissor is set to the render target texture size. So if the user wants to "disable" the scissor, they should simply call `setScissor` again and set it back to the render target texture size.
Repository: PowerToys
Issue: Ability to deal with '%' in `calculator` in `power toys run`
Labels: Help Wanted,Product-PowerToys Run,Run-Plugin

### Description of the new feature / enhancement

In `power toys run` -> `calculator`, add the ability to deal with '%'.
Like 1000+5% = 1050, 1000*5% = 50, etc. Google calculator on android has this behaviour.

Additionally you can also put 5% of 1000 = 50

### Scenario when this would be used?

It will be very useful

### Supporting information

_No response_
Repository: flutter
Issue: [Flutter GPU] Add RenderPass.setViewport.
Labels: engine,P2,team-engine,triaged-engine,flutter-gpu

The viewport determines the region and depth range of the framebuffer that the RenderPass draws to.

Allow the user to set the viewport on the RenderPass by passing in a Viewport class containing a floating point region rectangle and a floating point DepthRange (defaulting to zNear=0 and zFar=1).

Similar to the [scissor](https://github.com/flutter/flutter/issues/157199), there is no need to add functionality to "disable" the viewport. By default, the viewport's region is set to the render target texture size and the viewport's depth range is set to zNear=0 and zFar=1. So if the user wants to "disable" the viewport, they should simply call `setViewport` again and set it back to the default values.
Repository: deno
Issue: storybook: deno fails to init storybook in react+vite project
Labels: bug,node compat

Version: Deno 2.0.2


➜ `deno run -A npm:create-vite` (react, ts without swc)
➜ `deno i`
➜ `deno run -A npm:storybook@latest init`

```
╭──────────────────────────────────────────────────────╮
│                                                      │
│   Adding Storybook version 8.3.6 to your project..   │
│                                                      │
╰──────────────────────────────────────────────────────╯
 • Detecting project type. ✓
Installing dependencies...

npm error Cannot read properties of null (reading 'matches')
npm error A complete log of this run can be found in: /Users/admin/.npm/_logs/2024-10-18T22_52_29_828Z-debug-0.log
An error occurred while installing dependencies.

attention => Storybook now collects completely anonymous telemetry regarding usage.
This information is used to shape Storybook's roadmap and prioritize features.
You can learn more, including how to opt-out if you'd not like to participate in this anonymous program, by visiting the following URL:
https://storybook.js.org/telemetry
```
Repository: TypeScript
Issue: Design Meeting Notes, 9/6/2024
Labels: Design Notes


# Consistency for Computed Properties in Classes

#59860

* Working on making computed properties work consistently between source files and declaration files.
* In object literals, anything goes.
* In classes, they do not behave the same.
    * We error if a computed property doesn't resolve to a specific well-known symbol, unique symbol, or literal type.
    * For computed methods.... we say nothing?
* Want to make classes consistent with object literals.
* This PR just fixes computed 
* Downsides?
    * It breaks code (obviously).
    * Still need to run on top codebases.
* Does this just change classes, or also interfaces?
    * Just classes.
* Do we really need to adopt the behavior where it produces index signatures?
    * It's the only thing that has consistent behavior for isolated declarations?
* What if you have multiple computed properties with different types?
    * Just use the union of the types in a single index signature, but not necessarily the best behavior we could do - would be a follow up.
    * Can have multiple index signatures these days, so maybe we just produce multiple index signatures.
* What happens if you don't know the type?
    * Just create a string index signature right now so that it's consistent with object types.
* Do you really want these index signatutes?
    * In the object literal case, there is no way to add an index signature to the object literal.
    * But a class is sort of used as a hybrid between a JavaScript value declaration and a TypeScript type.
* We like consistency, but feel a little shaky about just introducing index signatures (the follow-up).
    * Can do that behavior, but can still error possibly?

# Node, Type, and Signature monomorphization

* #59190
* #59191
* #59192
* Moves non-monomorphic properties to a `data` grab-bag
  * Causes v8 to optimize this correctly
* getters/setters in the prototype chain expose the `data.` properties for compatibility
  * You can put arbitrarily many getters in the same chain for convenience since they're 1:1
  * We still go through these in this PR and see wins; we could go to .data instead and likely get faster?
* Big big big speedup, slightly more memory usage
* Concern: *all* these properties show up in a debugger
  * API consumers will see all these properties too; implications for `in`
  * Can we provide API users with a more-specific facade?
    * Work in progress, numbers on this approach soon
* Conclusion: Check on Ron's version and merge whatever looks best overall
Repository: TypeScript
Issue: Design Meeting Notes, 9/17/2024
Labels: Design Notes


# Extension Rewriting

https://github.com/microsoft/TypeScript/pull/59767

* We've discussed what we need to do with async imports.
    * One possibility: you do the transform yourself.
    * Another: we provide a runtime shim - possibly overridable.
* Also: we have the same situation for `require` calls in JS input files.
    * It is currently not as common, but possible, for us to transform JavaScript input files.
    * Those files can still refer to `.ts` files - do we want rewriting for those?
* Does the experimental mode in Node support `require`?
    * *Pretty sure* it does?
* There's `require` with a plain string and an arbitrary expression.
    * Why do we care about this difference?
    * `require` can be passed into arbitrary places.
        * Makes us inclined to say no shimming.
* We could error on `require` of an arbitrary expression in this mode.
    * People can always alias `require` or `// @ts-ignore`.
* Extension rewriting was always weird - but if we're gonna do it, maybe we should do it in a maximalist way?
    * Feels like if semantics diverges between runtime and emit, that's a problem.
* Could just say only `require` on static imports.
* Can you just create arbitrary `require`s?
    * Yes, there's `createRequire` - could maybe monkey-patch this?
    * Also `require.call(...)`
* Could add an import attribute to turn off rewriting for `import()`.
* Moved from "don't shim anything" to "shim everything".
* Between import attributes and `(require)(...)` these are reasonable opt-outs.
* Also open to just a global flag...
* Or a third state for the flag.
    * `"none"`, `"staticImportsOnly"`, `"bestEffort"`?
Repository: TypeScript
Issue: Design Meeting Notes, 9/24/2024
Labels: Design Notes

# Always Report `useDefineForClassFields`-Related Errors

https://github.com/microsoft/TypeScript/pull/59623

* When a dev writes a parameter property and a class field depends on the parameter property, we error under `useDefineForClassFields` (or if implicitly in a newer target).
* We want to issue the error regardless of the target.
* We like the idea but it could cause a lot of issues. No code fix today which makes it harder.
* We will just deprecate `useDefineForClassFields` in 6.0.
* Should clarify what the plan is for this (@RyanCavanaugh) - is the idea that we just flip the emit and errors over in 6.0 and let people set `useDefineForClassFields`+`ignoreDeprecations` until 6.5?

# Perform subtype reduction on call expression types if type argument arity fails

https://github.com/microsoft/TypeScript/pull/60036

* Let's imagine `Array<T> | ReadonlyArray<T>`.
* They both have the same `reduce` method overloads. Two of them are considered identical, but one generic signature which *is* the same isn't surfaced because we don't consider common methods as identical.
    * So if you write `reduce<...>(...)`, that'll fail.
* The idea here is that if you write a type argument and it doesn't match any signature's arity, the checker will subtype-reduce the expression type and try again.
* Seems very special-casey.
* Why are you writing `Array<T> | ReadonlyArray<T>`? Why not just write `ReadonlyArray<T>`?
* One weirdness here is the fact that you need to provide type arguments for this to kick in. This is a little bit ad-hoc and makes it hard to reason about. As a user, you wouldn't necessarily expect type arguments to trigger any special behavior.
    * `Array.prototype.reduce` is a pretty special case and 
* Maybe there should be a special rule about `Array<T> | ReadonlyArray<T>` being reduced appropriately?
* We have other special-cases around arrays, why is this one bad?
    * Those were not ideal, but they were motivated by common pain-points around operating on arrays. The issue this addresses doesn't have a lot of feedback other than the current report.
* For now we've decided not to pursue this change.