sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: "No valid library handle, can't terminate GDNative object" - Output Error
Labels: bug,topic:editor,confirmed,topic:gdextension

**Godot version:**
3.1


**OS/device including version:**
Latest OSX


**Issue description:**
I moved **from 3.1 beta 10 to 3.1** and I started seeing this in my output as an error everytime Godot refreshes (unfocus Godot and then focus it again).
```
 modules/gdnative/gdnative.cpp:393 - No valid library handle, can't terminate GDNative object
```

I get these errors whenever I run the debug project:
```
** Debug Process Started **
 modules/gdnative/gdnative.cpp:488 - No valid library handle, can't get symbol from GDNative object
 modules/gdnative/gdnative.cpp:393 - No valid library handle, can't terminate GDNative object
```

I've tried removing all my GDNative objects, and I still get those errors in output.

The game runs completely fine, no issues it seems, no crashes. It might be some type of overzealous error output?

Unfortunately, I haven't been able to find a minimal project to reproduce this.

Any ideas?
Repository: go
Issue: cmd/compile: bounds checking for unrolled loops is weird
Labels: Performance,NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
1.12 (but also 1.11)
</pre>

### Does this issue reproduce with the latest release?

seems to

### What operating system and processor architecture are you using (`go env`)?

amd64, but N/A-ish?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env

</pre></details>

### What did you do?

Tried to unroll a loop, then tried to reduce bounds checking. Here's the godbolt page with the assembly I was looking at.

https://godbolt.org/z/GQuZaf


### What did you expect to see?

A lot less bounds checking.

### What did you see instead?

It's obvious to me that `i := 0; i < 1024; i += 4` produces no values of i such that i+3 is is outside a :1024 slice.

However, there's an even weirder thing: If I do that loop, I get three bounds checks, one for each of the three lines that uses a value computed from i.

But if I change it to `i < 1024-3`, which does not actually change what values i can ever take, it *adds* a bounds check for the plain i+0 line! That can't possibly be right. If I know the loop's limit is definitely *smaller* than the size I've already checked the slice to have, that should allow eliminating some bounds checks. (Interestingly, if I set the limit to 1020, then all the bounds checks go away. I suppose I could just unroll the last four entries separately.)
Repository: go
Issue: cmd/compile: runtime check for availability of popcount is spammy
Labels: Performance,NeedsInvestigation,compiler/runtime

### What version of Go are you using (`go version`)?

<pre>
$ go version
1.12 (but also 1.11)
</pre>

### Does this issue reproduce with the latest release?

seems to

### What operating system and processor architecture are you using (`go env`)?

amd64

### What did you do?

Was looking at an unrolled loop.

https://godbolt.org/z/GQuZaf

### What did you expect to see?

A test for whether the target system had popcount.

### What did you see instead?

Four separate tests per unrolled loop, and the tests repeating every time through the loop.

This seems like it should be a cacheable result. It might even be worth generating two copies of the loop; the cost of all those branches is large, and doing a single branch up front would be nicer. I don't think there's any facility available to me to let me write the branch in my own code.
Repository: vue
Issue: vue-template-compiler lacks a stringify API
Labels: feature request

### What problem does this feature solve?
when i use vue-template-compiler parseComponent a vue file, and use  @babel/parser @babel/traverse @babel/generator modify some code at vueTemplateComplier AST.script content 
But can not find a api to auto generate file from  vueTemplateComplier AST it to origin file.


### What does the proposed API look like?
const fileContent = compiler.generateComponent(<vueTemplateComplier AST>, {
        pad: 'space'
});
// fileContent is same as *.vue file content

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: vscode
Issue: Ability to vary completion item insertion (based on chosen commit character?)
Labels: feature-request,suggest

`CompletionItem` allows setting a list of commit characters that can be used to select the item. However, what you can do with that in practice is limited, since the insertion will always be the same no matter which commit character was used.

