sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: ICE: E0107 points into derived code
Labels: A-diagnostics,I-ICE,T-compiler,C-bug,S-bug-has-test,requires-debug-assertions

<!--
ICE: Rustc ./a.rs '' 'thread 'rustc' panicked at /home/gh-matthiaskrgr/vcs/github/rust_debug_assertions/compiler/rustc_errors/src/diagnostic.rs:1006:9: 'Span must not be empty and have no suggestion'', 'thread 'rustc' panicked at /home/gh-matthiaskrgr/vcs/github/rust_debug_assertions/compiler/rustc_errors/src/diagnostic.rs:1006:9: 'Span must not be empty and have no suggestion''
File: /tmp/f/2/a.rs
-->

auto-reduced (treereduce-rust):
````rust
struct NonGeneric {}

#[derive(Default)]
struct NonGeneric<'a, const N: usize> {}

````

original:
````rust
struct NonGeneric {}

#[derive(Default)]
struct NonGeneric<'a, const N: usize> {}

pub fn main() {}

````

Version information
````
rustc 1.85.0-dev
binary: rustc
commit-hash: unknown
commit-date: unknown
host: x86_64-unknown-linux-gnu
release: 1.85.0-dev
LLVM version: 19.1.5

````
Repository: vscode
Issue: Add .gitIgnore file in new prjects when initializing new Git Repos
Labels: feature-request,git


Type: <b>Feature Request</b>

I created a new project in VSCode and created new repo in GitHub from from it using VSCode. But .gitIgnore file is not added to the project by default. 

VS Code version: Code 1.95.3 (Universal) (f1a4fb101478ce6ec82fe9627c43efbf9e98c813, 2024-11-13T14:50:04.152Z)
OS version: Darwin arm64 24.1.0
Modes:


<!-- generated by issue reporter -->
Repository: langchain
Issue: DOC: Exceptions that can be raised by the invocation of LLM models are not described
Labels: 🤖:docs

### URL

https://python.langchain.com/api_reference/core/language_models/langchain_core.language_models.llms.BaseLLM.html

### Checklist

- [X] I added a very descriptive title to this issue.
- [X] I included a link to the documentation page I am referring to (if applicable).

### Issue with current documentation:

The invoke() or ainvoke() methods of BaseLLMs may raise exceptions, yet the latter are not described in a "**Raises**" section. Some specific implementations like OpenAI's models should have their own exceptions documented too (like RateLimitError I guess).

The problem is that it's currently difficult to write a code that properly handles all possible exceptions without knowing them.

### Idea or request for content:

On top on the "Return type" section, a "Raises" section should be added for invoke() and ainvoke() and maybe other methods.
Repository: go
Issue: x/tools/gopls: feature request: refactor.extract.struct
Labels: FeatureRequest,gopls,Tools,Refactoring

