sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: if ... as T < ... && ... >= ... is treated as const generics
Labels: A-diagnostics,A-parser,T-compiler,D-confusing,D-terse

I'm not sure if it is expected behavior or not.

I tried this code:

```rust
fn main() {
    if 1 as f64 < 0.0 && 1 >= 0 {
        
    }
}
```

I expected to see this happen: the code compiles without errors

Instead, this happened:
```
Compiling playground v0.0.1 (/playground)
error: expressions must be enclosed in braces to be used as const generic arguments
 --> src/main.rs:3:19
  |
3 |     if 1 as f64 < 0.0 && 1 >= 0 {
  |                   ^^^^^^^^
  |
help: enclose the `const` expression in braces
  |
3 |     if 1 as f64 < { 0.0 && 1 } >= 0 {
  |                   +          +

error[E0109]: const arguments are not allowed for this type
 --> src/main.rs:3:19
  |
3 |     if 1 as f64 < 0.0 && 1 >= 0 {
  |                   ^^^^^^^^ const argument not allowed

error[E0308]: mismatched types
 --> src/main.rs:3:8
  |
3 |     if 1 as f64 < 0.0 && 1 >= 0 {
  |        ^^^^^^^^^^^^^^^^^^^^^^^^ expected `bool`, found `()`
  |
help: you might have meant to use pattern matching
  |
3 |     if let 1 as f64 < 0.0 && 1 >= 0 {
  |        +++

error[E0308]: mismatched types
 --> src/main.rs:3:19
  |
3 |     if 1 as f64 < 0.0 && 1 >= 0 {
  |                   ^^^ expected `bool`, found floating-point number

error[E0308]: mismatched types
 --> src/main.rs:3:26
  |
3 |     if 1 as f64 < 0.0 && 1 >= 0 {
  |                          ^ expected `bool`, found integer

Some errors have detailed explanations: E0109, E0308.
For more information about an error, try `rustc --explain E0109`.
error: could not compile `playground` due to 5 previous errors
```

rustc 1.54.0 stable.

If I change to (1 as f64) < 0.0 && 1 >= 0 it compiles.

Link to playground: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=48dbdf8fc80dde053da67f6b3db3d143
Repository: vscode
Issue: Self-signed certificate error when installing Python support in WSL in spite of custom root certificate correctly installed in WSL
Labels: bug,proxy

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes/No

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.59.1
- OS Version: Windows 10.0.19042, WSL  5.10.16.3-microsoft-standard-WSL2
- Python Language extension : v2021.8.1159798656

My company uses an SSL inspection on company devices and provides a custom root CA certificate. In Windows, this is already pre-installed in the system certificate store and VS Code works fine in Windows where there are no problems installing & using Python language support. For WSL, the certificates & a process to install them in the system certificate store are provided (below) However, when trying to setup Python Language support in WSL I get a self-signed certificate error in spite of following the process to install the custom root certificates in WSL.

Steps to Reproduce:
1. Copy custom certificates to WSL CA-Certificates folder
```
sudo cp *.crt /usr/local/share/ca-certificates/
```
2. Install 
```
sudo update-ca-certificates
```
3. Launch VS Code and connect to WSL project
4. Try to install Python support in WSL
5. Get error - `self signed certificate in certificate chain`
Repository: go
Issue: cmd/go: avoid using the term "work space" to refer to a GOPATH in documentation
Labels: Documentation,help wanted,NeedsFix



<!--
Please answer these questions before submitting your issue. Thanks!
-->
 
### What is the URL of the page with the issue?
 
 https://pkg.go.dev/cmd/go#hdr-Import_path_syntax
 
### What is your user agent?
 
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.159 Safari/537.36

 
 
 
### Screenshot
 
