sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: CharacterBody2D gets moved with no velocity and no KinematicCollision2D
Labels: topic:physics,needs testing,topic:2d

### Godot version

4.1.3

### System information

Windows 10

### Issue description

I have two CharacterBody2Ds: Player, and Cow. The overall goal is to have both Player and Cow stop moving in their current direction when they run into each other.

**Current Behavior:**
If I direct Player into Cow then Cow will get pushed back along the direction of Player movement. This happens even if I use move_and_collide() so there's no sliding behavior.

**Unexpected Behavior:**
If I give Cow an empty `_physics_process()` method, then when I direct Player into Cow then neither Player nor Cow will move. When I add ` move_and_collide(Vector2(0,0))` to Cow then the Cow will get pushed back again. Moreover `move_and_collide` will not return a KinematicCollision2D for either cow or player!


![CowPusher](https://github.com/godotengine/godot/assets/9043978/afa5e093-ae2c-4508-8e7a-6f534ed77d28)


### Steps to reproduce

Cow.gd:
```
func _physics_process(delta):
	# empty physics_process -> does not stutter move
	
	# adding move_and_collide will let cow get pushed around
	var collisionInfo = move_and_collide(Vector2(0,0))
	print(str(collisionInfo)) # prints <Object#null>
```

Player.gd:
```
func _physics_process(delta):
	# Get the input direction and handle the movement/deceleration.
	# As good practice, you should replace UI actions with custom gameplay actions.
	var direction = Input.get_axis("ui_left", "ui_right")
	if direction:
		velocity.x = direction * SPEED	
	else:
		velocity.x = move_toward(velocity.x, 0, SPEED)
		
	var verticalDirection = Input.get_axis("ui_up","ui_down")
	if verticalDirection:
		velocity.y = verticalDirection * SPEED
	else:
		velocity.y = move_toward(velocity.y, 0, SPEED)
	
	var collisionInfo = move_and_collide(velocity * delta)
	print(str(collisionInfo)) # also prints <Object#null> !!
```

### Minimal reproduction project

n/a

Basic setup of CharacterBody2D with CollisionShape2D node for Player and CollisionPolygon2D for Cow
Repository: angular
Issue: angular.dev tutorial "local" code is outdated and very different from "browser" code
Labels: P2,area: docs

### Describe the problem that you experienced

Go to https://angular.dev/tutorials, alternatively select "start coding in browser" and "start coding locally". The code for browser is based on angular 17, while the code for local run (linking to https://angular.dev/tutorials/first-app) is a different, older version, based on angular 15.
See screenshot below referring to `*ngFor` instead of `@for`.

### Enter the URL of the topic with the problem

https://angular.dev/tutorials

### Describe what you were looking for in the documentation

expected both samples to be semantically identical except for small differences between browser code and local code. Expected both to refer to angular 17 but only the browser version is based on angular 17

### Describe the actions that led you to experience the problem

following the tutorial locally

### Describe what you want to experience that would fix the problem

use the same sample for locally as is provided for browser mode.

### Add a screenshot if that helps illustrate the problem

![Screenshot 2023-11-10 at 09 47 45](https://github.com/angular/angular/assets/5142205/a9a69b6a-3b07-45c1-a3ae-5e79064a46e8)


### If this problem caused an exception or error, please paste it here

_No response_

### If the problem is browser-specific, please specify the device, OS, browser, and version

_No response_

### Provide any additional information here in as much as detail as you can

_No response_
Repository: next.js
Issue: Please add fix for "cache control directive for server side props" in v12
Labels: bug

### Link to the code that reproduces this issue

https://github.com/vercel/next.js/issues/45301

### To Reproduce

See https://github.com/vercel/next.js/issues/45301

### Current vs. Expected behavior

Would love to get snyk to stop erroring without the effort of upgrading to v13

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: win32
      Arch: x64
      Version: Windows 11 Pro
    Binaries:
      Node: 20.9.0
      npm: N/A
      Yarn: N/A
      pnpm: N/A
    Relevant packages:
      next: 12.3.4
      eslint-config-next: 12.1.0
      react: 17.0.2
      react-dom: 17.0.2
```


### Which area(s) are affected? (Select all that apply)

Not sure

### Additional context

Can't tell if canary has fixed as snyk only runs on this repo when pushed to remote

Snyk link: https://security.snyk.io/vuln/SNYK-JS-NEXT-6032387
Repository: flutter
Issue: Xcode cache mysteriously gets cleared on macOS
Labels: team-infra,P2,triaged-infra

### Is there an existing issue for this?

- [X] I have searched the [existing infra issues](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3Ateam-infra)

### Type of Request

bug

### Infrastructure Environment

LUCI

### What is happening?

In one build Xcode is downloaded: https://chromium-swarm.appspot.com/task?id=65cf2793c5a1a110
Next build was canceled: https://chromium-swarm.appspot.com/task?id=65cf4e5b7efc7b10
In next build the cache is suddenly empty (see step "Show xcode cache") and Xcode has to be downloaded again and fails: https://chromium-swarm.appspot.com/task?id=65cf57470c8f4c10

It seems like maybe anytime a build is cancelled in the middle, the Xcode cache is cleared

Here's another example:
Build canceled: https://luci-milo.appspot.com/ui/p/flutter/builders/try/Mac%20tool_integration_tests_2_4/29778/overview
Next build the cache is empty and Xcode fails to re-download: https://luci-milo.appspot.com/ui/p/flutter/builders/try/Mac_arm64%20macos_platform_tests%20master%20-%20packages/8150/overview

### Steps to reproduce

_No response_

### Expected results

I expect Xcode cache not to get deleted and for Xcode not to fail to install
Repository: TypeScript
Issue: Talk about Exceptions Here
Labels: Discussion

### Acknowledgement

- [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Comment

#13219 is locked so that the conclusion doesn't get lost in the discussion, so talk about exceptions here instead
Repository: ollama
Issue: Electron & root priveleges
Labels: feature request

This project has 84% of the codebase written in Go, but for some reason it uses Electron, which is very heavy (500MB+) both for persistent memory and RAM usage.
Why not use [Wails](https://wails.io/)? It was designed for golang projects with web-based frontends. 

Also, why is the app asking for root privileges right after installation? It says it is doing so to make ollama available from the CLI globally, but why is it necessary?
Repository: bitcoin
Issue: Blockchain fully synced, but `bitcoin-cli -getinfo` shows `verification progress: 99.9999%`
Labels: RPC/REST/ZMQ

### Is there an existing issue for this?

- [x] I have searched the existing issues

### Current behaviour

Although the blockchain is synced, after some minutes, `bitcoin-cli -getinfo` does not display `verification progress: 100.0000%` any more, but drops to `99.9999%` and even below.

New block arrived:
![verification-1000000](https://github.com/bitcoin/bitcoin/assets/126513496/7afefcc9-9920-4928-9e4f-dc960d0a8c0a)

After two minutes:
![verification-999999-hl](https://github.com/bitcoin/bitcoin/assets/126513496/47262508-abb9-4bc3-a6fa-be9fab2064c6)

After some more minutes:
![verification-999997-hl](https://github.com/bitcoin/bitcoin/assets/126513496/c07692ed-917b-482a-8dab-9697576e6273)


Is there a technical reason for such a behaviour? Or is this just probabilistic assumption that maybe a new block could have been mined somewhere, but not delivered to a node yet?

### Expected behaviour

When a new block was downloaded (and verified), the `verification progress` should stay at `100.0000%` and not drop with time – at least as long a new header is know to the node.

![verification-1000000](https://github.com/bitcoin/bitcoin/assets/126513496/e60d64ed-960c-46a7-8f8d-197278b81091)


### Steps to reproduce

Wait for a new block and call `bitcoin-cli -getinfo`. Should display `verification progress: 100.0000%`.

Wait some minutes and call `bitcoin-cli -getinfo`. Will probably display `verification progress: 99.999%` or below.

### Relevant log output

2023-11-10T19:29:22Z UpdateTip: new best=00000000000000000002cb8883317f93a44e213a584a62bf3ccef3274f22353c height=816190 version=0x32cb8000 log2_work=94.530644 tx=917108469 date='2023-11-10T19:28:52Z' progress=1.000000 cache=151.1MiB(1075120txo)
2023-11-10T19:29:20Z [net] Saw new cmpctblock header hash=00000000000000000002cb8883317f93a44e213a584a62bf3ccef3274f22353c peer=5
2023-11-10T19:29:20Z Saw new header hash=00000000000000000002cb8883317f93a44e213a584a62bf3ccef3274f22353c height=816190

### How did you obtain Bitcoin Core

Pre-built binaries

### What version of Bitcoin Core are you using?

v25.0.0

### Operating system and version

Debian 5.1.127 x86_64 (MyNode 0.3.18)
Repository: stable-diffusion-webui
Issue: [Feature Request]: Add rich-text prompt tabs
Labels: enhancement,extension-request

### 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 ?

Add rich-text prompt tabs.
https://github.com/songweige/sd-webui-rich-text

### Proposed workflow

1. we could get more control about prompt with rich text tabs



### Additional information

_No response_
Repository: neovim
Issue: Cursor moves to commandline when printing message after writing file (perceived as cursor flicker)
Labels: performance,bug-vim,display,messages

# Problem

The cursor briefly moves to the commandline when printing the message after writing a file.

## In terminal nvim
In terminal nvim, this is perceived as a cursor flicker.

https://github.com/neovim/neovim/assets/4657140/92c1229c-613a-458e-8158-87db80ae3670

## In neovide
In neovide with cursor animation enabled, this is perceived as the cursor jumping across the screen and then back.

https://github.com/neovim/neovim/assets/4657140/dd0a09b2-b2fe-4e9c-a616-c54428165759





# Steps to reproduce

### Open neovim:
```
nvim --clean
```
or
```
neovide -- --clean
```

### Insert 10,000,000 lines in buffer and save file:
```
iabcdefg<Esc>
yy10000000p
:write temp.txt
```

### Create mapping to invoke write silently:
```
:nnoremap <silent> w :write<CR>
```

### Invoke write with mapping:
```
w
```

Notice that cursor goes to commandline to print message `"temp.txt" 10000001L, 80000008B written`

# Expected behavior

The message should be printed in the commandline without moving the visible cursor there.

# Neovim version (nvim -v)

NVIM v0.10.0-dev-1461+g468292dcb-Homebrew

# Vim (not Nvim) behaves the same?

yes, vim 9.0.1544 (cursor disappears briefly as well but does not seem to appear in comandline)

# Operating system/version

macOS 13.5.1

# Terminal name/version

kitty 0.29.0

# $TERM environment variable

xterm-kitty

# Installation

homebrew
Repository: rust
Issue: `rustdoc` emits spurious build errors due to unsatisfied trait bounds on code that compiles fine
Labels: T-rustdoc

<!--
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.
-->

I tried this code: https://github.com/zopfli-rs/zopfli/pull/36

I expected to see this happen: the CI build workflow completes fine.

Instead, this happened: [the CI build workflow run](https://github.com/zopfli-rs/zopfli/actions/runs/6828734319/job/18573470961?pr=36) failed to build the crate documentation. However, the crate compiles without any problems when using `cargo test` and `cargo build` with the same features:

![Error screenshot](https://github.com/rust-lang/rust/assets/7822554/250264e2-feb1-462d-b743-546200e727bb)

I suspect there's a new issue with the latest nightly `rustdoc`, leading to unexpected trait bound errors. This suspicion stems from the fact that the same command works well under `rustc 1.75.0-nightly (df871fbf0 2023-10-24)`. Additionally, there have been recent changes made to the code that rustdoc accepts: https://github.com/rust-lang/rust/issues/117622, https://github.com/rust-lang/rust/pull/117450

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.75.0-nightly (0f44eb32f 2023-11-09)
binary: rustc
commit-hash: 0f44eb32f1123ac93ab404d74c295263ce468343
commit-date: 2023-11-09
host: x86_64-unknown-linux-gnu
release: 1.75.0-nightly
LLVM version: 17.0.4
```
Repository: godot
Issue: `OS.get_keycode_string()` returns empty string
Labels: enhancement,documentation

### Godot version

v4.1.3.stable.official [f06b6836a]

### System information

Godot v4.1.3.stable - Windows 10.0.22621 - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 4070 (NVIDIA; 31.0.15.4601) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

I'm trying to show an interaction hint in UI by getting `InputEventKey` from `InputMap`.

Code:
```
# var interact_event_key: := ...
print(interact_event_key)
print(OS.get_keycode_string(interact_event_key.keycode))
```

Output:
```
InputEventKey: keycode=69 (E), mods=none, physical=true, pressed=false, echo=false
<empty-string>
```

I expect `OS.get_keycode_string()` returns `E` in this particular example.

### Steps to reproduce

Download reproduction project, run it, look at the Output.

### Minimal reproduction project

[os_get_keycode_string_bug.zip](https://github.com/godotengine/godot/files/13323263/os_get_keycode_string_bug.zip)
Repository: pytorch
Issue: /nodefaultlib:vcomp doesn't seem to be set when compiling with Intel OpenMP on Windows
Labels: module: build,module: windows,triaged

### 🐛 Describe the bug

Hello, we (Anaconda) noticed that when compiling Pytorch 2.0.1 with Intel OpenMP+MKL on Windows, the `/nodefaultlib:vcomp` flag doesn't seem to be passed to the linker.

In our build logs, we see:
```
    [4311/5525] cmd.exe /C "cd . && C:\b\abs_4etuqaqn3v\croot\pytorch_1699482324714\_build_env\Library\bin\cmake.exe -E vs_link_dll --intdir=caffe2\CMakeFiles\torch_global_deps.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100190~1.0\x64\mt.exe --manifests  -- C:\PROGRA~2\MICROS~1\2019\BUILDT~1\VC\Tools\MSVC\1429~1.301\bin\Hostx64\x64\link.exe  caffe2\CMakeFiles\torch_global_deps.dir\__\torch\csrc\empty.c.obj  /out:bin\torch_global_deps.dll /implib:lib\torch_global_deps.lib /pdb:bin\torch_global_deps.pdb /dll /version:0.0 /machine:x64 /ignore:4049 /ignore:4217 /ignore:4099 /INCREMENTAL:NO  C:\b\abs_4etuqaqn3v\croot\pytorch_1699482324714\_h_env\Library\lib\mkl_intel_lp64_dll.lib  C:\b\abs_4etuqaqn3v\croot\pytorch_1699482324714\_h_env\Library\lib\mkl_intel_thread_dll.lib  C:\b\abs_4etuqaqn3v\croot\pytorch_1699482324714\_h_env\Library\lib\mkl_core_dll.lib  C:\b\abs_4etuqaqn3v\croot\pytorch_1699482324714\_h_env\Library\lib\libiomp5md.lib  kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib  && cd ."
```

We can see that `mkl_intel_lp64_dll.lib`, `mkl_intel_thread_dll.lib`, `mkl_core_dll.lib` and `libiomp5md.lib` are being linked, but `/nodefaultlib:vcomp` is not passed to the linker.

We analyzed our entire log and we also couldn't find any reference to `/nodefaultlib:vcomp`.

We are not 100% sure what effect this can have on the resulting binaries, but we figured we would post here in case it's a bug.

Thanks!

cc @malfet @seemethere @peterjc123 @mszhanyi @skyline75489 @nbcsm @vladimir-aubrecht @iremyux @Blackhex @cristianPanaite @danpetry

### Versions

2.0.1
Repository: angular
Issue: @defer additional support for "offset" option for both "on viewport" and "prefetch on viewport"
Labels: feature,area: core,feature: under consideration,core: defer

### Which @angular/* package(s) are relevant/related to the feature request?

compiler

### Description

Hey there  folks!

I was just taking a deep dive on the `@defer` and was thinking about some interactions and cases for the `prefetch`
where it would make sense to say that ...

Using the  `prefetch on viewport` makes little sense as if the `@placeholder` is in the `viewport` already, and we have the bundle (prefetched) then it would be great to just display the lazy loaded component and use the `on viewport` trigger instead of the prefetch. 

This means `prefetch on viewport` only makes sense when used with some `target` which appears before the actual `@defer` block but this is "work intense" and it is easy to forget to update targets when moving components around. Additionally, it also breaks the "self containment" of the `@defer` block as now we have to know both the `@defer` and the `target` to understand the full picture.

Because of that, it would be really cool to be able to specify something like `prefetch on viewport(200)` which would start prefetching `200px` before  `@placeholder` reaches the viewport!

This way the `@defer` block will be fully self contained and work even when moved around in the template of the component (or extracted to another component)


### Proposed solution

Add support for `offset` (or other name) option for the `on viewport(offset)` and `prefetch on viewport(offset) which will trigger lazy loading or prefetching before the target reaches the viewport. This could in theory work also with custom targets but the main use case is the default target, the `@placeholder`.

Examples

```
@defer(on viewport(200)) { }

@defer(on viewport; prefetch on viewport(200)) { }
// this one is great as we could prefetch before viewport
// but NOT run the component until viewport (eg if it triggers backend requests etc...)

// optional goal
@defer(on viewport(target, 200) { } // offset for custom target

```

### Alternatives considered

The main alternative is to specify target which appears on the page before manually but this is suboptimal as it's manual step that developer has to perform, manage and maintain.

Another alternative is to write a custom scroll / intersection observer based service and use it in `prefetch when customViewportOffsetLogic`
Repository: flutter
Issue: Add Spacer.fixed
Labels: c: new feature,P2,team-framework,triaged-framework,Design Systems Study

From the custom design systems study, we found spacing can be done a lot of ways.
Container, Padding, SizedBox, Spacer and Gap were all used interchangeably is a use case study. This made the code hard to read semantically and made it easy to introduce inconsistencies in the 

Spacer is a pretty relevant widget here, but only in the context of flexing to fill the available space. If we provide an option for a fixed size Spacer, we could recommend it for all cases of needing a bit of space in one way or another inserted into a layout.
Repository: angular
Issue: @defer additional support for "error" and "retry" options for the "@error" block
Labels: feature,area: core,feature: under consideration,core: defer

### Which @angular/* package(s) are relevant/related to the feature request?

compiler, core

### Description

Currently, the `@error` block doesn't support any options, it would be great to support two use-cases:

1. get access to the error itself to be able to parametrize the error block content
2.  to retry failed fetching of the lazy loaded component bundle file



### Proposed solution

```
@error (err; retry: 3) {  <p>Ooops {{err}}</p> }

// or even 
@error (err, retry: customRetryHandler)  {  <p>Ooops {{err}}</p> }
```

### Alternatives considered

Taping into requests with HTTP interceptor and trying to filter out failures for this lazy loading process?
Repository: electron
Issue: [Bug]: Frameless window can't be resized while cursor is next to but outside of window
Labels: platform/windows,bug :beetle:,status/confirmed,has-repro-gist,27-x-y,28-x-y

### 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

28.0.0-beta.3

### What operating system are you using?

Windows

### Operating System Version

Windows 11 10.0.22621

### What arch are you using?

x64

### Last Known Working Electron version

N/A

### Expected Behavior

When I place my cursor to the right of the right border of a frameless Electron window, I expect for the cursor to change to a resize one.

### Actual Behavior

When I place my cursor to the right of the right border of a frameless Electron window, the cursor does not change to a resize one.

### Testcase Gist URL

https://gist.github.com/rzhao271/a267df622a0f62f71b1e47e45d1b66fc

### Additional Information

Downstream issue: https://github.com/microsoft/vscode/issues/185249

This problem does not reproduce in Chrome with a PWA, or on Edge.
This problem does not reproduce with an Electron window that contains a frame.

I'm unsure how an Electron window with a frame seems to have a resize area that extends beyond the borders of the window, but I'd prefer if a frameless Electron window did the same thing so that a user can resize a frameless Electron application more easily.
Repository: vscode
Issue: `"colorizedBracketPairs"` only supports lowercase, but matching is case insensitive
Labels: bug,editor-bracket-matching,bracket-pair-colorization

in `language-configuration.json`; `"brackets"`, `"autoClosingPairs"` and `"surroundingPairs"` are all case sensitive
but `"colorizedBracketPairs"` will only accept lowercase letters
yet the bracket pairing algorithm is case insensitive

![image](https://github.com/microsoft/vscode/assets/33529441/025efdea-4b2f-4a05-bea1-99b42125fe1f)
![image](https://github.com/microsoft/vscode/assets/33529441/15b7ffed-3477-4df4-a7e2-2bdaffa9b1f2)
![image](https://github.com/microsoft/vscode/assets/33529441/2c800730-c9c9-4586-ab8e-babb3cf4e930)
Repository: flutter
Issue: Autosubmit dropped #136997 from the queue
Labels: P2,team-release

### Is there an existing issue for this?

- [X] I have searched the [existing infra issues](https://github.com/flutter/flutter/issues?q=is%3Aopen+is%3Aissue+label%3Ateam-infra)

### Type of Request

bug

### Infrastructure Environment

Interaction between autosubmit app and FRoB.

### What is happening?

When:

1. the `autosubmit` label is added to a PR
2. the google testing check fails (but autosubmit is not removed, for whatever reason)
3. a maintainer manually overrides the FRoB check in go/frob

The autosubmit bot will never merge the PR.

For example: https://github.com/flutter/flutter/pull/136997 (I manually merged it since the contributor had been blocked for weeks). Perhaps the reason is that "Google testing" failed at one point, but never passed (it was instead marked "skipped" by FRoB)?

### Steps to reproduce

See steps from "What is happening?"

### Expected results

I expect a PR with autosubmit and all scheduled checks that were scheduled to be either passing **or skipped**, to be auto merged.