sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/vulndb/internal/symbols: TestPatchedSymbols failures
Labels: NeedsInvestigation,vulncheck or vulndb

```
#!watchflakes
default <- pkg == "golang.org/x/vulndb/internal/symbols" && test == "TestPatchedSymbols"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8735794537960806193)):

    === RUN   TestPatchedSymbols
        patched_functions_test.go:42: lstat testdata/module: no such file or directory
        patched_functions_test.go:46: lstat testdata/fixed-module: no such file or directory
        patched_functions_test.go:54: (-got, want+):
              map[symbols.symKey]bool{
            + 	{pkg: "golang.org/module", symbol: "Foo"}:          true,
            + 	{pkg: "golang.org/module/internal", symbol: "Bar"}: true,
              }
        patched_functions_test.go:42: lstat testdata/module: no such file or directory
        patched_functions_test.go:46: lstat testdata/fixed-module: no such file or directory
        patched_functions_test.go:54: (-got, want+):
              map[symbols.symKey]bool{
            + 	{pkg: "golang.org/nestedmodule", file: "main_linux.go", symbol: "main"}: true,
              }
    --- FAIL: TestPatchedSymbols (0.00s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: godot
Issue: Empty Resource metadata property disappears from inspector when reopening the scene
Labels: bug,topic:editor,needs testing

### Tested versions

- Tested and confirmed on: v4.0.4, v4.2.2, v4.3 and v4.4-dev2.
- v3.6 did not have metadata in the inspector to test.

### System information

Windows 10 - Godot v4.3.0-stable

### Issue description

After creating a metadata property of type Resource and reopening the scene, the editor inspector does not show the property, even though it still exists in the scene's tscn file.

The property should still be visible, even if there is no value set.

### Steps to reproduce

1) Create a scene and add a metadata property of type Resource.
2) Do not add any value to it and save the scene.
3) Close and reopen the scene.

### Minimal reproduction project (MRP)

[Metadata Test.zip](https://github.com/user-attachments/files/17175944/Metadata.Test.zip)
It may not show, but the scene already has a metadata of type resource.
Repository: PowerToys
Issue: Image Resizer processes (shrinks) the same image multiple times (for a subset of images)
Labels: Issue-Bug,Needs-Triage

### Microsoft PowerToys version

0.84.1

### Installation method

PowerToys auto-update

### Running as admin

No

### Area(s) with issue?

Image Resizer

### Steps to reproduce

[PowerToysReport_2024-09-28-21-46-57.zip](https://github.com/user-attachments/files/17176083/PowerToysReport_2024-09-28-21-46-57.zip)

Prepare a bunch of images. I often work with sets of 50-150, so the issue might only occur on larger batches but not if you resize only 10 images at once.

I could not link the behaviour to anything. Same source (mobile phone), same resolution, no specific order e.g. by filename that would link to stuff like "every nth process".

I do overwrite in place.

Env: W11, 7950X3D, PCIe4 SSD (adding in case it's performance related).

### ✔️ Expected Behavior

Images are only processed once.

### ❌ Actual Behavior

Some (seemingly random) images are processed multiple times.

[edit1]
As in
Source 3472x4624px (WxH)
becomes 1080x1438px (WxH)
becomes 640x852px (WxH)

Wait a minute... was just editing to add this detail and calc the ratio (e.g. ratio applied double?).
Isn't 852 one of the default values for Small...?
https://learn.microsoft.com/en-us/windows/powertoys/image-resizer#settings
Ok it's 854x480. So not only different (yet close!) but also the wrong value (width instead of height).

I use "Medium" 1920x1080 in any case :)
[/edit 1]

[edit 2]
Just noticed something else. Width and Height are flipped anyway!?
![image](https://github.com/user-attachments/assets/b1989379-3bf3-4b50-bbc7-90505f63e7cd)

Then 852/854 is suddenly becoming very interesting again, no? :)
[/edit2]

![image](https://github.com/user-attachments/assets/2ee3e47b-f043-4ca4-a052-86fe90246e54)

![image](https://github.com/user-attachments/assets/c6ae57f8-48f9-4ece-97c1-c2ebcfe0a495)

![image](https://github.com/user-attachments/assets/be375aee-8b3b-4645-a78d-d0ef20da95bb)

![2024-09-28 21_43_55](https://github.com/user-attachments/assets/8e9741e0-3bc0-40c4-8a1f-f90997a77555)

### Other Software

_No response_
Repository: pytorch
Issue: Python implementation of RNN in docstring is broken
Labels: module: nn,module: rnn,triaged

### 📚 The doc issue

`RNN`'s docstring provides a Python implementation of a forward pass. This was added in https://github.com/pytorch/pytorch/pull/119150 (resolving https://github.com/pytorch/pytorch/issues/109443) and is helpful since the actual forward pass is implemented with ATen primitives, via _VF virtual function calls.

However, the implementation has two issues:
1. It cannot be directly used, in the sense of:
```
class PyRNN(nn.RNN):
    # paste in forward pass from documentation
    ...

