sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: lifetime elision for return type can refer to an explicitly named region
Labels: A-lints,A-diagnostics,A-lifetimes,T-lang,D-confusing,D-newcomer-roadblock,T-types

_Originally posted by @danielhenrymantilla in https://github.com/rust-lang/rust/issues/117967#issuecomment-1889193546_

I would nonetheless like to take this opportunity to talk a bit about:

## Aside: edge cases of lifetime elision rules which are confusing

There are two slightly related aspects which can make lifetime elision rules (w.r.t. the output elided lifetime) be rather confusing, or poorly readable.

 1. The gist of it is that **output `'_` can "connect"/match an input _explicitly named_ lifetime "parameter"**.
 2. Worse, in certain cases this named lifetime "parameter" may not be generic at this layer (outer generic parameter), or may not be generic at all (`'static` hard-coded / fixed value)!

To illustrate, consider:

```rs
type Metadata = &'static str;

struct Foo<'lt>(&'lt str);

impl<'lt> Foo<'lt> {
    fn a(this: Self, metadata: &'static str) -> &str;
    fn b(this: Foo<'lt>, metadata: Metadata) -> &str;
}
```

![What if I told you these two methods have different signatures](https://github.com/rust-lang/rust/assets/9920355/cb2569a5-1f03-4d59-a631-5bf20f2e8f58)

  - [Demo](https://rust.godbolt.org/z/68E1aeETr)

I personally find the capability of type aliases or `Self` aliases to affect semantics (here, those of lifetime elision rules) to be appaling.

It would thus be nice if certain efforts were made to try and go in the other directions, _e.g._, by linting whenever an output-elided lifetime (`'_`-explicitly, or implicitly) happens to match an _explicitly named_ input lifetime param, and even more so when this input lifetime "param" is `'static` or stems from an outer scope.
Repository: node
Issue: readdirSync cannot read files properly when using { recursive: true, withFileTypes: true }
Labels: fs

### Version

v18.17.1

### Platform

_No response_

### Subsystem

fs

### What steps will reproduce the bug?


```shell
mkdir -p test/include
touch test/libvips-cpp.so.42
``` 

```javascript
const fs = require('fs');
fs.readdirSync('test', {recursive: true, withFileTypes: true});
``` 

### How often does it reproduce? Is there a required condition?

_No response_

### What is the expected behavior? Why is that the expected behavior?

```javascript
await fs.promises.readdir('test', {recursive: true, withFileTypes: true})
``` 

```shell
[
  Dirent { name: 'include', path: 'folder', [Symbol(type)]: 2 },
  Dirent {
    name: 'libvips-cpp.so.42',
    path: 'folder',
    [Symbol(type)]: 1
  }
]
``` 

### What do you see instead?

```shell
[
  Dirent { name: 'include', path: 'folder', [Symbol(type)]: 2 },
  Dirent {
    name: 'libvips-cpp.so.42',
    path: 'folder',
    [Symbol(type)]: 1
  },
  Dirent {
    name: undefined,
    path: 'folder/include',
    [Symbol(type)]: undefined
  },
  Dirent {
    name: undefined,
    path: 'folder/include',
    [Symbol(type)]: undefined
  }
]
``` 

### Additional information

_No response_
Repository: opencv
Issue: Add border value parameter for border mode constant to GaussianBlur
Labels: feature

### Describe the feature and motivation

-

### Additional context

_No response_
Repository: opencv
Issue:  Add border value parameter for border mode constant to Sobel
Labels: feature,category: imgproc

### Describe the feature and motivation

-

### Additional context

_No response_
Repository: go
Issue: x/net/proxy: TestDial failures
Labels: NeedsInvestigation

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

Issue created automatically to collect these failures.

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

    panic: test timed out after 40m0s
    running tests:
    	TestDial (40m0s)
    	TestDial/DirectWithCancel (40m0s)
    
    testing.(*T).Run(0x8d0108, {0x603169, 0x10}, 0x60dcc8)
    	/tmp/gobuilder-mips64le/go/src/testing/testing.go:1750 +0x498
    golang.org/x/net/proxy.TestDial(0x8d0108)
    	/tmp/gobuilder-mips64le/gopath/src/golang.org/x/net/proxy/dial_test.go:20 +0x68
    testing.tRunner(0x8d0108, 0x60dc30)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: go
Issue: proposal: x/crypto/acme/autocert: export supportsECDSA somewhere?
Labels: Proposal,Proposal-Crypto

### Proposal Details

I recently found myself needing x/crypto/acme/autocert's `func supportsECDSA` but it's not exported.

Copy/pasting it works, but is slightly sad as it's kinda long and I worry about it getting out of sync.

It's possible to use it indirectly via ugly hacks like https://github.com/tailscale/scertec/pull/3 (using a fake acme/autocert.Cache that looks which keys are accessed) but it's a bit too ugly.

Proposal: export that code somewhere? method on ClientHelloInfo even?

/cc @rolandshoemaker
Repository: ollama
Issue: LargeWorldModel
Labels: feature request,model request

https://largeworldmodel.github.io

https://huggingface.co/LargeWorldModel

Seemingly a new state of the art MLLM that can also handle very large context sizes, and videos (not just images).
Repository: TypeScript
Issue: Annotations/IntelliSense gets lost with simple `&` and `|` joins or utilities
Labels: Suggestion,Help Wanted,Experience Enhancement

### 🔎 Search Terms

IntelliSense, comments, annotations, symbol annotation, utilities, utility, union, intersection

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about *annotations*

### ⏯ Playground Link

https://www.typescriptlang.org/play?#code/KYDwDg9gTgLgBASwHY2FAZgQwMbDgMQgjgG8AoOOAegCoa4BBJOTJJCGTGBCZ9aOOgRQAzvDBQIYNDACecGlQqDhYgAqTpsWQC44AIyIAbYK2W16TFmw5cefASODZeAEzgSpM+YuVOXSK4aXtp6SACuALb6aGQAvmRkoJCwiChoWLhwAEKYUKTmdIzMrOyc3LyCAjAAFni1wu6eWnIKSpQNUEGa3npiUMgA5vGJAWJVEHqExAC8BZRUVHCSRkZwEABuaHAwxIPA8KW2FUjKQqIwwS26gphGTgA05ksra5vbu3D7hzbl9n7ONxXXpwAAsACYRklwNB4HJpAQiExXAB5KC5fJzAAU0zgADIcnkAJRwAA+iOI5Ixo14434EGRGKmSMCaIxcDm5AWLwgq3e+SOf1pcFcvAA5PAAO7QADWcDqUGAZ1Ulx6oVu92AT0o-iBarkenB2p2NUawPVACI6nyLVDFnBItA8C5ImATCA4KBMK6THAALQBwNB4OBxLwvAAJWAAEdwsJgAwYAAZUxiFFIYAAHgAKg84ABpYCyESekCoQIlmVFiDoODZjlwKuyGt1gB8DbUCGwMszylzygAoiBsEZwq4s02W7mC0WRK2yO28couZQ4ABtfNpGfFgC6foA-Hoo7H465M53uzm8-nW4u4Go8tw7ueuz3p0OR2Os4Xi9fb-PKDiDdZx3MNZARRMU0wNMM1xOZjzjRVINTGB0yzaY8zFc51H1WQxTJOAxV1QJzTkMV5zIMZ4AAK3CGDgGmPRkOg1DYKIBsV3tV5+WsMo7GFO4RGIUUkAlOBpSgOUFSVShsNVEIDQ1Jx4iAA

### 💻 Code

```ts
// follow Playground link to see behavior

export interface Foo {
  /** An annotation for first property */
  firstProperty: boolean
  /** An annotation for second property */
  secondProperty: number
}

export interface Bar {
  /** An annotation for the third property */
  thirdProperty: string
}

const foo: Foo = {
  // roll over to get annotation
  firstProperty: false,
  // roll over to get annotation
  secondProperty: 42
}

export type FooAndOrBar = (Foo & Bar) | Foo | Bar

const fooAndBar: FooAndOrBar = {
  // rollover annotations don't work here
  firstProperty: true,
  secondProperty: 2,
  thirdProperty: "hello"
}
```


### 🙁 Actual behavior

IntelliSense doesn't work on properties after running through `&` (intersections) with `|` (unions) or more complex type manipulation.

### 🙂 Expected behavior

I expected the annotation to "come along" with the symbol and appear in IntelliSense.

### Additional information about the issue

_No response_
Repository: material-ui
Issue: [docs-infra] Fix page change speed regression
Labels: bug 🐛,performance,priority: important,regression,scope: docs-infra

## The problem

The page transition speed between pages is about x3-x4 too slow.

Open https://mui.com/material-ui/react-button/ and navigate to the Button Group page. It takes about 200ms to perform the transition:

<img width="313" alt="SCR-20240215-uewa" src="https://github.com/mui/material-ui/assets/3165635/6bf94d5a-d6fb-451d-afd7-5b936ecfb677">

According to https://web.dev/articles/inp, this is very borderline for my high-end MacBook Pro. Google Search will use a new performance ranking metric, which we don't do well: 

<img width="891" alt="Screenshot 2023-08-09 at 13 36 33" src="https://github.com/mui/material-ui/assets/3165635/22d20fee-33c3-467b-b962-493e7e4e1bfa">

https://search.google.com/search-console/core-web-vitals/summary?resource_id=sc-domain%3Amui.com&device=2#inp-table

## The goal

Compare the experience to https://www.radix-ui.com/primitives/docs/components/alert-dialog to move to the Accordion page:

<img width="309" alt="SCR-20240215-uget" src="https://github.com/mui/material-ui/assets/3165635/20482159-c9bb-4c0f-a307-d934af3c9a1b">

It's x2-3 better.

Same on https://ui.shadcn.com/docs/components/button, it's at about 65ms.

<img width="314" alt="SCR-20240215-uhtw" src="https://github.com/mui/material-ui/assets/3165635/6548fd4f-0155-43ed-9ed0-fdd46e1391ae">

So as a developer, my first impression is: **Material UI docs feels slow, then surely MUI System is not performant, I'm not using it, I want me end-users to have a great UX**. To be fair, we can't really compare Material UI docs page to others, we have a lot more content on the page.

It is to be noted that it seems a regression, https://v4.mui.com/components/button-group/ is faster:

<img width="312" alt="SCR-20240215-uhux" src="https://github.com/mui/material-ui/assets/3165635/8bb6210a-f41e-41d0-b44a-6c06a582821e">

## Part of the solutions

- Layout. We don't use layouts like the comparison I raised about. https://github.com/mui/material-ui/pull/38394 showcases the benefits of using a layout using the Next.js Pages Router. It helps a good amount. Same in https://github.com/mui/material-ui/pull/38050#discussion_r1268280912, https://github.com/mui/material-ui/pull/36732.
- Emotion. It's slow, we spend a lot of time doing style computations
- ?

## Context

This issue is meant to be closed with insights gathered after [the research task](https://github.com/orgs/mui/projects/24/views/5?pane=issue&itemId=53391205)

**Search keywords**: docs-infra, page load
Repository: pytorch
Issue: Update Protobuf submodule to v3.21.X
Labels: module: build,module: protobuf,triaged

### 🐛 Describe the bug

Using a prebuilt PyTorch binary with a build that uses https://github.com/googleapis/google-cloud-cpp results in a conflicting symbol for protobuf. This is because Google Cloud CPP [requires a minimum protobuf version of v3.21](https://googleapis.github.io/google-cloud-cpp/doc/packaging.html), yet Protobuf's curent version is v3.13.

Protobuf versions past v3.21 require abseil, which is a breaking change. Therefore, upgrading to v3.21 is an easier task. v3.21.12 was released in Dec 14, 2022, and our current version was released in Aug 14, 2020, so this is also a maintenance upgrade.

### Error logs

_No response_

### Minified repro

_No response_

### Versions

Collecting environment information...
PyTorch version: N/A
Is debug build: N/A
CUDA used to build PyTorch: N/A
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.1.0.2.5)
CMake version: version 3.28.0
Libc version: N/A

Python version: 3.11.7 (main, Dec  4 2023, 18:10:11) [Clang 15.0.0 (clang-1500.1.0.2.5)] (64-bit runtime)
Python platform: macOS-14.1.2-arm64-arm-64bit
Is CUDA available: N/A
CUDA runtime version: Could not collect
CUDA_MODULE_LOADING set to: N/A
GPU models and configuration: Could not collect
Nvidia driver version: Could not collect
cuDNN version: Could not collect
HIP runtime version: N/A
MIOpen runtime version: N/A
Is XNNPACK available: N/A

CPU:
Apple M2 Max

Versions of relevant libraries:
[pip3] flake8==6.0.0
[pip3] flake8-bugbear==23.3.23
[pip3] flake8-comprehensions==3.12.0
[pip3] flake8-executable==2.1.3
[pip3] flake8-logging-format==0.9.0
[pip3] flake8-pyi==23.3.1
[pip3] flake8-simplify==0.19.3
[pip3] mypy==0.960
[pip3] mypy-extensions==1.0.0
[pip3] numpy==1.24.3
[pip3] torch==2.2.0a0+git7e6cf04
[conda] Could not collect

cc @malfet @seemethere @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519
Repository: flutter
Issue: [devicelab] Remove and stop recording unused sub_result metrics.
Labels: P3,c: tech-debt,team-engine,triaged-engine

The devicelab allows tests to provide custom dimensions, and a number of them have either never regressed, never stabilized, or aren't useful in a post Skia world.

1. Unused

120hz_frame_percentage
30hz_frame_percentage
60hz_frame_percentage
80hz_frame_percentage
90hz_frame_percentage

2. Skia Specific

layer_cache_count
layer_cache_memory
picture_cache_count
picture_cache_memory
Repository: pytorch
Issue: [c10d] torch.distributed.breakpoint stuck with multi-thread process group
Labels: triaged

### 🚀 The feature, motivation and pitch

place a torch.distributed.breakpoint inside following code path and it will freeze. python native ``breakpoint`` work

``pytest test/distributed/_composable/fsdp/test_fully_shard_init.py``

### Alternatives

_No response_

### Additional context

_No response_
Repository: transformers
Issue: [i18n-ar] Translating docs to Arabic
Labels: WIP

Hi!

Let's bring the documentation to all the Arabic-speaking community 🌐 

Who would want to translate? Please follow the 🤗 [TRANSLATING guide](https://github.com/huggingface/transformers/blob/main/docs/TRANSLATING.md). Here is a list of the files ready for translation. Let us know in this issue if you'd like to translate any, and we'll add your name to the list.

Some notes:

* Please translate using an informal tone (imagine you are talking with a friend about transformers 🤗).
* Please translate in a gender-neutral way.
* Add your translations to the folder called `<languageCode>` inside the [source folder](https://github.com/huggingface/transformers/tree/main/docs/source).
* Register your translation in `<languageCode>/_toctree.yml`; please follow the order of the [English version](https://github.com/huggingface/transformers/blob/main/docs/source/en/_toctree.yml).
* Once you're finished, open a pull request and tag this issue by including #issue-number in the description, where issue-number is the number of this issue. Please ping @stevhliu and @MKhalusova for review.
* 🙋 If you'd like others to help you with the translation, you can also post in the 🤗 [forums](https://discuss.huggingface.co/).

## Get Started section
- [ ] [readme.md](https://github.com/huggingface/transformers/edit/main/README.md)
- [ ] [index.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/index.md) 
- [ ] [quicktour.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/quicktour.md)
- [ ] [installation.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/installation.md)

## Tutorial section
- [ ] [pipeline_tutorial.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/pipeline_tutorial.md)
- [ ]  [autoclass_tutorial.md](https://github.com/huggingface/transformers/blob/master/docs/source/autoclass_tutorial.md)
- [ ]  [preprocessing.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/preprocessing.md)
- [ ]  [training.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/training.md)
- [ ]  [accelerate.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/accelerate.md)
- [ ]  [model_sharing.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/model_sharing.md)
- [ ]  [multilingual.md](https://github.com/huggingface/transformers/blob/main/docs/source/en/multilingual.md)
Repository: godot
Issue: Crashes when building project with C# script
Labels: bug,platform:windows,topic:editor,needs testing,topic:dotnet

### Tested versions

Reproducible in v4.2.1.stable.mono.official [b09f793f5]

### System information

Godot v4.2.1.stable.mono - Windows 10.0.19045 - GLES3 (Compatibility) - NVIDIA RTX 3500 Ada Generation Laptop GPU (NVIDIA; 31.0.15.2919) - 13th Gen Intel(R) Core(TM) i9-13950HX (32 Threads)

### Issue description

Clicking the Run button or pressing F5 causes a dialog  with "Building .NET project" to appear.  The dialog never goes away, and Godot is no longer responsive. Need to kill the application.

### Steps to reproduce

This can be reproduced by clicking the Run button or press F5 to run. Also by going to the MSBuild menu and click the Build button. Choose "Build Project".  Choosing "Clean Project" however never caused a crash.

### Minimal reproduction project (MRP)

Was able to reproduce the error using the attached project.  Reproducible using the steps above.

[MRP.zip](https://github.com/godotengine/godot/files/14301039/MRP.zip)
Repository: godot
Issue: Font outline is inconsistent with small pixel fonts
Labels: bug,topic:gui

### Tested versions

v4.2.1.stable.mono.official [b09f793f5]

### System information

Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 Kernel Version: 6.5.0-17-generic (64-bit) Graphics Platform: X11 Processors: 16 × AMD Ryzen 7 5700G with Radeon Graphics Memory: 15.0 GiB of RAM Graphics Processor: RENOIR

### Issue description

Font outline are inconsistent for small pixels fonts...

Here is a picture of label outline of 1...
![image](https://github.com/godotengine/godot/assets/2453707/311089da-ad10-49f3-99dd-164c763d346e)

Here is a picture of a label outline of 6...
![image](https://github.com/godotengine/godot/assets/2453707/05cece65-43c6-496e-ac76-7c67c320b120)


anything less then 6 doesn't render inner pixels...
![image](https://github.com/godotengine/godot/assets/2453707/39370011-2bc2-4271-b00f-bf68cb541396)



### Steps to reproduce

- Download the project
- Open res://scenes/screens/option-screen.tscn
- Mess around with the label's outline...



### Minimal reproduction project (MRP)

[AstroWars.zip](https://github.com/godotengine/godot/files/14301059/AstroWars.zip)
Repository: go
Issue: runtime: invalid crash stack for morestackc unwind on arm64 mac
Labels: NeedsFix,compiler/runtime

Add this to runtime/proc.go:

```
diff --git a/src/runtime/proc.go b/src/runtime/proc.go
index 401dcd0a11..6d8fde4349 100644
--- a/src/runtime/proc.go
+++ b/src/runtime/proc.go
@@ -267,6 +267,10 @@ func main() {
 		// has a main, but it is not executed.
 		return
 	}
+
+println("oops")
+	oops()
+
 	fn := main_main // make an indirect call, as the linker doesn't know the address of the main package when laying down the runtime
 	fn()
 	if raceenabled {
@@ -7079,3 +7083,14 @@ func doInit1(t *initTask) {
 		t.state = 2 // initialization done
 	}
 }
+
+//go:noinline
+func oops() {
+	oopssys()
+}
+
+//go:systemstack
+//go:noinline
+func oopssys() {
+	println("onsys")
+}
% 
```

Running any program crashes like this, at least on my arm64 mac:

```
oops
fatal error: attempt to execute system stack code on user stack

goroutine 1 gp=0x140000021c0 m=0 mp=0x100e67620 [running]:
runtime.throw({0x100c18075?, 0x100a7ee40?})
	/Users/rsc/go/src/runtime/panic.go:1021 +0x40 fp=0x14000131f10 sp=0x14000131ee0 pc=0x100a7c510
runtime.morestackc()
	/Users/rsc/go/src/runtime/stack.go:1296 +0x1c fp=0x14000131f30 sp=0x14000131f10 pc=0x100ab3a4c
runtime.oopssys()
	/Users/rsc/go/src/runtime/proc.go:7094 +0x44 fp=0x14000131f30 sp=0x14000131f30 pc=0x100a8ebd4
runtime.main()
	/Users/rsc/go/src/runtime/proc.go:272 +0x294 fp=0x14000131fc0 sp=0x14000131f30 pc=0x100a7ee44
runtime.main()
	/Users/rsc/go/src/runtime/proc.go:272 +0x294 fp=0x14000132050 sp=0x14000131fc0 pc=0x100a7ee44
runtime: g 1: unexpected return pc for runtime.main called from 0x14000131fb0
```

Note that the runtime.oops frame is missing entirely 
(runtime.main calls oops calls oopssys calls morestackc during prologue).
Probably the unwinder gets out of sync somewhere around there.
Perhaps the out-of-sync is also the reason for the 'unexpected return pc' failure during unwind.

/cc @aclements
Repository: rust
Issue: Broken build after updating: `coverage` is ambiguous; ambiguous because of a name conflict with a builtin attribute
Labels: A-resolve,P-medium,T-lang,T-compiler,C-bug,regression-untriaged,A-code-coverage,S-has-mcve

### Code

I have an internal macro for domain-specific coverage tracking:

```rust
macro_rules! coverage {
    () => {
        /* .. */
    };
}

pub(crate) use coverage;
```

On version 1.73.0, this compiles without error ([godbolt](https://rust.godbolt.org/z/des8vs4xf)).
On version 1.74.0 and above, this results in an error ([godbolt](https://rust.godbolt.org/z/6MfaeTv4W)):

```
error[E0659]: `coverage` is ambiguous
 --> <source>:7:16
  |
7 | pub(crate) use coverage;
  |                ^^^^^^^^ ambiguous name
  |
  = note: ambiguous because of a name conflict with a builtin attribute
  = note: `coverage` could refer to a built-in attribute
```

My understanding is that this is an acceptable breakage in general. (Though, perhaps should be in the 1.74.0 compatibility notes).

**However**, what might make this unacceptable is that this attribute is not actually stable:

```rust
#[coverage(off)]
pub fn foo() {}
```

gives ([godbolt](https://rust.godbolt.org/z/b6z3cnxz3)):

```
error[E0658]: the `#[coverage]` attribute is an experimental feature
 --> <source>:1:1
  |
1 | #[coverage(off)]
  | ^^^^^^^^^^^^^^^^
  |
  = note: see issue #84605 <https://github.com/rust-lang/rust/issues/84605> for more information
  = help: add `#![feature(coverage_attribute)]` to the crate
```

Is it expected that an inactive experimental attribute can cause name ambiguity on stable Rust?
Repository: flutter
Issue: Dependabot PRs occasionally will not be merged as "unmergeable"
Labels: team-infra,P2,triaged-infra

### Type of Request

bug

### Infrastructure Environment

Autosubmit

### What is happening?

When dependabot goes to create a bump version PR it will occasionally get a message from autosubmit stating that the PR cannot be merged since it is "unmergeable." The issue is with github and the internal flags it uses to show that something is mergeable. 

The two mergeable and mergeable_state are used by github to determine mergeability. We use the latter and in the case of this situation the other flag will actually show that the PR is mergeable.

One solution may be to look at the other flag in this instance.

Opening to track to see how often this occurs. 

### Steps to reproduce

Happens with dependabot PRs.

### Expected results

I would assume that these pull requests are merged.