sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Better help for `pub(in parent)` in edition 2018 and beyond
Labels: A-diagnostics,A-resolve,T-compiler,D-newcomer-roadblock

### Code

```Rust
// Compile with edition 2018 or later
mod foo {
    pub(in parent) fn bar() {
        println!("hello from bar");
    }
}

fn main() {
    bar();
}
```


### Current output

```none
error: relative paths are not supported in visibilities in 2018 edition or later
 --> src/lib.rs:2:12
  |
2 |     pub(in parent) fn bar() {
  |            ^^^^^^ help: try: `crate::parent`
```

### Desired output

```none
error: relative paths are not supported in visibilities in 2018 edition or later
 --> src/lib.rs:2:12
  |
2 |     pub(in parent) fn bar() {
  |            ^^^^^^ help: try: `crate::parent`
  |         ^^^^^^^^ help: did you mean? `super`
```

### Rationale and extra context

If the programmer wrote `pub(in parent)` and there is no module named `parent` in the crate (at the location where edition 2015 would have resolved the path), it is likely that what they were actually trying to do is make the item visible to "the parent module", which is properly spelled `super`.

It would also probably be helpful to refer the programmer to https://doc.rust-lang.org/reference/visibility-and-privacy.html#pubin-path-pubcrate-pubsuper-and-pubself either directly or via `--explain`.

Note also that this error is missing an E-code (and therefore there is nothing to use `--explain` on).
Repository: godot
Issue: Lines appear black (Forward+) or not at all (Mobile) in `screen_texture` (such as BaseMaterial3D refraction)
Labels: bug,topic:editor,topic:3d

- Related to https://github.com/godotengine/godot/issues/82637.

### Tested versions

- Reproducible in: 4.0.stable, 4.2.stable

### System information

Godot v4.2.stable - Fedora Linux 39 (KDE Plasma) - X11 - Vulkan (Mobile) - dedicated NVIDIA GeForce RTX 4090 (nvidia; 545.29.06) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

### Issue description

