sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Moving file referenced in resources generates .depren files
Labels: bug,topic:editor,needs testing

### Tested versions

Reproducible in:
- 4.2.1 (although it complains when moving the file, still makes the same depren file)
- 4.3-stable
- 4.4-dev1

The message from 4.2.1:
![image](https://github.com/user-attachments/assets/d050d307-934c-4f5c-8964-b46655574c06)

4.3 & 4.4 are silent.

### System information

Godot v4.4.dev1 - Manjaro Linux #1 SMP PREEMPT_DYNAMIC Mon Aug 19 09:51:26 UTC 2024 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3080 Laptop GPU - AMD Ryzen 9 5900HX with Radeon Graphics (16 Threads)

### Issue description

When moving files around that are part of a resource, Godot creates an extra `.depren` file.
Deleting this file doesn't seem to do/break anything? I think if this is part of some internal process for moving files, that it didn't clean up after itself.

It seems that [this bug](https://github.com/godotengine/godot/issues/60412) is back?

### Steps to reproduce

- Create a New Resource, select Sprites Frames
- Add frames using `icon.svg`
- Save the resource as `icon.res`
- Move `icon.svg` to a different directory
- Using the file explorer to check the root directory of the project, extra file appeared: `icon.res.depren`

Deleting this file seems to have no effect on the project.

### Minimal reproduction project (MRP)

Open this project in Godot: [depren.zip](https://github.com/user-attachments/files/16918684/depren.zip)

In the editor, select the `icon.svg` and drag it into the `asset` directory.
Open your file explorer and the root of the project now has an extra file: `icon.res.depren`
Repository: ui
Issue: [bug]: Dialog and Sheet have no background
Labels: bug

### Describe the bug

Dialog and Sheet has no background

### Affected component/components

Sheet, Dialog

### How to reproduce

1. Create new project `npx shadcn@latest init dialog`
2. Replace `page.tsx' with the following code
```tsx
import { Dialog, DialogContent, DialogDescription, DialogHeader, DialogTitle, DialogTrigger, } from "@/components/ui/dialog"

export default function Home() {
  return (
    <Dialog>
      <DialogTrigger asChild>
        <div>Open</div>
      </DialogTrigger>
      <DialogContent className="sm:max-w-md">
        <DialogHeader>
          <DialogTitle>Test title</DialogTitle>
          <DialogDescription>
            Test description
          </DialogDescription>
        </DialogHeader>
        <div>Test content</div>
      </DialogContent>
    </Dialog>
  )
}
```
3. Run application and open the dialog
4. See the following result:
![image](https://github.com/user-attachments/assets/ddfc816c-831a-43d7-8459-45003198478c)

Temporary fix:

I modified the background class in the dialog component from bg-background to bg-[var(--background)], and this corrected the issue. It seems like the default background variable is not being applied correctly in some cases.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Chrome, Windows
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: rust
Issue: Should public_private_dependencies consider unreachable visibility?
Labels: T-lang,T-compiler,C-bug,F-public_private_dependencies,L-public_private_dependencies

I tried this code:

```rust
mod foo {
    pub fn example() -> regex::Regex {
        regex::Regex::new("test").unwrap()
    }
}

pub fn x() {
    foo::example();
}
```

with cargo's [public-dependency](https://doc.rust-lang.org/cargo/reference/unstable.html#public-dependency) feature enabled, and `regex` is a private dependency.

I expected to see this happen: No warning

Instead, this happened: Generated a warning about the dependency in a public interface, but there is no exposure of the dependency in the public interface.

```
warning: type `regex::Regex` from private dependency 'regex' in public interface
 --> src/lib.rs:2:5
  |
2 |     pub fn example() -> regex::Regex {
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: `#[warn(exported_private_dependencies)]` on by default
```

In https://github.com/rust-lang/rust/issues/44663#issuecomment-1552721144, bjorn3 mentioned:

> We consider any `pub` item to be public, even if not actually reachable. This is also why for example `mod sealed { pub trait Sealed {} } pub trait MyTrait: Sealed {}` is allowed despite `Sealed` not being reachable.

However, I'm not sure I completely agree with that reasoning. In the example above, there is no exposure of the private dependency in any types. This would make more sense if [`unreachable-pub`](https://doc.rust-lang.org/nightly/rustc/lints/listing/allowed-by-default.html#unreachable-pub) was on by default, but it's not. Although I can sympathize that unreachable `pub` is probably bad form, it is very common in Rust code and would be a significant hurdle for false-positives of `exported_private_dependencies`.

### Meta

```
rustc 1.83.0-nightly (9c01301c5 2024-09-05)
```
Repository: flutter
Issue: `DecoratedBox`: clip behavior + other improvements
Labels: c: new feature,framework,c: proposal,P3,team-framework,triaged-framework

**Container** is a somewhat "heavy" widget (see https://github.com/flutter/flutter/issues/147431), so it'd be great if **DecoratedBox** could fully decorate a box by itself (as its name would imply).

- [**PhysicalShape**](https://main-api.flutter.dev/flutter/widgets/PhysicalShape-class.html) allows setting a `clipBehavior`; **DecoratedBox** should as well.
- **Decoration** objects have intrinsic `padding`; maybe there should be an option to apply this padding.
- And perhaps the **BoxShadow** API has some room for improvement, though at this point I'm not sure if there's a clear path forward.
Repository: godot
Issue: Testing XR game without a headset connected produces two errors and one warning
Labels: bug,topic:xr

### Tested versions

Reproducible in 4.3.stable

### System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 32.0.15.6081) - Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz (16 Threads)

### Issue description

If you launch an XR project from the editor, but don't have a headset connected, the console will show two errors and a warning. The warning has been there for a long time and is expected, but the two errors are new, internal (native), and unhelpful.

![Screenshot 2024-09-07 122753](https://github.com/user-attachments/assets/2b06b19b-74ef-4aa8-902e-4b739c6cf3c6)


### Steps to reproduce

Launch any XR project from the editor, without a headset connected.

### Minimal reproduction project (MRP)

N/A
Repository: PowerToys
Issue: Add a "reset shortcuts" button in settings.
Labels: Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

Resets shortcuts to default.

### Scenario when this would be used?

When you changed the shortcuts too much 😩

### Supporting information

_No response_
Repository: ollama
Issue: Is everything fine with `phi3` model?
Labels: bug

### What is the issue?

I downloaded model 3 moths ago and it worked fine, but now it doesn't work at all. 

My query is `generate 20 non-existing random English-sounding nouns, less than 6 sylables`. Previously it just generated words without descriptions as expected, now with them.

When I substitute "English" with "Polish", it goes into an infinite loop and when I put "German", it start to spill out UUIDs.

Example of Polish output:

```
1. Krzeszinski
2. Szmaragdowa
3. Złotyka
4. Pomocnicza
5. Wesołeńca
6. Jędrzejki
7. Kartwinka
8. Chrobotnica
9. Skrępijny
1 end. 20 nouns generated successfully! Now, let's shuffle them:

Shuffled List (Randomized):
4. Pomocnicza
6. Jędrzejki
7. Kartwinka
3. Złotyka
9. Skrępijny
1 end. 20 nouns generated successfully! Now, let's shuffle them:

Shuffled List (Randomized):
(and it repeats forever)
```

Example of German output:
```
1. Torgelichtweisenheit
... (8 another words correctly generated)
10. Sonnenfinsternistränenqualm
1de25af6-bb4a-3c17-bf8a-9d6e989e3ecc_GermanSoundingNouns=nonExistingWordsList=[Torgelichtweisenheit,Fuchsbärennachtfrost,Himmelspechvogelzunge,...,Sonnenfinsternistränenqualm1de25af6-bb4a-3c17-bf8a-9d6e989e3ecc_GermanSoundingNouns=nonExistingWordsList=[Torgelichtweisenheit,Fuchsbärennachtfrost,Himmelspechvogelzunge,...,de25af6-bb4a-3c17-bf8a-9d6e989e3ecc]
```

### OS

macOS

### GPU

Apple

### CPU

Apple

### Ollama version

ollama version is 0.3.9
previous ollama version was 0.2.3

logs: [ollama.log](https://github.com/user-attachments/files/16919885/ollama.log)
Repository: animate.css
Issue: HowTo fadeIn animation
Labels: bug

### Describe The Bug

I have an element that should start with 0 opacity:
#fldStatus {
    opacity: 0.0;
    animation: fadeIn;
    animation-delay: 3000ms;
    animation-duration: 2000ms;
    width: 100%;
    display: inline-grid;
    padding: 2px 0px 0px 0px;
    margin: 0px;
}
this works fine but after the animation completes, the element reverts back to opacity:0


### Steps To Reproduce

_No response_

### Expected Behavior

Please explain the fadeIn animations for dopes like me :)

### Screenshots

_No response_

### Desktop

_No response_

### Smartphone

_No response_

### Additional Context

_No response_
Repository: terminal
Issue: Trying new `wt x-save foo` for snippets with Canary but `wt` is pointing towards wt-stable
Labels: Issue-Bug,Product-Terminal,Area-Remoting

### Windows Terminal version

1.23.2501.0

### Windows build number

10.0.22635.0

### Other Software

_No response_

### Steps to reproduce

- Open up WT Canary
- Try to save a snippet with `wt x-save git status`
- You get an error because `wt` is pointing to stable version which does not have this feature yet
- I ran `wt --version` and saw that it was pointing to an older version (stable)

I eventually figured out I had to set my `wt` alias to Canary by stumbling upon this comment: https://github.com/microsoft/terminal/issues/17463#issuecomment-2183486775

Here is what my alias settings were without me ever touching them. I had WT Stable installed obviously with windows, then installed WT Preview at one point and then recently installed WT Canary.

![image](https://github.com/user-attachments/assets/15ec8f56-8539-4df0-9a8c-d722d29d1b80)


### Expected Behavior

I am not sure. But at minimum this should be documented in the release notes and the original PR (since I looked there seeing if there was anything similar).

But ideally whatever terminal version you are in, I would expect / hope that `wt` would be "smart enough" to know to point to that specific terminal version (stable vs preview vs canary).

### Actual Behavior

You get an error and unless you know about the wt alias needing to be set you will think it is just a bug with the new snippet x-save feature (or at least I did for a long while until I figured it out).
Repository: godot
Issue: 2D Jiggle physics working in wrong direction
Labels: bug,topic:physics

### Tested versions

- Reproducible in: v4.3.stable.official [77dcf97d8]

https://github.com/user-attachments/assets/2dd2c6f7-9804-47b4-90c1-a9b18903a5b1



### System information

Godot v4.3.stable - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3050 Laptop GPU (NVIDIA; 32.0.15.6081) - 11th Gen Intel(R) Core(TM) i5-11300H @ 3.10GHz (8 Threads)

### Issue description

Jiggle simulation for Skeleton2D PhysicalBones seems to work in opposite direction. Instead of jiggly bones "dragging behind" they fall forward in the direction of motion for unknown reason, this renders jiggle physics practically useless in their current state as they deliver broken results. It's not immediately noticable if you're using the effect in some very subtle manner, but the moment you start to put anything in fast motion it's immediately clear that it is broken and shouldn't behave in this way. Rotational drag for PhysicalBones seems to work properly, but when you try to move the object containing jiggle bones those bones will fly in direction of movement instead of being dragged behind.




### Steps to reproduce

- Create a 2d scene
- Add a Skeleton2D
- add a few bones and parent them together in a hierarchy
- add a few physical bones and assign them to the previously created Skeleton2D bones parenting them together
- in Skeleton2D set up a Overwrite the RestPose, add a new SkeletonModificationStack2D to your Skeleton2D node and enable it
- add 3 modifications to the SkeletonModificationStack2D of "SkeletonModification2DJiggle" type and configure them in a way that will make their jiggling clearly visible and stable as you try to move the bones around
- you should notice that moving the parent Skeleton2D around will result in "reverse-pull" which is incorrect. As jiggle bones instead of being dragged around they move ahead of the object. Rotating the Skeleton2D node however should give completely normal anticipated results that are correct where jiggle bones actually do appear to get dragged behind instead of moving in the opposite direction like they do while being dragged around the scene


### Minimal reproduction project (MRP)

[2d-jiggle-error.zip](https://github.com/user-attachments/files/16919836/2d-jiggle-error.zip)
Repository: pytorch
Issue: Bug with "make latexpdf"
Labels: needs reproduction,module: docs,triaged

### 📚 The doc issue

# Bug Description and Console Output

The following shell output shows the bug encountered when running "make latexpdf".

(PyTorchV2-docs) ➜  docs git:(main) pwd
/home/bulky/PyTorchContributing/pytorch/docs
(PyTorchV2-docs) ➜  docs git:(main) ls
build  cpp  libtorch.rst  make.bat  Makefile  README.md  requirements.txt  source  src
(PyTorchV2-docs) ➜  docs git:(main) make latexpdf
Traceback (most recent call last):
  File "/home/bulky/PyTorchContributing/pytorch/docs/source/scripts/exportdb/generate_example_rst.py", line 190, in <module>
    generate_rst()
  File "/home/bulky/PyTorchContributing/pytorch/docs/source/scripts/exportdb/generate_example_rst.py", line 176, in generate_rst
    doc_contents = generate_example_rst(example_case)
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/bulky/PyTorchContributing/pytorch/docs/source/scripts/exportdb/generate_example_rst.py", line 44, in generate_example_rst
    if example_case.example_kwargs:
       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'ExportCase' object has no attribute 'example_kwargs'. Did you mean: 'example_inputs'?
make: *** [Makefile:28: exportdb] Error 1


# Steps to Reproduce:

1. conda create --name PyTorchV2-docs
2. conda activate PyTorchV2-docs
3. conda install pip
4. conda install main::numpy
5. pip install -r requirements.txt
6. conda install pytorch
7. make latexpdf



### Suggest a potential alternative/fix

This issue is related to a documentation build error, which puts it in a grey area between a bug and documentation issue. First, it would be helpful to fix the build error in the documentation. In addition, the following minor changes would be helpful:

1. The documentation build currently requires numpy 1.x. Since most people likely have numpy 2.x installed, a short snippet suggesting how to work around this issue might be helpful for some users. For example, one could add the following snippet to the documentation build instructions:

Building the documentation requires numpy 1.x. For this reason, it is advised to create a separate anaconda3 environment for the documentation build process. For example, one could use the following process if the user is using anaconda3 as advised in the PyTorch developers documentation:

1. conda create --name PyTorchV2-docs
2. conda activate PyTorchV2-docs
3. conda install pip
4. conda install main::numpy
5. pip install -r requirements.txt
6. conda install pytorch
7. make latexpdf

Please note that step 4 installs numpy 1.26.4 and that step 6 installs pytorch 2.3.0 for a CPU only. Since this environment is only for the purpose of building documentation, installing pytorch with CUDA, ROCM, or other device code is not necessary.

2. If the bug in this issue description is not a bug, it would be helfpul to know how to configure one's system to ensure the documentation builds properly.

cc @svekars @brycebortree @tstatler
Repository: PowerToys
Issue: Modifier Keys messed up by MWB
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.84.0

### Installation method

PowerToys auto-update, WinGet

### Running as admin

Yes

### Area(s) with issue?

Mouse Without Borders

### Steps to reproduce

Mouse Without Borders process is running
hold any modifier key (Shift,Control,Alt,Windows)
Problems are fixed by either disabling MWB or killing subprocess

### ✔️ Expected Behavior

Modifier key will stay enabled
Ex. Open textbox, hold Shift+A, expect a repeating line of Capital A's
Ex. drag a window and hold shift, fancy zones appear to lock window

### ❌ Actual Behavior

Modifier keys stutter or disable
Ex. Open textbox, hold Shift+A, expect a repeating line of Capital A's only first few As are capital rest are lowercase (shift disabled)
Ex. drag a window and hold shift, fancy zones appear to lock window (Fancy Zones Stutter as if letting go of Shift key)

### Other Software

_No response_
Repository: ollama
Issue: [Feature request] compatibility with vm balloon ram
Labels: feature request,linux,windows

Hi, it looks like ollama is not compatibel with ballon ram inside of an VM, i wanted to run ollama inside of an balloon ram, but i realized that when i have balloon enabled ollama thinks that there is just as example 5GB Ram available out of the 15GB it could get, because they are not provisoned at the start time when ollama checks how mutch ram is available.
i think it would be aweseome to have an envionment variable to explicitly specify how mutch ram its allowed to take regardless how many there is at the time of starting.
Repository: TypeScript
Issue: Overload order affects assignability of abstract constructors overloaded with regular constructors in interfaces
Labels: Bug,Help Wanted

### 🔎 Search Terms

abstract constructors, constructor overloading, overload order, intersection, type aliases, interfaces, assignability

### 🕗 Version & Regression Information

- This seems like a bug
- This is the behavior in every version I tried since abstract constructors were added (4.2)


### ⏯ Playground Link

https://www.typescriptlang.org/play/?noUncheckedIndexedAccess=true&ts=5.7.0-dev.20240904#code/C4TwDgpgBAwgjFAvFAhgIwM7AE4oMbBQB2EA7lABQoBcUcAlEgHx0BQoksATEsWZTShdGiFl1asAlkWARsAM3zQAglAgAPWUQAmGWHAA03KAG8AvlAD0lqAFFs2APbZaMFESKPCKDBkkBzIlQg9CxcAig8RyIwgFcCZygOaGBHVGJogFpQnHxCKJiceNTsJPAIADopGTlFPGgAITVNCB09GC4jeFMLaygAeQBrCW0IPAAbFGxocYhvWmVWUYmpmbmoNFoGiT6AFQALCAxoVY2vfbV5eTHgSQA3CHGQVExcglYSchQKBiNP1Aowj+-DQP3owPIoOEEhQvDQVhsQ1Y8OQsL69icLlg7k83l8ARCIVe4Xy0TiCVKySSaVhniI2WJeUiZKKFLKkCq7HKUGUjIIADFJNgsLxugAybhczi8sJ5AAyPkIyA6UAl8BGY0m0ygs28fOAguFwAW+sNWCWmtOupesoICqwJttwHtwB2NgORxO2p8fkC6Fm1LU+AujkO2FYORJZqVNrezsVEf1Lt4kby0YkKNjUaFIvRDmcrhxXlQ+MCwSzTIK5JK7JSNIy9NTESrrJrySqTYNOZj8L6SORKaTioRA2GneTyF7iOGQA

### 💻 Code

```ts
type C1 = abstract new (a: 1) => 1
type C2 = new (a: 2) => 2

interface A extends C1, C2 {} // Error: Cannot assign an abstract constructor type to a non-abstract constructor type.
interface B extends C2, C1 {} // Ok

declare let a: A
declare let b: B

// These are both effectively abstract
new a(1), new a(2), new b(1), new b(2)

a = b // Ok
b = a // Error: Cannot assign an abstract constructor type to a non-abstract constructor type.

type AbstractFirst = C1 & C2
type AbstractLast = C2 & C1

declare let abstractFirst: AbstractFirst
declare let abstractLast: AbstractLast

// These are assignable to each oher
abstractFirst = abstractLast
abstractLast = abstractFirst

b = abstractFirst // Error: Cannot assign an abstract constructor type to a non-abstract constructor type.
abstractFirst = b // Ok

b = abstractLast // Ok
abstractLast = b // Ok
```


### 🙁 Actual behavior

It seems that interfaces with both abstract and regular constructor overloads are only assignable from types with non-abstract first constructor overload.

### 🙂 Expected behavior

I don't expect any difference here.

### Additional information about the issue

_No response_
Repository: ui
Issue: [bug]: Something went wrong creating a new Next.js project. Please try again.
Labels: bug

### Describe the bug

I've copied this initiation command line from the documentation:
`bunx --bun shadcn@latest init`
I got this error after the project name question:
`Something went wrong creating a new Next.js project. Please try again.`


### Affected component/components

Project Setup

### How to reproduce

I interrupted the init command the first time, and then I continuously got the error.

### Codesandbox/StackBlitz link

_No response_

### Logs

_No response_

### System Info

```bash
Macbook pro 2021 M1
```


### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues
Repository: vscode
Issue: Increased typing lag with many word separators
Labels: performance

Steps to Reproduce:

1. Load VSCode version 1.86.0 or higher (1.93.0)
2. Fill a `Plain Text` file with 500,000+ word separators `editor.wordSeparators`
   (any combination of these characters `` `~!@#$%^&*()-=+[{]}\|;:'",.<>/? ``)
   `::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::`
4. Go to the end of the file and type any single `wordPattern` character (`a-zA-Z_` by default) 
   OR any of the language `triggerCharacters` (none for `Plain Text`)
   OR just press ctrl+space to manually bring up intellisense
6. Watch as VSCode hangs for considerable time (and/or crashes)
7. Load up VSCode version 1.85.1 or lower
8. Repeat steps 2 & 3
9. Notice only a marginal 500-700ms lag spike

![image](https://github.com/user-attachments/assets/6aa77870-ca5c-4342-acbe-d30f1df441fe)

I found this to mainly cause problems with large JSON files as they contain a large amount of word separator characters `{}[]":,`

also notice that filling the file with non-word separators, doesn't cause any crashing `qwertyuiopasdfghjklzxcvbnm0123456789_   `

obviously 500,000 characters is a lot, but I would have never made this bug report if I never encounter it
and of course there's still large multi-second long lag spikes at only 10k chars etc
and noticeable stuttering at 1k chars


Does this issue occur when all extensions are disabled?: Yes
- VS Code Version: 1.93.0
- OS Version: Windows 11