sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: const validation hides sibling validation errors
Labels: C-enhancement,A-diagnostics,T-compiler,A-const-eval

If a const validation finds an invalid part of a constant, it reports that one error and bails out, this means that

```rust
#![feature(const_transmute)]
static FOO: (&bool, &bool) = unsafe { std::mem::transmute((&42u8, &43u8)) };
```

gives us just

```
type validation failed: encountered 0x2b at .1.<deref>, but expected a boolean
```

While it would be trivial to change https://github.com/rust-lang/rust/blob/29630cea47506125fb0b94318104b1b93a59b052/src/librustc_mir/const_eval/eval_queries.rs#L192 to continue after errors, that would just give us more of these verbose diagnostics.

Furthermore

```rust
#![feature(const_transmute)]
static FOO: (&i32, &i32) = unsafe { std::mem::transmute((42usize, 43usize)) };
```

gives us just

```
type validation failed: encountered a dangling reference (created from integer) at .0
```

since we bail out early in https://github.com/rust-lang/rust/blob/29630cea47506125fb0b94318104b1b93a59b052/src/librustc_mir/interpret/visitor.rs#L188 we never see errors in the other fields.

Thinking about different ways to report better diagnostics, maybe we could report something as an inline-expansion similar to what we print when we print constants. I don't want to repeat the const printing infrastructure, we could just replace all valid fields with <VALID>, but still report errors inline:

```
type validation failed: (
    &<expected boolean, got 0x2a>,
    &<expected boolean, got 0x2b>,
)
```

So here's a complex example of how this could look like:

```
type validation failed: MyStruct {
    field_a: <VALID>,
    field_b: [
        TupleStruct(<expected boolean, got 0x3>),
        <VALID>,
        <VALID>,
    ],
    field_c: Enum::Variant {
         meh: <dangling reference (created from integer)>,
    },
}
```

I haven't deeply thought about implemenation details of such a scheme, but the `mir::interpret::visitor` can definitely be extended to stop returning `Result` in all functions, and instead have a custom `enum`:

```rust
enum ValidationResult {
    Valid,
    Invalid(Error),
    InvalidStruct {
         name: Symbol,
         fields: HashMap<FieldName, ValidationResult>,
    }
    InvalidTuple(Vec<ValidationResult>),
    // ... or something similar
}
```

cc @rust-lang/wg-const-eval @rust-lang/wg-diagnostics
Repository: pytorch
Issue: [JIT] Aliased Python references to script::Object escape IValue reference counting
Labels: oncall: jit,triaged

Test class: https://github.com/pytorch/pytorch/pull/38141

Test script:

```
import torch

class AliasTest(torch.nn.Module):
    def __init__(self):
        super().__init__()
        self.cpp = torch.classes._TorchScriptTesting._AliasTester([300, 400])
        self.alias = [self.cpp]

m = torch.jit.script(AliasTest())
torch.jit.save(m, 'test.zip')
```
After you run this script, looking at the zip archive indicates that the serialized tensor was written out redundantly:

```
$ unzip -v test.zip
Archive:  test.zip
 Length   Method    Size  Cmpr    Date    Time   CRC-32   Name
--------  ------  ------- ---- ---------- ----- --------  ----
       2  Stored        2   0% 00-00-1980 00:00 55679ed1  test/version
  *480000  Stored   480000   0% 00-00-1980 00:00 611fb420  test/data/0*
  *480000  Stored   480000   0% 00-00-1980 00:00 611fb420  test/data/1*
     456  Stored      456   0% 00-00-1980 00:00 937a9532  test/data.pkl
     203  Defl:N      120  41% 00-00-1980 00:00 1b463388  test/code/__torch__.py
      28  Stored       28   0% 00-00-1980 00:00 accc6c4e  test/code/__torch__.py.debug_pkl
       0  Stored        0   0% 00-00-1980 00:00 00000000  test/code/__torch__/torch/classes/_TorchScriptTesting.py
       6  Stored        6   0% 00-00-1980 00:00 816d0907  test/code/__torch__/torch/classes/_TorchScriptTesting.py.debug_pkl
       4  Stored        4   0% 00-00-1980 00:00 57092f6d  test/constants.pkl
--------          -------  ---                            -------
  960699           960616   0%                            9 files
```

