sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: x/build/cmd/coordinator: add health item for work queue size and errors in finding work
Labels: Builders,NeedsInvestigation,FeatureRequest

When issue #43312 was reported, https://farmer.golang.org/#health displayed all green health items. Looking into coordinator logs showed that the findTryBotLoop was having very frequent errors. We expect no errors to happen under normal operation.

It would be helpful to add health items to https://farmer.golang.org/#health that make it more visible when there are recent errors in finding work (both TryBot work, and post-submit work; they're different queues).

CC @golang/release.
Repository: TypeScript
Issue: Syntax error in emitted declaration's generic arguments
Labels: Bug,Domain: Declaration Emit,Fix Available,Rescheduled

# Bug Report

### 🔎 Search Terms

syntax error declaration emit generics "Cannot find name" ts2304

### 🕗 Version & Regression Information

- This is syntactically incorrect output from tsc
- It is not a regression
- This is the behavior in every version I tried (3.3 - 4.2.0-dev.20201222)

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/dev/bug-workbench/?ts=4.2.0-dev.20201222#code/PTAEAEBMFMGMBsCGAnRAXAlgewHYCgQJF54sB3AKQGcAuUAM2KujwLHHo3mh0QFtodPogw4AdGip40ATwAO0UAHVUcgDwBBAHygAvKADeeUCdA5oVNHQ14AvgG48otNGSNYigArJoANx5oAJI48KKiAObBACJwSKiYuACifBhohnZ40AAecljIabIKoJ4ArgBGobAqiOoAGgA0oACaeoa2OvrV6k06AGTFPv44QSFhOJE4MQgo6Ng4yamO2bn5DCU4sAk4DDhqACo6ABQo4XR7AJSgdKUVGFWq+zpGpqA+aCXI2wZmFlagJ6BbBlYLhLD9LNBIK16DhDt96FgsHQAIy2c72UyEADKMmGiCyoESyGQeVAolAMGm8TmoGgKTSAAtXCxlnk0jBGCV4GlzBDII4gA)

**Important:** The playground itself has a rendering bug in the display of the declaration.  It still looks invalid.  But it's invalid in another way in the truthful output.  I paste the truthful output below.

### 💻 Code

```ts
// @declaration
type Wrap<A> = {
    nest: A
};
interface PreventInliningInDeclarationEmit {
}
export type PublicWrap<X, Y = {}> = Wrap<Y> & PreventInliningInDeclarationEmit;
export function fn<T> (arg: T) : PublicWrap<T> {
    return { nest: arg }
}
const nested = fn({ foo: 1});   // Syntax Error in declaration emit here
export default nested;
```

### 🙁 Actual behavior

Emitted declaration has syntax error.  `Cannot find name 'T'. (ts2304)`

```ts
declare type Wrap<A> = {
    nest: A;
};
interface PreventInliningInDeclarationEmit {
}
export declare type PublicWrap<X, Y = {}> = Wrap<Y> & PreventInliningInDeclarationEmit;
export declare function fn<T>(arg: T): PublicWrap<T>;
declare const nested: PublicWrap<T, {}>;
export default nested;
```

### 🙂 Expected behavior

A valid declaration.

```ts
declare type Wrap<A> = {
    nest: A;
};
interface PreventInliningInDeclarationEmit {
}
export declare type PublicWrap<X, Y = {}> = Wrap<Y> & PreventInliningInDeclarationEmit;
export declare function fn<T>(arg: T): PublicWrap<T>;
declare const nested: PublicWrap<{
    foo: number;
}>;
export default nested;
```
Repository: TypeScript
Issue: Type of reverse enum lookup is string | undefined with noUncheckedIndexedAccess enabled
Labels: Suggestion,In Discussion

# Bug Report

### 🔎 Search Terms

* enum
* noUncheckedIndexedAccess
* undefined

### 🕗 Version & Regression Information

This is a new feature in Typescript 4.1.

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?noUncheckedIndexedAccess=true#code/KYOwrgtgBAYg9nKBvAUFKBBANFNUBCWeAwkQL4ooA2wALlAB4BcUAzrQE4CWIA5lAF5YCANrw4AOgwBdANyUAxnBCs4NCVTi8AFAwCUsoA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
enum Foo {
  A, 
  B,
  C,
}

