sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Argument types of functions with multiple declarations should be smarter.
Labels: Suggestion,Awaiting More Feedback,Domain: Control Flow

<!-- 🚨 STOP 🚨 𝗦𝗧𝗢𝗣 🚨 𝑺𝑻𝑶𝑷 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Please read the FAQ first, especially the "Common Feature Requests" section.

-->

## Search Terms

<!-- List of keywords you searched for before creating this issue. Write them down here so that others can find this suggestion more easily -->

## Suggestion
Argument types of functions with multiple declarations should be smarter.
<!-- A summary of what you'd like to see added or changed -->

## Use Cases
As showed in example,b should be a number when we are sure that a is "b".But it still think b as a number|string.
<!--
What do you want to use this for?
What shortcomings exist with current approaches?
-->

## Examples
http://www.typescriptlang.org/play/index.html#src=class%20test%7B%0D%0A%20%20%20%20public%20test(a%3A%20%22a%22)%3B%0D%0A%20%20%20%20public%20test(a%3A%20%22b%22%2C%20b%3A%20number)%3B%0D%0A%20%20%20%20public%20test(a%3A%20%22c%22%2C%20b%3A%20string)%3B%0D%0A%20%20%20%20public%20test(a%3A%20%22a%22%20%7C%20%22b%22%20%7C%20%22c%22%2C%20b%3F%3A%20number%20%7C%20string)%20%7B%0D%0A%20%20%20%20%20%20%20%20if%20(a%20%3D%3D%20%22a%22)%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20a%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20b%0D%0A%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%20%20%20%20else%20if%20(a%20%3D%3D%20%22b%22)%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20a%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20b%0D%0A%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%20%20%20%20else%20if%20(a%20%3D%3D%20%22c%22)%20%0D%0A%20%20%20%20%20%20%20%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20a%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20b%0D%0A%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%20%20%20%20else%20%7B%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20a%0D%0A%20%20%20%20%20%20%20%20%20%20%20%20b%0D%0A%20%20%20%20%20%20%20%20%7D%0D%0A%20%20%20%20%7D%0D%0A%20%20%20%20public%20testf()%20%7B%0D%0A%20%20%20%20%20%20%20%20this.test(%22a%22)%3B%0D%0A%20%20%20%20%20%20%20%20this.test(%22b%22%2C%201)%3B%0D%0A%20%20%20%20%20%20%20%20this.test(%22c%22%2C%20%221%22)%3B%0D%0A%20%20%20%20%7D%0D%0A%7D
<!-- Show how this would be used and what the behavior would be -->

## Checklist

My suggestion meets these guidelines:

