sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Borrow checker error does not figure out source of `'static` requirement through closure capture
Labels: A-diagnostics,P-medium,T-compiler,regression-from-stable-to-stable

### Code

```Rust
fn main() {
    let targets = String::new();
    let queue = targets.as_str();

    (move || require_static(queue))();
}

fn require_static(_: &'static str) {}
```


### Current output

```Shell
error[E0597]: `targets` does not live long enough
 --> src/main.rs:3:17
  |
2 |     let targets = String::new();
  |         ------- binding `targets` declared here
3 |     let queue = targets.as_str();
  |                 ^^^^^^^---------
  |                 |
  |                 borrowed value does not live long enough
  |                 argument requires that `targets` is borrowed for `'static`
...
6 | }
  | - `targets` dropped here while still borrowed

For more information about this error, try `rustc --explain E0597`.
error: could not compile `playground` (bin "playground") due to 1 previous error
```


### Desired output

```Shell
error[E0597]: `targets` does not live long enough
 --> src/main.rs:3:17
  |
2 |     let targets = String::new();
  |         ------- binding `targets` declared here
3 |     let queue = targets.as_str();
  |                 ^^^^^^^ borrowed value does not live long enough
4 |
5 |     (move || require_static(queue))();
  |              --------------------- argument requires that `targets` is borrowed for `'static`
6 | }
  | - `targets` dropped here while still borrowed

For more information about this error, try `rustc --explain E0597`.
error: could not compile `playground` (bin "playground") due to 1 previous error
```


### Rationale and extra context

_No response_

### Other cases

```Rust
This works on stable, but regressed on nightly.
```


### Rust Version

```Shell
rustc 1.80.0-nightly (804421dff 2024-06-07)
```


### Anything else?

_No response_
Repository: pytorch
Issue: test/dynamo/test_torchrec.py doesn't run in OSS CI (and won't run locally)
Labels: triaged,oncall: pt2,module: dynamo

Putting up this issue. I was in the middle of fixing it and got distracted, I may or may not come back to it.

What's going on is:
- we run this test internally, which is why it hasn't bitrotten yet
- our fbgemm and torchrec commit pins need to be updated. (I can't seem to compile fbgemm from main in open source, though)
- the test needs a test that it runs in OSS CI, otherwise, it will regress again

cc @ezyang @anijain2305 @chauhang @voznesenskym @penguinwu @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @chenyang78 @kadeng
Repository: storybook
Issue: [Bug]: infinite paths on Add a new story: ENAMETOOLONG. Function unavailable
Labels: bug,core,sev:S3

### Describe the bug

When attempting to document a new component, component search fails

BUG:
A large RED popup window with white text beginning
An error occurred while searching for components in the project. ENAMETOOLONG: name too long, scandir '/

IMPACT:
No components can be documented using the UI
may occur for any user on any host

SYMPTOMTS:
—1 the paths listed are away from the project directory but in the root file-system directory in which the project is located
—2 Storyboard is for some reason scanning directories outside the project directory
—3 The BUG can occur for any user on any host

Apparently, scanning is not filtered for cyclic symbolic paths. A map of absolute paths is going to be required
file systems do not guarantee the path to a particular node being unique even when symlinks are resolved, so a limit on recursion must be implemented, like Go limits to 100 symlinks

CAUSE:
some permitted use of symlinks in the file system that Storybook decides to scan but is unable to successfully complete

### Reproduction link

N/A

### Reproduction steps

install vanilla storybook
on browser Storybook page, click +next to Find Components search box
In lightbox Add a new story ./components/**/*.tsx search box, type a character


### System

```bash
macOS 14.5 vite React Storybook 8.1+
```


### Additional context

_No response_
Repository: rust
Issue: `async_closure`: error: implementation of `AsyncFnOnce` is not general enough
Labels: T-compiler,C-bug,A-async-await,AsyncAwait-Triaged,T-types

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I'm not sure if this is *really* a bug (or perhaps a duplicate issue of another bug). However, I can't see any reason why this shouldn't work.

I tried this code:

```rust
#![feature(async_closure)]

