sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Subpar documentation for ptr-to-ref conversion methods
Labels: C-enhancement,E-help-wanted,A-docs,A-doctests,T-libs,C-discussion

While trying to merge #122492, some issues with the existing documentation became apparent.

## The methods in question

- [ ] `<*const T>::as_ref`
- [ ] `<*mut T>::as_ref`
- [ ] `<*mut T>::as_mut`
- [ ] `<*const T>::as_ref_unchecked` [^unchecked]
- [ ] `<*mut T>::as_ref_unchecked` [^unchecked]
- [ ] `<*mut T>::as_mut_unchecked` [^unchecked]
- [ ] `<*const T>::as_uninit_ref` [^uninit]
- [ ] `<*mut T>::as_uninit_ref` [^uninit]
- [ ] `<*mut T>::as_uninit_mut` [^uninit]

[^unchecked]: Not yet stabilized (#122034)
[^uninit]: Not yet stabilized (#75402)
  
 ## The problems
 
 - [ ] The overarching pain-point is that big parts of documentation are repeated for all (or at least the most) of the methods, which makes it difficult to keep the wording in sync.
 
 ### Documentation

- [ ] Generally subpar wording (probably due to these docs' being a patchwork of many separate changes). But also specifically:
- [ ] [Imprecise wording around `UnsafeCell`](https://github.com/rust-lang/rust/pull/122492#discussion_r1526668965)
- [ ] ~[Needlessly scary wording around the output's lifetime](https://github.com/rust-lang/rust/pull/122492#discussion_r1526671594)~ [Or not](https://github.com/rust-lang/rust/issues/124669#issuecomment-2304262133)?

 ### Doctests
 
- [x] ~Currently, [they do printing instead of asserting](https://github.com/rust-lang/rust/pull/122492#discussion_r1526708586). This should probably be changed to assertions.~ (Fixed in #126210)
- [ ] The assertions that we want [should reflect the API](https://github.com/rust-lang/rust/pull/122492#issuecomment-2091907587) being tested. (For example, we probably want an assertion that null pointer gets converted to `None` for `as_ref`, but no such assertion for `as_ref_unchecked` is possible.)
- [ ] Currently [some asserts are hidden](https://github.com/rust-lang/rust/pull/122492#discussion_r1526710064). Why?
 
 
 ## Moving forward
 
Feel free to voice your opinions/wishes/suggestions/questions regarding this issue or to submit PRs addressing any of the problems above (not necessarily all at once). Also, doctests can probably be worked on independently from the documentation itself.
 
 ## Beep-Boop
 
 @rustbot label +A-docs +A-doctests +C-discussion +C-enhancement +E-help-wanted
 
 And now footnotes:

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"lolbinarycat"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: [TRACKER]  FBX importer issues
Labels: tracker

### Tested versions

- Reproducible: https://github.com/godotengine/godot/commit/03e6fbb010c3546593bd91a0dabc045a9882705a

### System information

Mac Mini, Apple Silicon, M2 Pro

### Issue description

Here are some of the open issues for UFBX importer we want to solve.

- [x] #91528
- [x] #91526
- [x] #85402
- [x] #90734
- [x] #90986
- [x] #92197
- [x] #90888
- [x] #84249
- [x] #92100
- [x] #91062
- [ ] #90298
- [ ] #90314 
- [ ] #86309

### Steps to reproduce

1. Start Godot Engine master.
2. Use the fbx importer

### Minimal reproduction project (MRP)

None
Repository: PowerToys
Issue: Add "Run at startup" Feature in group policies
Labels: Idea-Enhancement,Help Wanted,Product-Settings,Area-Runner,Area-Enterprise

### Description of the new feature / enhancement

Add a group policy allowing to run PowerToys at startup
Example : Run at startup (User can choose, On, Off)

### Scenario when this would be used?

When admins use ADMX for apply group policies

### Supporting information

This had already been proposed by @Aaron-Junker 
https://github.com/microsoft/PowerToys/issues/14008
Repository: godot
Issue: [TRACKER] Typos and UI Paper Cuts
Labels: enhancement,tracker,topic:codestyle

As per https://github.com/godotengine/godot-proposals/issues/9648, this issue tracks tiny issues which can easily be fixed and are not opinionated changes. This includes:

- A misspelling in the user interface or class reference
- A misspelling in the code (comment, variable name, class name, etc. as long as it is not a breaking change)
- Adding or tweaking the property hint of a property
- Giving names to unnamed method arguments
- Changing the "basic/advanced" status of Project Settings

It does NOT include any functional changes, such as refactoring or reordering code.
Purpose of tracking these is NOT for users to make PRs for fixing them directly, but rather:

1. For maintainers to periodically fix all of the listed issues in larger batches, instead of doing small PRs for individual issues.
2. For contributors that are already touching code near a known issue, to fix it while they're at it.

A task list is used to keep track of how many issues there are, but you can simply remove the bullet points when done instead of checking them, to keep this tracker clean and re-usable.

# Typos

- [x] `core/object/script_language.cpp`
  - typo: `characacteristics` -> `characteristics`
- [x] [`editor/plugins/visual_shader_editor_plugin.cpp`](https://github.com/godotengine/godot/blob/e4e024ab88efe74677769395886bc1b09eccbac7/editor/plugins/visual_shader_editor_plugin.cpp#L3306) at `_setup_node` function
  - code style: `camelCase` should be `snake_case`
- [x] `scene/gui/code_edit.cpp`
  - typo: `all_ocurence` -> `all_occurrences` (local variable)

# Other minor mistakes

- [x] `doc/classes/Window.xml`
  - Documentation of `WINDOW_MODE_FULLSCREEN` and `WINDOW_MODE_EXCLUSIVE_FULLSCREEN` was not synced with `DisplayServer.xml` equivalent. Both are missing the line `[b]On Android:[/b] This enables immersive mode.`
- [x] `doc/classes/String.xml`
  - Missing link to class:
  ```diff
  -To convert any Variant to or from a string
  +To convert any [Variant] to or from a string
  ```
# Functional changes

- [x] `core/string/translation.cpp` inside of `TranslationServer::setup()`
  - Add property hint `ProjectSettings::get_singleton()->set_custom_property_info(PropertyInfo(Variant::STRING, "internationalization/locale/test", PROPERTY_HINT_LOCALE_ID, ""));`

Maintainers are free to edit this issue to add to the list or change wording.
Other contributors are welcome to write comments and they'll be taken into account.
Repository: go
Issue: x/tools/gopls: "View package documentation": use type information
Labels: FeatureRequest,gopls

gopls v0.16's new doc viewer has access to the complete type information. It should make use of it to display such things as:
- methods promoted from embedded fields
- size/offset information
- the relationship between interfaces  and concrete types within the same package
etc.
Repository: pytorch
Issue: [inductor] TorchInductor does not correctly recognize the grad status of model code
Labels: triaged,oncall: pt2,module: inductor

### 🐛 Describe the bug

At https://github.com/pytorch/pytorch/blob/30610251ec7b8f7e0507df06c3aadbcf90658e0e/torch/_inductor/compile_fx.py#L1371, torchinductor finds `torch.is_grad_enabled()` is `True` even if the compiled code sets `with torch.no_grad()`.

Reproduction script:

```
import torch
import torch.nn.functional as F

class TestModule(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.conv1 = torch.nn.Conv2d(1, 20, 5)

    def forward(self, x):
        return F.relu(self.conv1(x))

model = TestModule()
example_inputs = torch.randn([1, 1, 10, 10]).cpu()

@torch.compile
def run(model, example_inputs):
    with torch.no_grad():
        # Check inductor grad status at
        # https://github.com/pytorch/pytorch/blob/30610251ec7b8f7e0507df06c3aadbcf90658e0e/torch/_inductor/compile_fx.py#L1371
        # If we print `torch._inductor.config.cpp.weight_prepack` , torchinductor believes torch.is_grad_enabled() is False
        # Otherwise, torchinductor believes torch.is_grad_enabled() is True 
        # print("torch._inductor.config.cpp.weight_prepack", torch._inductor.config.cpp.weight_prepack)
        model(example_inputs)

run(model, example_inputs)
```

### Versions

The latest nightly release (20240503).

cc @ezyang @msaroufim @bdhirsh @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @peterbell10 @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire
Repository: godot
Issue: GPUParticles2D collisions don't work correctly when using particle animations
Labels: bug,topic:2d,topic:particles

### Tested versions

4.2.stable

### System information

Godot v4.2.2.stable.mono - Ubuntu 22.04.4 LTS 22.04 - X11 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1050 Ti (nvidia; 535.171.04) - Intel(R) Core(TM) i5-6600 CPU @ 3.30GHz (4 Threads)

### Issue description

GPUParticles2d collisions are using a wrong collision size when particle animations are used.
[gpuparticles2d_bug.webm](https://github.com/godotengine/godot/assets/11878694/9d08a4f6-3414-4efb-8a04-3cc64b4bf7a6)

The expected behaviour in the shown example is that both particles collide the same with the floor.
[gpuparticles2d_fixed.webm](https://github.com/godotengine/godot/assets/11878694/552bde3f-41a9-4b27-b343-1a808d206dbb)


### Steps to reproduce

-Add a GPUParticles2D to a scene
-Add a sprite sheet texture to it
-Add a CanvasItemMaterial
-Enable particles animation on the material and set its v_ and h_frames

### Minimal reproduction project (MRP)

[gpuparticles2d_bug.zip](https://github.com/godotengine/godot/files/15202869/gpuparticles2d_bug.zip)

The above shown expected behaviour can be achieved with this patch (against 4.3 master):

```
diff --git a/scene/2d/gpu_particles_2d.cpp b/scene/2d/gpu_particles_2d.cpp
index bc39513c03..6dc33567b1 100644
--- a/scene/2d/gpu_particles_2d.cpp
+++ b/scene/2d/gpu_particles_2d.cpp
@@ -216,7 +216,14 @@ void GPUParticles2D::_update_collision_size() {
 	real_t csize = collision_base_size;
 
 	if (texture.is_valid()) {
-		csize *= (texture->get_width() + texture->get_height()) / 4.0; //half size since its a radius
+		int twidth = texture->get_width();
+		int theight = texture->get_height();
+		CanvasItemMaterial *mat = Object::cast_to<CanvasItemMaterial>(get_material().ptr());
+		if (mat && mat->get_particles_animation()) {
+			twidth /= mat->get_particles_anim_h_frames();
+			theight /= mat->get_particles_anim_v_frames();
+		}
+		csize *= (twidth + theight) / 4.0; //half size since its a radius
 	}
 
 	RS::get_singleton()->particles_set_collision_base_size(particles, csize);
```
Repository: PowerToys
Issue: TextExtractor screen problem
Labels: Issue-Bug,Needs-Triage,Needs-Team-Response,Product-Text Extractor

### Microsoft PowerToys version

v0.80.1

### Installation methods

PowerToys auto-update
Winget

### Running as admin

No

### Area(s) with issue?

TextExtractor

### Steps to reproduce

# TextExtractor issue

With the previous version of PowerToys, the precision of the TextExtractor tool was perfect, enabling very precise text selection. Since the latest update, once I hit the shortcut to use TextExtractor it's as if TextExtractor's overlay window moved upwards and no longer focused on my entire screen. It causes the selection to be a very wide area around the text for it to be retrieved. And if the zone isn't wide enough, nothing happens: the tool asks us which zone of text to retrieve.

 - Step 1: trigger the ⊞Win+Maj+T shortcut to launch TextExtractor
 - Step 2: the TextExtractor overlay window appears and shifts a bit upwards and not taking into account the entire screen anymore.
 - Step 3: try selecting a zone close to the text / it won't work as good as previously and might even ask us which zone of text to retrieve.


### ✔️ Expected Behavior

The TextExtractor overlay window should focus the entire screen.

### ❌ Actual Behavior

The TextExtractor overlay window shifts a bit upwards causing some precision issues.

### Other Software

_No response_
Repository: godot
Issue: Godot docs unselected text copied
Labels: bug,topic:editor,topic:gui

### Tested versions

Reproducible in 4.2.2.rc, 4.2.2.stable.

### System information

Windows 10

### Issue description

When selecting text in Godot documentation and dragging cursor too far while selecting, copying that text copies too much text above with no selection indication.

### Steps to reproduce

- Open Godot built-in documentation.
- Select text starting from right, to the left, all the way to the left documentation panel edge.
- Copy it.
- Paste it somewhere.
- Notice that too much text has been copied with no selection indication.

See attached video.

https://github.com/godotengine/godot/assets/58703216/9919ab0f-e8ed-40d8-990f-8bc9bb03b6e4



### Minimal reproduction project (MRP)

N/A
Repository: PowerToys
Issue: Option to hide PowerRename from folder background context menu
Labels: Needs-Triage

### Description of the new feature / enhancement

A setting to hide PowerRename from the context menu that is displayed when right-clicking on the blank space in Explorer or desktop, but keeping it for context menus of selected files and folders.

### Scenario when this would be used?

I prefer the folder background context menu to be less crowded, and appearing for selected files and folders only is also the default behavior for other tools such as File Locksmith and Image Resizer.

### Supporting information

_No response_
Repository: ollama
Issue: model run command not rendered on mobile
Labels: feature request,ollama.com

https://ollama.com/library/phi3:3.8b
 In the page the installation commrnd is not written likw llama and gemma.
Repository: go
Issue: x/net/ipv4: TestRawConnReadWriteUnicastICMP failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/net/ipv4" && test == "TestRawConnReadWriteUnicastICMP"
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/901947ede2219b48bc66118b57003d8f60c5d3d7)):

    --- FAIL: TestRawConnReadWriteUnicastICMP (0.00s)
        unicast_test.go:234: got type=destination unreachable, code=3; want type=echo reply, code=0


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: ollama
Issue: "which/max" command line options to help with sizing.
Labels: feature request

Frequently I have to play with various quants available, I'd like to run instead of downloading and testing each one until I get one that works.  This would save us all some bandwidth.

`ollama which somemodel` to determine which models I can run

`ollama max somemodel` to choose the largest model from a list that I can run.

Not sure how instruct/chat might interact, since those are usually after the colon perhaps with dashes? `ollama which somemodel-instruct` ?  or some wildcard?  `ollama which somemodel:*instruct*` ?
Repository: flutter
Issue: Proposal: use "enhanced enums" in the repo for reduced boilerplate
Labels: framework,c: proposal,P3,team-framework,triaged-framework,refactor

There are a few situations where the same enum logic is implemented over and over again.

<br>

A good example would be distinguishing an `AnimationStatus` between forward/complete and reverse/dismissed.

<details open> <summary>15 <a href="https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#avoid-using-if-chains-or-or-with-enum-values">style guide violations</a> (click to collapse)</summary>

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/demo/material/backdrop_demo.dart#L281

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/demo/shrine/backdrop.dart#L235

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/demo/shrine/expanding_bottom_sheet.dart#L236

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/flutter_gallery/lib/gallery/backdrop.dart#L260

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/pages/splash.dart#L71-L72

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/reply/adaptive_nav.dart#L525-L526

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/shrine/app.dart#L122-L123

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/shrine/backdrop.dart#L214-L215

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/dev/integration_tests/new_gallery/lib/studies/shrine/expanding_bottom_sheet.dart#L343-L344

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/navigation_bar.dart#L1309-L1310

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/navigation_drawer.dart#L691

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/scaffold.dart#L610-L611

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/material/scaffold.dart#L3206-L3207

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/widgets/animated_cross_fade.dart#L320-L321

https://github.com/flutter/flutter/blob/31847bcc4424921e3e5d58901a2573fa8a502758/packages/flutter/lib/src/widgets/routes.dart#L1939-L1940

</details>

Rather than refactoring all of these into switch expressions, I think it'd be best to take advantage of [enhanced enum](https://dart.dev/language/enums#declaring-enhanced-enums) features and improve `AnimationStatus` directly.
Repository: vscode
Issue: screen reader issue since 1.89.0 with open file CTRL+p
Labels: bug,verified,accessibility,quick-pick,regression

<!-- ⚠️⚠️ 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/No
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. -->
- VS Code Version: 1.89.0
- OS Version: Windows 10

Steps to Reproduce:

I'm using NVDA as screen reader, before 1.89.0 this worked:

1. Opening the "search file by name or symbol" with `CTRL+p`
2. If I type path where only 1 file exists, the file name isn't "announced", cannot do up/down arrow as there's only one result.
3. In fact, the first file isn't announce for result with more than one results.

To be clear, image we have the following file/directory tree

|- dir1/
|--- abc.go
|- main.go

Doing CTRL+p and than typing `dir1/` it displayed the `abc.go` file but screen reader says nothing.

For result with multiple file, the first file of the list isn't "sent" to screen reader, doing down arrow and the second file in list is "said" by scree reader.

If I may this is a huge problem.
Thanks
Repository: ollama
Issue: [Feature] Rapid Modelfile Updates
Labels: feature request

Ollama is an absolutely brilliant project. Thank you everyone involved in creating it!

I've been working on local models, and noticed one weakness of Ollama. The initial import obviously has to take some time to convert the GGUF model weights into Ollama's native format. But after that, I need to tweak parameters, stop-words, temperature, template, etc, to perfect the model.

This is where Ollama falls apart a little bit.

First of all, I spent an hour scouring the documentation about how to update a locally created model. Finally, I figured out that if you want to update a locally created model, you have to run `ollama create` with the *exact same* parameters again.

It would be great to add a note about that to these three locations:

- https://github.com/ollama/ollama?tab=readme-ov-file#create-a-model
- https://github.com/ollama/ollama/blob/main/docs/modelfile.md
- https://github.com/ollama/ollama/blob/main/docs/import.md

Anyway, when I finally figured out that you have to "create" the model again, I noticed that it's taking a very long time. 23 seconds to be precise. It reads the model files on disk again, converts them again, hashes them, and finally figures out that the hashes match the on-disk data (`using already created layer sha256:...`), and then it *finally* at long last updates the stored model to match the latest Modelfile contents.

I have two potential ideas for improvements.

- Option 1: Add a flag to `ollama create` with the word `--keep-weights` or similar. This would just do an instantaneous update of the Modelfile parameters, while immediately reusing the latest, previously converted weights.
- Option 2: Automatically detect changed weights, by tracking the file modification timestamp of local model files, and not doing any conversion again if the Modelfile's `FROM` file timestamp matches the same as the previously imported model metadata. This would be a very convenient solution and would avoid user-error (such as users accidentally importing a Modelfile which belongs to another model into a mismatched model name). Ollama could simply alert the user that it detected no changes to the weights, and giving the user an alert that they can run again with `--convert-weights` if they want to force weight-conversion again anyway (someone might want that?).

Anyway, I really hope that this can be improved in some way, because waiting half a minute after every tiny Modelfile parameter tweak, just to check the changes, is a very tedious process. Other than this, Ollama has been absolutely perfect! :)
Repository: pytorch
Issue: Error calling to_sparse_coo() on any subclass of Tensor
Labels: module: sparse,triaged,tensor subclass

### 🐛 Describe the bug

```
import torch

class Temp(torch.Tensor):
    pass

# Works
torch.zeros(0).to_sparse_coo()

# Breaks
Temp(torch.zeros(0)).to_sparse_coo()
```

Full traceback:
```
Traceback (most recent call last):
  File "/tmp/sparse2.py", line 10, in <module>
    Temp(torch.zeros(0)).to_sparse_coo()
  File "/root/.pyenv/versions/3.11.6/lib/python3.11/site-packages/torch/_tensor.py", line 1331, in to_sparse_coo
    return self.to_sparse()
           ^^^^^^^^^^^^^^^^
  File "/root/.pyenv/versions/3.11.6/lib/python3.11/site-packages/torch/_tensor.py", line 1401, in __torch_function__
    return _convert(ret, cls)
           ^^^^^^^^^^^^^^^^^^
  File "/root/.pyenv/versions/3.11.6/lib/python3.11/site-packages/torch/_tensor.py", line 1491, in _convert
    ret = ret.as_subclass(cls)
          ^^^^^^^^^^^^^^^^^^^^
NotImplementedError: Cannot access storage of SparseTensorImpl
```

The issue is specifically introduced with by wrapping the tensor in a dummy subclass.

### Versions

I can't disclose versions due to company security policy, but it's modern.

cc @alexsamardzic @nikitaved @pearu @cpuhrsch @amjames @bhosmer @jcaip @ezyang @msaroufim @albanD