This is because of the two references to the `script::Object` in the module. Since these references don't bump the use_count for the underlying IValue, the memoization check in the pickler fails: https://github.com/pytorch/pytorch/blob/ff9a809ccd5bd61f18dfaa04d41b681e600b3a02/torch/csrc/jit/serialization/pickler.cpp#L186

As we're serializing AliasTest, we write serialize the two references to self.cpp twice as we traverse the attributes.

Essentially, the fact that we have this indirection via `script::Object` on top of the IValue means we're missing references in a way that is usually benign. However, when used as an optimization in the pickler in this case, this is causing issues by making objects that would have been memoized get serialized redundantly

cc @suo
Repository: excalidraw
Issue: title tooltips are not discoverable enough
Labels: enhancement

Someone asked me what the lock icon did and after I explained they asked me to add a tooltip. We already have one implemented with `title` html attribute which is taking a second to show up.

We implemented a custom tooltip for the badge icon. We should think about using it for all the places where we use title.
Repository: pytorch
Issue: Python script name with "profile.py" will run twice
Labels: needs reproduction,triaged

## 🐛 Bug

Python script name with "profile.py" will run twice

## To Reproduce

1. (optional) Create an empty folder outside pytorch source code foder. 
2. Create a new file with name "profile.py".
3. Add following code to the file

```python
import torch
print(torch.__version__)
print("hello world")
```

4. Run with `python profile.py` 

## Expected behavior

Run once?

## Environment

This behavior exists when pytorch is compiled from source, ~~or installed with pip~~.

Update: it seems like this only affects pytorch built from source. 

## Additional context

@zasdfgbnm
Repository: flutter
Issue: [proposal] Make "value" required for "DropdownMenuItem"
Labels: c: new feature,framework,f: material design,c: proposal,P3,team-design,triaged-design

`DropdownButtonFormField` is not showing the value provided into `value` param.

Facing this on the latest Flutter version (`1.17.0`)

## Steps to Reproduce

1. Run `flutter create bug`.
2. Run the code bellow 
3. Try to select a item in the dropdown field...

**Expected results:** The selected value should be visible to the user

**Actual results:** The first value is displayed instead

## Code

```
class MyHomePage extends StatefulWidget {
  @override
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> {
  String _i;

  @override
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(title: Text('Página Inicial')),
      body: Column(
        children: <Widget>[
          DropdownButtonFormField<String>(
            value: _i,
            onChanged: (i) {
              setState(() {
                _i = i;
              });
            },
            items: List.generate(
              10,
              (index) => DropdownMenuItem(
                child: Text('$index'),
              ),
            ),
          )
        ],
      ),
    );
  }
}
```

</details>
Repository: pytorch
Issue: OneCycleLR  raises "Tried to step { step_num + 1 } times" after the value is more than expected.
Labels: triaged

I am not sure but maybe it is better to remove +1 in the print statement because it rises only when num_step is greater than total_steps,  therefore, debugging without +1 will be a bit clearer.

```
if step_num > self.total_steps:
            raise ValueError("Tried to step {} times. The specified number of total steps is {}"
                             .format(step_num + 1, self.total_steps))
```
Repository: flutter
Issue: IOSPlatformView: document that the [FlutterPlatformView view] should not return a new instance every time its called
Labels: platform-ios,framework,d: api docs,a: platform-views,P3,team-ios,triaged-ios

The `view` API is declared here:
https://github.com/flutter/engine/blob/master/shell/platform/darwin/ios/framework/Headers/FlutterPlatformViews.h#L22
After we implemented the unobstructed platform view. We need the embedded view to be cached. As a result, the platform view implementer must not create a new instance of the platform view every frame.
It was never a good practice anyway as it reduces performance. 
One example of good implementation of platform view would be:
```swift
class UIRectView: NSObject, FlutterPlatformView {
    let embedded_view: UIView

    init(_ frame: CGRect) {
        embedded_view = UIView(frame: frame)
        embedded_view.backgroundColor = UIColor.cyan
    }

    func view() -> UIView {
        return embedded_view
    }
}
```

A bad example would be:
```swift
class UIRectView: NSObject, FlutterPlatformView {
    func view() -> UIView {
        let embedded_view = UIView(frame: frame)
        embedded_view.backgroundColor = UIColor.cyan
        return embedded_view;
    }
}
```