fn assert_send<T: Send>(_: T) {}

#[derive(Clone)]
struct Ctxt<'a>(&'a ());

async fn commit_if_ok<'a>(ctxt: &mut Ctxt<'a>, f: impl async FnOnce(&mut Ctxt<'a>)) {
    f(&mut ctxt.clone()).await;
}

fn operation(mut ctxt: Ctxt<'_>) {
    assert_send(async {
        commit_if_ok(&mut ctxt, async |_| todo!()).await;
    });
}

fn main() {}
```

I expected to see this happen: Code compiles successfully

Instead, this happened: Compile error:
```
error: implementation of `AsyncFnOnce` is not general enough
  --> src/lib.rs:13:5
   |
13 | /     assert_send(async {
14 | |         commit_if_ok(&mut ctxt, async |_| todo!()).await;
15 | |     });
   | |______^ implementation of `AsyncFnOnce` is not general enough
   |
   = note: `{async closure@src/lib.rs:14:33: 14:42}` must implement `AsyncFnOnce<(&mut Ctxt<'1>,)>`, for any two lifetimes `'0` and `'1`...
   = note: ...but it actually implements `AsyncFnOnce<(&mut Ctxt<'_>,)>`

error: could not compile `playground` (lib) due to 1 previous error
```

 (see https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=536db823e50d32307ee54645dbec25c6)

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.80.0-nightly (032af18af 2024-06-02)
binary: rustc
commit-hash: 032af18af578f4283a2927fb43b90df2bbb72b67
commit-date: 2024-06-02
host: x86_64-unknown-linux-gnu
release: 1.80.0-nightly
LLVM version: 18.1.6
```

</p>
</details>
Repository: vscode
Issue: Skip re-requesting implicit code actions if diagnostics around the cursor have not changed
Labels: editor-code-actions,under-discussion

https://github.com/microsoft/vscode/blob/a0185ee7cbcceda421361a2af44989dd40916a51/src/vs/editor/contrib/codeAction/browser/codeActionModel.ts#L57

I believe the implicit code actions are re-requested whenever  diagnostics in the file change. Instead I proposed that we only re-request code actions if the diagnostics on the cursor's currently line change. For example, if I'm one line 100 and the diagnostics at the very top of the file change, we should not compute code actions

This is impacting some prototype work that TS is doing around sending incremental diagnostic updates
Repository: flutter
Issue: `Matrix4 entries must be finite. 'dart:ui/painting.dart'`
Labels: a: tests,c: crash,platform-ios,framework,P3,team-framework,triaged-framework

### Steps to reproduce

use https://github.com/svthalia/Reaxit/tree/fe7c99c0852a7cbf8e44bbb73647ac473baa090d
Run the integration tests in github CI, try about 20 times and it should fail at least once. It is flaky

### Expected results

The tests should all pass

### Actual results