![pkg go dev-cmd-go-work-space](https://user-images.githubusercontent.com/29250114/131214742-ac27c482-beb5-419c-ad8a-ef2da5d9b57d.png)

 
 
### What did you do?
 
Read the page and tried to understand it.
 
The page says: 

> An import path (see 'go help packages') denotes a package stored in the local file system. In general, an import path denotes either a standard package (such as "unicode/utf8") or a package found in one of the work spaces (For more details see: 'go help gopath').

and:

> Second, if you are compiling a Go program not in a work space, you can use a relative path in an import statement in that program to refer to nearby code also not in a work space. This makes it easy to experiment with small multipackage programs outside of the usual work spaces, but such programs cannot be installed with "go install" (there is no work space in which to install them), so they are rebuilt from scratch each time they are built. To avoid ambiguity, Go programs cannot use relative import paths within a work space.
 
### What did you expect to see?
 
A description or definition of what a "work space" is. (I also looked in the output of `go help gopath` and didn't find it.)
 
### What did you see instead?

No such description or definition.

From context, I'd guess a "work space" may be a directory (package? module???) in the local file system, possibly outside GOPATH; but I hate guessing. Besides, "Go programs cannot use relative import paths within a work space" seems to rule this out.

(Importance: very low; urgency: non-existent)
Repository: go
Issue: spec: unclear definition of the capacity of a slice
Labels: NeedsDecision

### What version of Go are you using (`go version`)?
https://golang.org/ref/spec says: Version of Jul 26, 2021

### What did you do?

After a few years of Go experience, I decided to read the spec again.
When I got to the section about slices, I stumbled upon these sentences:

> The array underlying a slice may extend past the end of the slice.
> The capacity is a measure of that extent: it is the sum of the length of the slice and the length of the array beyond the slice.

The second sentence seemed wrong to me, so I tried it using go1.16:

https://play.golang.org/p/dkHHwZ0vqmc
~~~go
arr := [5]int{1, 2, 3, 4, 5}
slice := arr[1:2:3]
~~~

In the above code, the slice starts at `&arr[1]`, it has length 1 and capacity 2.
The "length of the array beyond the slice" probably refers to "beyond len(slice)". If so, I assume it to be 3.
The sum of these is 1 + 3 == 4, but the capacity of the underlying array is 5.
The spec says the capacity should be 4, but in reality it is 2.

Is the spec wrong in this regard, or did I just interpret it wrong?
In the first sentence, I interpreted that the word "beyond" means "past the end", ignoring the portion of the underlying array that is before the beginning of the slice.
Repository: rust
Issue: Match does not understand lifetimes of enum variants
Labels: C-enhancement,A-borrow-checker,T-lang,A-patterns

<!--
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:

```rust
use std::borrow::Cow;

enum Example<'a> {
    TotallyOwned{ foo: u32, bar: u32 },
    MaybeBorrowed(Cow<'a, [u8]>),
}

impl<'a> Example<'a> {
    fn to_owned(self) -> Example<'static> {
        match self {
            Example::MaybeBorrowed(p) => Example::MaybeBorrowed(Cow::Owned(p.into_owned())),
            
            // Doesn't work!
            a @ Example::TotallyOwned { .. } => a, //~ ERROR lifetime may not live long enough
            
            // Does work, but verbose!
            // Example::TotallyOwned { foo, bar } => Example::TotallyOwned { foo, bar }
        }
    }
}
```

I expected the match arm `a @ Example::TotallyOwned { .. } => a` to work, as this variant is completely owned.

Instead, I needed to completely destruct the enum variant, and create a new one, to "make Rust understand" I was creating a fully owned enum instance.

I can understand *why* this error exists: namely if I am returning a rebound instance of the original enum, it still is bound to the `'a` lifetime, however in the case of the `TotallyOwned` variant, this lifetime is "meaningless", which (someday?) rustc may be able to see.

Since this is more of an "improvement request" kind of issue, let me know if there is a better place to open this, or if this is the sort of thing that would require an RFC.

### 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.
-->

This presents in the current stable (1.54.0), as well as the current nightly (2021-08-27), though is likely true for all versions

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>
Repository: flutter
Issue: [snippets] Generates invalid snippet paths (on Windows)
Labels: framework,dependency: dart,platform-windows,d: api docs,P2,team-framework,triaged-framework

This issue regards the [`snippets`](https://github.com/flutter/assets-for-api-docs/tree/master/packages/snippets) package.

## Description

The snippet paths generated are invalid for me (when I generated them using `dart pub global run snippets:extract_sample --input packages/flutter/lib/src/material/theme_data.dart`).

There are two separate problems:
1. _Only on Windows_: the generated paths **use backslashes**, which makes the CI in `flutter/flutter` fail because it cannot deal with them. Instead, forward slashes should be used since they work both on Windows and Linux/OS X.
2. The generated paths are **not relative** from the repository root, i.e. `d:\os\flutter\flutter\dev\snippets\config\templates\stateless_widget_scaffold.tmpl` was generated for me instead of `dev/snippets/config/templates/stateless_widget_scaffold.tmpl`.

## Resources

* What I needed to manually fix after generation (Git commit): https://github.com/flutter/flutter/pull/89070/commits/ab80376ff58764e83d373e38cc6b5633bf7434b7
* CI failure in `flutter/flutter` due to backslahes in paths: https://github.com/flutter/flutter/pull/89070/checks?check_run_id=3447125054

### Versions

I used `snippets 0.2.4` to generate the snippets.

```
[✓] on Microsoft Windows [Version 10.0.19042.1165], locale en-150
    • Dart version 2.15.0 (build 2.15.0-64.0.dev)
```
Repository: rust
Issue: 'Unstable' flags should be more descriptive about the state of the flag
Labels: T-rustdoc,A-diagnostics,T-compiler

This issue is inspired by a recent [zulip message](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/.E2.9C.94.20rustdoc.20--no-run.20option.20for.201.2E54.2E0/near/249140502) from @ehuss in a thread about `rustdoc` unstable flags.

> FWIW, I've been working on improving this same situation in Cargo, as it can be quite confusing for people unfamiliar with it. For help text, I've tried to ensure that every unstable flag says whether or not it is unstable in the help. In the past, we've hidden those options but found that was bad for discovery. I've also reworked Cargo's unstable messages to be different based on the channel. For example:
>
> ```
> error: the `--unit-graph` flag is unstable, and only available on the nightly channel of Cargo, but this is the `beta` channel
> See https://doc.rust-lang.org/book/appendix-07-nightly-rust.html for more information about Rust release channels.
> See https://github.com/rust-lang/cargo/issues/8002 for more information about the `--unit-graph` flag.
> ```
> vs on nightly:
> ```
> error: the `--unit-graph` flag is unstable, pass `-Z unstable-options` to enable it
> See https://github.com/rust-lang/cargo/issues/8002 for more information about the `--unit-graph` flag.
> ```
> It is a bit hard to squeeze a complete explanation in an error message of what "nightly" is and how to install and use nightly. It's definitely not perfect, but hopefully an improvement from the old messages. It might be nice for rustc and rustdoc to consider something similar.
Repository: rust
Issue: `#[should_panic]` ignores function-like macros
Labels: A-libtest,C-bug

<!--
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:

```rust
#[cfg(test)]
mod tests {
    #[test]
    #[should_panic = concat!("a")]
    fn test() {
        panic!("b");
    }
}

fn main() {}
```

https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1268154aa9d34acf6833b9affa7e6b81

I expected to see this happen:
```
running 1 test
test tests::test - should panic ... FAILED

failures:

---- tests::test stdout ----
thread 'tests::test' panicked at 'b', src/lib.rs:6:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
note: panic did not contain expected string
      panic message: `"b"`,
 expected substring: `"a"`

failures:
    tests::test

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
```

Instead, this happened:
```
running 1 test
test tests::test - should panic ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s


running 0 tests

test result: ok. 0 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 0.00s
```

Changing `concat!("a")` to `"a"` shows the expected error:  
https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=e0aa41c95b4cd19e82332b6f030987f5
Repository: go
Issue: debug/pe: Calling File.ImportedLibraries returns an empty slice
Labels: NeedsInvestigation,FeatureRequest

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.17 windows/amd64
</pre>

### Does this issue reproduce with the latest release?
Yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
set GO111MODULE=auto
set GOARCH=amd64
set GOBIN=
set GOCACHE=C:\Users\keith\AppData\Local\go-build
set GOENV=C:\Users\keith\AppData\Roaming\go\env
set GOEXE=.exe
set GOEXPERIMENT=
set GOFLAGS=
set GOHOSTARCH=amd64
set GOHOSTOS=windows
set GOINSECURE=
set GOMODCACHE=C:\py\go\pkg\mod
set GONOPROXY=github.com/keithcat1/nvgo
set GONOSUMDB=github.com/keithcat1/nvgo
set GOOS=windows
set GOPATH=C:\py\go
set GOPRIVATE=github.com/keithcat1/nvgo
set GOPROXY=https://proxy.golang.org,direct
set GOROOT=C:\go
set GOSUMDB=sum.golang.org
set GOTMPDIR=
set GOTOOLDIR=C:\go\pkg\tool\windows_amd64
set GOVCS=
set GOVERSION=go1.17
set GCCGO=gccgo
set AR=ar
set CC=gcc
set CXX=g++
set CGO_ENABLED=1
set GOMOD=
set CGO_CFLAGS=-g -O2
set CGO_CPPFLAGS=
set CGO_CXXFLAGS=-g -O2
set CGO_FFLAGS=-g -O2
set CGO_LDFLAGS=-g -O2
set PKG_CONFIG=pkg-config
set GOGCCFLAGS=-m64 -mthreads -fmessage-length=0 -fdebug-prefix-map=C:\Users\keith\AppData\Local\Temp\go-build3753911013=/tmp/go-build -gno-record-gcc-switches

</pre></details>

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
Imported the "debug/pe" package, called pe.Open("somefile.exe") or pe.Open("somefile.dll") and then called ImportedLibraries on the result.


### What did you expect to see?
List of all imported libraries (I.E. []string{"kernel32.dll", "msvcrt.dll"}


### What did you see instead?
[]string{}, even when the error is nil.
Repository: godot
Issue: Emoji not displayed correctly with the default editor font
Labels: enhancement,topic:editor,confirmed

### Godot version

3.3.2.stable.official

### System information

macOS BigSur (11.15) 

### Issue description

When you copy/paste an emoji into a text input in Project Settings, it doesn't display correctly.

<img width="698" alt="Captura de Pantalla 2021-08-28 a les 17 14 19" src="https://user-images.githubusercontent.com/481475/131227618-c5cb3b1d-9338-461d-8ba4-2889292abad1.png">


### Steps to reproduce

Go to:

- **Project** -> **Project Settings**
- Paste an emoji in `application/config/name` or `application/config/description` and a "warning" interrogation mark icon will be displayed instead of the actual emoji.

### Minimal reproduction project

_No response_
Repository: excalidraw
Issue: copy/paste not in contextMenu for larger touch devices
Labels: bug

### Discussed in https://github.com/excalidraw/excalidraw/discussions/3946

<div type='discussions-op-text'>

<sup>Originally posted by **valiyaveedan** August 26, 2021</sup>
How do I copy a shapes I drew and then paste in another  instance while on iPad? On the PC it works with Ctrl + C and Ctrl +V but when I get the context menu on iPad I am not able to see the copy and paste options. I have seen this in earlier versions. Was this removed?</div>
Repository: pytorch
Issue: Longer int and normal Floats conversion to FloatTensor is strange
Labels: module: docs,triaged

## 🐛 Bug

I've noticed that a longer int or a not so big float from python fails to convert properly with torch.FloatTensor()
I have not found any documentation to decide if this is correct or not (for example: it is represented in  32bit but not clear how data is stored and what is the exponent part etc). With torch.DoubleTensor() the conversion works fine,

## To Reproduce

Steps to reproduce the behavior: (python version: 3.8.11, pytorch 1.9.0)

Follow these steps in python:
>> a =  [1630175280000, 48946.15]
>> b = torch.FloatTensor(a)
>> b[0].item()
     Out[104]: 1630175**232000.0**
>>b[1].item()
     Out[105]: 48946.1**484375**


## Expected behavior

At least the float will be preserved. It is not a huge float number with extreme precision or value...

## 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 (e.g., 1.0): 1.9.0
 - OS (e.g., Linux): Ununtu 
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source): no
 - Python version: 3.8.11
 - CUDA/cuDNN version: 10.1 
 - GPU models and configuration: n/a (issue was reproduced on CPU device)
 - Any other relevant information: n/a

## Additional context

<!-- Add any other context about the problem here. -->


cc @brianjo @mruberry
Repository: TypeScript
Issue: Infer typeof self if unspecified on cast
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms

- type casting
- implicit typing
- syntactic sugar

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, 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

It would be a lot cleaner if when you cast a type to some other type (for example NonNullable) you don't have to specify typeof self.

## 📃 Motivating Example

if you have an Array that could be undefined you can filter out undefined like so

```ts
const array = ["one", undefined, "two"].filter(Boolean);
console.log(array) // ["one", "two"]
```

but in this case the type would still be `(string | undefined)[]` so it would cause linting errors later in the code. While this may be specific to the .filter method, it may be unreasonable to expect all methods accurately account for type checks like this. So one easy way to fix this would just be to do

```ts
const arrayUndefined = ["one", undefined, "two"]

const array = arrayUndefined.filter(Boolean) as NonNullable<UnArrayify<typeof arrayUndefined>>
```

what I'm suggesting is that instead of requiring you do `typeof arrayUndefined` you can instead do an implicit cast to make the code cleaner
```ts
const arrayUndefined = ["one", undefined, "two"]

// it's implied that UnArrayify would be called with <typeof array.filter(Boolean)>
const array = arrayUndefined.filter(Boolean) as NonNullable<UnArrayify>
```

## 💻 Use Cases

I would like this because it would result in cleaner typing for unhandled edgecases in the typescript linter
Repository: rust
Issue: Excessive drop glue duplication in vtables can blow up compile times
Labels: A-codegen,A-destructors,I-compiletime,T-compiler

Currently, it seems like every CGU that contains a `&ConcreteType -> &dyn Trait` cast will instantiate the corresponding vtable and drop glue of `ConcreteType`. This can result in *massive* LLVM IR bloat that then slows down compile times.

We have observed this in rust-analyzer (https://github.com/rust-analyzer/rust-analyzer/issues/10065, also Zulip discussion [here](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/Dropping.20arcs/near/251079669)), where the drop glue of a single type `RootDatabase` is responsible for over 40% of LLVM IR in some downstream crates.