We should document the same in the public API.
Repository: TypeScript
Issue: Decorator mixin intellisense working improperly
Labels: Needs Investigation

<!-- 🚨 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:**  3.8.3
<!-- Search terms you tried before logging this (so others can find this issue more easily) -->
**Search Terms:**
Intellisense
Decorator
Mixin
Interface

**Code**

```ts
// A *self-contained* demonstration of the problem follows...
// Test this by running `tsc` on the command-line, rather than through another build tool such as Gulp, Webpack, etc.

class AccountSchema {
// Implementation
}

abstract class AccountLoginSchema {
username: string;
password: string;
getTokenID() {
  // Implementation
}
}

interface CustomerSchema extends AccountLoginSchema {}
@Mixin(AccountLoginSchema) class CustomerSchema extends AccountSchema {
  constructor() {
    super();
    // Intellisense showing up
    this.getTokenID();
  }

// Intellisense not showing up
 getToken

}
```

**Expected behavior:**

1) Invoking method, 2) accessing property, 3) redefining method implementation should display intellisense. 

**Actual behavior:**
1 and 2 works, however 3 doesn't display intellisense properly.

**Playground Link:** <!-- A link to a TypeScript Playground "Share" link which demonstrates this behavior -->

https://www.typescriptlang.org/play?ssl=25&ssc=68&pln=25&pc=8#code/MYGwhgzhAECCzAPYFcB2AXAysAFgUwFsxoBvAKGkugHproBJAgBxELwzHQEtFUyBfMmVrQAKgE8meAOaJEEPNAi5CxCImhdpqRACdFyBbtRgCisKgAm0JpAgB3PdZ3poAIzxdU0zc1ZmMPGsvaCRUCHRdZGB0PTIwNwjdMBjQ8Cg4BBQMABlEaS9sfCJSCioRAAEmXUQmAAoSfQBHZC59SwAuaEjkPH4ASjLKJmQ3EC5gaEM8Y1M8LqSvaQBuIZtR8cnbKEddTqVIpdWqaGk8dFFEAGt2egAROv6Fw+9Sk5ORRhY2Dm5eNZO+nQyGM0AARGDjlRBIIyF50DMAGYpRQAYUMsTMuiKqmgeAAHgirDB4Eg0Og8gVUDiSiRBCJYFBkGZujhOKzFMAMYgsUoVCU2TBiAQuPiQpY8EhkrFdGRQHZoOiIjyZjTiASiZYSVlyWq3lQwklojLHvr3kpkFJdI8oeb0DguBAAHTTWYsgC84LATG+kIBVHtjqdZwu11ud2gntN7oAfODAzBdlcIH6TrCPnR6IEQOMFOFFPh9NBLIg8BBUAByVxJ6D2fCoTSuCA4FAgawQLzARRcat6ZNrEQh0QCMhAA

**Related Issues:** <!-- Did you find other bugs that looked similar? -->
Repository: pytorch
Issue: valgrind says libtorch has memory leak
Labels: module: memory usage,triaged

linux c++ app with libtorch
valgrind report that at::native::mm_cpu_out in libtorch_cpu.so cause "possibly loss" in memory leak checking.
Repository: PowerToys
Issue: [KBM] Visualizer and Tester
Labels: Idea-Enhancement,Product-Keyboard Shortcut Manager,Area-User Interface

# Summary of the new feature/enhancement

