sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: String literal rename doesn't work in object unions
Labels: Bug,Domain: Refactorings

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.2.0-dev.20201109

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
String literal rename

**Code**

```ts
type Actions = { type: 'one', payload: number } | { type: 'two', payload: boolean }
const q: Actions = { type: 'one', payload: 1 }
```

**Expected behavior:**
Renaming of values of 'type' fields should also rename the value in actual variable. For example if I rename `'one'` in the type `Actions` TS should also rename the value of `type` field in `q` variable, and vice versa.

**Actual behavior:**
Looks like renaming doesn't start at all

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
https://www.typescriptlang.org/play?ts=4.2.0-dev.20201109#code/C4TwDgpgBAggxsAlgewHYGcoF4oG8qiQBcUA5GhKQDRRgCGIANsnQCYmoCuAtgEYQAnKAF8oAHzwFwEEqWAB3ZNVoNmbEr2TJGEOqhEAoOGnTAoARxLwkJ7JMIyyFZfSYt2UAIwigA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
https://github.com/microsoft/TypeScript/issues/5602
https://github.com/microsoft/TypeScript/pull/39298
Repository: create-react-app
Issue: Export a subset of react-scripts build config for usage in dependencies
Labels: issue: proposal,needs triage

Hello,

As many, I think, I often want to split my projects into multiple submodules.
But CRA doesn't build dependencies outside of src.

So each time I create a submodule, I have to create a rollup config which reproduces quite exactly the same build config as in react-scripts files. And I try to maintain it when CRA is released.

It would be very helpful if I could just import a config file that would allow me to build libraries the same as it would if they were build in the src folder. But as an exported module.

So my suggestion is, if possible, to refactor react-scripts configs files in order to export this subset of babel and other needed configs.

Any idea ?
Repository: pytorch
Issue:  Attempted to read a PyTorch file with version 3, but the maximum supported version for reading is 2
Labels: module: serialization,triaged

## 🐛 Bug

Torch models saved in PyTorch 1.7 fail to load when loaded on 1.4, both as state-dicts and TorchScript models. 

## To Reproduce

Steps to reproduce the behavior:

Training Environment:
1. Trained model using PyTorch 1.7.0, saved using torch.save(model.state_dict())
2. Convert model to TorchScript.  

Testing Environment:
1. Load model with `torch.jit.load(path)`
2. Error.
```
RuntimeError: version_ <= kMaxSupportedFileFormatVersion INTERNAL ASSERT FAILED at /pytorch/caffe2/serialize/inline_container.cc:132, please report a bug to PyTorch. Attempted to read a PyTorch file with version 3, but the maximum supported version for reading is 2. Your PyTorch installation may be too old. (init at /pytorch/caffe2/serialize/inline_container.cc:132)
```
<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior

Changes between PyTorch versions shouldn't break the compatibility of model weights. 

## Environment

Please copy and paste the output from our
[environment collection script](https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py)
(or fill out the checklist below manually).

You can get the script and run it with:
```
wget https://raw.githubusercontent.com/pytorch/pytorch/master/torch/utils/collect_env.py
# For security purposes, please check the contents of collect_env.py before running it.
python collect_env.py
```

 - PyTorch Version 1.7.0 (training), 1.4.0 (test):
 - OS (e.g., Linux): Ubuntu 18.04
 - How you installed PyTorch (`conda`, `pip`, source): pip
 - Build command you used (if compiling from source): n/a
 - Python version: 3.6.12
 - CUDA/cuDNN version: 10.0.0 / 7.0
 - GPU models and configuration: RTX 2080Ti (train) | Tesla P40 testing 
 - Any other relevant information: n/a

<!-- Add any other context about the problem here. -->


cc @mruberry
Repository: vscode
Issue: command tooltip and keyboard shortcut name should be the same.
Labels: debt,search

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

Please use the same terms throughout the application.

When editing keyboard shortcuts, it's very difficult to find what command name that I find.

The term tooltip shows is different in keyboard shortcuts editor.

It's very confusing.
Repository: rust
Issue: Transparently retrying `Interrupted` `waitpid` calls is not always appropriate
Labels: C-bug,T-libs,O-unix,A-process

NB: this issue is just some rambling based on some drive-by review I've done elsewhere. I think its a genuine and useful thing to track, but its not something I hold strong opinions about.

Currently the `Child::wait` call on UNIX systems is implemented to retry in case the `waitpid` call gets interrupted, due to its use of `cvt_r`: https://github.com/rust-lang/rust/blob/d4ea0b3e46a0303d5802b632e88ba1ba84d9d16f/library/std/src/sys/unix/process/process_unix.rs#L434-L443

