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

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(integer_sign_cast)]`

This is a tracking issue for explicit signedness casting methods for integer primitive types. Libs discussion: https://github.com/rust-lang/libs-team/issues/359.

### Public API

(for `N` in [`8`, `16`, `32`, `64`, `128`, `size`]):
```rust
impl uN {
    pub const fn cast_signed(self) -> iN {}
}

impl iN {
    pub const fn cast_unsigned(self) -> uN {}
}

```

### Steps / History

- [x] Implementation: #125884 
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

Mostly bikeshedding regarding naming, as mentioned in the Libs discussion. The current proposal follows the naming of `cast_const` and `cast_mut` for pointers.

Alternatively, these could be implemented as `from_bits` and `to_bits` methods for the signed types.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: godot
Issue: Spurious "BUG: Unreferenced static string to 0"- errors when generating script tests
Labels: bug,topic:gdscript,topic:tests

### Tested versions

The issue occurs on commit 705b7a0b0bd535c95e4e8fb439f3d84b3fb4f427 of master when compiled with `gcc (Ubuntu 13.2.0-4ubuntu3)`. The issue is related to static destruction timing, which is undefined behaviour and therefore the compiler may do different things in different builds with no reason whatsoever, but in practice the results tend to be consistent for the same compiler version and inputs.

Tested also with `Ubuntu clang version 16.0.6 (15)`. Happens with it also.

### System information

Ubuntu 23.10

### Issue description

When generating the gdscript tests, the output always contains many errors like: `ERROR: BUG: Unreferenced static string to 0:`.

I looked into the matter and this is caused by the combination of two factors:
1) The script test generation logic calls `exit` instead of returning normally (`GDScriptTestRunner::handle_cmdline`).
2) Some singletons stored in static variables contain dynamic StringNames that use the cow data from static StringNames.

The order in which static variables are cleaned up is not guaranteed. What happens is that the static variable StringName (created with the `SNAME` macro from string_name.h) happens to be destroyed before the static variable that holds the relevant singleton. This causes the dynamic StringName in the singleton to be the last holder of the cow block. But the cow block knows it was static, so it produces this error when it it released by a dynamic StringName.

In normal execution the singletons are cleaned up by `Main::cleanup`, but the `exit` in `GDScriptTestRunner::handle_cmdline` avoids that. Since the static destruction order is undefined, you may by chance not get these errors with some compiler versions and inputs.

The impact of this bug is mostly confusion for developers, it shouldn't affect end users. But a search for `BUG: Unreferenced static string to 0` in the issue database shows some cases where users have encountered the message in more normal use case's outputs. If the logic for the warning could be made more accurate, it would not confuse in cases where it's not actually relevant.

### Steps to reproduce

1. Compile godot `scons tests=yes dev_build=yes`
2. In accordance with [the documentation](https://docs.godotengine.org/en/stable/contributing/development/core_and_modules/unit_testing.html#integration-tests-for-gdscript), run ` bin/godot.linuxbsd.editor.dev.x86_64 --gdscript-generate-tests modules/gdscript/tests/scripts`

### Minimal reproduction project (MRP)

No project required, this is related to running unit tests of Godot itself.
Repository: electron
Issue: [Feature Request]: addChildView option to stop the added view grabbing focus
Labels: enhancement :sparkles:

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

Whenever addChildView is called to add a WebContentsView to an existing BaseWindow, the webcontents will always grab the focus from whichever has it currently.  It would be very useful to have an option to add the child view without losing focus from the current web contents.

Example: I have a child view with an input box which, as you type, creates another child view showing related contents.  After the child view is created and addChildView called, the focus switches to the new child view and you can't continue typing into the original input box.

### Proposed Solution

Change addChildView from addChildView(view, [index]) to addChildView(view, [options])  where 
```
options = { 
  index?:number,   // Default is the end of the list
  focus?:boolean   // Default is true
}
```
For backwards compatibility, check if options is a number and behave as it does currently.  

### Alternatives Considered

I've tried a number of alternatives, such as setting the parent BaseWindow with setFocusable(false) before adding the child view but this move other windows above the current and also loses focus.

### Additional Information

_No response_
Repository: tauri
Issue: [feat] scope for asset protocol `convertFileSrc()`
Labels: type: feature request

### Describe the problem

I need to have different permission scopes for `convertFileSrc` for different windows.
It seems like `convertFileSrc` doesn't support scopes like the file system plugin in Tauri v2.

### Describe the solution you'd like

Have a scope capability setting like the fs plugin.

### Alternatives considered

_No response_

### Additional context

_No response_
Repository: godot
Issue: When instancing nodes in runtime, nodes with unique names on @onready are null.
Labels: discussion,topic:core,topic:gdscript,needs testing

### Tested versions

Reproducible on 4.2.2-stable.

### System information

Windows 11. Godot 4.2.2-stable

### Issue description

If you instance a node in runtime that references an unique named node on `@onready`, the unique named node is always null.

### Steps to reproduce

1. Create a scene Spawner with a script that instantiate SpawnedNode during runtime and add it to the tree as a child.
2. Add a node as a child of Spawner. Right click and select "% Access as Unique Name".
3. In the SpawnedNode's script, add the standard `@onready` for the unique named node.
4. Run the game.

### Minimal reproduction project (MRP)

[UniqueNameBugMRP.zip](https://github.com/user-attachments/files/15524977/UniqueNameBugMRP.zip)
Repository: godot
Issue: Light2D's Mix blend mode with shadows leaves black lines in occluded room with more lights
Labels: bug,topic:rendering,topic:2d

### Tested versions

- Reproducible in: v4.2.2.stable.mono.official [15073afe3], v4.3.beta1.official [a4f2ea91a]

### System information

Godot v4.3.beta1 - Linux Mint 21.3 (Virginia) - X11 - Vulkan (Forward+) - dedicated AMD Radeon RX 6600 (RADV NAVI23) () - 12th Gen Intel(R) Core(TM) i5-12400F (12 Threads)

### Issue description

When putting a lot of PointLight2Ds in an occluded room, with walls in the middle, choosing Mix blend mode, and enabling shadows for occluder to work, zooming in shows weird black lines:
![image](https://github.com/godotengine/godot/assets/32240709/f459eb5e-a9f2-4d40-b1cc-f0d1b02773c7)

Changing their shadow filter from none to average shows the artifacts more clearly:
![image](https://github.com/godotengine/godot/assets/32240709/d7e1c299-fad6-4ba0-b665-13f978b8f775)

Changing shadow filter smooth doesn't help...
![image](https://github.com/godotengine/godot/assets/32240709/e3d5f1cc-fd3c-4fc8-ae1f-dd0b3cc3c5e0)

Changing shadow filter color from "black" transparent to "white" transparent seems to ease the effect..
However you can still see the lines there:
![image](https://github.com/godotengine/godot/assets/32240709/5fc6f0d3-147b-4b71-9ac3-4e5838046cbf)

Change shadow filter to average from none and you'll see clearly that the artifacts are still there:
![image](https://github.com/godotengine/godot/assets/32240709/ee0db57a-a817-437f-a639-fa6998ba0f8c)



### Steps to reproduce

Place a lot of PointLight2Ds with Radial texture, Blend mode set to `Mix` and Shadow enabled in an encapsulated room with occluded walls, and two pillars on the center.

...or download already prepared Minimal reproduction project

### Minimal reproduction project (MRP)

[LightShadowIssue2D.zip](https://github.com/user-attachments/files/15524978/LightShadowIssue2D.zip)
Repository: vscode
Issue: `explorer.excludeGitIgnore` should also exclude files listed in `.git/info/exclude`
Labels: feature-request,file-explorer

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Not sure whether to classify this as a feature or a bug. It is probably an oversight. To me, excluding files listed in `.git/info/exclude` would make just as much sense as excluding files listed in `.gitignore`'s.
Repository: godot
Issue: Wrong error line indicator position of Static typed for loop
Labels: bug,topic:gdscript

### Tested versions

- Reproducible in 4.3 Beta 1

### System information

Win11  4.3 Beta 1 win64

### Issue description

<sub>(this is originally written as GIP [here](https://github.com/godotengine/godot-proposals/issues/9869) as I was unsure if such behavior is intentional or not)</sub>

Assignment error for typed `for` loop marks error indicator at end of loop which could cause confusion.

![image](https://github.com/godotengine/godot-proposals/assets/26041217/614d4bb7-33cd-42e0-80a8-b3f6e1fec417)

For given MRE this is not an issue, but if the last line of the loop was assignment operations of ***Similar Types*** - then error message alone won't be helpful, and user might spend minutes or hours to debug nonexistence bug or file wrong bug report to godot repo, consuming already busy dev's time further.

Best example for this is when fixing the breaking changes happened during upgrade of 4.2 to 4.3.

![image](https://github.com/godotengine/godot-proposals/assets/26041217/0ecaeaac-e0ed-4202-8ca7-48e10cc321eb)  
<sup>^ godot 4.3 beta 1 win64</sup>

Godot 4.3 introduced `PhysicsBoneSimulator3D` node, and it's now being *Sliently* added to `Skeleton3D` *Only In Remote*, not in local.

Therefore, if there's pre-4.3 codes that iterate thru bones and fetch meshs from it - it will break the code, and show error on unhelpful position and user will have no idea what happened.

Even more, if the last line of the for-loop is also confusing enough - it won't be easy day for that user finding that until navigating the long trees in remote to find what is going on.

### Steps to reproduce

write a `for` loop that triggers assignment error by giving it wrong type node/element for corresponding iterator.

### Minimal reproduction project (MRP)

MRE: [for_loop_test.zip](https://github.com/user-attachments/files/15524966/for_loop_test.zip)
Repository: godot
Issue: Save and Exit not working if Settings in Editor Behaviour changed.
Labels: bug,topic:editor

### Tested versions

- 4.2 and latest git version 4.3 dev ...

### System information

Windows 11

### Issue description

If Godot editor are changed (tested on enable/disable toggles on Text Editor -> Behaviour settings), closing Godot using X on Windows does not save the changes made to script files.

### Steps to reproduce

1) Open a project in Godot, and create a script (or open an existing script)
2) Open Editor Settings and change a Text Editor Behaviour setting. e.g.,

![image](https://github.com/godotengine/godot/assets/231068/f889ec59-e67d-431e-b452-c791868b340e)

2) Change the script and wait until (*) is visible
3) Close Godot using X on top-right without saving the file
4) Click on save & quit option

You can notice that the asterisk does not disappear.

5) Reopen the project and the script.

This is not an issue, if no settings are changed and if you perform 2 3 4. It does save the file...

I also tested with other togglable settings (not only Text Editor Behaviour) and it is reproducible.

### Minimal reproduction project (MRP)

Project is created with v4.2, but reusable in 4.3 to reproduce the bug.

[TestBug.zip](https://github.com/user-attachments/files/15525117/TestBug.zip)
Repository: godot
Issue: `AnimationPlayer` preview in editor conflicts with ability to set the default `texture` for `Sprite3D`
Labels: bug,topic:editor,topic:animation,topic:3d

### Tested versions

- tested in Godot Engine v4.3.dev6.mono.official.89850d553

### System information

Vulkan 1.3.260 - Forward+ - Using Device #0: NVIDIA - NVIDIA GeForce RTX 3070 Laptop GPU

### Issue description

When looking at my Sprite 3D in the editor, the `texture` property is overwritten by the `AnimationPlayer`'s modification of that `texture` property, leaving me unable to set/view the default texture unless I look in the `.tscn` file and find that property.

<img width="1280" alt="Screenshot 2024-06-02 144032" src="https://github.com/godotengine/godot/assets/30541183/8eaaf199-a3a5-45ad-b399-0f7de5220f1f">

In the image, the editor shows my `texture` as "dead.png`, but this is not my default texture, and I have no way of finding out what the default is.