<!-- 
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).
-->
A keyboard manager can't be "perfect" and "complete" without an actual visualization for the new remapped keyboard. With a fluent UI it would be cool to have something which would show you how your keyboard layout looks like after remappings keys, and even better something where you can press your keys and see animation like the On-Screen Keyboard.
![image](https://user-images.githubusercontent.com/32061677/81461906-cc15ec00-9163-11ea-979f-5292315ac3d8.png)
If you swapped your Win and Ctrl keys, the keyboard visualizer extension would appear like that, and whenever you click your keys that would highlight. The same could be done for remapping shortcuts, so users can see exactly what happens when they remap their keys and shortcuts. Having a visualization makes it much easier for users to remember and understand their mappings as well as they could have the opportunity to use a tool which swallows all keyboard input to test out their new remappings.

This could start out as an English keyboard feature since it might be hard to handle all languages. It is a known thing that even for english keyboards, the layout varies a bit from keyboard to keyboard. To solve that we could have a default layout and the users can move the keys around to make it appear like their physical keyboard pre-remap.

# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
Everything mentioned above is technically possible, it just mostly needs UI development. For just having a tool which swallows all your input we already have the Type Key interface on KBM, so the backend will be exactly the same as that, except instead of displaying the key name, we would highlight the key on the keyboard (at the end of the day everything is just key codes internally).
For the UI to support keyboard with different layouts we would need to have draggable blocks which would be keys, and they would start in a default keyboard layout. The user would then be able to move the keys around to look more like there own keyboard (sort of reminiscent of the FancyZones editor). 
For highlighting the key and showing the remapped versions of keyboard the above layout doesnt really matter since we deal with key codes at the end of the day. It just makes the visualization for the user better and improves the user experience a ton.
Repository: PowerToys
Issue: Teaching Tips in PowerToys
Labels: Idea-Enhancement,Area-User Interface,Area-OOBE

# Summary of the new feature/enhancement

<!-- 
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).
-->
PowerToys has many tools which have complicated terminology or certain "not-straightforward" concepts. Most of these things can become clear to the user by taking a look at the Readme, but going to the current "Module overview" link isn't the first thing a user would do if they get frustrated with some terminology or understanding how to use the tool. They might just uninstall instead. 
Inspired by the fact that KBM has complicated terminology and users need to know what are valid shortcuts and things like that, having warnings is not enough, and certain things will have to be clarified using the Readme. With the migration to Fluent UI, what if instead of expecting the users to go to the readme when they are facing issues we use WinUI teaching tips instead by detecting when users are stuck on something. The teaching tip could either just provide more information, or an easier more noticeable solution would be to redirect the user to the readme.