pyrnn = PyRNN(10, 20, 2)  # breaks!
```

This breaks primarily because forward implementation in the documentation is missing `self` references.

2. The implementation breaks for stacked RNNs (i.e. `num_layers >= 2`). The culprit is the line `x[t] @ weight_ih[layer].T`, which is correct for the first layer of the RNN, but incorrect for subsequent layers. In those subsequent layers, the LHS of the multiplication should be the previous hidden state to match the dimension of weight_ih[layer].T.


The documentation should either be "downgraded" to looser pseudocode or "upgraded" to a working Python implementation. I think the latter is the right choice, given the tutorial value; plus, will be a lightweight change.

### Suggest a potential alternative/fix

#⁠1 can be fixed by adding the requisite `self`'s. Here's a quick working implementation that adds the requisite `self`'s.

```
def forward(self, x, h_0=None):
    if self.batch_first:
        x = x.transpose(0, 1)
    seq_len, batch_size, _ = x.size()
    if h_0 is None:
        h_0 = torch.zeros(self.num_layers, batch_size, self.hidden_size)
    h_t_minus_1 = h_0
    h_t = h_0
    output = []
    for t in range(seq_len):
        for layer in range(self.num_layers):
            h_t[layer] = torch.tanh(
                x[t] @ eval(f"self.weight_ih_l{layer}").T
                + eval(f"self.bias_ih_l{layer}")
                + h_t_minus_1[layer] @ eval(f"self.weight_hh_l{layer}").T
                + eval(f"self.bias_hh_l{layer}")
            )
        output.append(h_t[-1])
        h_t_minus_1 = h_t
    output = torch.stack(output)
    if self.batch_first:
        output = output.transpose(0, 1)
    return output, h_t
```

(The `eval`'s are a hack though, will fix...)

#⁠2 needs a closer look at the code inside the `for` loop.

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: rust
Issue: Tracking Issue for File lock API
Labels: T-libs-api,proposed-final-comment-period,C-tracking-issue,disposition-merge

<!--
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(file_lock)]`

This is a tracking issue for https://github.com/rust-lang/libs-team/issues/412

This feature exposes advisory file locks on `File`. They allow a file handle to acquire an exclusive or shared file lock, which blocks other file handles to the same file from acquiring a conflicting lock. Some semantics are platform dependent, and these are documented in the API documentation.

<!--
Include a short description of the feature.
-->

### Public API

