sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Cannot call by reference to `&mut F: FnMut`
Labels: T-compiler,A-HIR,C-bug

<!--
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 tried this code:

```rust
fn call_by_ref<F, A0, A1>(mut f: F, arg0: A0, arg1: A1)
where
    A0: Sized,
    A1: Sized,
    for<'w> &'w mut F: FnMut(A0, A1),
{
    // This doesn't work.
    (&mut f)(arg0, arg1);
}

// Workaround
fn call_by_ref_and_hack<F, A0, A1>(mut f: F, arg0: A0, arg1: A1)
where
    A0: Sized,
    A1: Sized,
    for<'w> &'w mut F: FnMut(A0, A1),
{
    fn call_once<B0, B1>(f: impl FnOnce(B0, B1), arg0: B0, arg1: B1){
        f(arg0, arg1)
    }
    // This works
    call_once(&mut f, arg0, arg1);
}
```

I expected to see this happen: Both functions should compile and work.

Instead, this happened: Only version with inner function hack works.

### 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.70.0 (90c541806 2023-05-31)
```
AFAIK, it never worked.
Repository: rust
Issue: poor diagnostic for missing extern crate in 2015 edition
Labels: A-diagnostics,A-resolve,D-edition

## Description:

I have recently published a crate named [kmmp-structure](https://crates.io/crates/kmmp-structure) on crates.io and added it as a dependency to my [kmmp-generator](https://crates.io/crates/kmmp-generator) crate. In the Cargo.toml file of kmmp-generator, I have added the following dependency:
```toml
[dependencies]
kmmp-structure = "0.1.2"
```

I expect to be able to use the structs and code defined in the `kmmp-structure` crate without using the `extern crate` syntax, as I have successfully done with other crates like `serde_json` and `clap` in the past.

However, when I try to use the `kmmp-structure` crate in my code by adding the following line in `kmmp-generator's` lib.rs file:

```rust
pub use kmmp_structure::*;
```
Or 

```rust
use kmmp_structure::{
    project::{
        Project,
        Module,
    },
    gradle::{
        gradle_file::{
            ModuleContent,
            ModuleGradle,
            SettingsGradle
        },
        metadata::GradleProperties
    }
};
```
Cargo shows an error indicating a missing crate:

```rust
--> src\lib\mod.rs:6:9
   |
6  | pub use kmmp_structure::*;
   |         ^^^^^^^^^^^^^^ maybe a missing crate `kmmp_structure`?
   |
```

But then adding extern crate resolves the issue 
```rust
extern crate kmmp_structure;
pub use kmmp_structure::*;
```

Strangely, if I specify the precise path to the struct, the code compiles without any issues and i have tested this point with different structs in different paths

```rust
impl Generate for kmmp_structure::....::ModuleGradle<'_>
```

### 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.70.0 (90c541806 2023-05-31)
binary: rustc
commit-hash: 90c541806f23a127002de5b4038be731ba1458ca
commit-date: 2023-05-31
host: x86_64-pc-windows-msvc
release: 1.70.0
LLVM version: 16.0.2
```
`cargo --version --verbose`
```rust
cargo 1.70.0 (ec8a8a0ca 2023-04-25)
release: 1.70.0
commit-hash: ec8a8a0cabb0e0cadef58902470f6c7ee7868bdc
commit-date: 2023-04-25
host: x86_64-pc-windows-msvc
libgit2: 1.6.3 (sys:0.17.0 vendored)
libcurl: 8.0.1-DEV (sys:0.4.61+curl-8.0.1 vendored ssl:Schannel)
os: Windows 10.0.19045 (Windows 10 Home) [64-bit]
```

I am using the stable version of the Rust compiler.

Please note that both crates (`kmmp-structure` and `kmmp-generator`) are written by me and are using the same tool versions. I have successfully used other crates without the need for `extern crate` in the past or with other crates like `serde_json`
Repository: angular
Issue: Add convenience methods to eliminate control getters
Labels: feature,area: forms,feature: insufficient votes

### Which @angular/* package(s) are relevant/related to the feature request?

forms

### Description

Oftentimes when working with reactive forms, we need to create control getters in order to be able to get a reference to `AbstractControl` with a coercion to a more specific type:

```ts
get myArrayCtrl(){
  return this.form.get('path.to.control') as FormArray
}
```

```html
<div *ngFor="let control of myArrayCtrl.controls; let i = index">
...
</div>
```

This happens usually when working with FormArrays, but also when you need a`[formGroup]` in order to be able to use `formControlName` in `ng-template` (Error: NG01050: formControlName must be used with a parent formGroup directive.). Unfortunately, in the template it doesn't seem possible to provide the coercion, so we need to go and create a getter.

With just one getter this might not be a big deal, but with complex forms every single getter contributes to unnecessary boilerplate code. Sometimes you need to use the reference in multiple places, so making a getter might actually make a lot of sense, but for just one instance creating a getter feels superficial.

### Proposed solution

Therefore, I would propose (assuming that this is feasible at all) that reactive forms provide a collection of convenience methods `getFormGroup | getFormArray | getFormControl | getFormRecord` which internally would do the necessary coercion and **could be used directly within templates**:

```html
<ng-template [formGroup]="form.getFormGroup('path.to.form.group')">
...
</ng-template>