let x: string = Foo[Foo.A];
```

### 🙁 Actual behavior

With `noUncheckedIndexedAccess` it gives an error because the type of `Foo[Foo.A]` is determined to be `string | undefined`.

### 🙂 Expected behavior

I can't see any reason why the type shouldn't be `string` even with `noUncheckedIndexedAccess` enabled.
Repository: pytorch
Issue: c10::scalar_to_tensor(...) uses should be audited for performance and type promotion impact
Labels: high priority,module: performance,module: cuda,triaged

See, for example: 

https://github.com/pytorch/pytorch/blob/272f4db043ec2c63ecfe6d2759e7893cb842a3c3/aten/src/ATen/native/Pow.cpp#L53

There are several other cases, too, and the pattern is, in general, an antipattern. This may affect type promotion and (see below) impacts performance.

cc @ezyang @gchanan @zou3519 @bdhirsh @jbschlosser @ngimel @VitalyFedyunin
Repository: TypeScript
Issue: Language server: Recursively auto-complete default object instance.
Labels: Suggestion,Awaiting More Feedback

# Suggestion


## 🔍 Search Terms

- auto complete typescript object recursively 
- typescript language server options
- typescript set default nested object


## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code

* [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, new syntax sugar for JS, etc.)

## ⭐ Suggestion

Is it possible to add an auto complete feature to the language server that allows starting with this code:

```typescript
const o: Animal = {
// Place cursor here
}
```

And then offering to set all keys recursively to a default value:
```typescript
const o: Animal = {
    name: "",
    age: 0,
    children: [],
    mostFamousCousin: {
        name: "",
        age: 0,
        children: []
    }
}
```
I'm using Webstorm, which has this feature for other typed languages.

This comes in useful when you are entering data directly into large nested data types.

Thanks.



## 📃 Motivating Example

- "Save yourself hours of work filling in each field of an object by auto completing the whole tree".

## 💻 Use Cases

- When creating a large nested object it would be much faster to create the whole tree of objects.
- For branching at enum points (one of many possible types) or recursive definitions, the auto complete code should end the recursion as early as possible, in which case the user can create the root object and type of their desired type for that branch and repeat the auto complete process.

## Related

- https://youtrack.jetbrains.com/issue/WEB-39222
	- IntelliJ's "Implement members" feature already completes all keys, but it has some issues with nested object literals, and when all keys are optional.
	- This feature proposes integrating the same "implement members" feature of IntelliJ into the TS lang server so it works in all editors flawlessly.
Repository: rust
Issue: Function pointer does not fulfill the required lifetime
Labels: A-lifetimes,C-bug,T-types

Function pointers have no lifetime of their own, and essentially are `'static` ([Unsafe Code Guidelines Reference](https://rust-lang.github.io/unsafe-code-guidelines/layout/function-pointers.html)), so I would expect `fn(T) -> U: 'a` to hold for any lifetime `'a` and types `T, U`. A function pointer that lived longer than its argument type would be fine, since it won't be possible to make an instance of the argument type after it's expired, and so you cannot call it then. Similarly, there's nothing wrong with a function pointer that lives longer than its return type, as outside the return type's lifetime you either won't be able to call it or it will never return.

Yet the following example fails to compile.

```rust
pub fn foo<'a, T: 'a>() {}

pub fn bar<'a, 'b>() {
    foo::<'a, fn(&'b u32)>(); // Errors
}
```
[Playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=853723e8cfef529c965b72c3d91a14f2)

