sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: storybook
Issue: Missing types for async loaders in React 
Labels: bug,react,typescript

**Describe the bug**
The types for async loaders are missing from `StoryContext` and `Story`

**To Reproduce**
Steps to reproduce the behavior:

1. Create a CSF story in typescript
2. Try to add `loaders` prop to story
4. See error

**Expected behavior**
A clear and concise description of what you expected to happen.

**Screenshots**
missing optional `loaded`
![image](https://user-images.githubusercontent.com/675601/111863596-22aca300-898f-11eb-8a1d-9088000263e8.png)

Missing optional `loaders` 
![image](https://user-images.githubusercontent.com/675601/111863827-51774900-8990-11eb-978d-6b0ed3ec0c9e.png)

**Code snippets**
```
import { Story } from '@storybook/react';
import * as React from 'react';

interface MyComponentProps {
    someText: string;
}

const MyComponent = (props: MyComponentProps ) => (
    <div>{props.someText}</div>
);

const Template: Story<MyComponentProps> = (args) => (
    <MyComponent {...args} />
);

export const MyStory: Story = Template.bind({});
MyStory.loaders = []; //error
```

**System**
Environment Info:

  System:
    OS: Windows 10 10.0.19042
    CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Binaries:
    Node: 12.16.1 - C:\Program Files\nodejs\node.EXE
    Yarn: 1.22.4 - C:\Program Files (x86)\Yarn\bin\yarn.CMD
    npm: 6.13.4 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: 89.0.4389.90
    Edge: Spartan (44.19041.423.0), Chromium (89.0.774.57), ChromiumDev (91.0.825.0)
  npmPackages:
    @storybook/addon-actions: ^6.1.21 => 6.1.21
    @storybook/addon-essentials: ^6.1.21 => 6.1.21
    @storybook/addon-links: ^6.1.21 => 6.1.21
    @storybook/addons: ^6.1.21 => 6.1.21
    @storybook/api: ^6.1.21 => 6.1.21
    @storybook/client-api: ^6.1.21 => 6.1.21
    @storybook/client-logger: ^6.1.21 => 6.1.21
    @storybook/components: ^6.1.21 => 6.1.21
    @storybook/react: ^6.1.21 => 6.1.21
    @storybook/theming: ^6.1.21 => 6.1.21
Repository: rust
Issue: Error message suggests invalid Rust code with PartialEq<OtherType> and ToString
Labels: A-diagnostics,T-compiler,C-bug,A-suggestion-diagnostics,D-invalid-suggestion

Given the following code:

```rust
enum ETest {}

impl ToString for ETest {
    fn to_string(&self) -> String { String::new() }
}

#[derive(PartialEq)]
struct Props {
    to: ETest
}

impl PartialEq<String> for ETest {
    fn eq(&self, other: &String) -> bool { true }
}

struct Test {
    props: Props
}

trait Foo {
    type TProps: PartialEq;
}

impl Foo for Test {
    type TProps = Props;
}
```

The current output is:

```
error[E0308]: mismatched types
 --> src/lib.rs:9:5
  |
9 |     to: ETest
  |     ^^^^^^^^^
  |     |
  |     expected struct `String`, found enum `ETest`
  |     help: try using a conversion method: `(to: ETest).to_string()`
  |
  = note: this error originates in a derive macro (in Nightly builds, run with -Z macro-backtrace for more info)
```

If we replace our code with compiler's suggestion, we end up with this code:

```rust
#[derive(PartialEq)]
struct Props {
    (to: ETest).to_string()
}
```

Which is invalid Rust.

I've only observed this happen with `PartialEq<Type>` and `ToString` being implemented.  
Related to: https://github.com/rust-lang/rust/issues/63564

https://github.com/rust-lang/rust/issues/63564 makes this error message even worse as it isn't obvious what's actually wrong here.

I reproduced this with today's nightly build (`2021-03-19 f5f33ec0e0455eefa72f`)

Playground link: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=7ac536d0521cefa0cf1f088b9d88db1f
Repository: PowerToys
Issue: Power Automate Desktop flows among the actions that can be performed via PT Run
Labels: Idea-Enhancement,Product-PowerToys Run,Run-Plugin

Hi, lately I've been exploring much automation with **[Power Automate Desktop](https://flow.microsoft.com/en-us/desktop/)**  and I'm finding it extremely practical.

One feature that I think would be incredibly useful is the ability to invoke a flow produced on PAD via **PowerToys Run**.
![image](https://user-images.githubusercontent.com/24718181/111869029-96de4b00-897d-11eb-8bc8-cdd4e2a4760e.png)

![image](https://user-images.githubusercontent.com/24718181/111868997-71e9d800-897d-11eb-8331-b17867273160.png)

I don't know if it is possible to easily retrieve the list of invocable flows, but if so I believe the functionality could be very valuable to several people.

**If you'd like to see this feature implemented, add a 👍|🚀 reaction to this post.**
Repository: flutter
Issue: Table border is drawn over the cell content
Labels: framework,f: material design,a: quality,has reproducible steps,found in release: 2.1,team-design,triaged-design

## Steps to Reproduce

Run this snippet:
```dart
import 'package:flutter/material.dart';

void main() {
  runApp(
    MaterialApp(
      home: MyWidget(),
    ),
  );
}

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    final BorderSide borderSide = BorderSide(
      width: 20,
      color: const Color(0xff00ff00),
    );

    return Scaffold(
      body: Table(
        border: TableBorder(
          verticalInside: borderSide,
          horizontalInside: borderSide,
        ),
        children: <TableRow>[
          for (var row = 0; row < 10; row++)
          TableRow(
            children: <Widget>[
              for (var col = 0; col < 10; col++) Text("cell ${row + 1} ${col + 1}", style: TextStyle(fontSize: 20, fontWeight: FontWeight.bold)),
            ],
          ),
        ],
      ),
    );
  }
}
```

**Expected results:** actually, I don't know if it is intended behaviour. I expect borders to be drawn between cells, not over them.

**Actual results:** 
https://codepen.io/Dimous/pen/abBeWML
Repository: flutter
Issue: Usage of MaterialApp.router breaks Semantics
Labels: a: tests,framework,a: accessibility,d: api docs,f: routes,has reproducible steps,P2,found in release: 2.1,team-framework,triaged-framework

## Reproduction

### Create a sample flutter app

~~~bash
flutter create semantics_bug
cd semantics_bug
~~~

### Create a unit test

Open `test/widget_test.dart` and paste the following code: 

~~~dart
import 'package:flutter/material.dart';
import 'package:flutter_test/flutter_test.dart';

final c = Container(width: 100, height: 100, color: Colors.blue);
final content = Stack(children: [
  Positioned(right: 0, child: Semantics(label: 'c1', child: c)),
  Positioned(right: 100, child: Semantics(label: 'c2', child: c)),
]);

final contentWrappedIntoSemantics =
    Semantics(explicitChildNodes: true, child: content);

// A mock router delegate
class MockDelegate extends RouterDelegate<String>
    with ChangeNotifier, PopNavigatorRouterDelegateMixin<String> {
  final Widget widget;
  MockDelegate(this.widget) : navigatorKey = GlobalKey<NavigatorState>();

  @override
  Widget build(BuildContext context) => widget;

  final GlobalKey<NavigatorState> navigatorKey;
  String get currentConfiguration => '';
  Future<void> setNewRoutePath(_) async => null;
}

// A mock route information parser
class MockParser extends RouteInformationParser<String> {
  Future<String> parseRouteInformation(
          RouteInformation routeInformation) async =>
      '';

  RouteInformation restoreRouteInformation(String configuration) =>
      RouteInformation(location: '');
}

void main() {
  performTest(WidgetTester tester, Widget content) async {
    await tester.pumpWidget(
      MaterialApp.router(
        routeInformationParser: MockParser(),
        routerDelegate: MockDelegate(content),
      ),
    );
    expect(find.bySemanticsLabel('c1'), findsOneWidget);
    expect(find.bySemanticsLabel('c2'), findsOneWidget);
  }

  testWidgets('BROKEN: Semantic labels do not work by default',
      (WidgetTester tester) async {
    await performTest(tester, contentWrappedIntoSemantics);
    await performTest(tester, content); // BROKEN!!!
  });
}
~~~

### Run the unit test

Switch to the command line and run the tests:

~~~bash
flutter test
~~~

The unit test will fail. 

## Analysis

In the test file, look at the following two code lines: 

~~~dart
await performTest(tester, contentWrappedIntoSemantics);
await performTest(tester, content); // BROKEN!!!
~~~

The first test will work because the widget content is wrapped into a `Semantics` widget with `explicitChildNodes` set to `true`.

The second test breaks. It does the same, with the only difference that the content is not wrapped into a `Semantics` widget.

## Solution 

This might two possible solutions: 

- a) Fix the thing. Everything should work out of the box.
- b) Add documentation to `RouterDelegate` telling the developer to apply the wrapping as shown above.
Repository: rust
Issue: ToSocketAddrs should be implemented for Iterator<Item=SocketAddr>
Labels: C-enhancement,T-libs

`ToSocketAddrs` is used for functions like `UdpSocket::bind()` to abstract over "objects which can be converted or resolved to one or more SocketAddr values." Yet it is not implemented for Iterators of `SocketAddr`s (the closest analog it is implemented for is `&[SocketAddr]`)

This makes trying to bind to a large range of ports allocate unnecessarily - 6 bytes per ipv4 SocketAddr or 18 bytes per ipv6 SocketAddr. This isn't much per socket, but it can add up for large port ranges. For example
```rust
let localhost = Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1);
let socket_addrs = (0..=3000).map(|port| SocketAddrV6::new(localhost, port));
let socket_addrs:Vec<_> = socket_addrs.collect();  //<- unnecessary allocation of 54K
let udp_socket = UdpSocket::bind(socket_addrs)
```
Ideally, I could do something like
```rust
let localhost = Ipv6Addr::new(0, 0, 0, 0, 0, 0, 0, 1);
let socket_addrs = (0..=3000).map(|port| SocketAddrV6::new(localhost, port));
// No heap allocations, yay
let udp_socket = UdpSocket::bind(socket_addrs)
```
Of course users can always manually loop over their `SocketAddr`s, but this is the complexity `ToSocketAddrs` was created to solve.

### How to fix it

I'm not sure exactly. My first attempt at fixing it was adding
```rust
#[stable(feature = "rust1", since = "1.0.0")]
impl<T> ToSocketAddrs for T
where T: Iterator<Item=SocketAddr> + Clone,
{
    type Iter = T;
    fn to_socket_addrs(&self) -> io::Result<Self::Iter> {
        Ok(self.clone())
    }
}
```
which fails at compile time with
```
error[E0119]: conflicting implementations of trait `net::addr::ToSocketAddrs` for type `(net::ip::IpAddr, u16)`:
   --> library/std/src/net/addr.rs:897:1
    |
871 | / impl<T> ToSocketAddrs for T
872 | | where T: Iterator<Item=SocketAddr> + Clone,
873 | | {
874 | |     type Iter = T;
...   |
877 | |     }
878 | | }
    | |_- first implementation here
...
897 |   impl ToSocketAddrs for (IpAddr, u16) {
    |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ conflicting implementation for `(net::ip::IpAddr, u16)`
    |
    = note: upstream crates may add a new impl of trait `core::iter::Iterator` for type `(net::ip::IpAddr, u16)` in future versions
```
(and many more similar warnings)
This seems a little silly - adding an implementation of Iterator for `(net::ip::IpAddr, u16)` both doesn't make sense and will cause rustc to not compile, so it couldn't be overlooked in testing, but maybe I'm missing something. Hopefully there's an escape hatch for internals to skirt orphaning rules.
Repository: node
Issue: investigate flaky test-crypto-secure-heap on LinuxONE
Labels: crypto,flaky-test,linux

<!--
Thank you for reporting a flaky test.

Flaky tests are tests that fail occasionally in the Node.js CI, but not
consistently enough to block PRs from landing, or that are failing in CI jobs or
test modes that are not run for every PR.

Please fill in as much of the template below as you're able.

Test: The test that is flaky - e.g. `test-fs-stat-bigint`
Platform: The platform the test is flaky on - e.g. `macos` or `linux`
Console Output: A pasted console output from a failed CI job showing the whole
failure of the test
Build Links: Links to builds affected by the flaky test

If any investigation has been done, please include any information found, such
as how consistently the test fails, whether the failure could be reproduced
locally, when the test started failing, or anything else you think is relevant.
-->

* **Test**: test-crypto-secure-heap
* **Platform**: LinuxONE rhel7-s390x
* **Console Output:**
```
not ok 373 parallel/test-crypto-secure-heap
  ---
  duration_ms: 0.173
  severity: fail
  exitcode: 1
  stack: |-
    node:assert:936
        throw err;
        ^
    
    AssertionError [ERR_ASSERTION]: The input did not match the regular expression /--secure-heap must be a power of 2/. Input:
    
    ''
    
        at ChildProcess.<anonymous> (/home/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel7-s390x/test/parallel/test-crypto-secure-heap.js:71:12)
        at ChildProcess.<anonymous> (/home/iojs/build/workspace/node-test-commit-linuxone/nodes/rhel7-s390x/test/common/index.js:381:15)
        at ChildProcess.emit (node:events:369:20)
        at Process.ChildProcess._handle.onexit (node:internal/child_process:290:12) {
      generatedMessage: true,
      code: 'ERR_ASSERTION',
      actual: '',
      expected: /--secure-heap must be a power of 2/,
      operator: 'match'
    }
  ...
```
* **Build Links**: https://ci.nodejs.org/job/node-test-commit-linuxone/26230/nodes=rhel7-s390x/consoleText
Repository: TypeScript
Issue: Support import maps and bare import specifiers
Labels: Suggestion,Needs Proposal

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

1.  import maps
2.  bare import specifiers

<!--
  💡 Did you know? TypeScript has over 2,000 open suggestions!
  🔎 Please search thoroughly before logging new feature requests as most common ideas already have a proposal in progress.
  The "Common Feature Requests" section of the FAQ lists many popular requests: https://github.com/Microsoft/TypeScript/wiki/FAQ#common-feature-requests

  Replace the text below:
-->


## ✅ Viability Checklist

<!--
   Suggestions that don't meet all these criteria are very, very unlikely to be accepted.
   We always recommend reviewing the TypeScript design goals before investing time writing
   a proposal for ideas outside the scope of the project.
-->
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, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

<!-- A summary of what you'd like to see added or changed -->

As import maps are part of Chrome (as of version 89), and Firefox has given a nod of approval, it would be great if Typescript embraced this cross-package import syntax.

Import maps assume an index.html (for example) file with a script tag, e.g.:

```html
<script type="importmap">
{
  "imports": {
    "moment": "/node_modules/moment/src/moment.js",
    "lodash": "/node_modules/lodash-es/lodash.js"
  }
}
</script>
```

I would suggest being able to 

1.  Point to a file containing such an importmap in tsconfig and/or
2.  Just supporting bare import specifiers, based on package.json/package-lock.json, the way unpkg.com [is able to do](https://unpkg.com/#query-params)..

## 📃 Motivating Example

<!--
  If you were announcing this feature in a blog post, what's a short explanation that shows
  a developer why this feature improves the language?
-->

Now you can reference cross-package JS files seamlessly, without bundling tools, based on browser standards.


<!--
  What do you want to use this for?
  What shortcomings exist with current approaches?
  What workarounds are you using in the meantime?
-->

Workaround:

The [path resolution](https://www.typescriptlang.org/docs/handbook/module-resolution.html#path-mapping)  Typescript provides is inadequate, and quite unhelpful.

The only fairly reliable workaround I've found is cloning the repo to a sibling folder of my project.
Repository: PowerToys
Issue: Improve small screen UX
Labels: Area-User Interface

PowerToys is good but not enough

I use it on an small display  which that means the options will be shown too bigger than what we can expect 

Great if powerful PowerToys team decide to add a feature for make toys compatible with small screens

Color picker & PT Run are big seriously 😑

Anyway color picker without a color maker is just a joke good if pick a vision for it
Repository: TypeScript
Issue: `eval?.()` is now an indirect eval
Labels: Bug

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

There has apparently been a recent change to the behavior of `eval?.()` in all major JavaScript engines. It is now considered an indirect eval instead of a direct eval. This behavior was changed in July 2020. TypeScript is still compiling it as a direct eval and I didn't see an issue about this, so I created this issue.

More context: https://bugs.chromium.org/p/v8/issues/detail?id=10630

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
optional chain direct indirect eval scope

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried

### ⏯ 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?#code/OYGw9gRghiAqAWBLAzgOigAgLwYESkhlwG4AoACkywD4MBTANxgH5VzcBjMAO2TBDqpwwSgEpco0e3AcioskA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
globalThis.a = "global";
(a => eval?.("console.log(a)"))("local");
```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->

When compiled with TypeScript, this prints `local` instead. That matches the behavior of older JavaScript runtimes such as node v14 but doesn't match the latest JavaScript runtimes.

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->

This code now prints `global` when run in an up-to-date browser or in node v15, so it should print `global` when compiled with TypeScript as well.
Repository: three.js
Issue: LineSegmentsGeometry: Calling "setPositions" twice does not update the lines correctly
Labels: Needs Investigation

**Describe the bug**

Calling `LineSegmentsGeometry.setPositions` a second time with more line segments still only renders the amount of line segments specified in the first call. Everything works as expected if you call "dispose" before calling "setPositions" again.

I'm not exactly sure why it's happening. Perhaps it's an issue related to instanced geometry rendering?

**To Reproduce**

Steps to reproduce the behavior:
1. Create a `LineSegments2` object
2. Call `line.geometry.setPositions` with 1 line segment
3. See that it renders 1 line
4. 1 second later call `line.geometry.setPositions` with 2 line segments
5. See that it only renders the first of the two lines

***Code***

```js
line = new LineSegments2();
line.geometry.setPositions( [ 0, -0.5, 0, 0, 0.5, 0 ] );

setTimeout( () => {

  // uncomment to display both lines
  // line.geometry.dispose();
  line.geometry.setPositions( [
    0, -0.5, 0, -0.5, 0.5, 0,
    0, 0, 0, 0.5, 0, 0,
  ] );

}, 1000 );
```

***Live example***

https://jsfiddle.net/rhjeL01n/

**Expected behavior**

The correct amount of lines are rendered after calling "setPositions".

**Screenshots**

If applicable, add screenshots to help explain your problem (drag and drop the image).

**Platform:**

 - Device: Desktop
 - OS: Windows
 - Browser: Chrome
 - Three.js version: latest (r126)
Repository: pytorch
Issue: [proposal] Integrate autograd graph visualizer for displaying crashed locations during detect_anomaly
Labels: feature,module: autograd,triaged

@szagoruyko made a good simple visualizer: https://github.com/szagoruyko/pytorchviz. if sth like that starts to include identifiers produced by stack traces (produced by anomaly detector), it would be very useful for debugging infs/nans produced at forward or backward

Otherwise, could PyTorch enable some tracing information (like line numbers) at python level, so that exceptions from anomaly detector include it?

cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer
Repository: rust
Issue: Confusing error message when trying to use a lifetime on an `Any` trait object
Labels: A-diagnostics,A-lifetimes,T-compiler,D-confusing,D-terse,A-trait-objects

The following code [playground link](https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=0cfffdc1eb1d37a33b71970013fa371b)

```rust
use std::any::Any;

struct Something<'a> {
    broken: Box<dyn Any + 'a>
}
```

Outputs an error message related to lifetime issues that is not clear what the issue exactly is.

```
error[E0478]: lifetime bound not satisfied
 --> src/lib.rs:4:13
  |
4 |     broken: Box<dyn Any + 'a>
  |             ^^^^^^^^^^^^^^^^^
  |
note: lifetime parameter instantiated with the lifetime `'a` as defined on the struct at 3:18
 --> src/lib.rs:3:18
  |
3 | struct Something<'a> {
  |                  ^^
  = note: but lifetime parameter must outlive the static lifetime
```

This error is caused by `trait Any: 'static`, however this error message is not clear as to **why** the lifetime needs to outlive the static lifetime.  Ideally the error message would say where the requirement comes from, like other lifetime-related errors.

cc @estebank who was looking for weird and unintuitive errors.  This wasn't caused by a crate specifically, but it still isn't a good error.