sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: LLVM cannot prove that index is in bounds
Labels: A-LLVM,I-slow,T-compiler,C-bug

**Current status**: Waiting for llvm/llvm-project#90417

When trying to get rid of `unsafe` code in commit 57d25179e6751854c298313070adc4ac4454e230 in #81427.
I found a case that GCC can prove that the slice index in bound but LLVM cannot.

I tried this code (see generated assembly at godbolt <https://godbolt.org/z/dTraGe>):

```rust
pub fn eat_digits<const N: usize>(s: &[u8; N]) -> bool {
    let mut i = 0;
    while i < N {
        let c = s[i];
        if b'0' <= c && c <= b'9' {
            i += 1;
        } else {
            break;
        }
    }
    i <= N
}

pub fn foo(s: &[u8; 1234]) -> bool {
    eat_digits(s)
}
```

I expected to see this happen: Compiler optimizes `eat_digits` to only `true`.

Instead, this happened: LLVM cannot prove that, which leads to bounds check with `s[..i]`.

Note that for the C version (more or less), gcc can optimize the code to `ret true`:

```c
#include <stdint.h>
#include <stddef.h>
#include <stdbool.h>

#define N 1234

bool eat_digits(uint8_t s[N]) {
    size_t i = 0;
    while (i < N) {
        uint8_t c = s[i];
        if ('0' <= c && c <= '9') {
            i += 1;
        } else {
            break;
        }
    }
    return i <= N;
}
```

### Meta

`rustc --version --verbose`:
```
rustc 1.51.0-nightly (d1aed50ab 2021-01-26)
binary: rustc
commit-hash: d1aed50ab81df3140977c610c5a7d00f36dc519f
commit-date: 2021-01-26
host: x86_64-unknown-linux-gnu
release: 1.51.0-nightly
LLVM version: 11.0.1
Compiler returned: 0
```

@rustbot label  A-LLVM I-slow T-compiler
Repository: PowerToys
Issue: [Color Picker] Add  RAL color standard
Labels: Idea-Enhancement,Help Wanted,Product-Color Picker

Hi.
As an architect, I use the RAL color standard often. RAL standard is very common and popular in my field of work. Is it possible to add this color format to Power toy's Color Picker?

[RAL Color Standard] (https://en.wikipedia.org/wiki/RAL_colour_standard)
Repository: PowerToys
Issue: [Run] Website appends forwardslash
Labels: Idea-Enhancement,Help Wanted,Product-PowerToys Run

## ℹ Computer information

- PowerToys version: v0.29.3
- PowerToy Utility: PowerToys Run
- Running PowerToys as Admin: Yes
- Windows build number: 19631.1

## 📝 Provide detailed reproduction steps (if any)

1. Open PowerToys Run
2. Type "YouTube" for example without quotation marks
3. Hit enter

### ✔️ Expected result

The expected result would be to either go to youtube.com or to just have "youtube" in the bar on top

### ❌ Actual result

The actual result is that you end up going to youtube/

## 📷 Screenshots
![image](https://user-images.githubusercontent.com/49172424/105996353-7e9f2d80-60aa-11eb-992e-da815ae4a700.png)
![image](https://user-images.githubusercontent.com/49172424/105996338-78a94c80-60aa-11eb-9bc7-b5bdb3788d7a.png)
Repository: pytorch
Issue: Complex->Real cast is a warning, calling `real` or `imag` on non-complex tensors is an Error.
Labels: triaged,module: complex,module: ux

As per title.

I would expect exactly the opposite behavior, that is:
Casting complex tensors to real ones is an error. And if this cast is necessary, then it makes sense to call it on either real or imaginary part.
I see no issues with calling `real` or `imag` on real tensors as these operations are well-defined.

Current behavior:
```python
In [1]: import torch
x
In [2]: x = torch.rand(3, 3, dtype=torch.cdouble).long()
/home/nik/.conda/envs/pytorch-cuda-dev/bin/ipython:1: UserWarning: Casting complex values to real discards the imaginary part (Triggered internally at  ../aten/src/ATen/native/Copy.cpp:219.)
  #!/home/nik/.conda/envs/pytorch-cuda-dev/bin/python

In [3]: x = torch.rand(3, 3)

In [4]: x.imag
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-4-f2d086c634a9> in <module>
----> 1 x.imag

RuntimeError: imag is not implemented for tensors with non-complex dtypes.

In [5]: x.real
---------------------------------------------------------------------------
RuntimeError                              Traceback (most recent call last)
<ipython-input-5-afe486272bd1> in <module>
----> 1 x.real

RuntimeError: real is not implemented for tensors with non-complex dtypes.

```

cc @ezyang @anjali411 @dylanbespalko @mruberry
Repository: ant-design
Issue: Table gets overflow scroll instead of auto when scroll is set
Labels: Inactive

- [ ] I have searched the [issues](https://github.com/ant-design/ant-design/issues) of this repository and believe that this is not a duplicate.

### Reproduction link
[![Edit on CodeSandbox](https://codesandbox.io/static/img/play-codesandbox.svg)](https://codesandbox.io/s/fixed-header-antd4112-forked-qg2x7)

### Steps to reproduce
Look at the table, it has a gray scrollbar-holder even though it's not tall enough to scroll.

### What is expected?
It should have `overflow-y: auto` instead of `overflow-y: scroll` since auto allows scrolling when max-height is reached, while `scroll` always 

### What is actually happening?
It gets `overflow-y: scroll`, leading to a gray bar at all times.

| Environment | Info |
|---|---|
| antd | 4.6.4 |
| React | 16.13.1 |
| System | N/A |
| Browser | Chrome 88 |


<!-- generated by ant-design-issue-helper. DO NOT REMOVE -->
Repository: create-react-app
Issue: CRA UI
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

No.

### Describe the solution you'd like

Like vue cli you can a script "vue ui" to preview you projects in web and add plugins or npm package like react-electron and other npm packages. This will be very helpful for the react developer to add stuff or feather in interactive web UI. Well This will take the CRA to next level :heart: :heart: :+1:   

### Describe alternatives you've considered

NO alternatives

### Additional context

Here is vue ui web screenshot

![vueUI](https://user-images.githubusercontent.com/66471461/106014583-9e9f1300-60e3-11eb-9db3-1f448cd5746b.png)
Repository: rust
Issue: Large BTreeMap key or value types cause avoidable stack overflow
Labels: C-enhancement,A-collections,T-libs

I tried this code:

```rust
use std::collections::BTreeSet;

fn main() {
    let mut s = BTreeSet::new();
    s.insert([0u8; 19580]);
}
```

built with plain `rustc` on 64 bit Windows (it happens in release code too but not with this example).
I expected to see the program finishing silently.

Instead, this happened:
```
thread 'main' has overflowed its stack
fatal runtime error: stack overflow
Aborted
```

This becomes sporadic if you decrease the size of the key and disappears below 19540 bytes (on my system).

On my Linux box, and [on playground](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=d5497059a73d991be85bd8fd1230b472), the size can be increased to somewhere between 160_000 and 170_000 bytes before the stack overflows.

`rustc --version --verbose`:
```
rustc 1.51.0-nightly (d1aed50ab 2021-01-26)
binary: rustc
commit-hash: d1aed50ab81df3140977c610c5a7d00f36dc519f
commit-date: 2021-01-26
host: x86_64-unknown-linux-gnu
release: 1.51.0-nightly
LLVM version: 11.0.1
```

This is not necessarily a bug, since there has to be some system-dependent limit. And it's not smart to inline big chunks of data as key or value, because usually about half of the key-value space allocated by BTreeMap remains unused. But the limit on Windows is much lower than I expected (and before #81494 can apparently easily be ~~lifted~~ improved by using `box` instead of `Box::new` for the construction of btree nodes).
Repository: create-react-app
Issue: JSON files cannot be imported in a TS project when using yarn v2 (berry)
Labels: stale,needs triage,issue: bug report

### Describe the bug

This issue was described in #9172, but is still present in v4 (and indeed v4.0.1) so I am recreating the issue as instructed

### Did you try recovering your dependencies?

Yes

### Environment

create-react-app: 4.0.1

### Steps to reproduce

See #9172

### Expected behavior

See #9172

### Actual behavior

See #9172

### Reproducible demo

See #9172
Repository: terminal
Issue: Saving/restoring character attributes (and DECSCNM)?
Labels: Product-Conhost,Area-Output,Issue-Bug,Priority-3,Impact-Visual

Microsoft Windows 10 Pro for Workstations
10.0.19042.746 (2009, 20H2)
WindowsTerminalPreview_1.5.3242.0_x64

I have a VBEEP command (visual beep, plugin for TCC.EXE from JPSoft).  It saves the character attributes in the viewport like this.

```
dwSize = con.csbi.dwSize.X * con.csbi.dwSize.Y;	// terminal viewport
ReadConsoleOutputAttribute(con.h, attrs_original, dwSize, {0,0}, &dwRead); // get current attributes
```

Then it momentarily changes all attributes to the reverse of the default, like this.

```
attrs_reversed = ((con.csbi.wAttributes & 0x00F0) >> 4) | ((con.csbi.wAttributes & 0x000F) << 4);
FillConsoleOutputAttribute(con.h, attrs_reversed, dwSize, {0,0}, &dwWritten);
```

Then it restores the original attributes, like this.

`WriteConsoleOutputAttribute(con.h, attrs_original, dwSize, {0,0}, &dwWritten);	// back to original attributes`

But, as I hope can be seen below, After executing VBEEP, the attributes of previously displayed text seem to have changed.  Check out the display of the previous "echos ..." commands before/after the "vbeep" command; lines that were half yellow before the vbeep, are all yellow afterward.

https://user-images.githubusercontent.com/61856645/106033613-eef48180-609f-11eb-95d6-b508c3c01e62.mp4
Repository: TypeScript
Issue: Inferred type is not the same as what's passed in original generic type.
Labels: Bug,Help Wanted,Effort: Difficult

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms
infer, generic
<!--
  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.
-->

### 🕗 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 a crash
- This changed between versions _________ and _________
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about infer.
- I was unable to test this on prior versions because _______

### ⏯ Playground Link
https://www.typescriptlang.org/play?ts=4.1.3#code/C4TwDgpgBACgTgezAYQQOwM7DgVwMbAJwA8AKlALxQCGaIAfJQFBRQA+UA3lGhAO5QAFADpR1OAHMMALhp0A2gF0AlLPIAyKAgBGAKwgEoAXxbsuQ1VHImmoSFACyIAJJoAZhBKlGVchAAewBBoACYYsIgo6Fi4BETEAJbunlAAaowA-GlQsgDk-gW5TLbg0KnllEKCypSMMUkSNRyC1bU8OAC22p7KxXbQABqVTq4eJPBIqJjY+IQk5en0TEA
<!--
  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/PTAEFkE9QYwewCYFNQHM5IM6gBZIE5JA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->

```ts
// The variable names are meaningless, they are simplified from vue project.
type PropConstructor<T = any> =
  | { new (...args: any[]): T & object }
  | { (): T }

type MyInfer<T> = T extends PropConstructor<infer V> ? V : 'xxx'

type VVV = (() => string) | (() => number)

type X = MyInfer<PropConstructor<VVV>>

```


### 🙁 Actual behavior
```
type X = (() => string) | (() => number) | ((() => string) & object) | ((() => number) & object)
```

<!-- What happened, and why it was wrong -->

### 🙂 Expected behavior
```
type X = (() => string) | (() => number))
```

<!-- What you expected to happen instead, and why -->
Repository: rust
Issue: Incorrect private field diagnostic when `self` is passed
Labels: T-compiler,C-bug,A-suggestion-diagnostics,D-invalid-suggestion

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code ([playground link](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=74b6cc513cc3e8e131b1b31805d0240e)):

```rust
mod some_module {
    pub struct Test<T: ?Sized>(T);
}

use some_module::Test;

struct TestBuilder;

impl TestBuilder {
    fn build(self) -> Test {
        Test(self)
    }
}
```

I expected to receive the "cannot initialize a tuple struct which contains private fields" lint.

Instead, this happened:

```
error[E0423]: expected function, tuple struct or tuple variant, found struct `Test`
  --> src/lib.rs:11:9
   |
11 |         Test(self)
   |         ^^^^------
   |         |
   |         help: try calling `Test` as a method: `self.Test()`
```

it appears the "method on self" lint takes priority over the "private field initialization" lint when it likely shouldn't, at least in this scenario.

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`:
```
rustc 1.50.0-nightly (d9a105fdd 2020-11-23)
binary: rustc
commit-hash: d9a105fdd46c926ae606777a46dd90e5b838f92f
commit-date: 2020-11-23
host: x86_64-unknown-linux-gnu
release: 1.50.0-nightly
```

(also happens on stable, see the playground link provided)

</p>
</details>


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: pytorch
Issue: `torch.cuda.device` should look like it is inherited from `torch.device`
Labels: module: cuda,triaged,enhancement



cc @ngimel
Repository: flutter
Issue: Make DartEntrypoint only optionally take a bundle path
Labels: c: new feature,platform-android,engine,a: existing-apps,P3,team-android,triaged-android

[pathToBundle](https://cs.opensource.google/flutter/engine/+/master:shell/platform/android/io/flutter/embedding/engine/dart/DartExecutor.java;l=282;drc=915e2ca178e5b957933377800b291ff144e99f05) is a required construction parameter and is not a very useful customization since most people don't know what it is or want to change it. Let it be optional and pick it up from the FlutterInjector by default.
Repository: vue
Issue: Checking whether v-on handler is a function invocation is broken
Labels: improvement,feat:compiler

### Version
2.6.11

### Reproduction link
[https://jsfiddle.net/adamsol/pknr8dae/](https://jsfiddle.net/adamsol/pknr8dae/)







### Steps to reproduce
Click the buttons.

### What is expected?
All the buttons should behave in the same way: a message should appear below.

### What is actually happening?
Only the first button works correctly.

---
See #11893 for the origin of the issue.

The problem lies probably here: https://github.com/vuejs/vue/blob/5255841aaff441d275122b4abfb099b881de7cb5/packages/vue-template-compiler/build.js#L3801

The regexes used do not take into account cases such as additional spaces, parentheses, or chained function invocations. As a result, a promise is correctly returned only in the first case in the repro, and in all the other cases `errorHandler` won't capture the exception thrown in the async method.

The difference in the generated code (`return` is present only in the first case): https://template-explorer.vuejs.org/#%3Cdiv%20id%3D%22app%22%3E%0A%20%20%3Cbutton%20%40click%3D%22click(1)%22%3E%0A%20%20%20%20click(1)%0A%20%20%3C%2Fbutton%3E%0A%20%20%3Cbutton%20%40click%3D%22click%20(2)%22%3E%0A%20%20%20%20click%20(2)%0A%20%20%3C%2Fbutton%3E%0A%20%20%3Cbutton%20%40click%3D%22click((3))%22%3E%0A%20%20%20%20click((3))%0A%20%20%3C%2Fbutton%3E%0A%20%20%3Cbutton%20%40click%3D%22(click(4))%22%3E%0A%20%20%20%20(click(4))%0A%20%20%3C%2Fbutton%3E%0A%20%20%3Cbutton%20%40click%3D%22click(5).then()%22%3E%0A%20%20%20%20click(5).then()%0A%20%20%3C%2Fbutton%3E%0A%3C%2Fdiv%3E

Suggested solution: either add `return` in every case, or don't add it at all, so that the behaviour is consistent. If checking for the function invocation is crucial, then the code must be parsed in some other way.

<!-- generated by vue-issues. DO NOT REMOVE -->
Repository: pytorch
Issue: std::type_index doesn't provide reliable equality for getCustomClassTypeMap
Labels: module: internals,triaged

## 🐛 Bug

[getCustomClassTypeMap](https://github.com/pytorch/pytorch/blob/master/aten/src/ATen/core/ivalue.h#L1105), uses std::type_index as the lookup key. Although, in the presence of shared libraries it is not guaranteed that std::type_index produces same results for the same type. Some resources that explain this in more detail: 1) https://cpptruths.blogspot.com/2018/11/non-colliding-efficient.html, 2) https://www.reddit.com/r/cpp_questions/comments/6u9w08/does_stdtype_index_work_reliably_across_shared/, 3) https://bugs.llvm.org/show_bug.cgi?id=33542

For example, on my local machine I see the following: https://gist.github.com/pritamdamania87/dcbc681a2bbfaeaa16694d3b7220ea11.

The paste above shows that during insertion and lookup the type name is same, however during insertion the hash_code is 4789144592, whereas during lookup the hash_code is 4615135440.

## To Reproduce

Steps to reproduce the behavior:

1. Failing test: https://github.com/pytorch/pytorch/issues/50842.
2. Was able to reproduce the failing test above locally on my mac.

## Expected behavior

We should provide a consistent and reliable way of determining type equality.

## Environment

Collecting environment information...
PyTorch version: 1.7.0a0+9dc2bcd
Is debug build: True
CUDA used to build PyTorch: None
ROCM used to build PyTorch: N/A

OS: macOS 10.15.7 (x86_64)
GCC version: Could not collect
Clang version: 11.0.0 (clang-1100.0.33.12)
CMake version: version 3.18.2

Python version: 3.6 (64-bit runtime)
Is CUDA available: False
CUDA runtime version: No CUDA
GPU models and configuration: No CUDA
Nvidia driver version: No CUDA
cuDNN version: No CUDA
HIP runtime version: N/A
MIOpen runtime version: N/A

Versions of relevant libraries:
[pip3] numpy==1.19.1
[pip3] torch==1.8.0a0+unknown
[conda] mkl                       2020.2                      260  
[conda] mkl-include               2020.2                      260  
[conda] numpy                     1.19.1           py36ha6d8c68_0  
[conda] numpy-base                1.19.1           py36h68fea81_0  
[conda] torch                     1.8.0a0+unknown          pypi_0    pypi


cc @ezyang @bhosmer @smessmer @ljk53 @bdhirsh @ailzhang
Repository: vscode
Issue: Support minimap for native notebooks
Labels: feature-request,notebook


Issue Type: <b>Bug</b>

open a notebook and select "toggle minimap" from command menu

VS Code version: Code - Insiders 1.53.0-insider (7b0cfdd04ad530a9c8d782c618afd79290be3d64, 2021-01-27T08:59:32.031Z)
OS version: Windows_NT x64 10.0.19042

<details>
<summary>System Info</summary>

|Item|Value|
|---|---|
|CPUs|Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz (12 x 3192)|
|GPU Status|2d_canvas: enabled<br>gpu_compositing: enabled<br>multiple_raster_threads: enabled_on<br>oop_rasterization: enabled<br>opengl: enabled_on<br>protected_video_decode: unavailable_off<br>rasterization: enabled<br>skia_renderer: enabled_on<br>video_decode: enabled<br>vulkan: disabled_off<br>webgl: enabled<br>webgl2: enabled|
|Load (avg)|undefined|
|Memory (System)|31.81GB (20.86GB free)|
|Process Argv|--crash-reporter-id 3e39eadc-8160-42f8-bd96-0e1478ce2612|
|Screen Reader|no|
|VM|0%|
</details><details><summary>Extensions (14)</summary>

Extension|Author (truncated)|Version
---|---|---
vscode-markdownlint|Dav|0.38.0
vscode-open-in-application|fab|1.0.5
vscode-settings-cycler|hoo|1.0.1
gather|ms-|2021.1.0
python|ms-|2021.2.513962232-dev
vscode-pylance|ms-|2021.1.2
jupyter|ms-|2020.12.414227025
remote-wsl|ms-|0.53.2
vsliveshare|ms-|1.0.3577
copy-gather-paste|Ser|1.0.9
code-spell-checker|str|1.10.2
html-preview-vscode|tht|0.2.5
vscodeintellicode|Vis|1.2.10
vscode-icons|vsc|11.1.0


</details><details>
<summary>A/B Experiments</summary>

```
vsliv695:30137379
vsins829:30139715
vsliv368cf:30146710
vsreu685:30147344
openlogontheside:30221882
python383cf:30185419
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30208930
wsl2prompt:30219162
vstry914:30244316
pythonvsdeb440:30224570
unusedprompt:30219164
folderexplorer:30219166
openfilemenucf:30219169
pythonvsded773:30223139
pythonvspyt600:30247031
core-portspanel:30233467
coreuntitledfile:30249963

```

</details>

<!-- generated by issue reporter -->We have written the needed data into your clipboard because it was too large to send. Please paste.