It would be very powerful if the insertion could vary depending on which commit character was selected (`insertText`, `additionalTextEdits`).

Here's an example of one of the use cases we wanted to support in the Haxe extension:

- When inserting an unimported type, we have two options: generate an import via `additionalTextEdits`, or insert the fully qualified path instead. You don't always want the same behavior here, so it would be neat if you could for instance:
    - use <kbd>Enter</kbd> to generate the import and insert the unqualified name
    - use <kbd>Tab</kbd> to insert the fully qualified name
- Right now, there's two workarounds:
    - Duplicate each completion item, so you have one for auto-importing and one for inserting fully quallified names. However, this would make for a very messy completion list, so we don't do this in the Haxe extension.
   - Have a setting that controls which behavior should be used. We _do_ have this in the Haxe extension, but as mentioned before, sometimes you want to decide which one to use "in the moment", without having to mess with settings.

There's precedent for this sort of behavior in other IDEs. For instance in IntelliJ (Java), you can use <kbd>Alt</kbd>+<kbd>Enter</kbd> to open a code action menu _on completion items_. There you can for instance choose to import a method statically:

![](https://i.imgur.com/Udt5Ofp.png)

Perhaps allowing "code actions" on completion items like that is better than basing it purely on which commit character was used, as it's much more explicit.

Thoughts?
Repository: pytorch
Issue: Context Manager that disables training mode with in a nn.Module.
Labels: feature,module: nn,triaged

## 🚀 Context Manager that disables training mode with in a nn.Module.
When running inference on validation datasets, you need to put some modules in evaluation mode and its desirable to stop gradient calculation. Currently `with torch.no_grad():` can be used to disable gradient calculation temporarily while batchnorm and drop out layers have to be set to evaluation mode using `model.train(True)` followed by a `model.train(False)` once evaluation is complete. Currently this syntax is used, 

```python
model.train(False)
with torch.no_grad():
  outputs = model(inputs)
  model.train(True)
  return outputs
```
. This is a potential source of bugs, as people will sometimes instead use `model.eval()` and forget to set the model back to training mode at the end of inference. Suggest having the following syntax, 

```python
with torch.no_train(model):
  with torch.no_grad():
    outputs = model(inputs):
    return outputs
```
. This syntax would stop this type of bug from occurring.
Repository: pytorch
Issue: Add support for tuple type deduction in C++ custom operators
Labels: module: internals,module: bootcamp,triaged,enhancement

## 🚀 Feature
Right now RegisterOperators support deduction of schema and "auto converting" values for multiple types, including lists and dicts. We should support tuples (as mapped to std::tuple in C++) too.

## Pitch

All reasonable torchscript types should be easily mappable to C++ operators. following code should work:

```
    RegisterOperators reg({createOperator(
        "foo::tuple((int, float, Tensor) arg) -> float",
        [](const std::tuple<int, double, at::Tensor>& arg) { return std::get<1>(); })});
```

## Additional context

Places to change:
https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/core/ivalue.h#L803 (generic_to)
https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/core/jit_type.h#L1026 (getTypePtr_)

Some metaprogramming would be required

@smessmer might be interested or up for grabs
Repository: flutter
Issue: Investigate `onPerformClick` and `onTouchEvent` in both `FlutterView`s
Labels: platform-android,engine,a: accessibility,P2,team-android,triaged-android

The engine Android linter is complaining that we have implemented `onTouchEvent()` but not `performClick()`.  This relationship needs to be investigated and we either need to implement what is expected, or update the linter rules to avoid blocking PRs on this check.

https://developer.android.com/reference/android/view/View#onTouchEvent(android.view.MotionEvent)

https://developer.android.com/reference/android/view/View.html#performClick()

CC @gspencergoog
Repository: TypeScript
Issue: Feature Request: allow exclusion of node_modules when skipLibCheck is false
Labels: Suggestion,In Discussion

## Search Terms

`skipLibCheck node_modules`, `skipLibCheck`

All I've found is this lonely [SO post](https://stackoverflow.com/questions/49985943/skip-library-check-only-in-node-modules). As that user notes, there are a lot of posts around Angular and excluding node_modules from typechecking on one dimension or another, but they all end up suggesting turning _on_ `skipLibCheck`.

## Suggestion

Allow the exclusion of files in node_modules (regardless of their inclusion in the Project) from lib checking when `skipLibCheck` is set to `false`.

## Use Cases

I want to be able to typecheck _my own_ `.d.ts` files without being responsible for all of the types my dependencies import. My local configuration is `strict` and it may be that the types provided in my packages were not intended `strict`ly, or other configurations in my local JSON run up against the way other packages have written theirs.

I am assuming the counterargument is that it's all-or-nothing, but then why do `.ts` files that _rely on_ `.d.ts` files typecheck fine when my `.d.ts` files are not typechecked? Can't that behavior be applied to definitions in node_modules?

## Examples

Not sure how to show an example here. I would like to be able to run `tsc --noEmit` on my codebase and get errors for my own definitions files without having a bunch of noise from unfixable errors in `node_modules/@types` etc.

## Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code  
  _If implemented as some additional flag?_
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).  
  I think so?