### Steps to reproduce

- Create a `Character3D` node
- Add a `Sprite3D` node and set a `texture`
- Add an `AnimationPlayer` node and animation the `texture` property of the `Sprite3D` node
- play the animation and observe how it takes over the `texture` property

### Minimal reproduction project (MRP)

[mrp.zip](https://github.com/user-attachments/files/15525332/mrp.zip)
Repository: godot
Issue: Frame rate halved when VSYNC is turned off during runtime and Nvidia low latency mode is ultra.
Labels: bug,platform:windows,topic:rendering,topic:porting,topic:thirdparty,needs testing

### Tested versions

- 4.3 beta 1, noticed in earlier versions.

### System information

Godot v4.3.beta1 - Windows 10.0.22631 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 6GB (NVIDIA; 32.0.15.5585) - Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (8 Threads)

### Issue description

The framerate gets halved (360 to 180fps in my tests) when disabling VSYNC during runtime and while low latency mode is set to ultra in the nvidia configuration panel. This can result in situations where the fps is drasticly lower when disabling VSYNC. 

For example: Videocard is capable of 160 fps. vsynced to 144fps. disabling vsync during runtime results in 80 fps. 

### Steps to reproduce

1. Set "low latency mode" to "ultra" in the Nvidia configuration panel. 
2. Run any 3D project with VSYNC turned OFF in the project settings. (NOT from code)
3. Note the framerate
4. Run turn VSYNC on and off again from code. 
5. Note the framerate
6. The framerate from step 3 is twice as high as the framerate from step 5.

### Minimal reproduction project (MRP)

[VSYNC.zip](https://github.com/user-attachments/files/15525548/VSYNC.zip)
Note the framerate from initial load and after switching vsync on and off again with the toggle. 
Reminder to set low latency mode to ultra.
Repository: rust
Issue: Support for 'split-debuginfo' on wasm targets
Labels: T-compiler,O-wasm,C-feature-request

According to the documentation at [Rust Compiler Codegen Options](https://doc.rust-lang.org/rustc/codegen-options/index.html#split-debuginfo), setting split-debuginfo = "packed" should result in the generation of dwp files.

However, when building for wasm32-unknown-unknown and wasm32-wasip1, I was unable to obtain dwp files. In contrast, dwp files were successfully generated when building for x86_64-linux-unknown-gnu.

I hope that 'split-debuginfo' will be properly supported for wasm targets as well.
Repository: rust
Issue: compiletest: more consistent handling of bool-like env vars
Labels: C-cleanup,C-enhancement,T-bootstrap,E-medium,A-compiletest

Noticed in https://github.com/rust-lang/rust/pull/125890#issuecomment-2143875898.

It would be nice to have more consistent handling of what is considered "truthy" or "falsey" for env vars that accept a bool-ish value. In particular, if an env var's value contains invalid UTF-8, we probably should straight up error instead of silently parsing it as truthy/falsey?
Repository: godot
Issue: Exported packed arrays with default values reset with every script change
Labels: bug,topic:editor

### Tested versions

Reproducible in 4.3.beta1

### System information

Godot v4.3.beta1 - Windows 10.0.22631 - GLES3 (Compatibility) - NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 31.0.15.5212) - Intel(R) Core(TM) i7-10700F CPU @ 2.90GHz (16 Threads)

### Issue description

When you export a packed array property with a default value in a script (Node or Resource, doesn't matter), then any time you make any changes to the script, _even if you don't save the changes_, it silently and permanently wipes that value on everything in the project with that script.
![ArrayReset](https://github.com/godotengine/godot/assets/13228932/b577688e-ad44-4cfe-b233-802617f5cf66)

Note that this happens _whether or not you are currently inspecting_ a Node or Resource with that script attached. Its effect is instant, and project-wide.
![ArrayReset2](https://github.com/godotengine/godot/assets/13228932/ed07387d-db2e-4f74-90be-a106b1e152fc)

Notes:
- This doesn't happen with regular arrays, only packed arrays of all types.
- This doesn't happen if a default value is not provided for the property.
- This also happens if you don't make *any* changes to the script, but rather just save the script twice in a row.
- It can also happen sometimes as soon as you save the resource you're editing, without touching the script at all.

### Steps to reproduce

- Open the attached project.
- Open `test.tscn` and inspect the root object.
- Change the array's values to something other than default.
- Open up `test.gd` and add a newline at the end. No need to hit save.
- Observe that the array's values in the inspector have reverted to `[0, 0, 0]`.

### Minimal reproduction project (MRP)

[bug-report.zip](https://github.com/user-attachments/files/15525705/bug-report.zip)
Repository: flutter
Issue: Add easy way to change app-wide font family for `CupertinoApp`
Labels: c: new feature,framework,f: cupertino,c: proposal,P2,team-design,triaged-design

### Use case

I want to switch a Cupertino app's global font family (akin to `MaterialApp(theme: ThemeData(fontFamily: 'Foo'), ...)` for material apps), but I couldn't found an easy way to do so. This is because `CupertinoTextThemeData` has multiple, separate text styles, each of which specify a font family separately from the other text styles. After digging around in Flutter's code looking for a solution, I decided to copy the default values of `CupertinoTextThemeData`'s text styles, paste them into my code, and change just the font family, like so:
```dart
CupertinoApp(textTheme: CupertinoTextThemeData(
  textStyle: TextStyle(
    inherit: false,
    fontFamily: 'Foo',
    fontSize: 17.0,
    letterSpacing: -0.41,
    color: CupertinoColors.label,
    decoration: TextDecoration.none,
  ),
  // Do the same for the rest of the parameters
))
```

Obviously this isn't ideal though.

### Proposal

Add a simple `fontFamily` (and `fontFamilyFallback` too? `ThemeData` has that as well) parameter to `CupertinoTextThemeData` that, if provided, overrides all the font families of the global Cupertino text styles.
Repository: ollama
Issue: Error: invalid file magic for IQ2_M.gguf based models
Labels: model request

https://huggingface.co/bartowski/Codestral-22B-v0.1-GGUF
 
From this hugging face repo i downloaded - Codestral-22B-v0.1-IQ2_M.gguf  this model , But when i tried to build with ollama it give me  Error: invalid file magic . I did research in ollama issues and many IQ models support were added thanks to devs but this IQ2_M support i couldnt see so creating this issue here so that support for this type of model can be added to ollama so that many more can test type of quantized model.
This variant is much better than some supported ones by ollama  like IQ2_XS so addition of this variant will help them in choosing better too in my opinion saying on basis of this data :
https://gist.github.com/Artefact2/b5f810600771265fc1e39442288e8ec9

Thankyou very much for this awesome project devs :-))
Repository: godot
Issue: `Area2D` detects a `CollisionObject2D` again if the latter is already in the area, when the `shape` or `disabled` of the latter's `CollisionShape2D` gets changed
Labels: discussion,confirmed,topic:physics

### Tested versions

Reproducable in all 4.x versions.

### System information

Windows 11, GLES3, x86_64, AMD APU A4-7210 with AMD R3 Graphics and AMD R5 M330

### Issue description

I'm not sure if this should be a proposal or a bug report, but the issue does confused a lot of people.

When a `CollisionShape2D` of a `CollisionObject2D` gets its `shape` changed, or when two or more `CollisionShape2D`s in one `CollisionObject2D` gets their `disabled` changed, switched, or swapped (like one's `disabled` becoming `false` while the other one's becoming `true`), if the `CollisionObject2D` is already in an `Area2D`, the `Area2D` will emit first `body_exit`/`area_exit` and then `body_entered`/`area_entered`, which seems to mean that the `Area2D` regard this object as re-entering the area...

While the expected behavior should be that when such changes happen, the `Area2D` should not regard this object as immediately exiting and entering the area. Instead, in my point of view, `Area2D` should examine whether the corresponding signal should be emitted after these changes are done.

### Steps to reproduce

1. Create an `Area2D` and any `CollisionObject2D`
2. Create a `CollisionShape2D` for the latter
3. Connects the `*_entered` and `*_exited` signal(s) to a `print()` method, while when the `*_exited` signal is connected to `print()`, an additional `"exited"` should be bound to the callable
4. Script to make the collision shape's `shape` changed after 2 seconds, and run the scene to see the result in output. Finishing the runtime, clear the script.
5. Add another `CollisionShape2D`. This time, script to switch/swap their `disabled` after 2 seconds, and run the scene to see the result in output

### Minimal reproduction project (MRP)

https://1drv.ms/u/c/d100bbc430894770/EVCKFFbQhVpLqwAAqBukBJQB89tdghmzOQitbtWDOnNRpQ?e=vnFbr8