I'd like to argue that this is not always correct or appropriate. For instance, consider implementation of a service manager (a-la systemd, supervisord, etc.) Such a thing will in general want to register signal handlers and then forward some of the signals to some of the managed processes. With `Child::wait` retrying automatically the tool wanting to do something on a signal is forced to either drop down to directly calling the libc functions or to avoid the `Child::wait` altogether.
Repository: flutter
Issue: [web] Line with stroke width 0 not hairline when canvas is scaled
Labels: platform-web,c: rendering,e: web_html,has reproducible steps,P2,found in release: 3.3,found in release: 3.5,team-web,triaged-web

Drawing lines with (the default) strokeWidth 0 on web acts more like strokeWidth 1, it scales when the canvas is scaled.  It should always produce a 1-pixel line.


## Steps to Reproduce - run this code in DartPad
```dart
import 'package:flutter/material.dart';
import 'dart:ui';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(

      home: Scaffold(
        body: Center(
          child: CustomPaint(
            painter: MyCustomPainter(),
            child: Center()
          ),
        ),
      ),
    );
  }
}

class MyCustomPainter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size){
    var myPaint = Paint()
      ..color = Color(0xffff0000)
      ..strokeWidth = 0;
    canvas.drawLine(
      Offset(0,0),
      Offset(size.width,size.height),
      myPaint);
    canvas.scale(10,10);
       canvas.drawLine(
      Offset(size.width/10,0),
      Offset(0,size.height/10),
      myPaint);

  }
  @override
  bool shouldRepaint(MyCustomPainter arg) => true;
}
````

**Expected results:**  A hairline X filling the draw area.  This works properly on Android
**Actual results:**  One hairline drawn with the unscaled canvas, one thick line with the scaled canvas.
Repository: pytorch
Issue: Eliminate redundant device guards in generic dispatch key kernel wrappers
Labels: module: performance,triaged,module: dispatch

We codegen device guards into kernel wrappers for backends that need them, so kernel implementors don't have to. 

Currently, we also generate device guards into *generic* kernel wrappers. But being generic, we should be able to assume that if these kernels wind up calling any backend-specific kernels, those will do their own device guarding.

Device guards can be expensive, so eliminating redundant calls to them should be a useful win.

Task:
* modify codegen to not emit device guards into generic kernel wrappers (trailhead [here](https://github.com/pytorch/pytorch/pull/47765/files#diff-6382c847dac2d011f822c492e61f9fa0eceb47c2d6fc5fb4f0c42af726c1a3aaR249))
* if anything breaks, figure out why and either fix it or memorialize the situation here

cc @VitalyFedyunin @ngimel cc @ezyang
Repository: godot
Issue: Resizeable WindowDialog with container inside can shrink beyond its expected minimum size
Labels: bug,topic:gui

Godot 3.2.0
Godot 3.2.4 beta1

I made a plugin with a popup containing a complex UI which has an inherent minimum size, due to its design being based on containers. However, after I wrapped it inside a resizeable WindowDialog, Godot allows me to resize it beyond its minimum size.
The contents dont shrink, but the WindowDialog does.

![image](https://user-images.githubusercontent.com/1311555/98866659-31c19880-2465-11eb-9eb0-18a724638203.png)

MRP:
[WindowDialogResizeContainer.zip](https://github.com/godotengine/godot/files/5526851/WindowDialogResizeContainer.zip)
Repository: TypeScript
Issue: typeAcquisition.exclude configuration settings changes are ignored when already cached
Labels: Bug

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.0.5

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:** typeAcquisition exclude 

**Code**
Use the following `jsconfig.json` file:
```json
{
    "compilerOptions": {
        "checkJs": true,
        "strict": true,
        "resolveJsonModule": true,
    },
    "include":[
        "./**/*",
    ],
    "typeAcquisition": {
        "exclude": [
            "copy-webpack-plugin"
        ]
    }
}
```

**Expected behavior:**
When identifying that the source of a type-related issue exists in the automatically acquired type declarations, it is natural to add that package to the `typeAcquisition.exclude` array in the `[j/t]sconfig.json` file.

Once this is done, the TypeScript language service should **not use** automatically acquired type declarations for the specified package (the [`copy-webpack-plugin` package](https://github.com/webpack-contrib/copy-webpack-plugin) in the example above).

In other words, a user should be able to make the configuration adjustment, restart the TypeScript/JavaScript Language Service and find that any packages newly added to the "typeAcquisition.excluded" array should no longer use automatically acquired packages.

**Actual behavior:**
The TypeScript language service **continues to use** automatically acquired type declarations for the newly excluded package.

To be clear, in the example above, setting `typeAcquisition.enable = false` _**does**_ disable the type acquisition for `copy-webpack-plugin`.

Manually "uninstalling" the type declarations (using, for example, `npm uninstall --save-dev @types/copy-webpack-plugin`) allowed the `typeAcquisition.exclude` setting to work as expected. In my case, the cache in question was located at `~/.cache/typescript/4.0`.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
**N/A.** The Playground does not have an option to configure the `typeAcquisition` setting.

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Couldn't find any.
Repository: material-ui
Issue: [Dialog] Dialog title announced after dialog closed in NVDA
Labels: accessibility



- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

Upon closing the Dialog component it announces the dialog title in NVDA
<!-- Describe what happens instead of the expected behavior. -->

## Expected Behavior 🤔

After closing of a Dialog component it should not announce anything related to the Dialog

<!-- Describe what should happen. -->

## Steps to Reproduce 🕹

1) Turn on NVDA
2) Visit https://next--material-ui.netlify.app/components/dialogs/#main-content
3) Using the tab key arrive on 'Open Simple Dialog'
4) Press enter
5) Once the Dialog appears, hit the 'Esc' key

Now observe the text 'dialog.  Set backup account' gets announced. this should not be announced.

![Screen Shot 2020-11-11 at 4 49 45 PM](https://user-images.githubusercontent.com/19170080/98868321-e9db4b00-243d-11eb-8118-8968225d4064.png)

## Context 🔦

<!--
  What are you trying to accomplish? How has this issue affected you?
  Providing context helps us come up with a solution that is most useful in the real world.
-->

## Your Environment 🌎

<!--
  Include as many relevant details about the environment with which you experienced the bug.
  If you encounter issues with TypeScript please include version and tsconfig.
-->

| Tech        | Version |
| ----------- | ------- |
| Material-UI | V5.0.0-alpha.15 |
| React       |     17.0.1    |
| Browser     |    Version 86.0.4240.183 (Official Build) (64-bit)     |
| TypeScript  |         |
| etc.        |         |
Repository: TypeScript
Issue: Type narrowing with assertions containing truthy literals
Labels: Suggestion,In Discussion

<!-- 🚨 STOP 🚨 STOP 🚨 STOP 🚨

Half of all issues filed here are duplicates, answered in the FAQ, or not appropriate for the bug tracker. Even if you think you've found a *bug*, please read the FAQ first, especially the Common "Bugs" That Aren't Bugs section!

Please help us by doing the following steps before logging an issue:
  * Search: https://github.com/Microsoft/TypeScript/search?type=Issues
  * Read the FAQ: https://github.com/Microsoft/TypeScript/wiki/FAQ

Please fill in the *entire* template below.
-->

<!--
Please try to reproduce the issue with the latest published version. It may have already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly
-->
**TypeScript Version:**  4.2.0-dev.20201109

<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**

`type narrowing truthy`
`type narrowing assertion`
`conditional throw`

**Code**

```ts
function test(foo?: number) {
  if (!foo) throw new Error();

  return foo.toFixed();
}