<div *ngFor="let control of form.getFormArray('my.array').controls; let i = index">
...
</div>
```

(or `getAsFormGroup | ...` etc)

This would eliminate the getters and slim our code a bit.

### Alternatives considered

Let's make the alternative obsolete.
Repository: rust
Issue: Tracking Issue for `slice_split_once`
Labels: T-libs-api,C-tracking-issue

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(slice_split_once)]`

This is a tracking issue for the `slice::split_once` and `slice::rsplit_once` methods, which split a slice into two chunks on the first occurrence of a single-element delimiter. These mirror the existing stable `str::split_once` and `str::rsplit_once`. I expect these to be mostly used for ad-hoc parsing data that is not UTF-8.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::slice

impl [T] {
    pub fn split_once<F>(&self, pred: F) -> Option<(&[T], &[T])>
    where
        F: FnMut(&T) -> bool;
    pub fn rsplit_once<F>(&self, pred: F) -> Option<(&[T], &[T])>
    where
        F: FnMut(&T) -> bool;
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] ACP: https://github.com/rust-lang/libs-team/issues/102
- [x] Implementation: #112818
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

 - Should we include `split_once_mut` and `rsplit_once_mut`?

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: TypeScript
Issue: Find all references on super() only shows other calls to `super()`, not all calls to ctor
Labels: Suggestion,Help Wanted,Experience Enhancement

Repro:

1. Go to the super() call of a class that extends another multiple times
2. Peek references on super(), 🐛 it goes to definition
3. Peek references on the constructor you landed on, it correctly peeks references