Sometimes the tests fail, such as in this case:
```
flutter: ══╡ EXCEPTION CAUGHT BY SCHEDULER LIBRARY ╞═════════════════════════════════════════════════════════
flutter: The following assertion was thrown during a scheduler callback:
flutter: Matrix4 entries must be finite.
flutter: 'dart:ui/painting.dart':
flutter: Failed assertion: line 42 pos 10: '<optimized out>'
flutter:
flutter: Either the assertion indicates an error in the framework itself, or we should provide substantially
flutter: more information in this error message to help you determine and fix the underlying cause.
flutter: In either case, please report this assertion by filing a bug on GitHub:
flutter:   https://github.com/flutter/flutter/issues/new?template=2_bug.yml
flutter:
flutter: When the exception was thrown, this was the stack:
flutter: #2      _matrix4IsValid (dart:ui/painting.dart:42:10)
flutter: #3      _NativeSceneBuilder.pushTransform (dart:ui/compositing.dart:642:12)
flutter: #4      TransformLayer.addToScene (package:flutter/src/rendering/layer.dart:1991:27)
flutter: #5      ContainerLayer.buildScene (package:flutter/src/rendering/layer.dart:1130:5)
flutter: #6      RenderView.compositeFrame (package:flutter/src/rendering/view.dart:252:37)
flutter: #7      RendererBinding.drawFrame (package:flutter/src/rendering/binding.dart:596:20)
flutter: #8      WidgetsBinding.drawFrame (package:flutter/src/widgets/binding.dart:986:13)
flutter: #9      RendererBinding._handlePersistentFrameCallback (package:flutter/src/rendering/binding.dart:457:5)
flutter: #10     SchedulerBinding._invokeFrameCallback (package:flutter/src/scheduler/binding.dart:1325:15)
flutter: #11     SchedulerBinding.handleDrawFrame (package:flutter/src/scheduler/binding.dart:1255:9)
flutter: #12     LiveTestWidgetsFlutterBinding.handleDrawFrame (package:flutter_test/src/binding.dart:1780:13)
flutter: #13     SchedulerBinding.scheduleWarmUpFrame.<anonymous closure> (package:flutter/src/scheduler/binding.dart:978:7)
flutter: #24     _RawReceivePort._handleMessage (dart:isolate-patch/isolate_patch.dart:184:12)
flutter: (elided 12 frames from class _AssertionError, class _Timer, dart:async, and dart:async-patch)
flutter: ════════════════════════════════════════════════════════════════════════════════════════════════════
```

### Code sample

https://github.com/svthalia/Reaxit/tree/fe7c99c0852a7cbf8e44bbb73647ac473baa090d

### Screenshots or Video

_No response_

### Logs

[logs_23871072258.zip](https://github.com/user-attachments/files/15809600/logs_23871072258.zip)

### Flutter Doctor output

I did not run this, but the environment is fully reproducible using github actions
Repository: pytorch
Issue: [torch.compile] Llama2 failure using dynamic shapes with Torch 2.4 nightly
Labels: triaged,oncall: pt2,module: dynamic shapes

### 🐛 Describe the bug

torch.compile fails with the following error on Llama2. The error seems to occuring here : https://github.com/pytorch/TensorRT/blob/main/py/torch_tensorrt/dynamo/backend/backends.py#L90-L97
```py
RuntimeError: View operation returned a tensor that is the same as the input base tensor.  This is no longer allowed; you must explicitly create a new tensor (e.g., using .detach()). As a user, you could have made a mistake implementing __torch_dispatch__ or a Python operator decomposition or meta registration; if that's not the case, please report a bug to PyTorch or the backend you are using.
```

Please run the following instructions to reproduce:

1) Please login via huggingface-cli (install it via pip install -U "huggingface_hub[cli]" )
https://huggingface.co/docs/huggingface_hub/en/guides/cli#huggingface-cli-login. The user access token can be accessed in your settings.

2) Please install transformers via `pip install transformers=4.41.2`. You can install torch_tensorrt nightly via `pip install torch_tensorrt --index-url https://download.pytorch.org/whl/nightly/cu121` 

3) Run the following script

```py
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
import torch_tensorrt

llama_path = "meta-llama/Llama-2-7b-hf"
model = AutoModelForCausalLM.from_pretrained(llama_path).eval().cuda()
tokenizer = AutoTokenizer.from_pretrained(llama_path)

base_prompt = "How many hours are in a day?"
base_inputs = tokenizer(base_prompt, return_tensors="pt").to("cuda:0")
input_ids = base_inputs.input_ids
pyt_out = model(input_ids)

from torch.nn.attention import SDPBackend
with torch.nn.attention.sdpa_kernel([SDPBackend.MATH]), torch.no_grad():
    torch._dynamo.mark_dynamic(input_ids, 1, min=2, max=1024)
    model.model = torch.compile(model.model, backend="tensorrt",
                                dynamic=False,
                                fullgraph=True,
                                options={"truncate_long_and_double": True,
                                        "debug": True,
                                        "enabled_precisions": {torch.half},}
                                )
```