```rust
impl File {
    fn lock(&self) -> io::Result<()>;
    fn lock_shared(&self) -> io::Result<()>;
    fn try_lock(&self) -> io::Result<bool>;
    fn try_lock_shared(&self) -> io::Result<bool>;
    fn unlock(&self) -> io::Result<()>;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #130999 
- [ ] 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

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: rust
Issue: proc-macro span syntax context and hygiene is underspecified and underdocumented
Labels: T-lang,T-compiler,A-docs,A-proc-macros,C-discussion,A-hygiene

zulip thread: https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/proc-macro.20span.20syntax.20context.20docs.20and.20best.20practices

Are there any clear docs or guidance about proc-macro span syntax context and hygiene? I'm asking because I've noticed that rustc lints, diagnostics, also clippy lints, all run into issues where we don't want to lint on or make suggestions on code that are generated by proc-macros, but `Span::from_expansion` returns `false` for proc-macro-generated spans that naively forwards user spans without adding distinguishable syntax context.

The best explanation about proc-macro span syntax context and hygiene I can find atm is the [The Little Book of Rust Macros](https://veykril.github.io/tlborm/proc-macros/hygiene.html) by @Veykril. AFAICT The reference on proc-macro span syntax context and hygiene is quite terse: https://doc.rust-lang.org/reference/procedural-macros.html?highlight=hygiene#procedural-macro-hygiene.

This causes issues where crate authors who write proc-macros use

> e.g. `m!(t)` and the span of `t` is used when generating code via `.set_span`/`quote_spanned!`/etc.

Example issue I ran into when trying to implement `unit_bindings`: https://github.com/rust-lang/rust/pull/112380#issuecomment-1657124150 (I think I now know the fix for Rocket isn't exactly reasoned correctly but happened to add sufficient Syntax Context to suppress the lint)
Example clippy issue: https://github.com/rust-lang/rust-clippy/issues/13458

From the perspective of `rustc` and `clippy`, *technically* it's "not our fault" because the user provided a span that has no distinguishing syntax context, but from the perspective of the user it's very confusing. It does not help rustc/clippy maintainers nor does it help users.

Zulip thread: https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/proc-macro.20span.20hygiene

I don't know who's maintaining `proc-macro` or who has purview over the proc-macro API, I thought it was T-libs or T-libs-api but apparently it's not T-libs, and I don't know about T-libs-api. I found @petrochenkov in triagebot.toml, maybe you know more about this?

Tagging this as T-lang because it's part of the Rust language that is quite rough when in comes to interaction between compiler/tooling and user experience.
Repository: godot
Issue: Documentation of InputEventMouseMotion Velocity is misleading
Labels: bug,documentation,topic:input

### Tested versions

v4.4.dev2.official [97ef3c837]

### System information

Godot v4.4.dev2 - Windows 10.0.22631 - OpenGL 3 (Compatibility) - NVIDIA GeForce RTX 4070 (NVIDIA; 32.0.15.5585) - AMD Ryzen 7 5800X 8-Core Processor (16 Threads)

### Issue description

The documentation of the InputEventMouseMotion velocity and screen_velocity talks about how it should be used with Input.MOUSE_MODE_CAPTURED. Which is confusing as in captured mode both return `(0,0)`. Which is intended according to this: https://github.com/godotengine/godot/issues/32578 (it's an old one, so idk if this still is intended).

IMO either velocity should return a value in captured mode or the documentation should be adjusted to remove the note about captured mouse and instead document that it returns Vector2(0, 0) in that case.

Current documentation for reference:
![image](https://github.com/user-attachments/assets/2970ebd8-26da-4d9c-b5c8-7cf9b78beaa0)
![image](https://github.com/user-attachments/assets/aecb9565-9331-4396-be26-62d79dec730c)

 

### Steps to reproduce

add this script and see it printing (0,0). _If you comment out the mouse capture it prints a velocity_:

```
func _ready() -> void:
	Input.mouse_mode = Input.MOUSE_MODE_CAPTURED

func _input(event: InputEvent) -> void:
	if event is InputEventMouseMotion:
		print(event.get_velocity())
		print(event.get_screen_velocity())
```

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: [4.4.dev 2] ufbx importer does not find Synty textures 
Labels: needs testing,topic:import

### Tested versions

4.4.dev 2

### System information

Windows 11 Vulkan Forward +

### Issue description

I saw a similar report/post somewhere, but could not find it so I apologize if this is repeated somewhere.

The Synty assets that are released as their "Sources Files" contain .FBX files that reference links to Dropbox or the .psd image textures rather then the same file name with the .png extension that is actually contained in the files.  

```
  Resource file not found: res:// (expected type: Texture2D)
  Can't open file from path 'res://Dropbox/SyntyStudios/PolygonHorrorMansion/_Working/_Textures/PolygonHorror_Texture_01.psd'.
  modules/fbx/fbx_document.cpp:1088 - FBX: Image index '1' couldn't be loaded from path: res://Dropbox/SyntyStudios/PolygonHorrorMansion/_Working/_Textures/PolygonHorror_Texture_01.psd because there was no data to load. Skipping it.
  Resource file not found: res:// (expected type: Texture2D)
  Can't open file from path 'res://_Textures/PolygonHorror_Texture_01.psd'.
  modules/fbx/fbx_document.cpp:1088 - FBX: Image index '0' couldn't be loaded from path: res://_Textures/PolygonHorror_Texture_01.psd because there was no data to load. Skipping it.
  Resource file not found: res:// (expected type: Texture2D)
  Can't open file from path 'res://PolygonShops/_Working/_Textures/PolygonShops_Walls_Texture_01.psd'.
  modules/fbx/fbx_document.cpp:1088 - FBX: Image index '1' couldn't be loaded from path: res://PolygonShops/_Working/_Textures/PolygonShops_Walls_Texture_01.psd because there was no data to load. Skipping it.
  Resource file not found: res:// (expected type: Texture2D)
  Can't open file from path 'res://_Textures/Glass.psd'.