[in slack](https://gophers.slack.com/archives/C0VPK4Z5E/p1733498044427149)

Suppose I have:

```go
type X struct {
  A, B, C, D string
}
```

and I want to move to:

```go
type Y struct {
  A, B string
}

type X struct {
  Y
  C, D string
}
```

It would be nice to have some help with that.
Repository: ollama
Issue: Administrative / silent install is borked
Labels: feature request,windows,install

### What is the issue?

For deployment scenarios like for classrooms or to regular managed devices the setup needs to perform an administrative / unattended install. For InnoSetup built installers this can normally be done via the command-line switches /SILENT (or /VERYSILENT) or via a response file via /LOADINF. (See: https://jrsoftware.org/ishelp/index.php?topic=setupcmdline ) 

If the setup can be performed by both, an unprivileged user and an administrator the switch "/ALLUSERS" helps to select the latter. If the install paths are (correctly) derived from the common environment variables this should automagically move the files to "C:\Program Files" or "C:\Program Files (x86)" instead of the users AppData folder. 

Normally this would also lead the installer engine to register the application under the systems registry (HKLM:) and create a system wide start menu.

With Ollamas setup this does not work even though setting the install-path like mentioned in the documentation to 'C:\Program Files\Ollama' makes it look like it should. 

Instead it creates a mix of both methods where the files are installed to the Program Files folder, but the registry and start menu entries are limited to the user (context) installing the software. And as most management system use a local system service as context this creates a rather weird state. And even if I could limit the permissions down - for a classroom for example I can never know which user will access the device...

### OS

Windows

### GPU

_No response_

### CPU

_No response_

### Ollama version

0.4.7
Repository: flutter
Issue: [packages] Eliminate use of Pigeon `dartHostTestHandler`
Labels: team,package,team-ecosystem,P2,triaged-ecosystem

In my experience doing Pigeon conversions of our plugins, `dartHostTestHandler` didn't make tests noticeably easier than simply mocking/faking/stubbing the host API class directly, and in some cases it was actually harder to use correctly to simulate things like exceptions. We have a robust test suite for Pigeon itself, so having package-level unit tests covering part of the Pigeon serialization isn't necessary, and the test generator is another generator we need to maintain.

We should try to eliminate all use of `dartHostTestHandler` in our own plugins, and if we are able to do so without any significant issues, remove the test generator from Pigeon entirely to reduce complexity and ongoing maintenance costs.

Current usage:
- [ ] `camera_android_camerax`
- [ ] `file_selector_ios`
- [ ] `file_selector_linux`
- [ ] `file_selector_macos`
- [ ] `file_selector_windows`
- [ ] `image_picker_android`
- [ ] `image_picker_ios`
- [ ] `in_app_purchase_storekit`
- [ ] `path_provider_android`
- [ ] `path_provider_foundation`
- [ ] `shared_preferences_android`
- [ ] `shared_preferences_foundation`
- [ ] `url_launcher_windows`
- [ ] `video_player_android`
- [ ] `video_player_avfoundation`
- [ ] `webview_flutter_wkwebview`
Repository: rust
Issue: Tracking issue for release notes of #43244: Tracking issue for Vec::extract_if and LinkedList::extract_if
Labels: A-collections,T-libs-api,relnotes,relnotes-tracking-issue


This issue tracks the release notes text for #43244.

### Steps

- [ ] Proposed text is drafted by PR author (or team) making the noteworthy change.
- [ ] Issue is nominated for release team review of clarity for wider audience.
- [ ] Release team includes text in release notes/blog posts.

### Release notes text

The responsible team for the underlying change should edit this section to replace the automatically generated link with a succinct description of what changed, drawing upon text proposed by the author (either in discussion or through direct editing).

````markdown
# Category (e.g. Language, Compiler, Libraries, Compatibility notes, ...)
- [Tracking issue for Vec::extract_if and LinkedList::extract_if](https://github.com/rust-lang/rust/issues/43244)
````

> [!TIP]
> Use the [previous releases](https://doc.rust-lang.org/nightly/releases.html) categories to help choose which one(s) to use.
> The category will be de-duplicated with all the other ones by the release team.
>
> *More than one section can be included if needed.*

### Release blog section

If the change is notable enough for inclusion in the blog post, the responsible team should add content to this section.
*Otherwise leave it empty.*

````markdown
````

cc @Gankra, @the8472 -- origin issue/PR authors and assignees for starting to draft text
Repository: flutter
Issue: Default `GestureDetector` Hit Test Behavior of `deferToChild` Is Counterintuitive
Labels: c: new feature,framework,d: api docs,f: gestures,c: proposal,P2,team-framework,triaged-framework

### Steps to reproduce

1. Create a text widget with some padding around it and wrap it in a gesture detector
2. Tap on the visible text and note that the on tap is fired
3. Tap on the padded space immediately next to the text

### Expected results

The on tap is fired in step 3

### Actual results

The on tap is not fired in step 3


### Why this is a problem

This is "working as intended" because the default hit test behavior for `GestureDetector` is `deferToChild` and `Padding` does not consider the padded space for hit testing. This is reasonable if not desirable behavior in many circumstances, **but it is not intuitive enough to be a sane default**. Developers who are unaware of this nuanced behavior introduce usability issues everywhere in their app by creating text buttons with much smaller tappable regions than intended. Ideally, developers would just use `InkWell` or `TextButton`, but in practice the vast majority of major companies do not want to be that tied to Material and choose to write their own custom button wrappers as a part of their company-specific design system.

### Proposal

Make `HitTestBehavior behavior` a required argument with no default value. This will be slightly more annoying for developers, but it will force them to consciously choose the desired hit test behavior. IMO the increase in verbosity is more than justified by the reduction in developer confusion and bugs-explicitness is pretty reasonable here given that `GestureDetector` is a comparatively low level widget and if you want ease-of-use you should probably be using the more ready-made equivalents such as `InkWell`, etc.

### Code sample

<details open><summary>Code sample</summary>

```dart
return MaterialApp(
  title: 'Flutter Demo',
  home: Scaffold(
    body: Column(
      mainAxisAlignment: MainAxisAlignment.center,
      children: [
        // The padding around the button does not detect hit events because the
        // default hit test behavior is `deferToChild` and `Padding` doesn't
        // count padded space for hit testing.
        GestureDetector(
          onTap: () {
            print('Button A pressed!');
          },
          child: const Padding(
            padding: EdgeInsets.all(40),
            child: Text('Button A'),
          ),
        ),
        const Divider(),
        // Setting `behavior` to translucent fixes this.
        GestureDetector(
          behavior: HitTestBehavior.translucent,
          onTap: () {
            print('Button B pressed!');
          },
          child: const Padding(
            padding: EdgeInsets.all(40),
            child: Text('Button B'),
          ),
        ),
      ],
    ),
  ),
);
```

</details>


### Screenshots or Video

_No response_

### Logs

_No response_

### Flutter Doctor output

Not relevant.
Repository: flutter
Issue: Cocoon: be explicit about what "a long time" is when removing an assignment
Labels: team-infra,P3,triaged-infra

https://github.com/flutter/cocoon/blob/08d6d03f1cd7d62febe1901274250e05912d9673/triage_bot/lib/engine.dart#L1282

We know the value. Instead of saying `but has had no status updates in a long time` we could say
`but has had no status updates for ${dayCount} days`.
Repository: puppeteer
Issue: [Feature]: No way to set proxy to connect to a Chrome running in another PC.
Labels: feature,P3

### Feature description

My testing chrome instance is running in another PC in LAN.
I can connect to the services running in this PC via SSH socks5 proxy.

But the puppeteer's `.connect()` method does not provide a parameter like `proxy`, or `agent` (like what package `node-fetch` does), to allow to connect to a chrome instance running in a different PC as the running Node script.

I tried to redirect the traffic using means like proxychains, it works for `fetch()`, but not for puppeteer's `.connect()`.
Repository: TypeScript
Issue: Add caching to improve performance of rebuilds in --build mode
Labels: Needs Investigation

### 🔎 Search Terms

"processSourceFile cache"

### 🕗 Version & Regression Information

- I was unable to test this on prior versions because: I don't think this has changed since it was implemented


### ⏯ Playground Link

_No response_

### 💻 Code

We have a large monorepo with several very large React apps.

### 🙁 Actual behavior

Rebuilds wind up re-processing lots of files that did not change

### 🙂 Expected behavior

Files that did not change can reuse their parsing from earlier

### Additional information about the issue

It does not appear that --build mode uses caches for file reads and getSourceFile computation between runs.

I’ve been investigating long delays between the time a user saves a file in their editor and when the tsc process finishes and displays success or errors that it found. In doing some profiling, nearly 70% of the total time was being spent in processSourceFile and its descendants. This was surprising to me because my mental model was that it would have already processed these files and cached the results, and that only the changed files would have to be reevaluated.

From looking at the code, it appears that there are two fairly distinct codepaths depending on whether --build has been specified. When --build is used, it winds up in buildNextInvalidatedProjectWorker which clears the cache of parsed source files after every iteration. This is in contrast with with createWatchProgram, which appears to keep a persistent cache of the parsed files and takes care to evict things from the cache when necessary.

As a naive test, I added [caching](https://github.com/microsoft/TypeScript/compare/v5.6.2...mfedderly:TypeScript:mf/getSourceFile-cached?expand=1) to  createGetSourceFile which still performs the file read, compares the source file’s string against the previous string for this fileName, and then skips the parse if they match (I assume this is flawed for many reasons, including leaking memory from files that have been deleted). This led to nearly a ~50% reduction in time to finish the type checking and print its status (30.5s to 17s). I assume this can be further improved by avoiding the file reads or string compares using something like file mtime or hashes.

Would it be possible to improve caching of the parsed source files in --build mode between runs? There appears to be quite a bit of benefit available if it is technically feasible.
Repository: godot
Issue: `EditorUndoRedoManager` `custom_context` results in "UndoRedo history mismatch" error
Labels: topic:core,documentation

### Tested versions

- v4.3.stable.official [77dcf97d8]
- 1f47e4c4e3a09a422e96880a7918d986dd575a63

### System information

Godot v4.3.stable - Windows 10.0.19045 - Vulkan (Mobile) - dedicated NVIDIA GeForce GTX 980 Ti (NVIDIA; 32.0.15.6614) - Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz (8 Threads)

### Issue description

In both the [description](https://docs.godotengine.org/en/stable/classes/class_editorundoredomanager.html#description) and [create_action](https://docs.godotengine.org/en/stable/classes/class_editorundoredomanager.html#class-editorundoredomanager-method-create-action) documentation of `EditorUndoRedoManager`, it states:

>If `custom_context` object is provided, it will be used for deducing target history (instead of using the first operation).

But providing this `custom_context` often results in an error something like this:

```
UndoRedo history mismatch: expected 0, got 1.
```

### Steps to reproduce

```
@tool
extends EditorPlugin

func _enter_tree() -> void:
	# Initialization of the plugin goes here.
	add_tool_menu_item("perform undo redo test action", undo_redo_test_action)


func _exit_tree() -> void:
	# Clean-up of the plugin goes here.
	remove_tool_menu_item("perform undo redo test action")


func undo_redo_test_action() -> void:
	var sc: Shortcut = Shortcut.new()

	var undo_redo: EditorUndoRedoManager = get_undo_redo()
	undo_redo.create_action("performed test action", UndoRedo.MERGE_DISABLE, ProjectSettings)
	undo_redo.add_do_property(sc, "events", [])
	undo_redo.add_undo_property(sc, "events", [])
	undo_redo.commit_action()
```

In the above example, `ProjectSettings` is passed as a `custom_context`, which instructs `EditorUndoRedoManager` to use the global history, regardless of the first operation. When `add_do_property` is called with a `Shortcut` resource, the `EditorUndoRedoManager` throws this error message:

```
UndoRedo history mismatch: expected 0, got 1.
```

If I do not provide a `custom_context` when calling `create_action`, this results in the **scene** history being used because my `add_do_property` uses a `Shortcut` object. This is an incorrect deduction of which undo/redo history should be used, so I expect I should be able to use a `custom_context` object without any error messages to force the Global history.

### Minimal reproduction project (MRP)

[undo-redo-context-bug.zip](https://github.com/user-attachments/files/18040935/undo-redo-context-bug.zip)
Repository: go
Issue: x/net/html: improper newline handling
Labels: NeedsInvestigation

### Go version

go version go1.22.7 linux/amd64

### Output of `go env` in your module/workspace:

```shell
GO111MODULE=''
GOARCH='amd64'
GOBIN=''
GOCACHE='/home/gopher/.cache/go-build'
GOENV='/home/gopher/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFLAGS=''
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMODCACHE='/home/gopher/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/gopher/go'
GOPRIVATE=''
GOPROXY='direct'
GOROOT='/usr/lib/golang'
GOSUMDB='off'
GOTMPDIR=''
GOTOOLCHAIN='local'
GOTOOLDIR='/usr/lib/golang/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.22.7'
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-build410475203=/tmp/go-build -gno-record-gcc-switches'
```


### What did you do?

In trying to understand why our HTML to LateX parser sometimes produced incorrect entries (sentence endings that didn't make sense), we found an explanation in the html tokenizer.
In fact, when using CRLF (\r\n) line breaks, we found that calling the Token() method caused some invalid entries when calling Raw() (doubled characters).
The documentation does mention that calling Token() can modify Raw entries, but I can't see why my characters would be doubled.

[Here is an exemple of the issue](https://go.dev/play/p/ryt_NlVhkOX)

### What did you see happen?

Parsing `ABC\r\nDEF\r\nGHI\r\n` is returning:

```
ABC
DEF
GHI
I
```

### What did you expect to see?

```
ABC
DEF
GHI
```
Repository: godot
Issue: Bad PackedScene load() performance when handling GDScript inheritance
Labels: bug,topic:gdscript,needs testing,performance

### Tested versions

- Reproducible in latest version: 4.4 dev4, 4.4 dev6
- Haven't tested on prior versions, but I suspect that this is a long standing issue.
- Tested on Windows 10, Android (several)

### System information

Windows 10 - Godot 4.4 dev 6  - Any pipeline - GeForce GTX 970

### Issue description

Loading times of empty, inherited GDScript node scenes are unreasonably high. I know Godot Engine is more oriented to node composition than inheritance, and that binary scene format is more performant than .tscn. However, these PackedScene load() times of just a small chain of 3 or 4 **empty** inherited classes are very high. Each "extends X" adds more than 1ms to load() on an EMTPY class, the issue gets way worse when you have actual code in the classes. 

To me, that smells fishy as hell. And that there must be some big innefficiency in the GDScript class loading code.

I include an extremely simple MRP where you can see the degrade of performance on every inheritance step. We are talking +1ms on a Windows 10 i7 with an empty parent class, and an empty child (extends) class. Imagine with, you know, actual code. On a low end Android device.

### Steps to reproduce

Just mount a simple project like I include as MRP, a few simple scenes with 1 single node:

a.gd:
extends Control # Can be Node, Object, Control whatever ...
class_name A

a.tscn:
- A # That's it, just a single node with the empty class, all properties to defaults

b.gd:
extends A
class_name B

b.tscn:
- B

c.gd:
extends B
class_name C

c.tscn:
- C

...

Then on your main scene run this simple test to load the scenes and time it (on _ready() or wherever you want):

for type in ["a", "b", "c", "d"]:
	var tstart = Time.get_ticks_usec()
	load("res://" + type + ".tscn")
	var time = (Time.get_ticks_usec() - tstart) / 1000.0
	print("%s base load: %.2fms" % [type, time])

# Output (on a Windows 10 Intel i7, 16GB ram)

#a base load: 4.89ms
#b base load: 5.70ms
#c base load: 6.55ms
#d base load: 7.94ms

We are talking 8 ms loading an "empty" scene with an "empty" class on an Intel i7 with 16GB RAM. You can imagine the performance on a real case scenario (actual code, export vars, etc.) on a low end device (like mobile). 

I got to this MRP after a thorough investigation of why a not too complex scene load() was taking 30ms on my desktop computer (after seeing truly atrocious performance on Android).

### Minimal reproduction project (MRP)

[high_scene_load_times.zip](https://github.com/user-attachments/files/18041051/high_scene_load_times.zip)
Repository: flutter
Issue: Gesture Detection Fails When WebViewWidget is Nested Inside a Scaling Layout Widget
Labels: framework,f: gestures,a: platform-views,p: webview,package,has reproducible steps,P2,team-framework,triaged-framework,found in release: 3.24,found in release: 3.27

### What package does this bug report belong to?

webview_flutter

### What target platforms are you seeing this bug on?

macOS

### Have you already upgraded your packages?

Yes

### Dependency versions

_No response_

### Steps to reproduce

1. Attempt to interact with the web content:
2. Try scrolling, tapping buttons, or interacting with any clickable element within the scaled WebView.
3. Observe the behavior:
4. Gestures may not register correctly, if at all.
5. Interactions that normally work in an unscaled WebViewWidget fail.

### Expected results

Gestures also work when the WebViewWidget was scaled.

### Actual results

It seems like all pointers are offset by a linear factor proportional to the scaling.

### Code sample

<details open><summary>Code sample</summary>

```dart
import 'package:flutter/material.dart';
import 'package:webview_flutter/webview_flutter.dart';

void main() {
  runApp(const MaterialApp(
    home: ScaledWebViewTest(),
  ));
}

class ScaledWebViewTest extends StatelessWidget {
  const ScaledWebViewTest({super.key});

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: const Text('Scaled WebView Gesture Test')),
      body: Transform.scale(
        scale: 0.9,
        child: WebViewWidget(
          controller: WebViewController()
            ..setJavaScriptMode(JavaScriptMode.unrestricted)
            ..loadRequest(
                Uri.parse('https://codepen.io/BananaCoding/pen/mdrGjpL')),
        ),
      ),
    );
  }
}

```

</details>


### Screenshots or Videos

<details open>
<summary>Screenshots / Video demonstration</summary>

https://github.com/user-attachments/assets/03e356d9-586c-4088-b059-187fc1005bf6




</details>


### Logs

_No response_

### Flutter Doctor output

<details open><summary>Doctor output</summary>

```console
Doctor summary (to see all details, run flutter doctor -v):
[✓] Flutter (Channel stable, 3.24.5, on macOS 14.7 23H124 darwin-arm64, locale en-US)
[✗] Android toolchain - develop for Android devices
    ✗ cmdline-tools component is missing
      Run `path/to/sdkmanager --install "cmdline-tools;latest"`
      See https://developer.android.com/studio/command-line for more details.
[✓] Xcode - develop for iOS and macOS (Xcode 15.3)
[✓] Chrome - develop for the web
[!] Android Studio (not installed)
[✓] VS Code (version 1.94.2)
[✓] Connected device (3 available)
[✓] Network resources

! Doctor found issues in 2 categories.
```

</details>