sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Visual shader plugin complains about missing version and category
Labels: discussion,topic:editor,topic:shaders

### Tested versions

4.3 rc3

### System information

Godot v4.3.rc3 - Nobara Linux 40 (GNOME Edition) - Wayland - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 3050 Ti Laptop GPU - 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz (8 Threads)

### Issue description

Unless I've misread, this page seems to indicate that these are optional:

https://docs.godotengine.org/en/stable/classes/class_visualshadernodecustom.html#class-visualshadernodecustom

But still I get this:

![image](https://github.com/user-attachments/assets/dba13912-4922-488b-979f-9e86db656c31)

And not sure why the other errors don't correspond to a line in my .gd file but rather some other files I don't know how to debug, because I'm just slightly modifying [this example](https://docs.godotengine.org/en/stable/tutorials/plugins/editor/visual_shader_plugins.html), and haven't changed much.

But still I've seen at least the category warning in [another plugin](https://github.com/arkology/ShaderV/issues/25) and seems it shouldn't be there.

### Steps to reproduce

Try to use the attached shader.

### Minimal reproduction project (MRP)

[VSSimplexNoise3D.zip](https://github.com/user-attachments/files/16591554/VSSimplexNoise3D.zip)
Repository: pytorch
Issue: Adafactor compile support tracker
Labels: module: optimizer,triaged,oncall: pt2

### 🚀 The feature, motivation and pitch

The single tensor version of Adafactor has already landed in https://github.com/pytorch/pytorch/pull/129905 with foreach Adafactor in progress here: #132336. 

This issue is to track torch.compile support:
- [ ] Ensure single tensor Adafactor can run and is tested
- [ ] Ensure foreach Adafactor can run and is tested
    - [ ]  Adafactor foreach relies on the grouping logic to return a non-None dtype value in order to calculate eps1 in the default case. Historically, torch.compile has skipped the grouping logic as it's already handled in inductor and returned Nones for device and dtype. This is the most visible hurdle for lack of compile support in the foreach case today.

### Alternatives

_No response_

### Additional context

Adafactor is our first param-wise (not pointwise, not global) optimizer. There are many improvements left to be desired in the eager foreach implementation by supporting more foreach ops. Compile support would be pretty cool though.

cc @vincentqb @jbschlosser @albanD @crcrpar @ezyang @chauhang @penguinwu
Repository: godot
Issue: Code completion shortcut (CTRL+SPACE) does not work without a filter (e.g. on blank lines before you start typing)
Labels: enhancement,topic:editor,usability,topic:gui

### Tested versions

- Reproducible in v4.2.2.stable.flathub [15073afe3]

I don't ever remember Godot not having this issue.

### System information

Godot v4.2.2.stable (15073afe3) - Freedesktop SDK 23.08 (Flatpak runtime) - X11 - Vulkan (Forward+) - integrated Intel(R) HD Graphics 5500 (BDW GT2) () - Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz (4 Threads)

### Issue description

Pressing the `ui_text_completion_query` shortcut like <kbd>Ctrl</kbd> <kbd>Space</kbd> should always trigger code completion, listing every API available on that context.

Instead it only triggers after a prefix (e.g. where I started typing `a`, filtering identifiers that have `a`).
This is very inconvenient as I often want to list everything available, as I don't know yet what I'm looking for.

Please implement unfiltered completion.
Preferably with (perhaps configurable) [well-defined useful ordering](https://github.com/microsoft/vscode/issues/80444), such as e.g.:
- Local variables first (closest above cursor first)
- Current class members (closest to cursor first)
- Inherited members (nearest super-class in inheritance chain first)
- Language keywords in the middle (alphabetic)
- Global functions (alphabetic)
- Global engine classes (alphabetic)
- Global user classes last, for easy access (alphabetic)

### Steps to reproduce

Create a new GDScript or GDShader code and press CTRL-SPACE on a blank line.
An example is on the line before `pass` in this code:
```gdscript
@tool extends EditorScript

func _run() -> void:
	
	pass

```
Same issue happens inside e.g. a method argument like `foo(` | `)` -- when I haven't yet typed anything, I don't get any completion at all.

### Minimal reproduction project (MRP)

N/A
Repository: ollama
Issue: Change log for updated models on website?
Labels: feature request

Seemed for the past few days llama3.1 models on the website had been constantly updated every couple of hours, wondering is there an changelog to see what's changed (specifically which size of models were updated)? 

Ps. attached image was captured just now, indicating the model was updated about an hour ago.

![Screenshot 2024-08-13 at 5 48 52 AM](https://github.com/user-attachments/assets/9944ffb8-f321-4f5b-a333-2268ac78e566)
Repository: storybook
Issue: [Bug]: TypeError [ERR_INVALID_ARG_TYPE] with test-runner and ES6 package
Labels: bug,needs triage

### Describe the bug

I'm seeing an error when trying to use the test-runner with ES6 modules. 

```
TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string or an instance of URL. Received undefined
    at Object.fileURLToPath (node:internal/url:1459:11)
    at getModulePath (/Users/scottnath/development/deletable/storybook-test-runner-playwright/node_modules/lighthouse/shared/esm-utils.js:24:14)
    at getModuleDirectory (/Users/scottnath/development/deletable/storybook-test-runner-playwright/node_modules/lighthouse/shared/esm-utils.js:31:23)
    at Object.<anonymous> (/Users/scottnath/development/deletable/storybook-test-runner-playwright/node_modules/lighthouse/shared/localization/locales.js:31:19)
    at Module._compile (node:internal/modules/cjs/loader:1369:14)
    at extensions..js (/Users/scottnath/development/deletable/storybook-test-runner-playwright/node_modules/esbuild-register/dist/node.js:4840:15)
    at Module.load (node:internal/modules/cjs/loader:1206:32)
    at Module._load (node:internal/modules/cjs/loader:1022:12)
    at Module.require (node:internal/modules/cjs/loader:1231:19)
    at require (node:internal/modules/helpers:179:18)
```

### Reproduction link

https://github.com/scottnath/storybook-test-runner-playwright

### Reproduction steps

1. install npm, etc
2. run storybook
3. run test-storybook
4. see failure
5. in test-runner.ts, comment out `playAudit` pieces
6. run test-storybook
7. passes (a11y throws errors, but unrelated to this bug)

### System

```bash
Storybook Environment Info:

  System:
    OS: macOS 14.2.1
    CPU: (16) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.12.2 - ~/.nvm/versions/node/v20.12.2/bin/node
    Yarn: 1.22.22 - ~/.nvm/versions/node/v20.12.2/bin/yarn
    npm: 10.7.0 - ~/.nvm/versions/node/v20.12.2/bin/npm <----- active
    pnpm: 9.1.0 - ~/Library/pnpm/pnpm
  Browsers:
    Chrome: 127.0.6533.100
    Safari: 17.2.1
  npmPackages:
    @storybook/addon-essentials: ^8.3.0-alpha.4 => 8.3.0-alpha.4
    @storybook/addon-links: ^8.3.0-alpha.4 => 8.3.0-alpha.4
    @storybook/blocks: ^8.3.0-alpha.4 => 8.3.0-alpha.4
    @storybook/test: ^8.3.0-alpha.4 => 8.3.0-alpha.4
    @storybook/test-runner: ^0.19.1 => 0.19.1
    @storybook/web-components: ^8.3.0-alpha.4 => 8.3.0-alpha.4
    @storybook/web-components-vite: ^8.3.0-alpha.4 => 8.3.0-alpha.4
    storybook: ^8.3.0-alpha.4 => 8.3.0-alpha.4
```


### Additional context

After more digging, this is a problem with the `lighthouse` dependency inside of playwright-lighthouse. Looks like webpack was causing the same problem:
https://github.com/GoogleChrome/lighthouse/issues/15007

That user removed webpack to fix it, but that's not relevant here.

Alternate fixes I've tried are putting either an `import()` or `require()` within the `postVisit`, specifically for the `lighthouse` dependency, but alas, same `path` error
Repository: node
Issue: parallel/test-esm-loader-hooks-inspect-wait child process crashes
Labels: s390,flaky-test,linux

### Test

parallel/test-esm-loader-hooks-inspect-wait

### Platform

Linux s390x, Linux x64

### Console output

```console
04:52:51 not ok 1100 parallel/test-esm-loader-hooks-inspect-wait
04:52:51   ---
04:52:51   duration_ms: 710.56400
04:52:51   severity: fail
04:52:51   exitcode: 1
04:52:51   stack: |-
04:52:51     [test] Connecting to a child Node process
04:52:51     [test] Testing /json/list
04:52:51     [err] Debugger listening on ws://127.0.0.1:36913/4edb9b89-b057-4298-8732-067307515397
04:52:51     [err] For help, see: https://nodejs.org/en/docs/inspector
04:52:51     [err] 
04:52:51     [err] Debugger attached.
04:52:51     [err] 
04:52:51     [err] Waiting for the debugger to disconnect...
04:52:51     [err] 
04:52:51     [err] child process crashed, signal SIGSEGV
04:52:51     AssertionError [ERR_ASSERTION]: Expected values to be strictly equal:
04:52:51     
04:52:51     null !== 0
04:52:51     
04:52:51         at runTest (/home/iojs/build/workspace/node-test-commit-linux/test/parallel/test-esm-loader-hooks-inspect-wait.js:30:10)
04:52:51         at process.processTicksAndRejections (node:internal/process/task_queues:105:5) {
04:52:51       generatedMessage: true,
04:52:51       code: 'ERR_ASSERTION',
04:52:51       actual: null,
04:52:51       expected: 0,
04:52:51       operator: 'strictEqual'
04:52:51     }
04:52:51     1
04:52:51   ...
```


### Build links

- https://ci.nodejs.org/job/node-test-commit-linux/nodes=ubuntu2204-64/59487/consoleFull
- https://ci.nodejs.org/job/node-test-commit-linux/nodes=fedora-latest-x64/59490/consoleFull
- https://ci.nodejs.org/job/node-test-commit-linux-containered/nodes=ubuntu2204_sharedlibs_openssl31_x64/45197/consoleFull
- https://ci.nodejs.org/job/node-test-commit-linux-containered/45241/nodes=ubuntu2204_sharedlibs_smallicu_x64/consoleFull
- https://ci.nodejs.org/job/node-test-commit-linuxone/nodes=rhel9-s390x/45008/consoleFull

### Additional information

According to https://github.com/nodejs/reliability/issues?q=is%3Aissue+is%3Aopen+%22test-esm-loader-hooks-inspect-wait%22 this started showing up from the [9 August reliability report](https://github.com/nodejs/reliability/issues/944).
Repository: godot
Issue: GDShader allows commas in `for` conditions (middle part) incorrectly
Labels: enhancement,topic:shaders

### Tested versions

- Reproducible in v4.2.2.stable.flathub [15073afe3]

### System information

Godot v4.2.2.stable (15073afe3) - Freedesktop SDK 23.08 (Flatpak runtime) - X11 - Vulkan (Forward+) - integrated Intel(R) HD Graphics 5500 (BDW GT2) () - Intel(R) Core(TM) i5-5300U CPU @ 2.30GHz (4 Threads)

### Issue description

GDShader is allowing commas in `for` middle part (condition), requiring every comma-separated part to be a boolean operator. Since GDShader (thankfully!) doesn't have a "comma operator" like in GLSL, this has to be a bug.

The compiler should either:
- Preferably, ***not allow a comma in the middle (condition) part of `for`***, while still allowing it on 1st part (to declare multiple variables) and on 3rd part (to run multiple instructions, e.g. to do `i++, j++`). This is consistent with `while`, which does NOT allow commas.
- The worse option: allow `,` PROPERLY with comma operator semantics, so only the last comma-separated part has to be a boolean in a condition area. But I'm strongly against adding a comma operator that works everywhere, as it's a very confusing syntax. It's only actually useful in the 3rd part of `for`.

Additionally, I don't understand why the `for` condition part requires a boolean *operator*. It makes more sense to allow any expression returning a boolean, e.g. some bool function, some bool variable, literals `true` and `false`, etc.

### Steps to reproduce

`buggy.gdshader`
```glsl
shader_type canvas_item;

void fragment() {
  for (int i = 0, j = 0; 1 == 2, j <= 10; i++, j++)
    COLOR = vec4(float(i)/10.0, float(j)/10.0, 0, 1);
  // yellow texture shows the comma operator is being accepted on the `for` condition (2nd part) too
  // but the editor incorrectly expects every part of the comma to be a boolean operator expression
}

```

### Minimal reproduction project (MRP)

N/A
Repository: pytorch
Issue: Fakeification fails through combination of subclass, .grad, and ._base having different ndims
Labels: triaged,tensor subclass,oncall: pt2,module: fakeTensor,module: aotdispatch,module: pt2-dispatcher

This appears to show up in the AO repro here: https://github.com/pytorch/ao/issues/652

We have a tensor `t` that is a `DTensor,` such that:
```
t._base.ndim == 2
t.grad._local_tensor._base.ndim == 1
```

This ends up failing in fakification, because explicitly pretend that `t` and `t.grad` have the same `symbolic_context` structures during fakeification here: https://github.com/pytorch/pytorch/blob/main/torch/_subclasses/meta_utils.py#L1541

Manually constructed minimal repro:
```
import torch

class MyTensor(torch.Tensor):
    @staticmethod
    def __new__(cls, a):
        shape = a.shape
        kwargs = {}
        kwargs["strides"] = a.stride()
        kwargs["storage_offset"] = a.storage_offset()
        kwargs["device"] = a.device
        kwargs["layout"] = a.layout
        kwargs["requires_grad"] = a.requires_grad
        kwargs["dtype"] = a.dtype
        out = torch.Tensor._make_wrapper_subclass(cls, shape, **kwargs)
        return out

    def __init__(self, a):
        self.a = a

    def __repr__(self):
        return f"MyTensor({self.a})"

    @classmethod
    def __torch_dispatch__(cls, func, types, args, kwargs=None):
        return func(args[0].a, *args[1:], **kwargs)

    def __tensor_flatten__(self):
        return ["a"], None

    @staticmethod
    def __tensor_unflatten__(inner_tensors, meta, outer_size, outer_stride):
        assert meta is None
        a = inner_tensors["a"]
        return MyTensor(a)


@torch.compile(backend="aot_eager")
def f(x):
    return x + 1


x_a = torch.randn(4, requires_grad=True)
x_a_view = x_a.as_strided((2, 2), (2,1), 0)
x = MyTensor(x_a_view).requires_grad_(True)

grad_a = torch.randn(2, 2, requires_grad=True)
grad_a_view = grad_a.as_strided((2, 2), (2,1), 0)
grad = MyTensor(grad_a_view)

# pre-populate grad
x.grad = grad
out = f(x)
```

cc @ezyang @albanD @chauhang @penguinwu @eellison @zou3519
Repository: rust
Issue: `unreachable_patterns` lint due to `min_exhaustive_patterns`
Labels: A-lints,A-diagnostics,T-lang,T-compiler,L-unreachable_patterns,F-min_exhaustive_patterns

### Code

```Rust
fn foo() -> Result<(), core::convert::Infallible> {
    todo!()
}

fn main() {
    match foo() {
        Ok(()) => {},
        Err(e) => match e {}
    }
}
```


### Current output

```Shell
warning: unreachable pattern
 --> src/lib.rs:8:9
  |
8 |         Err(e) => match e {}
  |         ^^^^^^
  |
  = note: this pattern matches no values because `Infallible` is uninhabited
  = note: `#[warn(unreachable_patterns)]` on by default
```


### Desired output

Until the 2024 edition, or the code's MSRV is ≥ 1.82, no warning.


### Rationale and extra context

Deleting the `Err(e) => match e {}` arm will produce code which does not warn on nightly/1.82, but which does not compile on 	1.80. This means that users which wish to keep a warning-free-ish nightly (or beta, eventually) build will have to `#[allow(unreachable_patterns)]` from now until 1.82 is released, or perhaps even until their next MSRV increase.

Deferring the warning until an edition or explicit MSRV increase seems to me to be a good way to avoid churn in the form of `#[allow]`s. Such `#[allow]`s are particularly dangerous because `unreachable_patterns` is also the lint that detects binding patterns that were intended to be matching against constants instead, so declaring it on a wide scope might hide serious bugs, especially if (as is likely) they're not promptly removed upon the release of 1.82.

### Rust Version

```Shell
1.82.0-nightly (2024-08-11 41dd149fd6a6a06795fc)
```


### Anything else?

I noticed this due to my CI against nightly, but comments on the stabilization PR https://github.com/rust-lang/rust/pull/122792#issuecomment-2282222700 mentioned it first. I'm filing this issue to make sure it is not overlooked by being only visible in that comment thread.
Repository: pytorch
Issue: Make CUDAPluggableAllocator  support getDeviceStats, resetPeakStats 
Labels: feature,module: cuda,triaged,module: CUDACachingAllocator

### 🚀 The feature, motivation and pitch

### Description:

I'm currently integrating the PyTorch allocator with the RMM allocator. I rely on `torch.cuda.max_memory_allocated` and `torch.cuda.reset_peak_memory_stats` for monitoring and optimizing memory usage. 

Specifically, these functions help me fit a predictive curve to estimate memory requirements for various batch sizes and sequence lengths. This allows me to create batches that are most compute-optimal.

## Issue:

Unfortunately, torch.cuda.max_memory_allocated and torch.cuda.reset_peak_memory_stats are not supported when using the RMM allocator. This limits my ability to efficiently manage memory when the RMM allocator is plugged in.

### Request:

Please consider adding support for torch.cuda.max_memory_allocated and torch.cuda.reset_peak_memory_stats when using the pluggable allocator. This would greatly enhance the ability to optimize memory usage in conjunction with RMM.

### Alternatives

I can use 2 code paths and use StatisticsResourceAdaptor module in RMM for doing this. 

### Additional context

_No response_

cc @ptrblck @msaroufim
Repository: rust
Issue: rustdoc prints the names of private consts when used as const generic parameter defaults
Labels: T-rustdoc,A-visibility,C-bug,A-const-eval,A-const-generics

```rust
const VALUE: usize = 1;
type Ty = ();
pub trait Foo<const N: usize = VALUE, T = Ty> {}
```

Rustdoc generates the following pseudocode for this trait’s documentation page:

```rust
pub trait Foo<const N: usize = VALUE, T = ()> { }
```

This seems inconsistent to me: non-public constants should be replaced with their value just like non-public type aliases are, because crates should be free to have aliases for their own things privately without affecting the public view.

Another case is when a public constant uses a private constant; in that case, the private constant is named *and* the final value is. I’m not sure whether that’s good, but it at least answers the question of what the value is.

### Meta

`rustc --version --verbose`:
```
rustc 1.82.0-nightly (41dd149fd 2024-08-11)
binary: rustc
commit-hash: 41dd149fd6a6a06795fc6b9f54cb49af2f61775f
commit-date: 2024-08-11
host: x86_64-apple-darwin
release: 1.82.0-nightly
LLVM version: 19.1.0
```

@rustbot label +T-rustdoc
Repository: pytorch
Issue: Give PrivateUse2 and PrivateUse3 the same treatment as PrivateUse1
Labels: triaged,enhancement,needs research,module: backend,module: PrivateUse1

### 🚀 The feature, motivation and pitch

PrivateUse1 support has been improved to allow multiple device authors the means to create an out of tree device that has the same look and feel as an in-tree device. This has been a huge benefit for new device development. However, in the cases where multiple in-development or limited scope devices are in development and are necessary to be available within the same pytorch environment, PrivateUse2 and PrivateUse3 has not seen the same care in their use as available local devices.

### Alternatives

_No response_

### Additional context

Supposing this gets implemented, it would also be nice to have a version of TORCH_LIBRARY_IMPL that could detect which of the PrivateUse Device are not yet use and bind to that.

cc @bdhirsh @NmomoN @mengpenghui @fwenguang @cdzhan @1274085042 @PHLens
Repository: vscode
Issue: Suggest: Test Explorer exists by default, but off
Labels: under-discussion,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. -->

<!-- Describe the feature you'd like. -->

The Test Explorer only shows up once you install an extension that contributes a Test provider.  Suggestion here is that there is a default Test Explorer view, but it is turned off by default. If you right click the Activity Bar, "Testing" is there by default but unchecked. When you turn it on and no Test provider extensions are installed, we could have a Welcome View that gives a brief overview of Testing and a link to query the Marketplace for Test Provider extensions.
Repository: stable-diffusion-webui
Issue: [Feature Request]: add support for stablediffusion.cpp inference.
Labels: enhancement

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

stablediffusion.cpp works fast on cpu, use less memory than pytorch and support of quantized models which take much less space.

### Proposed workflow

1. Go to settings
2. set inference method to stablediffusion.cpp



### Additional information

_No response_
Repository: stable-diffusion-webui
Issue: [Feature Request]: add gguf/ggml format support
Labels: enhancement

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

gguf format already used in stablediffusion.cpp, it does allow faster loading, and quantization to less than 8bit which save storage space

### Proposed workflow

1. webui should be able to load models/loras/lycoris/.... in gguf format


### Additional information

_No response_