sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: E0596 should suggest changing type if it suggest taking taking mutable reference instead of just reference
Labels: A-diagnostics,T-compiler,S-has-mcve

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
fn main() {
    let x: &[isize] = &[1, 2, 3, 4, 5];
    // Can't mutably slice an immutable slice
    let _slice: &mut [isize] = &mut [0, 1];
    let _ = &mut x[2..4]; //~ERROR cannot borrow `*x` as mutable, as it is behind a `&` reference
}
```

The current output is:

```
error[E0596]: cannot borrow `*x` as mutable, as it is behind a `&` reference
 --> src/lib.rs:5:18
  |
5 |     let _ = &mut x[2..4]; //~ERROR cannot borrow `*x` as mutable, as it is behind a `&` reference
  |                  ^ `x` is a `&` reference, so the data it refers to cannot be borrowed as mutable
  |
help: consider changing this to be a mutable reference
  |
2 |     let x: &[isize] = &mut [1, 2, 3, 4, 5];
  |                       ~~~~~~~~~~~~~~~~~~~~

For more information about this error, try `rustc --explain E0596`.
```
If we apply the suggestion this will cause the next problem, because `&mut[1,2...]` is not `&[isize]` but `&mut [isize]` :upside_down_face: 

````rust
fn main() {
    let x: &[isize] = &mut [1, 2, 3, 4, 5];
    // Can't mutably slice an immutable slice
    let _slice: &mut [isize] = &mut [0, 1];
    let _ = &mut x[2..4]; //~ERROR cannot borrow `*x` as mutable, as it is behind a `&` reference
}
````

so we should suggest ` let x: &mut [isize] = &mut [1, 2, 3, 4, 5];` right away, if possible.



<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"Ezrashaw"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: Renaming .txt file to .glsl while it is open in the editor has unpredictable results
Labels: bug,topic:editor,topic:shaders

### Godot version

v4.0.beta.custom_build [3c9bf4bc2]

### System information

Fedora 36 KDE, RTX 3080

### Issue description

If I create a TextFile in Godot and change the file extension to .glsl I get different behaviour if the file was open in the editor at the time of renaming.

### Steps to reproduce

First attempt, file **not** open when renaming:

1. Create a TextFile in Godot and name it "test1.txt"
2. Right click it in the FileSystem dock and rename it to "test1.glsl"
3. Double click the file -> ShaderFile tab opens.
4. In a script, both load and preload of the file produces a Resource / RDShaderFile

Everything works as expected.

Second attempt, file open when renaming:

1. Create a TextFile in Godot and name it "test2.txt"
2. Double click the file to open it in the Godot editor.
3. Right click it in the FileSystem dock and rename it to "test2.glsl"
4. Close the file in the Godot editor.
6. Double click the file -> It opens in the editor.
7. In a script, load the file produces a Resource / RDShaderFile
8. In a script, preload-ing the file produces a TextFile

### Minimal reproduction project

I think it's easier to see the strange behaviour by reproducing the steps in the editor.
Repository: godot
Issue: Blurred embedded subwindows, when content_scale_factor is set on parent Window
Labels: bug,topic:rendering,confirmed,regression,topic:gui

### Godot version

v4.0.beta12.official [3c9bf4bc2]

### System information

Windows 11, Mobile (Vulkan), NVIDIA RTX 2070 SUPER

### Issue description

When `content_scale_factor` is set to 1 on root Viewport, then everything renders correctly:
![image](https://user-images.githubusercontent.com/46926490/214242874-44e75f2f-dc56-4a40-a660-5d20d591e59c.png)

But when I set it to, for example, 2, then the popup is blurry (exept for the Popup's title label):
![image](https://user-images.githubusercontent.com/46926490/212480287-5442f0e8-e748-41a8-9c68-73d9c5383a97.png)

Additionaly, when I set content_scale_factor to 0.5, this happens:
![image](https://user-images.githubusercontent.com/46926490/212480339-76aa3c74-e99c-499c-886a-0c66726e0839.png)



### Steps to reproduce

Create a scene with Control and add any popup as a child. Add script to the root node and in `_ready` function write:
```
get_tree().root.content_scale_factor = 2	
$<PopupDialogNode>.popup_centered()
```
Hit play and enjoy

### Minimal reproduction project

[ContentScaleReproduction.zip](https://github.com/godotengine/godot/files/10418082/ContentScaleReproduction.zip)
Repository: rust
Issue: E0121 suggestion just causes another problem "non-defining opaque type use in defining scope" with no good suggestion
Labels: A-diagnostics,T-compiler

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
#![feature(type_alias_impl_trait)]

type Pointer<T> = impl std::ops::Deref<Target=T>;

fn test() -> Pointer<_> {
    //~^ ERROR: the placeholder `_` is not allowed within types
    Box::new(1)
}

fn main() {
    test();
}
```