Repository: godot
Issue: AnimationPlayer: Timeline cursor should jump to wherever I leftclick in the track
Labels: enhancement,topic:editor,usability

**Godot version:**
3.1


**Issue description:**
The AnimationPlayer currently only updates the 2D view when the user clicks on the timeline and therefore moves timeline cursor/timestamp (https://github.com/godotengine/godot/issues/27277)
If the user wants to insert a keyframe, they should be able to do so not by first clicking on the timeline, but directly on the location within the track where they want to insert or paste (https://github.com/godotengine/godot/issues/27280#) a keyframe. For my understanding for this to work, the timeline cursor/timestamp should jump to wherever the user leftclicks in the track. This would also allow the user to immediately see the state of the animation the user wants to change at this location. Right now, if they want to see what state the animation is at a given location on a track, the user always has to go up to the timeline and find the time, then go back down to the track. This is especially tedious the more tracks the animation has.
Repository: react
Issue: dangerouslySetInnerHTML is left empty on client render on top of bad server markup when rendering HTML
Labels: Type: Bug,Type: Needs Investigation

This seems to be an edge case of https://github.com/facebook/react/issues/11789 fixed in https://github.com/facebook/react/pull/13353/files.

I ran into this when trying to hydrate content rendered with https://github.com/prismicio/prismic-dom `asHtml` method.

**Do you want to request a *feature* or report a *bug*?**

Bug? I think. 

**What is the current behavior?**

Current behavior:

1. Server-side stuff comes in from server and contains the things we need
2. Hydration mismatch happens
3. dangerouslySetInnerHTML is called with correct value but an empty string gets rendered instead

I tried to replicate the issue on https://codesandbox.io/s/2xojk10jln but failed.

The following testcase for `packages/react-dom/src/__tests__/ReactDOMServerIntegrationElements-test.js` produces the same result (I tried it first with the same PrismicDOM.RichText.asHtml(obj) call I have in the app) but I am not sure if it's correct:

  ```js

# test case
    itRenders(
      'a div with dangerouslySetInnerHTML set to html inserted',
      async render => {
        const obj = '<li>bar</li>';
        const e = await render(
          <div dangerouslySetInnerHTML={{__html: obj }} />,
        );
        expect(e.childNodes.length).toBe(1);
        expect(e.firstChild.tagName).toBe('LI');
        expect(e.firstChild.childNodes.length).toBe(1);
      },
    );
```

```bash
      ✓ renders a div with dangerouslySetInnerHTML set to html return value of function called with server string render (190ms)
      ✓ renders a div with dangerouslySetInnerHTML set to html return value of function called with server stream render (52ms)
      ✓ renders a div with dangerouslySetInnerHTML set to html return value of function called with clean client render (37ms)
      ✓ renders a div with dangerouslySetInnerHTML set to html return value of function called with client render on top of good server markup (74ms)
      ✕ renders a div with dangerouslySetInnerHTML set to html return value of function called with client render on top of bad server markup (34ms)

  ● ReactDOMServerIntegration › ... › renders a div with dangerouslySetInnerHTML set to html return value of function called with client render on top of bad server markup

    expect(received).toBe(expected) // Object.is equality

    Expected: "bar"
    Received: ""
```


**What is the expected behavior?**

The client render would have rendered `<li>bar</li>`

**Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?**

commit c05b4b8  (latest master) and >16.8.

Sorry for a bit vague bug report.
Repository: rust
Issue: Suggest & when a lifetime precedes a type.
Labels: A-parser,T-compiler,A-suggestion-diagnostics

If one types
```rust
fn foo(bar: 'static SomeStruct) { ... }
```
the compiler could suggest adding a `&` before the lifetime. This can be more useful in a generic parameter, where a high concentration of special characters makes it easy to not notice the mistake:
```rust
fn foo(bar: &mut HashSet<'static SomeStruct>) { ... }
```

Currently, the error message is just ``expected one of `,` or `>`, found `SomeStruct` ``.
Repository: go
Issue: net/http/httputil: support RFC 7239 Forwarded header in ReverseProxy
Labels: NeedsDecision,FeatureRequest

Revival of #20526 which was frozen due to age

I've been using services that make use of Go's Reverse Proxy, and think there's some substantial improvements in the Forwarded header that were overlooked in the original discussion.

Forwarded includes not just previous client IP, it also has the host and protocol, information that is currently haphazardly implemented in a few other non-standard X headers `X-Forwarded-Proto` and `X-Forwarded-Host` _most_ of the time. There's also `X-Real-IP` competing with `X-Forwarded-For`, and while much less adopted, is used.

The protocol and host info also tends to not get nicely appended in the other headers as comma separated lists, and instead just clobbered by the most recent. If you're more than one proxy down, the chances of recovering that info is slim to nil, where as Forwarded would be a combined mechanism to ensure its survival.

Forwarded also specifies the format to put IPv6 addresses in, where as this is also somewhat mixed in implementation of `X-Forwarded-For` and requires a bunch of edge-case decoding.

Considering the RFC provides [migration guidelines](https://tools.ietf.org/html/rfc7239#section-7.4) on how to build a Forwarded header in the presence of an `X-Forwarded-For` header, I see no reason we couldn't supply both and help push adoption.

I've got code and tests for such a feature [on a branch](https://github.com/golang/go/compare/master...AndrewBurian:rfc7239-forwarded), and would be more than happy to open a PR if there's interest.
Repository: rust
Issue: Type mismatching cased by duplicate associated type resolution
Labels: A-type-system,A-diagnostics,T-compiler,C-bug,D-incorrect,T-types

Apologize that I could not give any code example right now. I'm working on creating one but it seems tricky. 

The compiler is complaining about `[E0308]: mismatched types` where it said it's expecting for a trait `SomeTrait<Apple=SomeApple, Apple=SomeApple, Banana=SomeBanana, Banana=SomeBanana>` but got `SomeTrait<Apple=SomeAPple, Banana=SomeBanana>`. Only some of the associated types in that trait are repeated once and there are few others are not repeated.

The example I gave in #59324 is an intermediate result of my attempt to create a minimal reproducible code to this issue. The type mismatch happened at the `with_factory` method when resolving concrete type for `ThriftService`.

The error happened when I'm doing the update from 1.32.0 to 1.33.0 so it's clearly a regression. 

Also, please let me know if you have any suggestion on bypassing this problem or tips on re-creating the problematic code.

Thanks.
Repository: flutter
Issue: Android: Only include the repos in places where we need them
Labels: c: new feature,platform-android,tool,t: gradle,P3,team-android,triaged-android

By default, Flutter generates the Android gradle scripts that most Flutter apps/plugins use. For the Flutter app generation, the gradle scripts put the follow at the top level gradle script:

```
allprojects {	
    repositories {	
        google()	
        jcenter()	
    }	
}
```
This is great practice for a top level gradle script that is managing many modules, but it’s a not so good practice for an one module app. The one module app should place this at the lower level app level gradle script. For the official Flutter script, having gold standard practices would prevent propagating this misunderstanding.

For the Flutter plugin generation, we have the following:
```
rootProject.allprojects {
    repositories {
        google()
        jcenter()
    }
}
```
It's forcing all apps that use this plugin to use those repositories and the plugin could only be used for that plugin. We should only be setting the repository only where it is needed.

References:
https://docs.gradle.org/current/userguide/multi_project_builds.html 
https://guides.gradle.org/creating-multi-project-builds/#configure_from_above
Repository: rust
Issue: Wrong unused warning for type alias
Labels: A-lints,T-compiler,C-bug

This code:
```
struct Runner;

type RuntimeImpl = Runner;

trait Runtime {
    fn run(&mut self);
}

impl Runtime for &mut RuntimeImpl {
    fn run(&mut self) { }    
}

fn main() {
    let mut runner = Runner;
    (&mut runner).run();
}
```

takes the warning:
```
   Compiling playground v0.0.1 (/playground)
warning: type alias is never used: `RuntimeImpl`
 --> src/main.rs:3:1
  |
3 | type RuntimeImpl = Runner;
  | ^^^^^^^^^^^^^^^^^^^^^^^^^^
  |
  = note: #[warn(dead_code)] on by default
```

But removing this alias introduces a compilation error :thinking: 

The link to the nightly playground example: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=22a044608f4d67680bcf1cc7fd23a381
Repository: flutter
Issue: Support embedding non-virtual a11y hierarchies for platform views on Android
Labels: platform-android,framework,a: accessibility,a: platform-views,c: proposal,P2,platform-views: vd,team-android,triaged-android

Currently we only support embedding virtual a11y trees, this works for things like WebView.
But we should also look into supporting non virtual a11y trees.
Repository: rust
Issue: closures with async blocks have concrete argument lifetimes
Labels: T-compiler,C-bug,A-async-await,AsyncAwait-Triaged

```rust
#![feature(async_await, futures_api)]

use std::future::Future;

trait Foo<'a> {
    type Future: Future<Output = u8> + 'a;

    fn start(self, f: &'a u8) -> Self::Future;
}

impl<'a, Fn, Fut> Foo<'a> for Fn
where
    Fn: FnOnce(&'a u8) -> Fut,
    Fut: Future<Output = u8> + 'a,
{
    type Future = Fut;

    fn start(self, f: &'a u8) -> Self::Future { (self)(f) }
}

fn foo<F>(f: F) where F: for<'a> Foo<'a> {
    let bar = 5;
    f.start(&bar);
}

fn main() {
    foo(async move | f: &u8 | { *f });

    foo({ async fn baz(f: &u8) -> u8 { *f } baz });
}
```

~~([playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=8ed7f0ec4b60119dceb5d7c860296e08)) currently errors with~~

([updated playground (with 2021 ed)](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=0cbbfb5886e0d0150c794f22addde627)) currently errors with:
```
error: implementation of `Foo` is not general enough
  --> src/main.rs:27:5
   |
27 |     foo(async move | f: &u8 | { *f });
   |     ^^^
   |
   = note: Due to a where-clause on `foo`,
   = note: `Foo<'1>` would have to be implemented for the type `[closure@src/main.rs:27:9: 27:37]`, for any lifetime `'1`
   = note: but `Foo<'_>` is actually implemented for the type `[closure@src/main.rs:27:9: 27:37]`, for some specific lifetime `'2`
```

You can see that the `async fn` correctly satisfies the HRLB required by `foo`, but the async closure has a concrete lifetime for the argument instead of being for any lifetime.