The whole log can be found here 
[llama2_tc.log](https://github.com/user-attachments/files/15810273/llama2_tc.log)

cc: @ezyang @angelayi Any suggestions here ? Thanks 

### Error logs

_No response_

### Minified repro

_No response_

### Versions

[pip3] numpy==1.26.4
[pip3] pytorch-triton==3.0.0+45fff310c8
[pip3] torch==2.4.0.dev20240610+cu121
[pip3] torch-tensorrt==2.4.0.dev0+a8a079715
[pip3] torchvision==0.19.0.dev20240610+cu121
[pip3] triton==2.3.1
transformers==4.41.2

cc @ezyang @anijain2305 @chauhang
Repository: bitcoin
Issue: docs: Wrong/outdated docs for `tr(KEY)` in doc/descriptors.md
Labels: Docs,Descriptors

Bitcoin Core uses BIP-386 for `tr(...)` descriptors, and in the case of `tr(KEY)`, the produced key is tweaked according to BIP-341: 

https://github.com/bitcoin/bips/blob/85cda4e225b4d5fd7aff403f69d827f23f6afbbc/bip-0341.mediawiki?plain=1#L156

In the current descriptors.md, it is documented that `tr(KEY)` uses `KEY` as the internal key, with no further comment:

https://github.com/bitcoin/bitcoin/blob/a7bc9b76e73f04dfe4d6ba42033fe38659090e8b/doc/descriptors.md?plain=1#L82

By looking only at descriptors.md without knowledge or reference to BIP-386, one can interpret `tr(KEY)` to use `KEY` directly without tweaking.

Ideally the docs should be expanded to reference BIP-386.
Repository: ollama
Issue: Add ollama run model --disable_model_load_on_start option.
Labels: feature request

I want an option that disables loading model on start of conversation. It will be helpful with another model requests from another client.
Repository: rust
Issue: rustdoc CURRENT_RUSTC_VERSION shows incorrect version between version bump and stage0 bump
Labels: T-rustdoc,T-bootstrap,A-docs,C-bug

Items marked with the stability attribute and `CURRENT_RUSTC_VERSION` will show the wrong version in nightly rustdoc output in between the version bump and the stage0 bump. That means in this sequence:

1. Item gets marked with `CURRENT_RUSTC_VERSION`.  Example, on nightly the current rust version is 1.80, which is what rustdoc shows.
3. Version is bumped [example](https://github.com/rust-lang/rust/pull/126114) bumps to 1.81.
4. Nightly docs for `CURRENT_RUSTC_VERSION` marked items now show 1.81 when they should say 1.80.
5. Stage0 is bumped, and CURRENT_RUSTC_VERSION placeholders get replaced [example](https://github.com/rust-lang/rust/pull/126273/). The item is now correctly marked 1.80.

This can be confusing since there can be a window of several days where the wrong version is displayed.
Repository: TypeScript
Issue: 5.4.5 nuget package is missing.
Labels: Visual Studio

### Acknowledgement

- [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Comment

[Nuget](https://www.nuget.org/packages/Microsoft.TypeScript.MSBuild#versions-body-tab) has 5.4.4 and 5.5.0.
Repository: flutter
Issue: Make it easier to develop for Android in the engine.
Labels: P2,c: tech-debt,team-engine,triaged-engine

Today, it is possible to setup language servers for C++, Python, and Dart sources in the engine. However, I have not been able to find a reliable setup for editing Java code in the engine. 

Anecdotally, editing java code is pretty miserable. I usually just have to resort to editing the file as plain text with no IDE features with only basic syntax highlighting and formatting.

This should be better.
Repository: pytorch
Issue: aot_export_module produces unserializable GraphModules
Labels: triaged,oncall: pt2,oncall: export

### 🐛 Describe the bug

GraphModules returned from aot_export_module cannot be saved and loaded successfully:

```
import torch
from torchvision.models import resnet18

def custom_compiler(model: torch.fx.GraphModule, example_inputs):
    gm, _ = torch._functorch.aot_autograd.aot_export_module(
        model,
        example_inputs,
        trace_joint=False,
        decompositions=torch._decomp.core_aten_decompositions(),
    )

    torch.save(gm, "resnet18_gm.pt2")

    return model.forward

if __name__ == "__main__":    
    model = resnet18().eval()
    input = torch.randn(1, 3, 224, 224)
    cmodel = torch.compile(model, backend=custom_compiler)
    output = cmodel(input)
    
    torch.load("resnet18_gm.pt2")
```

```
Traceback (most recent call last):
  File "/data/bvhworkspace/pt2/serialize_graph_module.py", line 22, in <module>
    torch.load("resnet18_gm.pt2")
  File "/data/bvhworkspace/.venv/lib/python3.10/site-packages/torch/serialization.py", line 1025, in load
    return _load(opened_zipfile,
  File "/data/bvhworkspace/.venv/lib/python3.10/site-packages/torch/serialization.py", line 1446, in _load
    result = unpickler.load()
  File "/data/bvhworkspace/.venv/lib/python3.10/site-packages/torch/fx/graph_module.py", line 129, in reduce_graph_module
    return _deserialize_graph_module(forward, body)
  File "/data/bvhworkspace/.venv/lib/python3.10/site-packages/torch/fx/graph_module.py", line 193, in _deserialize_graph_module
    graph = KeepModules().trace(com, **tracer_extras)
TypeError: _ModuleStackTracer.__init__() missing 1 required positional argument: 'scope_root'
```

### Versions

PyTorch version: 2.3.1+cpu
Is debug build: False
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: Ubuntu 22.04.3 LTS (x86_64)
GCC version: (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Clang version: 14.0.0-1ubuntu1.1
CMake version: version 3.22.1
Libc version: glibc-2.35

Python version: 3.10.12 (main, Nov 20 2023, 15:14:05) [GCC 11.4.0] (64-bit runtime)
Python platform: Linux-5.15.0-112-generic-x86_64-with-glibc2.35
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: True

CPU:
Architecture:                       x86_64

Versions of relevant libraries:
[pip3] numpy==1.26.4
[pip3] pytorch-lightning==2.2.3
[pip3] torch==2.3.1+cpu
[pip3] torch-utils==0.1.2
[pip3] torchaudio==2.2.1+cpu
[pip3] torchmetrics==1.3.2
[pip3] torchvision==0.18.1+cpu
[pip3] triton==2.3.0
[conda] Could not collect


cc @ezyang @chauhang @penguinwu @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4 @anijain2305
Repository: flutter
Issue: [fuchsia] Flutter schedules too many fences when calling `Present` in the rasterized thread, causing a crash
Labels: c: crash,engine,platform-fuchsia,P3,team-engine,triaged-engine

### Steps to reproduce

Sporadic.

### Expected results

A frame is rendered.

### Actual results

Crash.  Stack trace below.

```
0x80006df14ef4	(libc.so - abort.cc:16)	__llvm_libc::__abort_impl__
0x80006df06520	(libc.so - zx_panic_libc.cc:32)	__zx_panic
0x534899ec	(<_> - handle_close_many.cc:29)	fidl::HLCPPOutgoingBody::~HLCPPOutgoingBody()
0x5388a2d8	(<_> - fidl.cc:0)	fuchsia::ui::composition::Flatland_Proxy::Present(fuchsia::ui::composition::PresentArgs)
0x534541f8	(<_> - flatland_connection.cc:73)	<name omitted>
0x53453a48	(<_> - flatland_connection.cc:143)	<name omitted>
0x53454054	(<_> - function.h:531)	fit::internal::target<auto fit::bind_member<void, flutter_runner::FlatlandConnection, fuchsia::ui::composition::OnNextFrameBeginValues>(flutter_runner::FlatlandConnection*, void (flutter_runner::FlatlandConnection::*)(fuchsia::ui::composition::OnNextFrameBeginValues))::'lambda'(fuchsia::ui::composition::OnNextFrameBeginValues), false, false, std::__2::allocator<std::byte>, void, fuchsia::ui::composition::OnNextFrameBeginValues>::invoke(void*, fuchsia::ui::composition::OnNextFrameBeginValues)
0x5388a08c	(<_> - function.h:522)	fuchsia::ui::composition::Flatland_Proxy::Dispatch_(fidl::HLCPPIncomingMessage)
0x53486328	(<_> - proxy_controller.cc:103)	<name omitted>
0x53485d00	(<_> - message_reader.cc:235)	fidl::internal::MessageReader::CallHandler(async_dispatcher*, async_wait*, int, zx_packet_signal const*)
0x534a3fb8	(<_> - loop.c:0)	async_loop_dispatch_wait
0x534a48e4	(<_> - loop.c:343)	async_loop_run
0x534ab4b8	(<_> - loop_wrapper.cc:21)	fml::MessageLoopFuchsia::Run()
0x534a7224	(<_> - message_loop_impl.cc:94)	fml::MessageLoop::Run()
0x534a9694	(<_> - thread.cc:154)	<name omitted>
0x534a93d4	(<_> - function.h:856)	fml::ThreadHandle::ThreadHandle(std::__2::function<void ()>&&)::$_0::__invoke(void*)
0x80006df1ab74	(libc.so - pthread_create.c:57)	start_pthread
0x80006df58164	(libc.so - thread.cc:100)	thread_trampoline(unsigned long, unsigned long)
```

### Code sample

N/A

### Screenshots or Video

N/A

### Logs

N/A

### Flutter Doctor output

N/A
Repository: flutter
Issue: Easier, more direct access to ink effects
Labels: design doc,:scroll:

### Document Link

https://flutter.dev/go/layered-material-widgets

### What problem are you solving?

Ink effects are painted on an underlying `Material` widget, which has configuration options for elevation, border radius, clip behavior, and text style—even if none of those are necessary. Currently, the ability to create ink effects is exclusive to the Material library, even though the same concept is used in other design systems.

This design doc proposes a solution that more closely adheres to Flutter's [layered framework design philosophy](https://github.com/flutter/flutter/blob/master/docs/contributing/Style-guide-for-Flutter-repo.md#layers).
Repository: ollama
Issue: Suggestion for RFC7231 Compliant Endpoint for Model Deletion
Labels: feature request,api

**Description:**
Currently, the Ollama library’s DELETE /api/delete endpoint requires the model name to be provided in the request body. However, it would be beneficial and more in line with RFC7231 standards to support a URL-based model name specification. This approach is more intuitive and aligns with common RESTful API practices.

**RFC Reference:**
[RFC7231 Section 4.3.5](https://datatracker.ietf.org/doc/html/rfc7231#section-4.3.5) states: "A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request." While Ollama does handle this fine, certain tooling and source-code generators may draw issue with this in the future. Especially anything targeting OpenAPI spec <3.1.

**Proposed Change:**
Introduce a new endpoint or modify the existing endpoint to allow specifying the model name directly in the URL path. This would make the API more user-friendly and compliant with RESTful principles, ensuring compatibility with a wider range of HTTP implementations.

**Current Implementation:**
```bash
curl -X DELETE http://localhost:11434/api/delete -d '{
  "name": "llama3:13b"
}'
```

**Proposed Implementation:**
```bash
curl -X DELETE http://localhost:11434/api/models/llama3:13b
```

**Request:**
- **Endpoint:** `DELETE /api/models/{name}`
- **Parameters:** `name` (model name to delete)
- **Response:**
  - 200 OK if successful
  - 404 Not Found if the model to be deleted doesn’t exist

**Benefits:**
- Enhanced clarity and usability of the API.
- Improved compliance with established HTTP standards.
- Avoids potential issues with HTTP implementations that reject DELETE requests with payloads.
- Easier integration and interaction with the API for developers.

**Example:**
```bash
curl -X DELETE http://localhost:11434/api/models/llama3:13b
```

**Response:**
```json
{
  "status": "success",
  "message": "Model llama3:13b deleted successfully."
}
```