The current output is:

```
error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types
 --> src/main.rs:5:22
  |
5 | fn test() -> Pointer<_> {
  |              --------^-
  |              |       |
  |              |       not allowed in type signatures
  |              help: replace with the correct return type: `Pointer<i32>`

For more information about this error, try `rustc --explain E0121`.
```
Applying this gives us

```rust
#![feature(type_alias_impl_trait)]

type Pointer<T> = impl std::ops::Deref<Target=T>;

fn test() -> Pointer<i32> {
    //~^ ERROR: the placeholder `_` is not allowed within types
    Box::new(1)
}

fn main() {
    test();
}
```

Which has a even more vague description and no error index to look up details :/

````
error: non-defining opaque type use in defining scope
 --> src/main.rs:7:5
  |
7 |     Box::new(1)
  |     ^^^^^^^^^^^
  |
note: used non-generic type `i32` for generic parameter
 --> src/main.rs:3:14
  |
3 | type Pointer<T> = impl std::ops::Deref<Target=T>;
  |              ^
````
Repository: rust
Issue: E0404 suggestion is correct but E0782 is applied first, preventig autofixing the code
Labels: A-diagnostics,T-compiler,D-invalid-suggestion

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur.
-->

Given the following code: <!-- Please provide a link to play.rust-lang.org -->

```rust
// Regression test of #43913.

// run-rustfix

#![feature(trait_alias)]
#![allow(bare_trait_objects, dead_code)]

type Strings = Iterator<Item=String>;

struct Struct<S: Strings>(S);
//~^ ERROR: expected trait, found type alias `Strings`

fn main() {}
```

The current output is:

```
error[E0404]: expected trait, found type alias `Strings`
  --> src/main.rs:10:18
   |
10 | struct Struct<S: Strings>(S);
   |                  ^^^^^^^ type aliases cannot be used as traits
   |
help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias
   |
8  | trait Strings = Iterator<Item=String>;
   |

error[E0782]: trait objects must include the `dyn` keyword
 --> src/main.rs:8:16
  |
8 | type Strings = Iterator<Item=String>;
  |                ^^^^^^^^^^^^^^^^^^^^^
  |
help: add `dyn` keyword before this trait
  |
8 | type Strings = dyn Iterator<Item=String>;
  |                +++
```


If I only apply the E0404 suggestion, so 
`type Strings = Iterator<Item=String>;` => `trait Strings = Iterator<Item=String>;` , the code works, however, when runnig rustfix, it will apply the E0782 suggestion first which results in `type Strings = dyn Iterator<Item=String>;` which does not fix the problem.

So the code becomes
````rust
// Regression test of #43913.

// run-rustfix

#![feature(trait_alias)]
#![allow(bare_trait_objects, dead_code)]

type Strings = dyn Iterator<Item=String>;

struct Struct<S: Strings>(S);
//~^ ERROR: expected trait, found type alias `Strings`

fn main() {}
````

which will cause

````
error[E0404]: expected trait, found type alias `Strings`
  --> src/main.rs:10:18
   |
10 | struct Struct<S: Strings>(S);
   |                  ^^^^^^^ type aliases cannot be used as traits
   |