Imagine the text in the teaching tip in the image below as "_Confused with the terminology? Check out the documentation to clear things up._" which would link to the Readme.
![image](https://user-images.githubusercontent.com/32061677/81462222-c9b49180-9165-11ea-82cb-b2629319b2d2.png)
This idea actually reminds me a lot of PaperClip. It could also have some buttons for Dismiss, or Never Show Again so that a well versed user doesn't need to deal with annoying pop ups.


# Proposed technical implementation details (optional)

<!-- 
A clear and concise description of what you want to happen.
-->
For Keyboard Manager a scenario that can be implemented easily would be that a user tries remapping shortcuts and encounters say "10" warnings or they have stayed on the window for X minutes without getting a successful remap, we can show a little teaching tip on the side which would redirect the user to the readme. Teaching tips as shown in the screenshot earlier are a WinUI feature which means implementation should be straight forward too.
Repository: flutter
Issue: Reusing the same type of items in the sliver can bring better performance
Labels: c: new feature,framework,f: material design,f: scrolling,c: proposal,perf: speed,P3,team-design,triaged-design

## Use case

&nbsp;&nbsp;&nbsp;&nbsp;Our app uses the flutter list component sliver to display the results on the search results page. The feature of this page is an infinitely long list. There are a total of 5 kinds of cards, and one of them will appear in a large number, with a probability of about 80%.  
    
&nbsp;&nbsp;&nbsp;&nbsp;This means that when the user swipes down, the newly appeared card is likely to be the same kind of card that has appeared before. The tree structure of the nodes of the same card is generally consistent except that individual leaf nodes may be inconsistent.  

&nbsp;&nbsp;&nbsp;&nbsp;We noticed that in sliver, there is a layer of origin cache mechanism "keepAlive", but the problem with keepAlive is that it does not reuse the card created for the first time, only the card that slides out for the second time can be reused . And the key it uses is "index", which makes it impossible to reuse cards of the same type but in different positions.
    
&nbsp;&nbsp;&nbsp;&nbsp;In the case that the card does not meet the keepAlive, the sliver container will remove the slide-out card and re-create the slide-in card. Among them, we have not found any other effective caching mechanism to cached and reuse cards with same type( which means they have basically the same tree structure). Each time dettach and create will bring additional overhead.

## Proposal

&nbsp;&nbsp;&nbsp;&nbsp;We try to add a layer of cache before the updateChild method is called in the removeChild and createChild methods of sliver. In removeChild, we will put the removed Element into the cache with the card type as the key, and when createChild, we first go to the cache to look for the cached Element whose key is the same card type, and then updateChild is called. Because the tree structure of the same card is basically the same, so it is highly likely that child.update will be called at the end without going to infalte to recreate a new one.



&nbsp;&nbsp;&nbsp;&nbsp;The schematic is shown below

![image](https://user-images.githubusercontent.com/8213373/81463979-9e2ab900-91f0-11ea-968f-b76e1963b274.png)



&nbsp;&nbsp;&nbsp;&nbsp;And we conducted automated tests on both before and after optimization on the local model (HUAWEI P9), and the results are as follows:

![优化效果](https://user-images.githubusercontent.com/8213373/81464466-a127a880-91f4-11ea-9cf9-59cac716d0f3.png)
Repository: pytorch
Issue: Feature Request: Log uniform candidate sampler
Labels: feature,module: nn,triaged

Analogous to TensorFlow's https://www.tensorflow.org/api_docs/cc/class/tensorflow/ops/log-uniform-candidate-sampler. 

This was first proposed in https://github.com/pytorch/pytorch/issues/3718.

cc @albanD @mruberry
Repository: pytorch
Issue: Feature Request: Sampled softmax loss
Labels: feature,module: nn,module: loss,triaged

Analogous to TensorFlow's https://www.tensorflow.org/api_docs/python/tf/nn/sampled_softmax_loss. 

This was first proposed in #3718.

cc @albanD @mruberry @jbschlosser
Repository: vscode
Issue: Quick fix from hover interaction issues
Labels: bug,help wanted,polish,editor-code-actions,editor-hover

Steps to Reproduce:

1. hover over a problem
2. click on Quick fix link

=> 🐛 menu appears somewhere?
=> hover closes?

I would either expect the hover to stay and the menu to appear right below, or at least that the menu appears below the problem.

![cap](https://user-images.githubusercontent.com/900690/81466215-074e0480-91d0-11ea-83fb-b9341e8f0d28.gif)
Repository: flutter
Issue: Android Instant App Support
Labels: c: new feature,platform-android,framework,engine,c: performance,a: size,perf: app size,a: release,P3,team-android,triaged-android

I reviewed the previous discussion [here](https://github.com/flutter/flutter/issues/16833#issuecomment-447151309), but it seems that Instant App is not supported, and the APK growing up again.

## Steps to Reproduce

1. create new flutter app.
1. build a release appbundle.
1. generate the apks file from the appbundle.
1. run the ia checker on the generated apks file.

## Logs

```
WARNING - Combined size of an APK and its dependent APKs is larger than 4
    megabytes

    The following group of APKs has a combined size of 5976.3 KB:
    base-master.apk (635.7 KB) + base-tvdpi.apk (12.2 KB) + base-x86_64.apk
    (5328.4 KB)
    
    If you are not publishing as a game, there is a 4 MB size limit to enable
    additional discovery surfaces beyond Try Now. You may also need to enroll in
    the 10 MB app beta program before releasing to the production track.
```

When I tried to analyze the APK, t seems like `libflutter.so` and `libapp.so` alone will exceed the 4 MB limit alone without any extra assets.

<img width="768" alt="Screen Shot 2020-05-09 at 09 57 16" src="https://user-images.githubusercontent.com/9499808/81466576-7aa94380-91db-11ea-9d8b-2868139b18c1.png">

Is there any possibility to reduce the size -even if it will disable some features- or we need to wait from the Play Store team until they make the 10 MB limit available for public?
Repository: pytorch
Issue: test_interpolate_nearest_scale_3d in test_nn takes too long to run
Labels: module: tests,triaged

It's timing out on an internal test runner. Maybe there's a way we can keep the test effective but speed it up? 

cc @mruberry
Repository: pytorch
Issue: test_LocalResponseNorm_3d_custom_params (test_nn.TestNN) takes too long to run
Labels: module: tests,triaged

This test is timing out in one of our internal test runners.

cc @mruberry
Repository: pytorch
Issue: test_ReplicationPad3d (test_nn.TestNN) takes too long to run
Labels: module: tests,triaged

This test is timing out in one of our internal test runners.

cc @mruberry