function testWithLiteralTrue(foo?: number) {
  if (!foo && true) throw new Error();

  return foo.toFixed();
}

function testWithTruthyLiteral(foo?: number) {
  if (!foo && "str") throw new Error();

  return foo.toFixed(); // Object is possibly 'undefined'.
}
```

**Expected behavior:**

In all three functions typescript would know `foo` is a number after the assertion.

**Actual behavior:**

In the last example, `testWithTruthyLiteral`, typescript complains `foo` may be `undefined`.  This is the same behavior for all known truthy values except for literal `true`.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->
https://www.typescriptlang.org/play?ts=4.2.0-dev.20201109#code/GYVwdgxgLglg9mABFApgZygRgBTDnAfgC5EwQBbAIxQCcBKRAbwChFEZhFsBCPOBqAAsacAO6kU4gKI0RNbHQDczVohoooIGkj4A6KHABiMAB4oAJguUBfFaEiwEydFABMufMVIVq9Jqo4uXnxEADJQ5BoQFAFhMQlpWTh5JRU2dU1tRD0DYzNLVNtme2h4JFQMAGYPQhIyKloGFjZAnj4wiIAiDBpO2JFxMElEGTkrNLUNLR18fSNTC3GiksdylwAWGq963yaAzjaQ8MRMfvihxLHU1Qzp7NnchYKbO3BSpwqoAFYtup9G-wtA7BOAdJjWM6DYajZLjG5TLI5eb5JbMIA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
https://github.com/microsoft/TypeScript/issues/29323 

It sounds like from https://github.com/microsoft/TypeScript/issues/29323#issuecomment-454548280 that determining truthiness of expressions could lead to circular dependencies between compiler passes, but that literal `true` has been special cased.  This should be able to be extended to truthy _literals_ without the circular dependency concern.  

And for context, like others that have brought up similar issues, this stems from wanting a truthy token that can be used for a minification hook without affecting the types or code execution.
Repository: excalidraw
Issue: Consider switching box-selection to select-by-partial-overlap
Labels: discussion,UX/UI

Currently, box-selecting only selects elements that are fully covered by the selection box.

The alternative is a selection model where elements are select if the box selection even just partially covers the elements:

![figma_box_select_partial](https://user-images.githubusercontent.com/5153846/98870227-49078280-2473-11eb-916f-0ada8f38ccd4.gif)

While this generally should have comparable advantages/disadvantages to the alternative, our behavior is not commonly used in the wild (although it's used here and there), and thus may not be intuitive.

I propose we consider switching to the alternative behavior to align with Figma and most other software.

Thoughts (or examples of apps that use each model) welcome.
Repository: go
Issue: x/tools/gopls: support features (diagnostics, etc.) for open files inside of vendor directories
Labels: FeatureRequest,gopls,Tools

There should be some kind of message maybe in the gopls (server) output stating that a message wasn't recorded to PROBLEMS because it is from a file inside a "vendor" folder. 

Also, maybe errors should be reported to PROBLEMS if you open code inside a folder which is a subfolder of vendor since you're probably developing in the vendored project itself.
Repository: kubernetes
Issue: HA multiple apiserver setups aren't rolling upgrade safe
Labels: kind/bug,sig/api-machinery,sig/cluster-lifecycle,lifecycle/frozen,triage/accepted

In clusters running multiple apiservers for HA, doing a rolling upgrade from 1.x.y to 1.x+1.y of apiservers one at a time, currently results in client-go clients failing due to api discovery errors. this breaks kubectl, kube-controller-manager control loops, any client using standard discovery apis.

This issue happens with almost every minor version upgrade where there were either new API resources added or old deprecated API resources removed in the x+1 release.

For example, while upgrading from v1.18 to v1.19,  v1.19 added `certificates.k8s.io/v1`, `events.k8s.io/v1` api resources .  In a HA cluster with 3 apiservers loadbalanced, once the first apiserver is upgraded from v1.18->v1.19,  The initial /apis discovery call returns these 2 new resources in the discovery document as soon as the first apiserver is upgraded. If the subsequent apis/certificates.k8s.io group discovery call lands on one of the 2 un-upgraded apiservers, they fail with
```
unable to retrieve the complete list of server APIs: certificates.k8s.io/v1: the server could not find the requested resource, events.k8s.io/v1: the server could not find the requested resource
```

**What you expected to happen**:
Safe rolling upgrade of HA apiservers without any request failures due to apis discovery related..

**How to reproduce it (as minimally and precisely as possible)**:
setup a cluster with more than one apiservers for HA, upgrade from v1.18 to v1.19, one apiserver at a time.  during the window when there are mixed apiserver versions running, all of the client-go calls routed to un-upgraded apiserver fails with above discovery errors.

**Anything else we need to know?**:
this discovery api issue is discussed in these KEPs, but not in the context of HA apiservers upgrade lifecycle:
https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/20190802-dynamic-coordinated-storage-version.md
https://github.com/kubernetes/enhancements/blob/master/keps/sig-api-machinery/35-storage-version-hash.md#ha-masters

**Environment**:
- Kubernetes version (use `kubectl version`): v1.19
- Cloud provider or hardware configuration:  baremetal
- OS (e.g: `cat /etc/os-release`): CentOS

/sig api-machinery
/sig cluster-lifecycle

cc @caesarxuchao  since we talked about this in kubernetes-users slack channel..
Repository: go
Issue: x/tools/gopls: go list error messages are too verbose/hard to interpret
Labels: gopls,Tools

This is an umbrella issue tracking our plans to parse and enhance the error messages from `go list`.

https://github.com/golang/go/issues/41462 and https://github.com/golang/go/issues/38383 reference a larger problem--some `go list` error messages are hard for users to understand and fix. They also often include the full arguments to the full `go list` invocation, which can often be confusing because they will include the workspace module or the `-modfile` flag.

We should try to parse and clean up the `go list` error messages as much as possible--and offer ways to fix the problem if possible.

/cc @jayconrod  @bcmills @matloob in case they have input
Repository: flutter
Issue: image_picker leaves unreferencable files in temp directory
Labels: platform-ios,p: image_picker,a: images,package,has reproducible steps,P3,found in release: 2.10,found in release: 2.13,team-ios,triaged-ios

On ios, image_picker is writing temporary results to [application_home]/tmp/ which can't be cleaned easily through any Flutter methods.  This is causing applications to bloat as they open images.

1.) image_picker should write any results to NSCachesDirectory() instead of NSTemporaryDirectory()
2.) image_picker should not leave behind any temporary results.  When I pick an image it keeps the original in [application_home]/tmp in addition to the resized one.  The original is a dead link which I cannot reference nor delete.