Lines normally | Lines behind refractive material
-|-
![Screenshot_20231211_231955](https://github.com/godotengine/godot/assets/180032/b974c26d-1efa-43a0-9faa-6a91b06ca157) | ![Screenshot_20231211_232000](https://github.com/godotengine/godot/assets/180032/fc14a7c6-6d7d-467b-a459-4cb0db492996)

This mainly affects the editor as lines seen through a refractive material will appear black. It can also affect projects that use line drawing (e.g. when using Visible Collision Shapes or Visible Navigation).

A more minimal example where the issue may be more obvious:

![image](https://github.com/godotengine/godot/assets/180032/9bf466a8-961a-40fa-8ac8-d3f189f23ba3)

The refractive material is the box in the middle.

In 3.x, lines don't appear at all behind refractive materials, regardless of whether GLES3 or GLES2 is used.

This appears to be related to the depth prepass: disabling it in the Project Settings while using Forward+ hides the black lines behind refractive materials.

### Steps to reproduce

- Create a mesh with a BaseMaterial3D attached.
- Decrease albedo color's alpha to `0`, decrease roughness to `0.0` and enable refraction on the BaseMaterial3D. Set refraction scale to `0.0`.
- Move the camera around so the origin and grid lines appear behind the refractive material.

### Minimal reproduction project (MRP)

[test_refraction.zip](https://github.com/godotengine/godot/files/13649976/test_refraction.zip)
Repository: go
Issue: cmd/compile: PGO devirtualization of partial interface implementations
Labels: Performance,NeedsInvestigation,compiler/runtime

Callees that only partially implement an interface (they are embedded in another type that completes the interface) cannot be devirtualized.

e.g., consider:

```
func foo(r io.ReadCloser) {
  b := make([]byte, 64)
  r.Read(b)
}

func main() {
  b := make([]byte, 64)
  r := bytes.NewReader(b)
  rc := io.NopCloser(r)
  foo(rc)
}
```

`io.nopCloser` embeds `Reader`, so the PGO profile will report a call from `foo -> bytes.Reader.Read`. Devirtualization will consider this candidate, determine that `bytes.Reader` does not implement `io.ReadCloser` and decide that it must not be valid, but it is valid because of the wrapper type not visible from the profile.

Devirtualization could be more lenient and only type-check the single method that is called rather than the entire interface, though this risks more false positives in ambiguous situations.

cc @cherrymui @aclements
Repository: go
Issue: cmd/compile: PGO devirtualization of closures
Labels: Performance,NeedsInvestigation,compiler/runtime

https://go.dev/cl/539699 adds PGO devirtualization of calls to function values, but it is limited to callees that are standard functions. Closures (any function requiring closure context) are excluded due to the extra complexity of passing the closure context.

It should be feasible to devirtualize these calls, but will require extra work in SSA to pass a closure context to a closure call as well as work in IR to represent such static closure calls.

cc @cherrymui @aclements @mdempsky
Repository: go
Issue: cmd/compile: include PGO devirtualization targets in export data
Labels: Performance,NeedsInvestigation,compiler/runtime

When performing PGO devirtualization, we will look for callees reported by the profile from export data. If they are present, great! If not, it may be because that callee doesn't exist anymore, or it may exist but simply wasn't included in export data because it wasn't otherwise needed in export data.

For PGO inlining, we explicitly include bodies of functions that we expect to be PGO inlining targets. We could do the same with devirtualization, explicitly including any function in export data if we expect it to be a devirtualization callee.

I discussed this with @mdempsky a few months ago, who suggested that in addition to (or instead of?) IR-level PGO annotation, we also do analysis at the `cmd/compile/internal/syntax` level so that unified export generation could use PGO information to decide what needs to be exported.

cc @cherrymui @aclements
Repository: pytorch
Issue: `torch.jit.save` fails for static function from C++ TorchScript extension with "Failed to downcast a Function to a GraphFunction"
Labels: oncall: jit

### 🐛 Describe the bug

We have some code that relies heavily on custom TorchScript classes, and some of these classes also export static functions. The function are fully supported after running the code through `torch.jit.script` but fail when trying to save the scripted module. Here is a minimal reproduction:

```python
import torch
from torch.utils.cpp_extension import load_inline

source = """
struct SomeClass : torch::CustomClassHolder {
    static bool function() {
        return true;
    }
};

TORCH_LIBRARY(static_functions, m) {
  m.class_<SomeClass>("SomeClass")
    .def_static("function", &SomeClass::function);
}
"""

module = load_inline(
    name='static_functions',
    cpp_sources=[source],
    is_python_module=False,
)

def function() -> bool:
    return torch.classes.static_functions.SomeClass.function()


script = torch.jit.script(function)
print(script.code)
torch.jit.save(script, "saved.pt")
```

This outputs (on the `main` branch and with torch 2.1)

```
def function() -> bool:
  _0 = __torch__.torch.classes.static_functions.SomeClass.function
  return _0()

Traceback (most recent call last):
  File "~/code/pytorch/pytorch/tmp/static.py", line 32, in <module>
    torch.jit.save(script, "saved.pt")
  File "~/code/pytorch/pytorch/torch/jit/_serialization.py", line 80, in save
    m.save(f, _extra_files=_extra_files)
RuntimeError: false INTERNAL ASSERT FAILED at "~/code/pytorch/pytorch/torch/csrc/jit/api/function_impl.cpp":59, please report a bug to PyTorch. Failed to downcast a Function to a GraphFunction. This probably indicates that the JIT calling context needs a special case on tryToGraphFunction() instead.
```

### Versions

I just reproduced this with the latest commit on `main`.

```
Collecting environment information...
PyTorch version: 2.3.0a0+git794545c
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 14.1.2 (arm64)
GCC version: Could not collect
Clang version: 15.0.0 (clang-1500.0.40.1)
CMake version: version 3.27.9
Libc version: N/A

Python version: 3.11.6 | packaged by conda-forge | (main, Oct  3 2023, 10:37:07) [Clang 15.0.7 ] (64-bit runtime)
Python platform: macOS-14.1.2-arm64-arm-64bit
Is CUDA available: False
CUDA runtime version: No CUDA
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: False

CPU:
Apple M1 Max

Versions of relevant libraries:
[pip3] numpy==1.26.2
[pip3] optree==0.10.0
[pip3] torch==2.3.0a0+git794545c
```

cc @EikanWang @jgong5 @wenzhe-nrv @sanchitintel
Repository: node
Issue: It's not clear if FileHandle close() and stat() can fail
Labels: doc

### Affected URL(s)

https://nodejs.org/api/fs.html

### Description of the problem

Using Node.js `FileHandles` you can open a file, get a fs.Stats object from the handle and then close the file.

```
// first part of the function copied from the close() doc
// https://nodejs.org/api/fs.html#filehandleclose

import { open } from 'node:fs/promises';

function processFile(path)
    let filehandle;
    try {
        filehandle = await open(path, 'r');
    } finally {
        await filehandle?.close();
        return;
    }
 
    const fileStat = await filehandle.stat(); //  1
    // do something ...
    await filehandle.close();  // 2
}
```

Node.js documentation says:
```
filehandle.stat([options])
    Returns: <Promise> Fulfills with an <fs.Stats> for the file.

filehandle.close()
   Returns: <Promise> Fulfills with undefined upon success.
```

From these statements its' not clear if both methods can fail, or not, during the execution and in which cases.
Do we need to wrap FH.stat() and FH.close() calls in try-catch blocks?
Or, since the FileHandle has been already opened, they can't fail and it is safe to use them without a try-catch block?

I've also tried replacing the "do something" line with an `await setTimeout(10000)` in order to delete the opened file during the execution. But, at least on Linux, the deletion (`rm` command) is delayed until all file descriptors stop using it. So, even in that case both methods don't fail. Same story using `chmod` and `chown`...
Is there any platform specific behaviours?
Repository: go
Issue: regexp/syntax: named capture groups don't support non-latin alphabets
Labels: NeedsDecision

### Go version

go version go1.21.4 linux/amd64

### What operating system and processor architecture are you using (`go env`)?

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/root/.cache/go-build'
GOENV='/root/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/root/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/root/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/usr/lib/go-1.21'
GOSUMDB='sum.golang.org'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/usr/lib/go-1.21/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.21.4'
GCCGO='gccgo'
GOAMD64='v1'
AR='ar'
CC='gcc'
CXX='g++'
CGO_ENABLED='1'
GOMOD='/dev/null'
GOWORK=''
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
PKG_CONFIG='pkg-config'
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build1924873596=/tmp/go-build -gno-record-gcc-switches'
```


### What did you do?

Python's re and google/re2 has no issue compiling named capture groups with international characters.

Go doesn't support it, as you could see here running this sample: https://go.dev/play/p/d1pVihwOznE

```
package main

import (
	"regexp"
)

func main() {
	regexp.MustCompile(`(?P<тест>a)`)
}
```

### What did you expect to see?

No errors.

### What did you see instead?

```
panic: regexp: Compile(`(?P<тест>a)`): error parsing regexp: invalid named capture: `(?P<тест>`

goroutine 1 [running]:
regexp.MustCompile({0x485746, 0xf})
	/usr/lib/go-1.21/src/regexp/regexp.go:319 +0xb4
main.main()
	/root/test.go:8 +0x1f
```
Repository: storybook
Issue: [Bug]: flow typecheck fails due to malformed_package_json
Labels: bug,help wanted,compatibility with other tools,builder-webpack5

### Describe the bug

Flow responds with an error when I upgrade storybook to the latest version.

### To Reproduce

Run `npx storybook@latest upgrade` on a project that had storybook@7.6.3 to update the storybook to 7.6.4. This was also a problem when I ran that script to update storybook from 7.5.3 to 7.6.3.

Run `npx flow`.

Error message:
```
Error ┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈┈
node_modules/@storybook/preset-react-webpack/node_modules/resolve/test/resolver/malformed_package_json/package.json:2:1

Unexpected end of input, expected the token }

     1│ {
     2│



Found  1 error
```

### System

ubuntu2004 and on a macbook pro with sonoma 14.1.2

### Additional context

I looked up the file in the node_modules directory, and it just has a single open curly bracket.

Reverting @storybook/react-webpack5 to 7.5.3 resolves the flow error, but that package isn't kept in sync with the other storybook packages.

Running storybook locally works as expected with react-webpack5@7.6.4
Repository: transformers
Issue: LLaMa-VID: An Image is Worth 2 Tokens in LLMs
Labels: New model

### Model description

LLaMA-VID is an open-source chatbot trained by fine-tuning LLaMA/Vicuna on GPT-generated multimodal instruction-following data. LLaMA-VID empowers existing frameworks to support hour-long videos and pushes their upper limit with an extra context token. We build this repo based on LLaVA.

LLaMA-VID contains three parts: encoder and decoder are adopted to produce visual embedding and text-guided features, respectively; context token and content token are transformed with the tailored token generation strategy; instruction tuning is designed to unleash the potential of LLMs for image and video.

### Open source status

- [X] The model implementation is available
- [X] The model weights are available

### Provide useful links for the implementation

Page: https://llama-vid.github.io/
Weights already available on HF: https://huggingface.co/YanweiLi/llama-vid-7b-pretrain-224
Code: https://github.com/dvlab-research/LLaMA-VID
Repository: flutter
Issue: Differentiate trackpad from mouse wheels on web
Labels: engine,a: fidelity,f: scrolling,platform-windows,a: quality,platform-web,platform-linux,a: mouse,P2,team-web,triaged-web

With Flutter web on some desktop platforms (Windows and Linux), we do not know the difference between a trackpad and a physical mouse scroll wheel when the input is received by the framework. Because of this, both mouse and trackpad input is treated the same way, going through the pointerScroll method of ScrollPosition to handle the input.


When we know the difference, the trackpad is handled differently, supporting other interactions like panning, zooming, smoothing of input in accordance with the scroll physics upon release, etc. This should be available on all platforms, not just some.

For Mac, a heuristic was developed to tell the difference between these input devices, and has worked really well:
- https://github.com/flutter/engine/pull/36346

We need to do the same for Windows and Linux so that the experience is consistent across all platforms.

This is also needed to resolve https://github.com/flutter/flutter/issues/32120
Repository: godot
Issue: Nested class cannot be used as Resource in editor
Labels: discussion,topic:gdscript,topic:editor

### Tested versions

v4.2.stable.official [46dc27791]

### System information

MacOS 14.1.2 (23B92)

### Issue description

For resources defined like this:
```gdscript
extends Resource
class_name TestResource
@export var arr:Array[NestedResource]

class NestedResource extends Resource:
	@export var some_value:int
```
If you try to edit the array in inspector, you will notice that you cannot create new instance of NestedResource when adding new item to `arr` collection:
![image](https://github.com/godotengine/godot/assets/11059246/0c6002f4-c031-4bb3-a44b-0ebae1bf7e85)

Also there is no way to create new Resource from type `NestedResource`:
![image](https://github.com/godotengine/godot/assets/11059246/48fbbd83-5ae6-4930-a07d-12926c451d56)

If I convert the 'NestedResource` to normal class:
```gdscript
extends Resource
class_name Nestedresource
@export var aaa:int
```
I can create this resource as expected:
![image](https://github.com/godotengine/godot/assets/11059246/14a21e09-4563-4915-ac52-6d7c7836a8cb)

Both this and the lack of namespaces significantly limit the flexibility of GDScript.

### Steps to reproduce

See code above

### Minimal reproduction project (MRP)

N/A
Repository: PowerToys
Issue: Application won't Autostart - Self-Start Setting Disables Itself
Labels: Issue-Bug,Area-Runner,Needs-Triage

### Microsoft PowerToys version

0.76.1

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

Settings

### ✔️ Expected Behavior

The application starts itself when the computer is switched on.

### ❌ Actual Behavior

The application does not start itself when the computer is switched on. Although I can't switch on the self-start setting, it switches it off every time.

### Other Software

_No response_
Repository: next.js
Issue: Build failure for edge runtime with libsql
Labels: bug

### Link to the code that reproduces this issue

https://github.com/nooblyf/turso-drizzle-starter

### To Reproduce

1. Clone https://github.com/nooblyf/turso-drizzle-starter
2. pnpm install
3. pnpm build

### Current vs. Expected behavior

Build should succeed

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.2.0: Wed Nov 15 21:53:18 PST 2023; root:xnu-10002.61.3~2/RELEASE_ARM64_T6000
Binaries:
  Node: 20.10.0
  npm: 10.2.3
  Yarn: 1.22.21
  pnpm: 8.11.0
Relevant Packages:
  next: 14.0.4
  eslint-config-next: 14.0.4
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.3.3
Next.js Config:
  output: N/A
```


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

Not sure

### Additional context

i'm getting

> Build error occurred
> Error: Failed to collect page data for /api/ping
> at /Users/nooblyf/github.com/projects/turso-drizzle-starter/node_modules/.pnpm/next@14.0.4_react-dom@18.2.0_react@18.2.0/node_modules/next/dist/build/utils.js:1220:15
> at process.processTicksAndRejections (node:internal/process/task_queues:95:5) {
> type: 'Error'
> }
> Collecting page data . ELIFECYCLE  Command failed with exit code 1.

it works fine in dev but only fails when i'm doing a production build
Repository: go
Issue: x/build/dashboard: update dragonfly to 6.4.0
Labels: OS-Dragonfly,Builders,NeedsInvestigation,new-builder

It's long due but we should update the gobuilder from dfly 6.2.2 to 6.4.0
Repository: go
Issue: proposal: x/crypto/ssh: add top-level DialContext func
Labels: Proposal,Proposal-Crypto

### Proposal Details

Similar to #20288 which added a `DialContext` method to `ssh.Client`, we propose to add a top-level convenience function `DialContext` to the `crypto/ssh` package which mirrors the existing `Dial` func:

```go
func DialContext(ctx context.Context, network, addr string, config *ClientConfig) (*Client, error)
```

The `DialContext` func would accept a `context.Context` as its first argument, which would control the dial and handshake phases of the connection. Closing the Context after the connection is established would have no effect on the resulting `Client`. This is consistent with other `DialContext` uses in the Go standard library and this package.

We have a change ready to go (~33 SLOC), so happy to submit a CL when/if this is approved.
Repository: pytorch
Issue: Clean up AWS credentials from PyTorch CI and replace them with OIDC
Labels: module: ci,triaged

Here is the list that I find:

* https://github.com/pytorch/pytorch/blob/main/.github/templates/macos_binary_build_workflow.yml.j2#L68-L69
* https://github.com/pytorch/pytorch/blob/main/.github/workflows/upload-alerts.yml
* ~~https://github.com/pytorch/pytorch/blob/main/.github/workflows/update_pytorch_labels.yml~~
* ~~https://github.com/pytorch/pytorch/blob/main/.github/workflows/_binary-upload.yml~~
* ~~https://github.com/pytorch/pytorch/blob/main/.github/workflows/build-triton-wheel.yml~~
* https://github.com/pytorch/pytorch/blob/main/.github/workflows/nightly-rockset-uploads.yml
* https://github.com/pytorch/pytorch/blob/main/.github/workflows/_ios-build-test.yml

The following can be fixed as part of https://github.com/pytorch/test-infra/issues/4474:
* https://github.com/pytorch/pytorch/blob/main/.github/workflows/upload-torch-dynamo-perf-stats.yml
* https://github.com/pytorch/pytorch/blob/main/.github/workflows/upload-test-stats.yml

A bunch of them are stilled referred to in `.circleci` and need to be cleaned up, for example:
* ~~https://github.com/pytorch/pytorch/blob/main/.circleci/config.yml~~
* ~~https://github.com/pytorch/pytorch/blob/main/.circleci/scripts/binary_ios_upload.sh#L57-L58~~
* ~~https://github.com/pytorch/pytorch/blob/main/.circleci/scripts/setup_ci_environment.sh~~
* ~~https://github.com/pytorch/pytorch/blob/main/.circleci/verbatim-sources/job-specs/docker_jobs.yml#L21-L22~~

We can then remove a bunch of `AWS_*` keys from the repo

### Code pointer

https://github.com/pytorch/test-infra/pull/4794
https://github.com/pytorch-labs/pytorch-gha-infra/pull/303

cc @seemethere @malfet @pytorch/pytorch-dev-infra
Repository: go
Issue: proposal: runtime: add a default, non-destructive signal handler that creates a stack dump
Labels: Proposal

### Proposal Details

By default, [Go produces a stack dump and exits on various signals](https://pkg.go.dev/os/signal):

> A SIGQUIT, SIGILL, SIGTRAP, SIGABRT, SIGSTKFLT, SIGEMT, or SIGSYS signal causes the program to exit with a stack dump.

It is commonly desired to create such a stack dump using a mechanism such as a signal but without exiting. Such thread dumps may be used to investigate hangs or as a rudimentary sampling profiler. Such built-in handlers are common in other languages such as Java (e.g. using `SIGQUIT`).

One way for a program to handle this requirement is to [handle a signal](https://pkg.go.dev/os/signal#Notify) such as `SIGUSR1`, generate a stack dump by calling [`pprof.Lookup`](https://pkg.go.dev/runtime/pprof#Lookup) on the [`goroutine`](https://pkg.go.dev/runtime/pprof#Profile) profile and then write that to a file with [`Profile.WriteTo`](https://pkg.go.dev/runtime/pprof#Profile.WriteTo).

Alternatively, native debuggers and tools such as `pstack` may be used but they generally lack the detail of Go stack dumps.

This proposal is for Go to have a built-in signal handler that non-destructively writes a thread dump to `stderr` in response to a signal such as `SIGUSR2`. This would be a behavior change that may cause unintended side effects for any programs that already have a `SIGUSR2` handler.