```
the ufbx importer does not appear, as a fallback, to look through the filesystem and find the matching filename with other extension types that can be used in place of the ones referenced that it is unable to find. 

Additionally there appears to be no way to disable the ufbx importer so that the FBXState and FBXDocument classes can be used to override and "handle" the .fbx files.

### Steps to reproduce

I was importing .fbx files from their PolygonHorrorMansion Pack sourcefiles.

### Minimal reproduction project (MRP)

NA
Repository: vscode
Issue: Color of placeholder text of git commit message does not respect setting
Labels: bug,scm

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Version: 1.93.1 (user setup)
Commit: 38c31bc77e0dd6ae88a4e9cc93428cc27a56ba40
Date: 2024-09-11T17:20:05.685Z
Electron: 30.4.0
ElectronBuildId: 10073054
Chromium: 124.0.6367.243
Node.js: 20.15.1
V8: 12.4.254.20-electron.0
OS: Windows_NT x64 10.0.22631

Steps to Reproduce:

1. Pick any theme
2. set ` "workbench.colorCustomizations": { "editor.placeholder.foreground": "#ff0000"}`
3. expected: placeholder text of git commit message should turn red (or to any color you set) - but actually it stays the default which is  ` "editorGhostText.foreground"`. Changing the ghost text color indeed also changes this placeholder text color.

I checked using the developer tool that the placeholder text of git commit message is indeed controlled by `editor.placeholder.foreground`.

see screenshot below

(theme: default dark modern)

![image](https://github.com/user-attachments/assets/a9c2dd40-201b-452d-a2dd-3555cc95036f)

(theme: wine-bar-monokai)

![image](https://github.com/user-attachments/assets/c0abe612-347f-4468-aa80-e5d4b654e1f2)
Repository: godot
Issue: Moving Parallax2D node using the move tool with grid snap enabled causes rubber-banding effect.
Labels: bug,topic:editor,usability,topic:2d

### Tested versions

- Reproducible in 4.3.stable

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1660 SUPER (NVIDIA; 31.0.15.4633) - AMD Ryzen 5 5600G with Radeon Graphics (12 Threads)

### Issue description

Moving a Parallax2D node using the move tool with grid snap enabled causes a "rubber-banding" effect. The node's scroll offset will still be updated in the inspector but will not appear in the editor window until the position is adjusted using the inspector or the scene is reloaded (eg. via switching tabs).

![47995dbac447cbdfa602e040799d7aef](https://github.com/user-attachments/assets/9c2c7394-8114-42e8-8966-dccd8ce665d4)

A few things of note:
- Only reproducible if the "grid snap" option is enabled.
- Happens despite the `ignore_camera_scroll` property of the Parallax2D node being set to `true`.
- Happens despite the `screen_offset` property of the Parallax2D node being unmodified.
- Sometimes, the position *does* immediately appear in the editor. This happens once in the example provided above.

While I did read the following on the [documentation page](https://docs.godotengine.org/en/stable/classes/class_parallax2d.html#class-parallax2d) for the Parallax2D node:
> Note: Any changes to this node's position made after it enters the scene tree will be overridden if [ignore_camera_scroll](https://docs.godotengine.org/en/stable/classes/class_parallax2d.html#class-parallax2d-property-ignore-camera-scroll) is false or [screen_offset](https://docs.godotengine.org/en/stable/classes/class_parallax2d.html#class-parallax2d-property-screen-offset) is modified.

...This issue appears to be unrelated. If it is related or intended, I believe the engine should clarify that.



### Steps to reproduce

1. Create a new godot project and open the 2D view.
2. Create a new `Parallax2D` node. 
3. *Optionally, add a `Sprite2D`as a child of the `Parallax2D` node. This will make the effect more visible.*
4. *Optionally, set `ignore_camera_scroll` to `true`. This does not appear to have any effect, but the [documentation](https://docs.godotengine.org/en/stable/classes/class_parallax2d.html#class-parallax2d) says you won't be able to move it otherwise.*
5. Enable grid-snapping in the toolbar.
6. Select the move tool and attempt to move the `Parallax2D` node.

### Minimal reproduction project (MRP)

[Parallax2D-moving-bug.zip](https://github.com/user-attachments/files/17176727/Parallax2D-moving-bug.zip)
Repository: flutter
Issue: Remove all nullable generics in plugin Pigeon definitions
Labels: package,team-ecosystem,P1,triaged-ecosystem

Now that #97848 is fixed, we should sweep all of our plugins for any nullable generics that were nullable only because of that issue (that's probably *any* nullable generic, but there may be some rare exceptions). Many have a TODO annotated with #97848, but we shouldn't assume they all have an annotation.

In general I would expect that we can just:
- Remove the nullability from generics.
- Update to the latest version of Pigeon.
- Remove any casting on the Dart side.
- Do any incidental changes for intervening Pigeon breaking changes (e.g., setup->setUp)

Since most of our plugins are using Obj-C and Java on the native side still, native changes will likely be minimal.

This will give us a nearly-free improvement in type safety, and also avoid having other developers who look to our plugins as examples thinking they still need the same workaround.