sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: SubViewport displays none of its children objects in the 3D window of the editor if it has own_world_3d or world_3d set  
Labels: needs testing,topic:gui

### Godot version

4.0-beta1_mono_win64

### System information

Windows 10

### Issue description

SubViewport displays none of its children objects in the 3D window of the editor if it has own_world_3d or world_3d set.

We can see what's rendered in the SubViewportContainer though.

Setting its own world to a SubViewport is important because otherwise its content gets displayed on any other scenes on the 3D window, and displays other scenes that are opened in its render whenever I use it as an editor plugin dock slot. Not sure if it's normal too.



### Steps to reproduce

Create a control scene

Add a subviewport as child

Create anything as child of subviewport

Go in on the 3D window and assure what you just created is visible

tick own_world_3d or set world_3d of subviewport

whatever was visible before is now not rendered on the 3D window

### Minimal reproduction project
[BugSubViewport.zip](https://github.com/godotengine/godot/files/9639025/BugSubViewport.zip)
Repository: godot
Issue: Godot 4.0 beta1 crashes when I click on "close scene" button
Labels: bug,topic:editor,needs testing,crash

### Godot version

Godot 4.0 beta1

### System information

MacBook Pro m1, Big sur 11.7, gles3

### Issue description

It happens randomly in different projects when clicking on the "close scene" button.
<img width="151" alt="Screenshot 2022-09-24 at 14 17 27" src="https://user-images.githubusercontent.com/109857267/192095279-e7952a12-1330-4db1-bd41-df3393d2e27c.png">

I have been able to catch the bug in the terminal:

```
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.0.beta1.official (20d6672846b3fd1537603ac080116dcc914c10e3)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] 1   libsystem_platform.dylib            0x0000000196e76c44 _sigtramp + 56
[2] 2   ???                                 0xffff800196deabd0 0x0 + 18446603343047338960
[3] 3   libc++abi.dylib                     0x0000000196deabd0 __dynamic_cast + 172
[4] EditorPlugin* EditorPlugins::creator<GridMapEditorPlugin>()
[5] ScriptInstanceExtension::_add_property_with_state(void*, void*, void*)
[6] ScriptInstanceExtension::_add_property_with_state(void*, void*, void*)
[7] Node::is_inside_tree() const
[8] RendererCompositorRD::_create_current()
[9] 9   godot                               0x000000010063fbe0 godot + 3914720
[10] RendererCompositorRD::_create_current()
[11] 11  libdyld.dylib                       0x0000000196e49430 start + 4
-- END OF BACKTRACE --
================================================================
```

### Steps to reproduce

It happens randomly once in a few days, so I can not provide instruction to reproduce.

### Minimal reproduction project

_No response_
Repository: godot
Issue: .gd always unlisted from Favorites in FireSystem dock when create and save a new file
Labels: bug,topic:editor

### Godot version

v3.5.stable.official [991bb6ac7]

### System information

Windows 10

### Issue description

After you pin .gd file to Favorites in FireSystem dock. It will be unlisted from Favorites when create and save a new file in Godot.

![godot-fav-bug](https://user-images.githubusercontent.com/90498285/192096236-e655f69f-4703-4a58-a49a-fdc8d2f3a6aa.png)


### Steps to reproduce

step to reproduce bug
1. create .gd file and add to Favorites in FileSystem dock
2. make new empty Node  and save to .tscn.
3. That's it! gd file will unlisted from Favorites in FileSystem dock

### Minimal reproduction project

[godot_fav_bug.zip](https://github.com/godotengine/godot/files/9638616/godot_fav_bug.zip)
Repository: neovim
Issue: vim.diff: can't skip hunk in `on_hunk` callback
Labels: bug,diff

### Neovim version (nvim -v)

NVIM v0.8.0-dev-1152-g14610332b 

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Linux Mint 20.2

### Terminal name/version

Kitty 0.15

### $TERM environment variable

xterm-kitty

### Installation

appimage

### How to reproduce the issue

1. `nvim --clean repro.lua`
2. Paste the following Lua code:
```lua
local a = "a\n"
local b = "b\n"

vim.diff(a, b, {
  on_hunk = function(_, _, _, _)
    return -1
  end,
  result_type = "indices",
})
```
3. `:so %`

### Expected behavior

No error as I'm just trying to skip a hunk. This is what it says in the docs:
```
• `on_hunk` (callback):
  Invoked for each hunk in the diff. Return a
  negative number to cancel the callback for any
  remaining hunks.
```

### Actual behavior

```
Error detected while processing /home/user/test.lua:                                                                                                                                                                                   
E5113: Error while calling lua chunk: /home/user/test.lua:4: Error while performing diff operation                                                                                                                                     
stack traceback:                                                                                                                                                                                                                        
        [C]: in function 'diff'                                                                                                                                                                                                         
        /home/user/test.lua:4: in main chunk 
```
Repository: godot
Issue: Warnings use wrong character variants when `code_font_custom_opentype_features` are used
Labels: bug,topic:editor

### Godot version

v4.0.beta1.official [20d667284]

### System information

Windows 10, Vulkan, Nvidia 1050TI

### Issue description

Warning/Error descriptions in the text editor do not respect character variants (Font: [Firacode](https://github.com/tonsky/FiraCode) Variant: `&` (ss03)):

![image](https://user-images.githubusercontent.com/40064911/192098621-da65f394-e8e4-468f-a02f-8878a684b535.png)

Not really a bug-bug, but it'd definitely be better if the descriptions matched the written code.

### Steps to reproduce

1. Get a font that has a character variants(example: [Firacode](https://github.com/tonsky/FiraCode))
2. Set the font as `interface/editor/code_font` 
3. Enable and use the character variant (example Firacode: `ss03`):

![image](https://user-images.githubusercontent.com/40064911/192098313-f16aa3d3-e492-42ab-8c13-484988a98c5c.png)

### Minimal reproduction project

_No response_
Repository: neovim
Issue: `nvim_set_hl` is missing the `!` behavior of `hi! def link`
Labels: enhancement,api,highlight

### Neovim version (nvim -v)

NVIM v0.7.2

### Vim (not Nvim) behaves the same?

no

### Operating system/version

Arch Linux on Windows 10 x86_64

### Terminal name/version

windows terminal

### $TERM environment variable

xterm-256color

### Installation

system package manager : pacman

### How to reproduce the issue

### 1. 
nvim --clean debug.vim

debug.vim:

```vim
" This is a vim comment.
```
### 2. For `hi! def link`

```vim
:hi vimComment
vimComment     xxx links to Comment

:hi! def link vimComment Boolean

:hi vimComment
vimComment     xxx links to Boolean
```

### 3. For `nvim_set_hl`

```vim
:hi vimComment
vimComment     xxx links to Comment

:call nvim_set_hl(0, 'vimComment', {'link':'Boolean','default':1})

:hi vimComment
vimComment     xxx links to Comment
```

### Expected behavior

Expected an options to make `nvim_set_hl` behave the same as `hi! def link`.

### Actual behavior

If `vimComment` already has highlight, `:hi! def link vimComment Boolean` would override the origin highlight, but `:call nvim_set_hl(0, 'vimComment', {'link':'Boolean','default':1})` can't override it.
Repository: godot
Issue: Can't open the project settings panel in the editor 
Labels: bug,platform:windows,topic:editor,needs testing

### Godot version

4.0.beta (latest, commit: #f74491f)

### System information

Windows 11

### Issue description

I can't open the editor anymore since I got into windows 11. If I try to, the editor just freezes.
Also, all of my autoloads seem to be unregistered. 

### Steps to reproduce

Just try to open the Project Settings from windows 11

### Minimal reproduction project

_No response_
Repository: rust
Issue: `#[must_use]` on traits should apply to all types that implement the trait, not just for `impl Trait` placeholders
Labels: A-lints,A-diagnostics,T-lang,T-compiler

# General issue

Currently, `#[must_use]` on a trait `Foo` does not extend to types that implement `Foo`, it only works on `impl Foo` return types, and `Box<dyn Foo>` as a [special case](https://github.com/rust-lang/rust/pull/62228):

```rust
#[must_use]
trait Foo {}

struct Bar;
impl Foo for Bar {}

fn build_foo() -> impl Foo { Bar }

fn build_box() -> Box<dyn Foo> { Box::new(Bar) }

fn build_bar() -> Bar { Bar }

fn main() {
    build_foo(); // warning: unused implementer of `Foo` that must be used
    build_box(); // warning: unused boxed `Foo` trait object that must be used
    build_bar(); // no warning!
}
```

[(playground)](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=e20f4a36678da8e8b02f4c7e30276199)

This does not make much sense, presumably if a trait must always be used all types that implement that trait must also be used.

# Application to `Future`

I came across this when dealing with futures. The Future trait has a `#[must_use]` annotation, with the useful reminder to `.await` or poll them:

https://github.com/rust-lang/rust/blob/b8967b0d52a2ba5f0c9da0da03e78ccba5534e4a/library/core/src/future/future.rs#L28-L37

I was specifically using specifically [`BoxFuture`](https://docs.rs/futures/latest/futures/future/type.BoxFuture.html), a type alias for `Pin<Box<dyn Future>>`. This type [implements `Future`](https://doc.rust-lang.org/beta/core/future/trait.Future.html#impl-Future-for-Pin%3CP%3E), but there is no warning message when you forget to use it. This was also the original justification in https://github.com/rust-lang/rust/issues/67387, where a very different solution is proposed (extending `must_use` to `Pin` and other wrapper types).

Another effect of this missing warning is that any struct that implements `Future` has to repeat the same `must_use` annotation. Some examples:
* [`futures::future::Ready`](https://github.com/rust-lang/futures-rs/blob/dddfc35cbde4bd35e7103f4720ebfea1e3c55913/futures-util/src/future/ready.rs#L8)
* [`tokio::time::Sleep`](https://github.com/tokio-rs/tokio/blob/ebeb78ed40027032feb77c89a1de4b58d2dcafbf/tokio/src/time/sleep.rs#L227)
* `async_std` doesn't expose any public types that implement `Future`, instead they almost always use an `impl Future` return type. There is still the internal [`WriteFmtFuture`](https://github.com/async-rs/async-std/blob/798ce31e1095af16fe760aa97e86b924324bf118/src/io/write/write_fmt.rs#L9).

If `must_use` on traits infected any type that implemented it, these duplicate annotations could be removed and there would be no risk of forgetting them for any future types.
Repository: godot
Issue: Panning/scrolling stops working in editor on high zoom | Editor view limiter issue
Labels: bug,topic:editor,topic:2d

### Godot version

v4.0.beta1.official [20d667284]

### System information

Windows 10

### Issue description

When adding a bigger object (in my case 8k image) into the editor and zooming out, I lose the ability to navigate(pan/zoom) freely in the editor with the middle mouse button. I can move up and to the left, but not down or right. Once I reach the max top left position, the editor screen is locked(becomes unmovable).

https://user-images.githubusercontent.com/11314775/192106117-b36c5c40-84fb-48b6-bad9-f55ebe61b7b1.mp4

After playing a bit, I noticed all works well as long as there are scroll bars visible. Once I zoom out, so the entire scene is visible, the scroll bars disappear, and the problem starts. If I zoom in so the scroll bars are visible again, everything works again.

With _Editor Setting -> Editor -> 2D -> Constrain Editor View_ disabled, the problem does not occur.
There must be some problem with the auto-limiter. After I scaled down the picture and cloned it several times, placing each one more to the bottom and to the right, the issue was the same, so it's not about the sprite size but something more general.

As you can see on the attached video, I've been able to pan a lot to the left and up, so probably that's the issue. Detection is skewed, stealing area from right and bottom, allowing panning more into empty left and top.



### Steps to reproduce

1. Make sure _Editor Setting -> Editor -> 2D -> Constrain Editor View_ is ENABLED
2. Place on the scene a large object(I had an 8k image), or alternatively a smaller object but put it as far in the right bottom quarter as you can.
3. While still on 100% zoom confirm you can pan over the entire image
4. zoom out until the scroll bars disappear (and a bit more just to be safe)
5. Now you should not be able to pan to the right and to the bottom
6. Pan to the left and up (you should be able to)
7. Once you reach the most top left position, you should not be able to move at all anymore.

### Minimal reproduction project

_No response_
Repository: godot
Issue: Creating new Particles2D takes a lot of time when VSync is on
Labels: discussion,topic:rendering,performance,topic:particles

### Godot version

v3.5.stable.official [991bb6ac7]

### System information

Windows 10, OpenGL ES 3.0 Renderer: GeForce GTX 1060 6GB/PCIe/SSE2

### Issue description

Creating new `Particles2D` takes whole frame's time with default settings. When VSync is turned off, creating new `Particles2D` is fast. `CPUParticles2D` creation is also slow, but for example `Sprite` creation is fast even with VSync on.

### Steps to reproduce

Create new GLES3 project, add Node2D and script:

```gdscript
extends Node2D

func _process(delta: float) -> void:
	if Input.is_action_just_pressed("ui_select"): # press space
		var t0 = Time.get_ticks_usec()
		Particles2D.new()
		var t1 = Time.get_ticks_usec()
		prints('Time used: ', (t1-t0)/1000.0, 'ms')
```

Results with different settings:

```
VSync on (60 fps):
Time used:  16.713 ms

VSync off (about 3000 fps):
Time used:  0.276 ms

VSync off and Force FPS 60:
Time used:  0.266 ms
```

### Minimal reproduction project

_No response_
Repository: electron
Issue: [Bug]: Electron 21 breaks node-api stability guarantees
Labels: discussion,bug :beetle:,component/node-integration

### 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 bug report that matches the one I want to file, without success.

### Electron Version

21

### What operating system are you using?

Ubuntu

### Operating System Version

Ubuntu 20.04

### What arch are you using?

x64

### Last Known Working Electron version

20

### Expected Behavior

The NodeJS docs, state that the Node-API is stable api, intended so that modules do not need recompiling to work with newer version of NodeJS.
While I do not see Electron being referenced on that page, as Electron wraps specific versions of NodeJS and I have not seen reference to not following that stability guarantee, I would expect that Electron would follow the same Node-API support and stability promises as the version of NodeJS being wrapped.

At the very least, the NodeJS docs should be updated to make the methods deprecated or have a compatability warning, but ideally they shouldnt be broken at all.

### Actual Behavior

In the blog post about enabling of v8 memory cages, it clearly states that "native modules which rely on this functionality in V8 will need to be refactored to continue working in Electron 20 and later.", which violates the Node-API stability.

The docs do say "This is a fairly rare use case", but out of the 5 native modules I have contributed to, all of them use this technique. So from my experience, every native nodejs module is now a liability.

https://www.npmjs.com/package/sharp is a good example of an incredibly popular library that breaks because of this


### Testcase Gist URL

_No response_

### Additional Information

I am now facing the dilemma of how to handle this breaking api issue. I could:
1) always do an extra memcpy and worsen performance unnecessarily for nodejs users
1) produce separate builds for nodejs and electron like we used to with nan

Of course, this doesnt help in cases where the module author is unaware of this electron incompatability, which I expect will be a lot of them. Without proper documentation in the node-api docs, how would they be expected to know?

I expect that this api breakage will cause users of them a lot of pain in transitioning to electron 21. This could end up with long chains of users waiting for dependencies of dependencies to update before they can update electron
Repository: godot
Issue: VCS settings menu showing up as black 
Labels: bug,topic:editor

### Godot version

4.0.beta1

### System information

Windows 10, Vulkan, GeForce GTX 1060 6GB DCH driver 511.79

### Issue description

The VCS settings menu shows up as completely black. 

There are no directly related errors in the console, except for some API version mismatches, which is expected since this plugin is using an older version of the GDExtension API.

<details>
<summary>Console logs</summary>

```
Godot Engine v4.0.beta1.official.20d667284 - https://godotengine.org
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1060

Editing project: C:/Users/Twarit/Documents/Github/godotengine/godot-git-plugin/demo

Godot Engine v4.0.beta1.official.20d667284 - https://godotengine.org
ERROR: Condition "!windows.has(p_window)" is true.
   at: window_resize (drivers/vulkan/vulkan_context.cpp:1497)
Vulkan API 1.2.0 - Using Vulkan Device #0: NVIDIA - NVIDIA GeForce GTX 1060

WARNING: Blend file import is enabled in the project settings, but no Blender path is configured in the editor settings. Blend files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:75)
WARNING: FBX file import is enabled in the project settings, but no FBX2glTF path is configured in the editor settings. FBX files will not be imported.
     at: _editor_init (modules/gltf/register_types.cpp:99)
ERROR: Cannot get class 'GitPlugin'.
   at: (core/object/class_db.cpp:325)
ERROR: Received a nullptr VCS extension instance during construction.
   at: (editor/plugins/version_control_editor_plugin.cpp:185)
ERROR: Condition "!method" is true. Returning: 0
   at: get_builtin_method_hash (core/variant/variant_call.cpp:1235)
ERROR: Error getting method plus_file, hash mismatch.
   at: gdnative_variant_get_ptr_builtin_method (core/extension/gdnative_interface.cpp:497)
```

</details>

### Steps to reproduce

1. Open the repro project
2. Click on `Project > Version Control > Version Control Settings`
3. See a blacked out window

Workaround steps:
1. After the blacked out window has appeared, go back to the editor window
2. Click on `Project > Version Control > Version Control Settings` again (it wouldn't give a visual feedback of the popup getting selected)
3. Switch to the earlier blacked out window
4. Notice that it is now showing up as expected

### Minimal reproduction project
Does appear on a fresh new project
Repository: godot
Issue: VCS settings menu project path input field offset from rest of the UI
Labels: bug,topic:editor

### Godot version

4.0.beta1

### System information

Windows 10, Vulkan, GeForce GTX 1060 6GB DCH driver 511.79

### Issue description

![image](https://user-images.githubusercontent.com/31801364/192113034-d4ea58f3-602d-4df7-8480-a193344f8a52.png)

The project path should not extend towards the left. This is a minor UI bug however.

### Steps to reproduce

1. Open `Project > Version Control > Version Control Settings`

### Minimal reproduction project

_No response_
Repository: neovim
Issue: Visual block insert – preview results
Labels: enhancement,gsoc,multicursor

### Feature already in Vim?

No

### Feature description

Since you can preview the results of `:s/` for example, I think you should also be able to preview the results of visual block inserting. Let's say we have this block of text:

```
text1
text2
text3
```

At the top left, I press <kbd>Control-V</kbd> to enter visual block mode. I go down twice and then press <kbd>Shift-I</kbd>. At this point I should be able to see three cursors in front of each line. As I type some text, I should be seeing the text on all of the lines, not just the top one. This should definitely be the default behavior, just like `incsearch`.
Repository: angular
Issue: Extract i18n w/ XMB placeholders are missing examples
Labels: area: compiler,P4

### Which @angular/* package(s) are the source of the bug?

compiler

### Is this a regression?

Yes

### Description

When extracting i18n via the CLI with format set to "XMB", placeholders should have examples (<ex>) included.

I believe this is where the tags should be created, but they don't seem to be inserted into the tree. https://github.com/angular/angular/blob/3a60063a54d850c50ce962a8a39ce01cfee71398/packages/compiler/src/i18n/serializers/xmb.ts#L123

Interestingly there seem to be tests that cover this very scenario: https://github.com/angular/angular/blob/3a60063a54d850c50ce962a8a39ce01cfee71398/packages/compiler/test/i18n/serializers/xmb_spec.ts#L51

### Please provide a link to a minimal reproduction of the bug

https://github.com/tjlav5/temp-ng-i18n/blob/main/messages.xmb

### Please provide the exception or error you saw

```true
The messages.xmb created (see link) has placeholders for tags but they are missing <ex> nodes.

For example, exported message:
<msg id="2597221933847186549" desc="title"><source>src/app/app.component.html:0</source>Hello <ph name="START_BOLD_TEXT"/>world!<ph name="CLOSE_BOLD_TEXT"/></msg>

That START_BOLD_TEXT and CLOSE_BOLD_TEXT should both have examples inside that look something like:
<ph name="START_BOLD_TEXT"><ex>&lt;b&gt;</ex>&lt;b&gt;</ph>
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 14.2.3
Node: 16.15.1
Package Manager: npm 8.11.0 
OS: darwin arm64

Angular: 14.2.3
... animations, cli, common, compiler, compiler-cli, core, forms
... localize, platform-browser, platform-browser-dynamic, router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1402.3
@angular-devkit/build-angular   14.2.3
@angular-devkit/core            14.2.3
@angular-devkit/schematics      14.2.3
@schematics/angular             14.2.3
rxjs                            7.5.6
typescript                      4.7.4
```


### Anything else?

_No response_