```
error[E0477]: the type `fn(&'b u32)` does not fulfill the required lifetime
 --> src/lib.rs:5:5
  |
5 |     foo::<'a, fn(&'b u32)>(|_x: &'b u32| {}); // Errors
  |     ^^^^^^^^^^^^^^^^^^^^^^
  |
note: type must outlive the lifetime `'a` as defined on the function body at 3:12
 --> src/lib.rs:3:12
  |
3 | pub fn bar<'a, 'b>() {
  |            ^^
```
The compiler seems to think that a function pointer is only valid for as long as the types it uses are, rather than for the duration of the program.

I have also run into a similar issue when using `Box<dyn Fn(&'b u32)>` (and also `Box<dyn Fn(&'b u32) + 'a>`) instead of `fn(&'b u32)`, but I thought that the function pointer case would be the clearest.
Repository: PowerToys
Issue: [Image Resizer] Unneeded resize on startup
Labels: Area-Quality,Product-Image Resizer,Planning-Consideration

PowerToys version: 0.27.0
PowerToy Utility: Image Resiszer

Image resizer used to be a snappy little utility now it takes a few seconds to pop on the screen. Would really like it's launch speed as it was before... before the "new and improved" interface overhaul.
Repository: rust
Issue: LLVM ERROR: Function addresses with offsets not supported
Labels: A-LLVM,T-compiler,O-wasm,C-bug

I've ran into an issue with one of my libraries that was preventing it from compiling with `wasm-pack`.  It would otherwise compile just fine with `rustc` to other targets (no compiler errors) but when I would attempt to compile with `wasm-pack` I would get this cryptic error:

```
LLVM ERROR: Function addresses with offsets not supported
error: could not compile `hello-wasm`.
```

No line numbers, no error trace, just that.

After spending quite a while to find the offending block of code, I've discovered that the issue was caused by misusing the type system a bit.

Here's the offending code:

```rust
use wasm_bindgen::prelude::*;
use std::vec::Vec;

#[wasm_bindgen]
pub fn err() -> i32 {
    let vector: Vec<u8> = Vec::new();
    // In my library, I meant to use `core::u16::MAX` and did this instead
    let my_size = (u16::max as usize) - 1; // <- casting function as usize
    // `u16::max` is actually a function to compare two numbers and get the maximum between them
    if my_size > vector.len() {
        20
    } else {
        50
    }
}

```

I expected to see this happen: I think this is actually a type error.  `u16::max` is a function and I'm casting it to a `usize`.  I would hope the Rust compiler would yell at me for that or at least require me to write `unsafe` before I can cast a function to a `usize`.

Instead, this happened: The program compiles and runs just fine unless you attempt to compile it to wasm with `wasm-pack build`.  If you run the function in a test, it spits out `20`.

`rustc --version --verbose`:
```
rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-apple-darwin
release: 1.47.0
LLVM version: 11.0
```

`wasm-pack -V`: 
```
wasm-pack 0.9.1
```

Hoping to save someone else a few days of hair pulling!

Edit: A little bit more testing, it looks like the program compiles just fine if you change the line to this:
```rust
// let my_size = (u16::max as usize) - 1;
let my_size = (u16::max as usize)
```

So it seems like combining the cast with an operation causes the issue.  Interestingly, not all operations cause the error.

```rust
// Doesn't compile with `wasm-pack`
let my_size = (u16::max as usize) + 1;
let my_size = (u16::max as usize) - 1;
let my_size = (u16::max as usize) + 2;
let my_size = (u16::max as usize) - 2;

// Compiles Fine with `wasm-pack`:
let my_size = (u16::max as usize) * 1;
let my_size = (u16::max as usize) / 1;
let my_size = (u16::max as usize) * 2;
let my_size = (u16::max as usize) / 2;
```
Repository: pytorch
Issue: Compatibility with Raspberry Pi
Labels: module: build,feature,triaged

## 🚀 Feature
It would be great if we could just download and install Torch using pip install torch or pip install torch-gpu.


## Motivation

New models of Yolo are only written in PyTorch, which is great, I much prefer it to Tensorflow, but I would like to be able to use these fast new object detection models on my Raspberry Pi, like I can with older Yolo models.  As more efficient models are produced in PyTorch, it might be a good idea to make Torch more compatible with Raspberry Pi just to show off new Pytorch models' efficiency and accuracy on low-power devices.

## Pitch

I want Torch to be easily installed and used on the Raspberry Pi, particularly the Pi 4B.

## Alternatives

Tensorflow is awful, but it works on the Pi, so I have had to use it and downgrade to Yolov3.  Yolov5 is out but it is written in PyTorch, which is not compatible with the Pi.  I would like to use the latest software on my pi.  The latest software is written in PyTorch because it is amazing, but PyTorch is not compatible with the Pi at this time.

## Additional context
Please make it easily installable and usable.  pip3 install torch would be great.

cc @malfet @seemethere @walterddr
Repository: rust
Issue: Using doc comment at end of line triggers inner attribute error
Labels: A-attributes,A-parser,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 main() {
    if true {//!= bar
    println!("test");
    }
}
```

I expected to see this happen: the code should compile

Instead, this happened: the code does not compile with an error.

```rust
error: an inner attribute is not permitted in this context
 --> src/main.rs:2:14
  |
2 |     if true {//!= bar
  |              ^^^^^^^^
  |
  = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files. Outer attributes, like `#[test]`, annotate the item following them.
```

This behavior surprised me since I tripped this compiler error after I commented out the right-hand side of a condition expression. IMO the error should either be clear that this is being parsed *as a doc comment* or should interpret this as a comment when not at the start of the line.

### 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.49.0-nightly (8dae8cdcc 2020-10-12)
binary: rustc
commit-hash: 8dae8cdcc8fa879cea6a4bbbfa5b32e97be4c306
commit-date: 2020-10-12
host: x86_64-apple-darwin
release: 1.49.0-nightly
LLVM version: 11.0
```

This bug affects the latest stable as well.
Repository: create-react-app
Issue: Current npm. issues.
Labels: needs triage

If you have a general question about Create React App or about building an app with Create React App we encourage you to post in GitHub Discussions instead of this issue tracker. The maintainers and other community members can provide help and answer your questions there: https://github.com/facebook/create-react-app/discussions

If you're looking for general information on using React, the React docs have a list of resources: https://reactjs.org/community/support.html

If you've discovered a bug or would like to propose a change please use one of the other issue templates.

Thanks!
Repository: godot
Issue: Threaded loading crashes/general issues in 3.2 (and possibly 4.0)
Labels: bug,topic:core,crash

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:** 68013d23932688e57b489600f4517dd280edc464


**OS/device including version:**
Windows, Linux, GLES3, nvidia and AMD GPUs


**Issue description:**
Threaded loading in general seems unstable, particularly when loading images and scenes.

The problems seem to be:

- Memory corruption as reported by @Xananax (although I haven't been able to reproduce it), he stated that separation of memory between threads doesn't seem to work properly even when mutexes are used.
- Crashes/hangs.
- Textures not loading properly.

On an important note, I vividly remember doing threading in Godot 3.0 without problems, so I suspect the issue was introduced after that.

**Steps to reproduce:**
Develop a program that uses multi threading to load the aforementioned resources in threads.

**Minimal reproduction project:**
I've been unable to reproduce crashes (yet) but linked is a project that shows some issues on my machine, mainly it appears like it's only able to load some of the scenes, scenes 1 2 3 and 4 are identical.

![imagen](https://user-images.githubusercontent.com/3101690/102969532-264a9e00-44f6-11eb-8e88-04bf23c05972.png)

4 is loaded properly I assume because it's the last one.

2 also loads properly because the load has been increased by including a few audio stream players with an audio stream, so maybe there's some timing issue there.

Using multi threaded rendering mode seems to fix this issue in particular, but in my experience the crashes remain.

I suspect this might be related to allocating textures outside the main thread, as in my experience loading images as Image resources and only putting them in ImageTextures once they are in the main thread seems to solve the issue (additionally, I did some printf debugging that seems to confirm it's possible for textures to reach the main thread without being allocated, even when using VisualServer.force_sync).

This is all I've got for now, I'm still attempting to reproduce the crashes in a project, but it may be that they only happen with an increased load, so I've laid out the most probable explanations I can think of.

This is by the way entirely unrelated to the new 4.0 APIs that allow threaded loading of resources to be managed by the engine which I suspect suffer from the same problems, but I haven't tested this in 4.0.

[ThreadedLoadingExample.zip](https://github.com/godotengine/godot/files/5733782/ThreadedLoadingExample.zip)
Repository: pytorch
Issue: Caching for autoregressive decoding of Transformer
Labels: module: performance,feature,module: nn,triaged

## 🚀 Feature
<!-- A clear and concise description of the feature proposal -->
[This blog post](https://tunz.kr/post/4) says that we can reduce the computation time of autoregressive decoding by using caching, since we do not have to re-compute the previous attentions. It seems that [OpenNMT](https://github.com/OpenNMT/OpenNMT-py/issues/1551) uses such caching, but I can't find such usage of caching in `nn.Transformer`. I wonder if such feature will be implemented and released in future.

## Motivation

<!-- Please outline the motivation for the proposal. Is your feature request related to a problem? e.g., I'm always frustrated when [...]. If this is related to another GitHub issue, please link here too -->
Faster decoding.

## Pitch

<!-- A clear and concise description of what you want to happen. -->
Simple module for masked attention (with upper triangular mask) that enables caching for autoregressive decoding.

## Alternatives

<!-- A clear and concise description of any alternative solutions or features you've considered, if any. -->

## Additional context

<!-- Add any other context or screenshots about the feature request here. -->



cc @albanD @mruberry @jbschlosser @VitalyFedyunin @ngimel @zhangguanheng66
Repository: terminal
Issue: [Feature request] [Settings UI] Import a color scheme from a json file
Labels: Issue-Feature,Help Wanted,Product-Terminal,Area-SettingsUI

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

# Description of the new feature/enhancement


I was trying the new settings UI and I found that adding a new color scheme is actually harder than using the json editor. When using the json editor I can directly copy the colors. But with settings UI I cannot do that anymore, which frustrates me a bit. I'd like to propose the feature to import a json file as color scheme. This way all those color schemes in https://github.com/mbadolato/iTerm2-Color-Schemes/tree/master/windowsterminal can be used easily.

This is inspired by iTerm2 on macOS.

<!-- 
A clear and concise description of what the problem is that the new feature would solve.
Describe why and how a user would use this new functionality (if applicable).
-->

# Proposed technical implementation details (optional)

Ideally it should be just adding a button, parse the json & save.
<!-- 
A clear and concise description of what you want to happen.
-->