* [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [ ] This wouldn't change the runtime behavior of existing JavaScript code
* [ ] This could be implemented without emitting different JS based on the types of the expressions
* [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
* [ ] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: godot
Issue: Sphere shape should have 1 handle more
Labels: enhancement,topic:editor

**Godot version:**
3.1beta1

**Issue description:**
Sphere shapes are not resizable from the side: if you look at a sphere shape from the side the handle is "in the middle" of the sphere, making it completely useless.

**Proposal**
Add a second handle for when looking the sphere from the side. 2 handles are sufficient
Repository: rust
Issue: Iterating with step_by(1) is much slower than without
Labels: I-slow,E-needs-test

Greetings!

I'd like to report that I get some significant (negative) performance impact when calling `step_by(1)` on an iterator. I created a repository with a detailed description of the issue and benchmarks to reproduce it: https://github.com/mvlabat/step_by_one

These are the functions I tested:
```rust
pub fn iter_default_step(mut arr: Vec<i32>) -> Vec<i32> {
    for e in arr.iter_mut() {
        *e = e.wrapping_add(3);
    }
    arr
}

pub fn iter_step(mut arr: Vec<i32>, iter_step: usize) -> Vec<i32> {
    for e in arr.iter_mut().step_by(iter_step) {
        *e = e.wrapping_add(3);
    }
    arr
}
```

Calling `iter_step(vec![1; LARGE_ENOUGH], 1)` computes 1.75x slower than `iter_default_step(vec![1; LARGE_ENOUGH])`
with `const LARGE_ENOUGH: usize = 10_000_000;`.

I'm running Macbook Pro 2015 with Intel i5-5257U CPU (2.70GHz).

My rustc version: `1.33.0-nightly (c2d381d39 2019-01-10)`.

These are the exact benchmark results I got:
```
running 4 tests
test tests::bench_iter_default_step ... bench:   8,702,963 ns/iter (+/- 1,648,782)
test tests::bench_iter_step_1       ... bench:  15,267,083 ns/iter (+/- 1,236,220)
test tests::bench_iter_step_16      ... bench:   9,053,772 ns/iter (+/- 380,422)
test tests::bench_iter_step_64      ... bench:   8,711,169 ns/iter (+/- 327,562)
```

In the [repository README](https://github.com/mvlabat/step_by_one) there are also links to the generated asm code of these two functions.
Repository: TypeScript
Issue: Suggest renaming file from .ts to .tsx if needed?
Labels: Suggestion,Domain: Error Messages,Experience Enhancement

## Search Terms

ts tsx react jsx rename file errors

## Suggestion

When adding JSX elements (React) to a `.ts` file rather than a `.tsx` file, error messages aren't clear that it should be a `.tsx` file. If it's clear the user is intending to write JSX code, such as having multiple JSX-like components and/or components that extend `React.Component`, can a code fix be given (on the file? on individual `<>`-related parsing errors?) to rename to `.tsx`?

## Use Cases

There's been some buzz on Twitter lately about how easy it is to forget to rename to `.tsx`. Some users are apparently even used to writing JSX in `.js`, so the need to use `.tsx` is a bit confusing for them.

## Examples

Given this `file.ts`:

```ts
import * as React from "react";

export class ComponentClass extends React.Component {
    public render() {
        return <span />;
        // index.ts(5,22): error TS1005: '>' expected.
        // index.ts(5,23): error TS1161: Unterminated regular expression literal.
    }
}

export const ComponentArrow = () => <span />;
// index.ts(11,43): error TS1005: '>' expected.
// index.ts(11,44): error TS1161: Unterminated regular expression literal.
```

Would it be possible to special-case just from these errors to suggest to rename the file? Alternately, if we just have the `ComponentArrow` errors, would it still be possible to suggest to rename the file?

## Checklist

My suggestion meets these guidelines:

* [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, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: pytorch
Issue: ProcessGroupGlooTest.test_scatter_stress_cuda is flaky
Labels: oncall: distributed,triaged,module: flaky-tests,module: c10d

Example errors:

1. build: https://circleci.com/gh/pytorch/pytorch/550843?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
```
======================================================================
Jan 11 15:06:07 FAIL: test_scatter_stress_cuda (__main__.ProcessGroupGlooTest)
Jan 11 15:06:07 ----------------------------------------------------------------------
Jan 11 15:06:07 Traceback (most recent call last):
Jan 11 15:06:07   File "test_c10d.py", line 451, in wrapper
Jan 11 15:06:07     self._join_processes(fn)
Jan 11 15:06:07   File "test_c10d.py", line 496, in _join_processes
Jan 11 15:06:07     self._check_return_codes(elapsed_time)
Jan 11 15:06:07   File "test_c10d.py", line 507, in _check_return_codes
Jan 11 15:06:07     self.assertEqual(p.exitcode, first_process.exitcode)
Jan 11 15:06:07   File "/var/lib/jenkins/workspace/test/common_utils.py", line 443, in assertEqual
Jan 11 15:06:07     super(TestCase, self).assertLessEqual(abs(x - y), prec, message)
Jan 11 15:06:07 AssertionError: 12 not less than or equal to 1e-05 : 
```

2. build: https://circleci.com/gh/pytorch/pytorch/550696?utm_campaign=vcs-integration-link&utm_medium=referral&utm_source=github-build-link
```
======================================================================
Jan 11 13:48:43 ERROR: test_scatter_stress_cuda (__main__.ProcessGroupGlooTest)
Jan 11 13:48:43 ----------------------------------------------------------------------
Jan 11 13:48:43 Traceback (most recent call last):
Jan 11 13:48:43   File "test_c10d.py", line 451, in wrapper
Jan 11 13:48:43     self._join_processes(fn)
Jan 11 13:48:43   File "test_c10d.py", line 496, in _join_processes
Jan 11 13:48:43     self._check_return_codes(elapsed_time)
Jan 11 13:48:43   File "test_c10d.py", line 506, in _check_return_codes
Jan 11 13:48:43     raise RuntimeError('Process {} terminated or timed out after {} seconds'.format(i, elapsed_time))
Jan 11 13:48:43 RuntimeError: Process 0 terminated or timed out after 30.030478715896606 seconds
```

cc @pietern @mrshenli @pritamdamania87 @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @SciPioneer @H-Huang @teng-li
Repository: go
Issue: gccgo: confusing closure names
Labels: NeedsInvestigation

<!-- Please answer these questions before submitting your issue. Thanks! -->

### What version of Go are you using (`go version`)?
```
gccgo2 (GCC) 9.0.0 20190108 (experimental)
```

### What operating system and processor architecture are you using (`go env`)?
Linux/AMD64

### What did you do?
```
package main

type T struct {
	closure1, closure2 func()
}

func (t *T) M1()  { t.closure1 = func() { t.closure2() } }
func (t *T) M2()  { t.closure2 = func() { panic("XXX") } }

func main() {
	var t T
	t.M1()
	t.M2()
	t.closure1()
}
```

Built with gccgo, this program prints
```
panic: XXX

goroutine 1 [running]:
panic
	/tmp/src/gccgo/libgo/go/runtime/panic.go:588
main.func1
	/tmp/c.go:8
main.func1
	/tmp/c.go:7
main.main
	/tmp/c.go:14
```

The closures on line 7 and 8 are different functions, yet have the same name, which is confusing. It is ok that closures have somewhat artificial names, but it is super confusing if different closures have the name.

It appears to me (without checking the source code) that if the closures are defined in global scope or inside a function (NOT method), they are properly named as `package_name.funcN` or `package_name.function_name.funcN` with proper `N`. However, if they are defined in methods, they are all named `package_name.funcN` with `N` starting from 1 in each method. In this case, the two closures are defined in two different methods, and both named `main.func1`.

cc @ianlancetaylor @thanm
Repository: TypeScript
Issue: Allow use of infer in extends clause of generic type parameter
Labels: Suggestion,Awaiting More Feedback

## Search Terms

generic type parameter infer keyword conditional

## Suggestion

Allow the use `infer` keyword in the extends clause of generic type parameters. This would simply be a nice quality of life improvement to avoid unnecessary conditional types or extra free type parameters.

```ts
type ArrayType<A extends Array<infer T>> = T;
```

## Use Cases

Currently if you have a generic type whose parameter is constrained by a generic type, you need to write a conditional to extract the nested generic type:

```ts
type ArrayType<A extends Array<any>> = A extends Array<infer T> ? T : never;
```

This seems unfortunate that we need to write a conditional since only the true branch will ever be satisfied. (Additionally, avoiding unnecessary usages of `any` would be nice.) We could avoid some duplication by dropping the constraint:

```ts
type ArrayType<A> = A extends Array<infer T> ? T : never;
```

But passing a non array into this type would move the error to wherever `ArrayType` was used (or perhaps even be silenced) instead of on the type parameter itself where the error actually occurred.

We could also do this with an extra type parameter, but this puts the onus on the user of the type to pass a correct value (and they can always just pass `unknown` or `any`):

```ts
type ArrayType<A extends Array<T>, T> = T;
type T2 = ArrayType<number[], number>;
type T3 = ArrayType<number[], unknown>;
type T1 = ArrayType<number[], any>;
```

## Examples

```ts
type MyType<A, B> = { ... }

type OldLift<T extends MyType<any, any>, B> = T extends MyType<infer A, any>
    ? MyType<A, B>
    : never;

type NewLift<T extends MyType<infer A, any>, B> = MyType<A, B>;
```

## Checklist

My suggestion meets these guidelines:

* [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, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).
Repository: flutter
Issue: FAB shadows are not aligned with Material spec
Labels: framework,f: material design,has reproducible steps,P2,found in release: 3.3,found in release: 3.6,team-design,triaged-design

## Steps to Reproduce
1. Render a FAB.
2. Look at shadow.
3. Compare with FAB shadow with attached image
<img width="143" alt="screen shot 2019-01-11 at 11 02 54 am" src="https://user-images.githubusercontent.com/42326/51054103-84437c80-1590-11e9-8c6f-45506163aa18.png">

`material/shadows.dart` appears to define them appropriately, but in the case of the drawing the FAB there's a call out to a native function called `Canvas_drawShadow`, which takes a "Material elevation" argument. The call happens in the `RenderPhysicalShape` class in `flutter/lib/src/rendering/proxy_box.dart`.

cc @willlarche
Repository: TypeScript
Issue: JavaScript/TypeScript region folding with //region does not work
Labels: Suggestion,Awaiting More Feedback,Domain: Outlining

<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version: 1.30.2
- OS Version: Linux x64 4.20.0-arch1-1-ARCH

Steps to Reproduce:

1. Use `//region` and `//endregion` in JavaScript and/or TypeScript files to create folding regions.

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

[The release notes for 1.17](https://code.visualstudio.com/updates/v1_17#_folding-regions) mention that support was added for folding regions. For JavaScript/TypeScript, both `//#region` `//#endregion` and `//region` `//endregion` were added. However only `//#region` `//#endregion` seem to work. `//region` `//endregion` do not work. 
This is annoying because some projects I work on use this syntax throughout all the code. 

![vscode_folding_regions](https://user-images.githubusercontent.com/9055274/50963526-43366400-14cd-11e9-896b-c7bb45186763.png)

Code snippet
```javascript
//region region
//endregion

// region region with space
// endregion

//#region #region
//#endregion

// #region #region with space
// #endregion
```
Repository: go
Issue: cmd/compile: implement global new(T) without calling newobject
Labels: Performance,NeedsFix,compiler/runtime

```go
package p

var x = new(int)
```

This generates init code to call `newobject` (including a write barrier, which I thought wasn't supposed to happen any more?). Instead, we should make a BSS int symbol, and then make `x` contain a relocation to that symbol.

cc @randall77 @mvdan
Repository: go
Issue: x/build: add binary size sparklines to build.golang.org
Labels: Builders,NeedsInvestigation,FeatureRequest

Binary size keeps creeping up. Some visibility might help.

Here's an idea: At the end of every builder run, we have readily available a bunch of compiled binaries on a bunch of different platforms. We could pick a few binaries on a couple of platforms and add some spark charts (or regular charts) to the top of build.golang.org of binary sizes.

I'd like to do the same with compile time, etc, but that information is less readily available.

Related: #19327

cc @dmitshur @bradfitz
Repository: go
Issue: cmd/compile: use memmove to initialize non-global static data
Labels: Performance,NeedsFix,compiler/runtime

This is a duplicate of https://github.com/golang/go/issues/29573#issuecomment-451596366 and https://github.com/golang/go/issues/29574#issuecomment-451626918, but split out so that it doesn't get lost in the other discussions.

When initializing static data in a function (non-global) context, we generate code to construct the desired object. In some (most?) cases, it'd be preferable to have a static data symbol containing the desired object and then copy it into place using memmove/typedmemmove.

See those issues/comments for more details.

cc @dsnet @randall77
Repository: rust
Issue: rustdoc support for per-parameter documentation
Labels: T-rustdoc,A-attributes,C-feature-request

It appears to me that this pattern of documenting function parameter has become an informal standard:
```rust
    /// Supplies a new frame to WebRender.
    ///
    /// Non-blocking, it notifies a worker process which processes the display list.
    ///
    /// Note: Scrolling doesn't require an own Frame.
    ///
    /// Arguments:
    ///
    /// * `document_id`: Target Document ID.
    /// * `epoch`: The unique Frame ID, monotonically increasing.
    /// * `background`: The background color of this pipeline.
    /// * `viewport_size`: The size of the viewport for this frame.
    /// * `pipeline_id`: The ID of the pipeline that is supplying this display list.
    /// * `content_size`: The total screen space size of this display list's display items.
    /// * `display_list`: The root Display list used in this frame.
    /// * `preserve_frame_state`: If a previous frame exists which matches this pipeline
    ///                           id, this setting determines if frame state (such as scrolling
    ///                           position) should be preserved for this new display list.
    pub fn set_display_list(
        &mut self,
        epoch: Epoch,
        background: Option<ColorF>,
        viewport_size: LayoutSize,
        (pipeline_id, content_size, display_list): (PipelineId, LayoutSize, BuiltDisplayList),
        preserve_frame_state: bool,
) {...}
```

It's quite sub-optimal currently for a number of reasons:
  - have to repeat argument names
  - separate block of argument docs versus arguments themselves
  - just a lot of noise

So not only it's not exactly most convenient, it's also easy to get the docs de-synchronized from the code (notice the `document_id` above ^). It would be much better if we could do this instead:
```rust
    /// Supplies a new frame to WebRender.
    ///
    /// Non-blocking, it notifies a worker process which processes the display list.
    ///
    /// Note: Scrolling doesn't require an own Frame.
    pub fn set_display_list(
        &mut self,
        /// Unique Frame ID, monotonically increasing.
        epoch: Epoch,
        /// Background color of this pipeline.
        background: Option<ColorF>,
        /// Size of the viewport for this frame.
        viewport_size: LayoutSize,
        /// The ID of the pipeline that is supplying this display list,
        /// the total screen space size of this display list's display items,
        /// and the root Display list used in this frame.
        (pipeline_id, content_size, display_list): (PipelineId, LayoutSize, BuiltDisplayList),
        /// If a previous frame exists which matches this pipeline id,
        /// this setting determines if frame state (such as scrolling position)
        /// should be preserved for this new display list.
        preserve_frame_state: bool,
) {...}
```

Does that sound remotely possible? With an assumption that the latter case would produce near-identical documentation to the former.
Repository: go
Issue: Brand book: hex color codes don't match RGB values
Labels: Documentation,NeedsInvestigation

I was writing a Playground link¹ for a quick reference to the Go brand colors, and discovered that some of the hex values for some of the colors in the [Brand Book](https://golang.org/s/brandbook) don't match the RGB values listed beneath them.

Specificially:
* “Gopher Blue” is listed as `#00ADD8`,
   but its RGB value corresponds to `#01ADD8`.
* “Light Blue” is listed as `#5DC9E2`,
   but its RGB value corresponds to `#5EC9E3`.
* “Fuchsia” is listed as `#CE3262`,
   but its RGB value corresponds to `#CE3062`.

I'm not sure which of the values in those cases is correct, but they should be made consistent either way.

¹https://play.golang.org/p/DbqyvrenYA0
Repository: rust
Issue: first/second mutable borrow occurs here wrong diagnostic in nll
Labels: C-enhancement,A-diagnostics,A-borrow-checker,T-compiler,D-papercut

After https://github.com/rust-lang/rust/pull/56113 we figured with @nikomatsakis that the output of `src/test/ui/borrowck/borrowck-mut-borrow-linear-errors.rs` in NLL is not ideal ([play](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=e214c2f5b4adadbcdfde970a69b7557f)):

```rust
fn main() {
    let mut x = 1;
    let mut addr = vec![];
    loop {
        match 1 {
            1 => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
            //[mir]~^ ERROR [E0499]
            2 => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
            //[mir]~^ ERROR [E0499]
            _ => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
            //[mir]~^ ERROR [E0499]
        }
    }
}
```

This outputs:

```
error[E0499]: cannot borrow `x` as mutable more than once at a time
  --> $DIR/borrowck-mut-borrow-linear-errors.rs:13:30
   |
LL |             1 => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
   |                    ----      ^^^^^^ second mutable borrow occurs here
   |                    |
   |                    first borrow later used here
...
LL |             _ => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
   |                              ------ first mutable borrow occurs here

error[E0499]: cannot borrow `x` as mutable more than once at a time
  --> $DIR/borrowck-mut-borrow-linear-errors.rs:15:30
   |
LL |             1 => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
   |                    ---- first borrow later used here
LL |             //[mir]~^ ERROR [E0499]
LL |             2 => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
   |                              ^^^^^^ second mutable borrow occurs here
LL |             //[mir]~^ ERROR [E0499]
LL |             _ => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
   |                              ------ first mutable borrow occurs here

error[E0499]: cannot borrow `x` as mutable more than once at a time
  --> $DIR/borrowck-mut-borrow-linear-errors.rs:17:30
   |
LL |             _ => { addr.push(&mut x); } //[ast]~ ERROR [E0499]
   |                              ^^^^^^ mutable borrow starts here in previous iteration of loop

error: aborting due to 3 previous errors

For more information about this error, try `rustc --explain E0499`.
```

in NLL mode.

In particular the mention of first and second is weird. Why the `_ =>` arm is the first one?. Is that clear to the user?. There are several errors in the test also. Is it better to mix the fact that you're mutably borrowing something in `_ =>` and the mutably borrowing in `1 =>`? or is it better and easier to just state that both borrows are inside of the loop?.