sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/tools/gopls: IExportShallow returns unexpected error
Labels: NeedsInvestigation,gopls,Tools,gopls/telemetry-wins

```
#!stacks
"bug.Reportf" && "cache.(*typeCheckBatch).checkPackageForImport.func3:+3"
```
Issue created by [stacks](https://pkg.go.dev/golang.org/x/tools/gopls/internal/telemetry/cmd/stacks).

Not much to go on here....

```go
		exportData, err := gcimporter.IExportShallow(b.fset, pkg, bug.Reportf)
		if err != nil {
			bug.Reportf("exporting package %v: %v", ph.mp.ID, err)  // <---
			return
		}
```

This stack `jE2A4w` was [reported by telemetry](https://storage.googleapis.com/prod-telemetry-merged/2024-12-29.json):

- `gopls/bug`
- [`golang.org/x/tools/gopls/internal/util/bug.report:+35`](https://cs.opensource.google/go/x/tools/+/gopls/v0.15.3:gopls/internal/util/bug/bug.go;l=109)
- [`golang.org/x/tools/gopls/internal/util/bug.Reportf:+1`](https://cs.opensource.google/go/x/tools/+/gopls/v0.15.3:gopls/internal/util/bug/bug.go;l=54)
- [`golang.org/x/tools/gopls/internal/cache.(*typeCheckBatch).checkPackageForImport.func3:+3`](https://cs.opensource.google/go/x/tools/+/gopls/v0.15.3:gopls/internal/cache/check.go;l=737)
- `runtime.goexit:+0`
```
golang.org/x/tools/gopls@v0.15.3 go1.22.4 darwin/arm64 other (1)
```
Repository: rust
Issue: rustdoc search: for argument based searches, deprioritize associated items
Labels: A-type-based-search,A-rustdoc-search,T-rustdoc-frontend

Inspired by discussion on https://github.com/rust-lang/rust/pull/131806, opening an issue so it can be discussed separately.

currently, both "In Parameters" and "Type ->" searches are dominated by methods on that type (and if the aforementioned PR is merged, fields will also clutter such searches)

however, associated items for a type can easily be viewed simply by going to that type's page, so arguably this form of search should prioritize free functions and methods of *other* types, which are harder to find.

this could be considered the dual of https://github.com/rust-lang/rust/issues/134935
Repository: pytorch
Issue: torch.utils.flop_counter.FlopCounterMode
Labels: triaged,module: flop counter

I found this class because it was referenced in the llama_recipes repo.

My question is whether this definition counts one addition and one multiplication and 2 FLOPs, or, if that's counted as 1 FLOP?

When reporting on GPU hardware, it's common to count the above as two flops.

But when reporting on models, it's common to count the above as one flop... the more accurate term would have been "MAC" - Multiply-Accumulate. But I believe the model literature just started calling it a "flop". 

https://github.com/facebookresearch/fvcore/issues/69

This source strongly suggests that the reported value matches HW flops (a single multiply followed by a single add counts as two flops), since at the number of multiplications required for a matmul of two matrices of shapes MxK and KxN is MxKxN, and the number of additions is Mx(K-1)xN, commonly approximated to MxKxN, yielding 2xMxKxN. 

https://github.com/pytorch/pytorch/blob/baee623691a38433d10843d5bb9bc0ef6a0feeef/torch/utils/flop_counter.py#L55C1-L64C25
Repository: flutter
Issue: "Check Flakiness Status of a Test" Dashboard is broken
Labels: team-infra

[The "Check Flakiness Status of a Test" dashboard](https://data.corp.google.com/sites/dash_infra_metrics_datasite/flutter_check_test_flakiness_status_dashboard/) is no longer populating the flaky rates for various pools.  Checking the staging pool test flake rate is (one way) we decide to turn "bringup" tests back on.

The flakiness bot is [creating new issues](https://github.com/flutter/flutter/issues/160840) at least of 5 days ago, so possibly a dashboard issue, or the flakiness detection broke in the last 5 days.
Repository: material-ui
Issue: [Dialog] Focus lost on non-modal dialog after interacting with a full screen dialog
Labels: accessibility,support: question,waiting for 👍,component: dialog,component: modal

### Steps to reproduce

Steps:
1. Open this link to live example: https://codesandbox.io/p/sandbox/exciting-banzai-m76rln
2. The chat dialog is open by default. Open the full screen dialog by clicking on the button below the app bar.
3. Notice that the chat bot window can still be used and a message can be typed in the textfield.
4. Click on something in the full screen dialog, like the dropdown or list item.
5. You can't change the focus back to the chat bot text field anymore.

### Current behavior

The chat bot text field isn't set to focused anymore once you interact with the full screen dialog.

### Expected behavior

The chat bot text field should still be able to be focused.

### Context

We've found that by adding the `disableEnforceFocus` prop on the full screen dialog obviously works (as many others have pointed out) and allows the chat bot text field to be focused no matter what you do in the background. However, we have two questions related to this:
1. Why does this work in the very beginning before you interact with something on the full screen dialog? Is this a bug of some sort?
2. We have a lot of dialogs and drawers and other things in our UI. Is the only option to add this prop, `disableEnforceFocus`, for each one or is there something we can just set on the chat bot type dialog instead to make it easier?

### Your environment

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  System:
    OS: macOS 15.2
  Binaries:
    Node: 20.12.2 - /usr/local/bin/node
    npm: 10.5.0 - /usr/local/bin/npm
    pnpm: Not Found
  Browsers:
    Chrome: 131.0.6778.205
    Edge: Not Found
    Safari: 18.2
  npmPackages:
    @emotion/react: ^11.14.0 => 11.14.0 
    @emotion/styled: ^11.14.0 => 11.14.0 
    @mui/base:  5.0.0-beta.68 
    @mui/core-downloads-tracker:  6.3.0 
    @mui/lab: ^6.0.0-beta.21 => 6.0.0-beta.21 
    @mui/material: ^6.2.1 => 6.3.0 
    @mui/private-theming:  6.3.0 
    @mui/styled-engine:  6.3.0 
    @mui/system:  6.3.0 
    @mui/types:  7.2.20 
    @mui/utils:  6.2.1 
    @mui/x-data-grid:  7.23.3 
    @mui/x-data-grid-pro: ^7.21.0 => 7.23.3 
    @mui/x-date-pickers:  7.23.3 
    @mui/x-date-pickers-pro: ^7.21.0 => 7.23.3 
    @mui/x-internals:  7.23.0 
    @mui/x-license: ^7.21.0 => 7.23.2 
    @types/react: ^18.3.17 => 18.3.17 
    react: ^18.3.1 => 18.3.1 
    react-dom: ^18.3.1 => 18.3.1 
    typescript: ^5.6.3 => 5.7.2 
```
</details>


**Search keywords**: non-modal dialog, chatbot, disableEnforceFocus
Repository: godot
Issue: Imported audio `loop_offset` is ignored by `AudioStreamPlayer` in `PLAYBACK_TYPE_SAMPLE` (web)
Labels: bug,platform:web,topic:audio

### Tested versions

- Reproducible in v4.3.stable.flathub [77dcf97d8]

### System information

Godot v4.3.stable (77dcf97d8) - Freedesktop SDK 24.08 (Flatpak runtime) - X11 - GLES3 (Compatibility) - Mesa Intel(R) HD Graphics 5500 (BDW GT2) - Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz (4 Threads)

### Issue description

I've imported a `.ogg` audio with looping enabled, and it needs a loop offset.
But this offset is ignored on the Web platform, i.e. when playback type is Sample, it's looping to zero (beginning of music).
It loops to the expected point on web if I force playback type to Stream.

Is it just not supported, or is it a bug? Docs say:
> [AudioEffect](https://docs.godotengine.org/en/stable/classes/class_audioeffect.html#class-audioeffect)s are not supported when playback is considered as a sample.

But I think this is different? I would think if looping is supported at all, then it should be trivial to support the offset.

### Steps to reproduce

Just import some music with loop enabled and a noticeable loop offset.
Then run the exported web project while keeping playback type the default in the `AudioStreamPlayer`.

If it makes any difference, I used `.ogg` music, an autoload node for the audio player, and called `play()` from code. And the loop point is only slightly offset from the start (3.057 seconds).

### Minimal reproduction project (MRP)

N/A
Repository: godot
Issue: C# Library import issues for GPUParticles3D/CPUParticles3D etc
Labels: enhancement,discussion,documentation,topic:dotnet

### Tested versions


Discovered in Godot v4.3.stable.mono.official [77dcf97d8]
Other versions unknown.

### System information

Godot v4.3.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - integrated AMD Radeon(TM) Graphics (Advanced Micro Devices, Inc.; 31.0.21910.5) - AMD Ryzen 5 5500U with Radeon Graphics (12 Threads)

### Issue description

Greetings!
There seems to be a mismatch between documentation and actual design when it comes to GPUParticles3D and all related nodes. In the documentation it is listed as "GPUParticles3D", but in GodotSharp.xml (_root_/GodotSharp/Api/Release/GodotSharp.xml) it is listed as "GpuParticles3D".
Thus, when trying to use GPUParticles3D, one gets the error "The type or namespace name 'CPUParticles3D' could not be found (are you missing a using directive or an assembly reference?)" because GPUParticles3D doesn't actually exist, only GpuParticles3D exists.

Of course, newly armed with this knowledge I can easily continue my work, but this was a stumbling block for me and I'm sure it will be for many others unless the documentation matches the xml file, regardless of which side yields to the other. 

Tl:Dr:
Please ether change the _root_/GodotSharp/Api/Release/GodotSharp.xml to match with "GPUParticles3D" and "CPUParticles3D" etc or change the documentation and syntax highlighting to match the xml file's GpuParticles3D and CpuParticles3D.

So, it's not a Godot breaker, but it is a rough edge that I'd like to see patched up!
Cheers!

### Steps to reproduce

Add GPUParticles3D into your code, at any point, and compile for immediate results.
I first discovered it with
GPUParticles3D dustParticles = new GPUParticles3D();

### Minimal reproduction project (MRP)

N/A
Repository: excalidraw
Issue: Feature: Squared Paper
Labels: enhancement,UX/UI

It would be nice if there was an option to make the Background like squared Paper, for School related work.
For example writing math equations is much more convenient on checkered paper than on a plane white canvas
Repository: rust
Issue: #[thread_local] + #[no_mangle] produces a "symbol already defined" error on Windows targets
Labels: O-windows,T-compiler,A-thread-locals,C-bug,F-thread_local

```rust
#![feature(thread_local)]

#[no_mangle]
#[thread_local]
pub static FOO: u32 = 3;
```
Does not compile on x86_64-pc-windows-msvc and x86_64-pc-windows-gnu, due to:
```
error: symbol `FOO` is already defined
 --> lib.rs:5:1
  |
5 | pub static FOO: u32 = 3;
  | ^^^^^^^^^^^^^^^^^^^

error: aborting due to 1 previous error
```

Found this while working on https://github.com/rust-lang/rust/pull/134777
Repository: pytorch
Issue: [dynamo][guards][feature] Do not realize LazyVariableTracker on `isinstance` checks
Labels: triaged,oncall: pt2,module: dynamo

### 🐛 Describe the bug

Today, calling `isinstance` on LazyVariableTracker realizes the VT, inserting the guards. In many cases, this guard insertion is accidental and not really required for program correctness.

I am not sure how to do this exhaustively. Maybe we can look at the value of the LazyVariableTracker and support isinstance checks for a few common VTs.

### Error logs

_No response_

### Versions

NA

cc @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng @amjames
Repository: ollama
Issue: Incorrect NUMA detection logic, fails for AMD Threadripper 1950X
Labels: bug

### What is the issue?

On my AMD Threadripper 1950X CPU with NUMA mode enabled in the BIOS, ollama does not detect that I am running on a NUMA system due to flawed logic in its detection code here: https://github.com/ollama/ollama/blob/459d822b5188dba051e21dfd15b6552543a4bbcf/discover/cpu_common.go#L10-L24

I can "trick" ollama into detecting NUMA by setting up fake information in `/sys/devices/system/cpu/cpu*/topology/physical_package_id` using `overlayfs`, which gives me a ~20% speedup for CPU-only eval-rate (tested with gemma2:27b).

The problem in the logic is that it counts how many physical CPU packages are in the system, but my system has a single CPU package containing 2 dies each with their own memory controller.

A naïve fix would be to look at `die_id` rather than `physical_package_id`: this would work for me but I fear there may exist other hardware which has multiple dies sharing a single memory controller.  Also even on my system I can disable NUMA in the BIOS so that memory access appears to be uniform - under the hood this interleaves memory access across both NUMA nodes.  So in this mode looking at `die_id` would give the wrong answer.

A better fix would be to look at the actual NUMA node information presented by the kernel under `/sys/devices/system/node`, e.g. on my system the file `/sys/devices/system/node/online` contains `0-1` whereas on a uniform memory system it contains `0`.

### OS

Linux

### GPU

Nvidia

### CPU

AMD

### Ollama version

0.5.4
Repository: flutter
Issue: Linux and Windows flutter_packaging is marked bringup
Labels: team-infra

Linux and Windows flutter_packaging in .ci.yaml is:
https://github.com/flutter/flutter/blob/3762f2e9731ce97808fb2d78805f6712be83654d/.ci.yaml#L6925-L6932

1. It's labeled bringup I believe due to https://github.com/flutter/flutter/issues/139597 which isn't happening any more.
1. It's not visible on the [beta](https://flutter-dashboard.appspot.com/#/build?repo=flutter&branch=beta&showStaging=true&showBringup=true) or [stable](https://flutter-dashboard.appspot.com/#/build?repo=flutter&branch=stable&showStaging=true&showBringup=true) dashboards even though it appears that's where it should be running based on enabled_branches? 
2. I don't have permission to see the [luci console](https://ci.chromium.org/ui/p/flutter/builders/staging/Linux%20flutter_packaging) so maybe this is all working?

Is the right thing to do remove `bringup` for these two builders?
Repository: vscode
Issue: Configure coverage testing profile
Labels: bug,testing

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

The coverage testing profile should be configurable in the same manner as other kinds of testing profiles. From an outside perspective this seems like it should be a simple matter of adding a menu to the coverage run button.

![Image](https://github.com/user-attachments/assets/10eeee06-b454-4afa-825c-b745ab20ea36)

Rationale: When I execute `go test` there's a `-coverpkg` flag I can pass to control the scope of what code gets instrumented for coverage. In some cases it's natural to show coverage for the entire project, where in other cases it's natural to show coverage only for a single package.
Repository: PowerToys
Issue: [Advanced paste] new feature request - Other/Custom AI Provider Selection in "AI Prompt"
Labels: Needs-Triage

### Description of the new feature / enhancement

When “AI Prompt” is enabled, it would be beneficial to be able to select which AI provider to use. This would allow users to choose from providers such as OpenAI, Gemini, Claude, Mistral, or a custom OpenAI endpoint.

### Scenario when this would be used?

When working as a freelancer, some of my customers provide specific AI endpoints that have been validated by their security teams. Currently, users have to manually copy and paste these endpoints into the respective AI provider interfaces. Being able to configure the AI provider directly within the application would save a significant number of intermediate steps and improve efficiency.

### Supporting information

_No response_
Repository: godot
Issue: [4.4.dev7] Clicking on Play Animation in the Animation tab frequently freezes the engine
Labels: bug,topic:editor,needs testing,topic:animation

### Tested versions

- Reproducable in all version from 4.4.dev7 to 4.0.stable on Windows
- Did not test if reproducible before 4.0.stable

### System information

Godot v4.4.dev7 - Windows 11 (build 26100) - Multi-window, 2 monitors - Vulkan (Forward+) - dedicated NVIDIA GeForce RTX 3070 Laptop GPU (NVIDIA; 32.0.15.6603) - 11th Gen Intel(R) Core(TM) i7-11800H @ 2.30GHz (16 threads)

### Issue description

Clicking on the Play Animation button frequently causes Godot to stop responding. Freeze happens roughly between 0.6 - 0.9 seconds after animation began playing.
![Image](https://github.com/user-attachments/assets/98171271-4b9b-4209-99cf-aaf8bad8d14f)


### Steps to reproduce

1. Create a new scene with an Animation Player
2. Add a new animation to the player
3. Click on Play Animation and wait for the animation to finish playing
4. If Godot didn't freeze while the animation was playing, repeatedly perform step 3

### Minimal reproduction project (MRP)

N/A
Repository: flutter
Issue: Permission 'cloudkms.cryptoKeyVersions.useToDecrypt' denied on resource 'projects/flutter-infra-staging/locations/global/keyRings/luci/cryptoKeys/flutter-infra' 
Labels: team-infra

`Linux packages_autoroller` is marked flaky as of https://github.com/flutter/flutter/issues/160473 which is pointing to a flaking gradle issue.

However this build is newly flaking (seen in [Linux%20packages_autoroller/3144](https://ci.chromium.org/ui/p/flutter/builders/staging/Linux%20packages_autoroller/3144/overview)) with a `PermissionDenied` error for a cloudkms crypto key.
```
 [E2024-12-22T11:06:10.784181-08:00 14938 0 decrypt.go:37] Error while making request
 [E2024-12-22T11:06:10.784257-08:00 14938 0 common.go:325] Error while executing command               
{"error":"rpc error: code = PermissionDenied desc = Permission 'cloudkms.cryptoKeyVersions.useToDecrypt' denied on resource 'projects/flutter-infra-staging/locations/global/keyRings/luci/cryptoKeys/flutter-infra' (or it may not exist)."}
```
https://ci.chromium.org/ui/p/flutter/builders/prod/Linux%20packages_autoroller/12884/overview

See recipe at https://cs.opensource.google/flutter/recipes/+/master:recipe_modules/kms/api.py;l=32;drc=a73eacefcd83b580fedfa6b30be6b8451087cbb1
Repository: go
Issue: x/tools/gopls: PathEnclosingInterval is inappropriate for single-point LSP queries
Labels: gopls

The handlers for most gopls RPCs start by computing the node in the syntax tree that is identified by the selection.

An [unfortunate](https://github.com/microsoft/language-server-protocol/issues/377) limitation of LSP is that in most cases the RPC request indicates the selection by only a single point, the cursor position, losing valuable information. Indicating the selection by '[' and ']' and the cursor by '⁁', in this example:

    [break]⁁ label

the `break` keyword is selected, but the server can tell only that the cursor is after `break`. In:

    [break ]⁁label

the selection is the `break` keyword plus the following space, but the server knows only that the cursor is before `label`. And in:

    [break]⁁

the selection is the `break` keyword alone, but the server gets only the position after the 'k'.

Gopls makes extensive use of [astutil.PathEnclosingInterval](https://pkg.go.dev/golang.org/x/tools/go/ast/astutil#PathEnclosingInterval) for inferring the syntax node from a given selection (start, end). When invoked on an empty selection (end=start), which is the common case in gopls because of the limitation described above, it behaves as if invoked on the interval (start, start+1).  That means that it operates
- in the first example on the space between `break` and `label`, and returns the `BranchStmt` (a reasonable answer);
- in the second case on the first "l" of `label`, returning the `Ident` (again reasonable); but
- in the third on the newline following `break`, returning the enclosing `BlockStmt`, which is not helpful.

It is the wrong tool for the job.

Until such time as LSP furnishes the server with both the start and end points of the selection (which may be a long wait), I propose that we introduce a new function for all single-position queries in gopls that gives the right answers in all three cases (respectively: BranchStmt, Ident, BranchStmt).

@madelinekalil
Repository: next.js
Issue: NextJS is reporting Node warnings as errors instead of warnings in the browser
Labels: Runtime

### Link to the code that reproduces this issue

https://github.com/olivierr91/next-console-error-bug-repro

### To Reproduce

1. Start the application in development (next dev)
2. Navigate to the page in the browser (http://localhost:3000)
3. The following server error is thrown in the browser:

```
(node:33588) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use `node --trace-warnings ...` to show where the warning was created)
```

![image](https://github.com/user-attachments/assets/204189f7-62de-4405-bc8d-228a54d21c27)


### Current vs. Expected behavior

Node warnings like this should not throw errors in the browser. We should be able to change the value of NODE_TLS_REJECT_UNAUTHORIZED without Next throwing errors and inconveniencing the developer on every page load. 

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Enterprise
  Available memory (MB): 65376
  Available CPU cores: 16
Binaries:
  Node: 22.12.0
  npm: 10.9.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.1.1-canary.23
  eslint-config-next: N/A
  react: 19.0.0
  react-dom: 19.0.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Developer Experience, Runtime

### Which stage(s) are affected? (Select all that apply)

next dev (local)

### Additional context

Issue is new in v15 and was not present in v14
Repository: deno
Issue: `deno compile` should not surface graph errors for modules specified on `--include`
Labels: bug,compile

https://github.com/denoland/deno/issues/17994#issuecomment-2565983918
Repository: next.js
Issue: Cannot rewrite to external URL when basePath option is defined in next.config.js contains a hyphen
Labels: Middleware,Internationalization (i18n),Runtime

### Link to the code that reproduces this issue

https://github.com/massaynus/next-rewrite-issue

### To Reproduce

1. start app in dev mode
2. open network tab in dev tools and  access the app in `http://localhost:3000/mj-builder`
3. notice how the rewrite which has the app basePath and locale in it fails to execute the rewrite even if the url is computed correctly

### Current vs. Expected behavior

if the `basePath` in next.config.mjs is set to `/app` for example it works fine, it should be the same for `basePaths` with a hyphen in them like the value `mj-builder` showin in the example repo

### Provide environment information

```bash
/bin/sh: 1: yarn: not found
/bin/sh: 1: pnpm: not found

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Tue Nov 5 00:21:55 UTC 2024
  Available memory (MB): 31943
  Available CPU cores: 20
Binaries:
  Node: 20.17.0
  npm: 11.0.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 15.1.3 // Latest available version is detected (15.1.3).
  eslint-config-next: 15.1.0
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.7.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

Developer Experience, Internationalization (i18n), Middleware, Runtime

### Which stage(s) are affected? (Select all that apply)

next dev (local), next build (local), next start (local), Other (Deployed)

### Additional context

first discovered the issue on v15.1.0 then tested on v15.1.3 and also canary to confirm the issue.
issue is reproducible everywhere it seems!