help: you might have meant to use `#![feature(trait_alias)]` instead of a `type` alias
   |
8  | trait Strings = dyn Iterator<Item=String>;
   |

For more information about this error, try `rustc --explain E0404`.
````
but 

````rust
trait Strings = dyn Iterator<Item=String>;
````
is not the solution here:

````
error: invalid `dyn` keyword
 --> src/main.rs:8:17
  |
8 | trait Strings = dyn Iterator<Item=String>;
  |                 ^^^ help: remove this keyword
  |
  = help: `dyn` is only needed at the start of a trait `+`-separated list
````
Repository: stable-diffusion-webui
Issue: [Bug]: Textual_inversion folder is missing
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

 Textual_inversion folder is missing in the main directory so I can't create my own embeddings
![err](https://user-images.githubusercontent.com/112754950/212482616-279ffd51-890d-4928-8048-6f159962d9c3.png)
Windows 11, NVIDIA RTX 3070TI 8GB, 16 GB RAM

### Steps to reproduce the problem

1. Go to the main directory
2.  Textual_inversion folder is missing
3. I can't create my own embeddings


### What should have happened?

 Textual_inversion folder is there, so the training not fails

### Commit where the problem happens

69781031e7473e020b3af4461fdceb20130e56ab

### What platforms do you use to access UI ?

Windows

### What browsers do you use to access the UI ?

Google Chrome

### Command Line Arguments

_No response_

### Additional information, context and logs

_No response_
Repository: godot
Issue: SceneTreeTween created within IF block fails to show context helpers
Labels: bug,topic:gdscript,topic:editor,needs testing

### Godot version

3.5.1 stable

### System information

Linux

### Issue description

There is a bug I believe (but can't remember) that is now fixed to do with variables not appearing in debug window when declared inside a conditional branch. This is not that bug but I believe it is related. HOWEVER, it only seems to manifest itself with SceneTreeTween node.

In the image below typing '.' either fails to show anything or shows below image with incorrect data. If the variables is created outside the if statement or is explicitly type hinted then it works.

![image](https://user-images.githubusercontent.com/12863685/212483274-e8e3a25a-a1f1-43af-b473-15639352940d.png)

If you create any other type, e.g.
![image](https://user-images.githubusercontent.com/12863685/212483466-32abe0ba-1cea-4bdd-beb5-2e7c7d0ff38e.png)

Then everything is ok, so lends me to believe there is some kind of explicit hard-coding/editor massaging of SceneTreeTween going on.

### Steps to reproduce

code is as simple as above

### Minimal reproduction project

not really needed, it's 2 lines of code.
Repository: godot
Issue: Turning on doubles via `scons precision=double` will change the docs
Labels: bug,topic:core

### Godot version

https://github.com/godotengine/godot/commit/60d031777b2a922cba03210181c9ba7ad3a6f3ab

### System information

Windows 11, Nvidia 3000

### Issue description

Turning on doubles will change the doctool behaviour.

Problems:

1. The API should not change. Means you can't use the same API dump for multiple targets
1. Add a CI check for this, we already need to compile twice



### Steps to reproduce

1. build godot with `scons precsion=double`
2. run godot with --doctool
3. check git diff

### Minimal reproduction project

N/A
Repository: deno
Issue: could not resolve npm package
Labels: bug,node compat

```
> import * as pl from "npm:@pola-rs/browser"

✅ Granted env access to "NODE_CLUSTER_SCHED_POLICY".
✅ Granted env access to "NODE_UNIQUE_ID".
Uncaught TypeError: Could not resolve 'npm:@pola-rs/browser'.
  Caused by:
    not found
    at async <anonymous>:2:12
   ```

but it seems to exist https://www.npmjs.com/package/@pola-rs/browser?activeTab=readme
Repository: tauri
Issue: [feat] Replace `bundleIdentifier` with more correct `Qualifier`, `Organization`, and `ProductName` settings.
Labels: type: feature request

### Describe the problem

Tauri currently uses the `bundleIdentifier` as the base for a number of APIs, this however turns out to be a bad abstraction:
1. It's very low-level and not-self-explanatory at all (we get the question quite often "what do I choose as the bundleIdentifier?").
2. We use it wrong. Especially on Windows the reverse domain notation is actually not as common.
     E.g. our current `app_data_dir` is this `{FOLDERID_RoamingAppData}\{bundleIdentifier}` while it *should be* `{FOLDERID_RoamingAppData}\{Organization}\{ProductName}\data` => `C:\Users\Alice\AppData\Roaming\com.foo.bar` VS. `C:\Users\Alice\AppData\Roaming\Foo Corp\Bar App\data` (Incidentally the proper file path also looks much nicer visually)

### Describe the solution you'd like

Deprecate the `tauri > bundle > identifier` field in `tauri.conf.json` and replace it with the following fields:
- `package > productName` (already exists)
- `package > organization` (e.g. `Foo Corp` or `Tauri`)
- `package > qualifier` (e.g. `com`, `io`, or `co.uk`)

So that the `bundleIdentifier` can be constructed like this:
```rust
    let qualifier = config.package.qualifier; // qualifier must be lowercase and not contain any whitespace
    
    let organization = config
        .package
        .organization
        .to_lowercase() // `organization` may be capitalized
        .replace(char::is_whitespace, "-"); // and contain whitespace
        
    let product_name = config
        .package
        .product_name
        .to_lowercase() // `productName` may be capitalized
        .replace(char::is_whitespace, "-"); // and contain whitespace

    let bundle_identifier = format!("{qualifier}.{organization}.{product_name}");
```

### Alternatives considered

_No response_

### Additional context

This came up while porting the `tauri::api::path` module from the long unmaintained `dirs_next` crate to the better `directories` crate [which enforces proper app-scoped paths](https://docs.rs/directories/4.0.1/directories/struct.ProjectDirs.html) see the corresponding issue for details: #6063
Repository: stable-diffusion-webui
Issue: Organize install instructions
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Currently install instructions in this project are a mess. They are spread across multiple pages of various level of duplication, clutter and accessibility.

There is instruction in README, with Apple and colab options omitted:

https://github.com/AUTOMATIC1111/stable-diffusion-webui#installation-and-running

There is Dependencies page on wiki, which only lists instructions for Linux and suggests that you need a SD checkpoint (which is wrong, any model checkpoint will do):

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Dependencies

In wiki, there are instructions for linux, for some reason grouped by videocard, although it seems like the only difference between AMD and NVidia installation is having to install one driver:

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Install-and-Run-on-NVidia-GPUs
https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Install-and-Run-on-AMD-GPUs

Docker instruction is on AMD page for some reason:

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Install-and-Run-on-AMD-GPUs#running-inside-docker

Apple instruction is bloated and asks for confirmation, although Apple users already confirmed that it works. Also, it has a section redundant with dependencies page:

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Installation-on-Apple-Silicon

The online services, despite colab being the most popular way to run stable-diffusion-webui, are just a bunch of links:

https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Online-Services

I think it would be less confusing if installation information was all in one place (either README or wiki), and new users would benefit if it was rewritten in more concise way.

### Proposed workflow

I tried rewriting instructions myself, but I don't understand what's the deal with AMD cards, haven't used Windows in a decade and haven't used Apple ever, and I don't know whether it is acceptable to suggest using other models. 

### Additional information

Related issues:

[Wiki localization](https://github.com/AUTOMATIC1111/stable-diffusion-webui/issues/5931) - bloated installation instructions might mess up translations
Repository: deno
Issue: tlsHandshakeFailure is flaky
Labels: flaky

```
error: Test failed

tlsHandshakeFailure => ./cli/tests/unit/tls_test.ts:1321:6
error: AssertionError: Expected error to be instance of "InvalidData", but was "ConnectionReset".
    throw new AssertionError(msg);
          ^
    at assertIsError (file:///Users/runner/work/deno/deno/test_util/std/testing/asserts.ts:625:11)
    at assertRejects (file:///Users/runner/work/deno/deno/test_util/std/testing/asserts.ts:880:7)
    at async server (file:///Users/runner/work/deno/deno/cli/tests/unit/tls_test.ts:1337:11)
    at async Promise.all (index 0)
    at async tlsHandshakeFailure (file:///Users/runner/work/deno/deno/cli/tests/unit/tls_test.ts:1376:5)
```

https://github.com/denoland/deno/actions/runs/3918630641/jobs/6699130029
Repository: godot
Issue: Godot failing when out of VRAM
Labels: bug,topic:rendering,needs testing

### Godot version

Godot beta 12

### System information

Windows 10, AMD Radeon RX 480 4 GB RAM, 16 gb ram, Intel CPU 4 cores.

### Issue description

Im Trying to test the Game Liblast (link: https://codeberg.org/Liblast/Liblast), but when i start (play button) i see a black window and the console is spamming.

an attachment of the godot log:

[godot.log](https://github.com/godotengine/godot/files/10418609/godot.log)

Made a video: https://youtu.be/L1Mxvm47xss

### Steps to reproduce

Just press the play button

### Minimal reproduction project

Sorry no minimal.
link again: https://codeberg.org/Liblast/Liblast
Repository: vscode
Issue: Git - `Add to .gitignore` on folder is confused
Labels: feature-request,git

click `Add to .gitignore` on folder is confused what will happen, should split two menu items:

- `Add folder to .gitignore`
- `Add files to .gitignore`


<img width="1440" alt="image" src="https://user-images.githubusercontent.com/41773861/212492083-4fe4b697-c73d-4aa3-a779-af47d45c67d0.png">
Repository: godot
Issue: Looking through fog volumes shows scene depth undesirably
Labels: discussion,topic:rendering,topic:3d

### Godot version

v4.0.beta12.official [3c9bf4bc2]

### System information

Vulkan Forward+

### Issue description

The issue is somewhat difficult to explain for me, please understand.

When one looks at a scene from behind or within a fog volume (or a light contributing to the volumetric fog), the scene depth can be seen, in this case being very much an undesired effect, letting the player see further than intended.

I made a simple scene to demonstrate the issue, and recreated it in Blender to show how i intended it to look like.

With the volumetric fog Godot produces, you can clearly see the contours of the structure and the edge of the plane it's sitting on, despite the light not reaching that far and there being no other lights in the scene, apart from the red one on top of the structure.
![image](https://user-images.githubusercontent.com/98223724/212491513-6c8b6628-b80d-4536-a35b-d92cc22c96b0.png)

With the result i made in Blender, you cannot see the world border and the structure contours (the red light exists to show that it is still there). Please know that Blender was only used here to show how i intended the fog to look like, and not to compare the rendering of the two softwares.
![image](https://user-images.githubusercontent.com/98223724/212491699-44c72105-48bd-4906-b5e9-5077c93e0a0d.png)

Please, let me know if this is a rendering limitation that cannot/won't be fixed.

### Steps to reproduce

In the scene showed in the example the `world environment` has its `background mode` set to `Custom Color`, with the `Color` being the default pure black, and `volumetric fog` being turned on in it's default settings.

Both lights have their `volumetric fog energy` set to 16, but the issue isn't dependent on it.

### Minimal reproduction project
An even simpler scene demonstrating the issue, just make sure to disable preview sunlight.
[scene.zip](https://github.com/godotengine/godot/files/10419107/scene.zip)
Repository: rust
Issue: some issues types can no longer be previewed, impossible to add notes before/after mandatory fields
Labels: A-meta

cc https://github.com/rust-lang/rust/pull/106831 @estebank 

It looks like yaml templates no longer allow for a "preview" to make sure the issue actually looks nice.
Also there is no way to actually insert text before any of the fields (for diagnostics issues for example) such as "this code is from repo xy file foo.rs" or something like. You have to first post the entire ticket to then  `modify` the generated markdown which is an unpleasant sensation in the rear...