![Recording 2023-06-15 at 09 07 33](https://github.com/microsoft/vscode/assets/2193314/b48c2d13-dcfd-4c60-9971-11aeb2350b76)
Repository: vscode
Issue: getOnTypeFormattingEdits not triggered on selected code
Labels: feature-request,formatting

Currently, it appears that vscode doesn't support triggering `getOnTypeFormattingEdits` on selected code(see [source code here](https://github.com/microsoft/vscode/blob/111fb77051cc9584f002907ec76139eaaf2ea41a/src/vs/editor/contrib/format/browser/formatActions.ts#L100)). This is causing some problems with pylance's auto format strings feature, which is a feature that automatically adds an `f` prefix on a string if you type `{` within it. 

Specifically, the format on type is not triggered in the case where user has a text selection in a string and type `{` to add brackets around that selection. Please refer to this issue for more details and repro steps: https://github.com/microsoft/pylance-release/issues/4489

Is there a specific consideration or reason for not supporting that? If not, will vscode consider supporting it?
Repository: go
Issue: proposal: errors: add (stack)trace at error annotation 
Labels: Proposal,error-handling

This proposal try to address the lack of traceback in errors but keep the way we handle errors as value annotated where the error occur.

Errors are values, a string or a custom error.
To retrieve the stack of errors we need to follow the chain of strings, each annotation should be written carefully to retrieve easily from where the error comes. If we just `return err` one time we loose the path.

Because of this we can embed all the stack in a custom error at the higher lever and print it at the end with the hope that we didn't loose the path with a `return fmt.Errorf("... %v")`. Like that we can just `return err` everywhere, we'll just use the full traceback to see what's happen like in most of the others languages.
Often we'll have both, a huge traceback and a chain of annotations in the end and full of `return err` everywhere. This is not fun and not idiomatic in Go.

Sometimes we just need an annotation, in a lib for example, and sometimes it's interesting to have the method and the exact line in an  application. In a web server we generaly need only the stack after the handler and before the lib but not in the server and middlewares.

My proposal is to can add easily the trace and just this trace when we annotate the error. Something like `fmt.Errorf("@trace I call foo: %v", err)`

The result is a minimal traceback like that:
https://go.dev/play/p/VJSXkbOX7J_c
```go
> main.main() prog.go:44
 f1 call f2: 
> main.f1() prog.go:13
 f2 call f3: 
> main.f2() prog.go:22
 simple error with no trace
```

I believe it follow the Go way of handling errors.
The error is still a value, a value with a trace as annotation (not to do for an API).
We decide at each error if we need the trace or not and not for the whole chain.
We encourage to annotate.
Explicit.
Easy to implement.

It's easy to experiment, just replace fmt.Errorf with a function like this:
```go
func Errorf(s string, vals ...any) error {
	pc, file, line, ok := runtime.Caller(2)
	if ok {
		info := fmt.Sprintf("\n> %s() %s:%d\n",
			runtime.FuncForPC(pc).Name(), filepath.Base(file), line)
		s = strings.Replace(s, "@trace", info, 1)
	}
	return fmt.Errorf(s, vals...)
}
```

Hope it give at least inspiration.
Repository: vscode
Issue: Enable word wrapping / auto formatting within code blocks
Labels: feature-request,editor-wrapping

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

I created this feature request in Dart-Code:

https://github.com/Dart-Code/Dart-Code/issues/4596

> It would be really great if VS Code could treat comments (either multi-line comments, or runs of line comments) as an editable text region that auto-wraps to the current format margin, just like a word processor. This would make editing comments much easier, because you wouldn't spend as much time having to manually break long lines or manually reformat comment lines below the one you made a change in.

One of the Dart-Code developers replied to say that it would not be possible for Dart-Code to implement this, because the protocol VS Code uses to talk to Dart-Code does not allow for it.

How could VS Code be changed to allow this sort of richer editing experience across all languages?
Repository: vscode
Issue: Math is not rendered inside of html in markdown notebook cells
Labels: feature-request,notebook-markdown

### Applies To

- [X] Notebooks (.ipynb files)
- [ ] Interactive Window and\/or Cell Scripts (.py files with \#%% markers)

### What happened?

![image](https://github.com/microsoft/vscode-jupyter/assets/66289396/3eb91a74-351d-442b-8df8-50e83bf6361f)


### VS Code Version

1.79.0

### Jupyter Extension Version

2022.10.110

### Jupyter logs

_No response_

### Coding Language and Runtime Version

_No response_

### Language Extension Version (if applicable)

_No response_

### Anaconda Version (if applicable)

_No response_

### Running Jupyter locally or remotely?

Local
Repository: react-native
Issue: iOS: Multiline TextInput onKeyPress event handler unexpectedly receives a Backspace event
Labels: Platform: iOS,Component: TextInput,Needs: Triage :mag:,Needs: Attention

### Description

The `TextInput` `onKeyPress` event handler receives an unexpected `Backspace` event when `multiline` is `true`. The exact behavior varies between iOS 15 and iOS 16:

* **iOS 15:** The `Backspace` event is received after `value` is reset to an empty string
* **iOS 16:** The `Backspace` event is received on EVERY change AND when `value` is reset to an empty string

This has been tested on iOS 15.5, 16.4, and 16.5.

Possibly related: https://github.com/facebook/react-native/issues/34891

### React Native Version

0.71.11

### Output of `npx react-native info`

System:
    OS: macOS 13.4
    CPU: (16) x64 Intel(R) Core(TM) i9-9900K CPU @ 3.60GHz
    Memory: 27.38 GB / 64.00 GB
    Shell: 5.9 - /usr/local/bin/zsh
  Binaries:
    Node: 18.16.0 - ~/.asdf/installs/nodejs/18.16.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 9.6.6 - ~/.asdf/plugins/nodejs/shims/npm
    Watchman: Not Found
  Managers:
    CocoaPods: 1.12.1 - /Users/jeff/.asdf/shims/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK: Not Found
  IDEs:
    Android Studio: 2022.2 AI-222.4459.24.2221.10121639
    Xcode: 14.3.1/14E300c - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.13 - /Users/jeff/.asdf/shims/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0
    react-native: 0.71.11 => 0.71.11
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

### Steps to reproduce

1. Add a `<TextInput multiline />` component and log all events received by `onKeyPress`
2. Type into the input
3. Observe that an event with `nativeEvent.key` set to `'Backspace'` is received *after* every `onKeyPress` event is received for the typed key

### Snack, code example, screenshot, or link to a repository

https://github.com/jbrowning/RN071TextInputBackspace
Repository: rust
Issue: Tracking Issue for implementation of `Extend` parameterized over "token tree items" (`Group`, `Literal`, `Punct`, `Ident`) for `TokenStream`
Labels: T-libs-api,C-tracking-issue

Feature gate: `#![feature(ts_extend_w_tt_item)]`

This is a tracking issue for implementation of [`Extend`](https://doc.rust-lang.org/std/iter/trait.Extend.html) parameterized over "token tree items" (`Group`, `Literal`, `Punct`, `Ident`) for `TokenStream` as proposed by [this](https://github.com/rust-lang/libs-team/issues/242) API Change Proposal (ACP).

In this context, "token tree item" is a stipulative definition that means any of the types that can be stored as variants inside of [`proc_macro::TokenTree`](https://doc.rust-lang.org/proc_macro/enum.TokenTree.html), namely

1. [`proc_macro::Group`](https://doc.rust-lang.org/proc_macro/struct.Group.html)
2. [`proc_macro::Ident`](https://doc.rust-lang.org/proc_macro/struct.Ident.html)
3. [`proc_macro::Punct`](https://doc.rust-lang.org/proc_macro/struct.Punct.html)
4. [`proc_macro::Literal`](https://doc.rust-lang.org/proc_macro/struct.Literal.html)

### Public API

```rust
// proc_macro

impl Extend<Group> for TokenStream {
  /*...*/
}

impl Extend<Ident> for TokenStream {
   /*...*/
}

impl Extend<Punct> for TokenStream {
   /*...*/
}

impl Extend<Literal> for TokenStream {
   /*...*/
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: godot
Issue: Discrepancy between Compatibility and Forward+ renderers when using filter_nearest in CanvasGroup shader
Labels: bug,topic:rendering,topic:2d

### Godot version

v4.1.beta2.official [a2575cba4]

### System information

Windowss 11, NVidia 3070

### Issue description

In a `CanvasGroup` shader, there is a discrepancy in the rendering between the Compatibility renderer and the Forward+ renderer. The compatibility renderer appears to use `filter_linear` despite `filter_nearest` being explicitly specified in the shader.

**Compatibility renderer:**

https://github.com/godotengine/godot/assets/4622925/8c4432bb-7451-49e1-86c4-56f7765c8d8a

**Forward+ renderer:**

https://github.com/godotengine/godot/assets/4622925/47ae222f-8c25-458c-81e7-0ac80f504ca8

Notice how the Forward+ renderer has sharp pixel edges, while the Compatibility renderer has softer edges. I believe the `CanvasGroup` shader is ignoring `filter_nearest`, because when I specify `filter_linear` instead I see the same output in both Compatibility and Forward+ renderers.

<details>
  <summary>Shader code</summary>
  
  ```gles
shader_type canvas_item;
render_mode unshaded;

uniform sampler2D screen_texture : hint_screen_texture, filter_nearest, repeat_disable;
uniform float wave_amplitude = 1.0;

void fragment(){
	vec2 wave_offset = vec2(0, sin((TIME * 2.0) + (SCREEN_UV.x) * 30.0) * SCREEN_PIXEL_SIZE.y * wave_amplitude);
	float modifier = 1.0;
	ivec2 size_texture = textureSize(screen_texture, 0);
	vec2 adjustedUv = SCREEN_UV + wave_offset;
	vec2 nearest_uv = floor(adjustedUv * vec2(float(size_texture.x), float(size_texture.y)) + vec2(0.5)) / vec2(float(size_texture.x), float(size_texture.y));

	vec4 c = textureLod(screen_texture, adjustedUv, 0.0);
	
    if (c.a > 0.0001) {
        c.rgb /= c.a;
    }

    COLOR *= c;
}
  ```
  
</details>

### Steps to reproduce

1. Create a `CanvasGroup` node
2. Add a sprite as a child. In the inspector, set texture filtering to "Nearest"
3. Apply a shader material to the `CanvasGroup` and be sure to add some animation. In the shader material, specify `filter_nearest`
4. Observe discrepancy between Compatibility and Forward+ 

### Minimal reproduction project

[RendererDiscrepancyMRP.zip](https://github.com/godotengine/godot/files/11794026/RendererDiscrepancyMRP.zip)