sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: pytorch
Issue: Qt 5.14.2, libtorch1.7.0 cuda10.2，Error after using header file
Labels: triaged,module: static linking

## ❓ Questions and Help

Whether I use qmake or cmake to build a qt project that includes libtorch, it will be successful when I build it, but when I add the #include <torch/script.h> file to the .h file, click Run, The program will report an error. The error content of these two methods is exactly the same.

D:\libtorch\include\c10\core\DispatchKeySet.h:59: error: C3250: "<range>$L0": declaration in "constexpr" function body is not allowed
D:\libtorch\include\c10\core\DispatchKeySet.h:59: error: C3249: "constexpr" function statement or sub-expression is illegal
D:\libtorch\include\c10\core\DispatchKeySet.h:59: error: C3250: "<begin>$L0": declaration in "constexpr" function body is not allowed
D:\libtorch\include\c10\core\DispatchKeySet.h:59: error: C3250: "<end>$L0": declaration in "constexpr" function body is not allowed
D:\libtorch\include\c10\core\DispatchKeySet.h:59: error: C3250: "k": declaration in "constexpr" function body is not allowed
D:\libtorch\include\c10\core\DispatchKeySet.h:60: error: C3249: "constexpr" function statement or sub-expression is illegal
D:\libtorch\include\c10\util\ConstexprCrc.h:103: error: C3250: "i": declaration in "constexpr" function body is not allowed
D:\libtorch\include\c10\util\ConstexprCrc.h:103: error: C3249: "constexpr" function statement or sub-expression is illegal
D:\libtorch\include\c10\util\ConstexprCrc.h:104: error: C3249: "constexpr" function statement or sub-expression is illegal
D:\libtorch\include\c10\util\ConstexprCrc.h:105: error: C3249: "constexpr" function statement or sub-expression is illegal
D:\libtorch\include\c10\util\Optional.h:283: error: C2556: "c10::ScalarType &c10::optional<c10::ScalarType>::contained_val(void) const &": overloaded function and "Const c10::ScalarType &c10::optional<c10::ScalarType>::contained_val(void) const &" is only different in the return type
Repository: svelte
Issue: Bind to a Map() Object not possible
Labels: temp-stale

**Describe the bug**
I am not sure if this should work or if it's a feature request in the end.

It is easily possible to bind to a normal Object `{}` with "keys", but it seems not to be possible if i have a Map object. I have tried to simplify the repl as much as possible.

Works:
```svelte
	const id = 1;
	
	const obj = {};
	obj[id] = {x: 0, y: 0};
...
<input type="range" min="0" max="100" bind:value={obj[id].x} />
````

Does not work:
```svelte
	const map = new Map();
	map.set(id, {x: 50, y: 50});
...
<input type="range" min="0" max="100" bind:value={map.get(id).x} />
````

Full repl see link.

**To Reproduce**
Repl:
https://svelte.dev/repl/947950a2c1754c20a86c39f34924485a?version=3.30.0

**Expected behavior**
Can bind to object stored in Map

**Severity**
Low

**Context**
In my real Application the Map object is a Store with lots of objects in it which I access by key. I wanted to do a performance comparison between Objects and Maps for my specific case.
Repository: rust
Issue: Dummy Overlapping Line Program Range produced for WASM Target
Labels: A-debuginfo,E-needs-test,T-compiler,O-wasm,C-bug

The following minimal WASM example:

```rust
#![no_std]

#[panic_handler]
fn panic(_info: &core::panic::PanicInfo) -> ! {
    loop {}
}

#[no_mangle]
pub fn internal_func() {
}
```

Produces a line number program in DWARF with what appears to decode to two overlapping ranges:

```
Line Number Rows:
<pc>        [lno,col]
0x00000000  [   4, 0] NS uri: "src/lib.rs"
0x0000001d  [   5, 5] NS PE
0x00000021  [   0, 5]
0x00000023  [   0, 5] ET
0x00000002  [   9, 0] NS
0x00000003  [  10, 2] NS PE
0x00000005  [  10, 2] NS ET
```

The output here is from the gimli dwarfdump tool but you can basically see that from pc `0x00` a sequence is started and ends at `0x23` which is the end of the program. The actual function `internal_func` sits at `0x2` and ends at `0x5`. Since DWARF does not permit code at `0x0` it would appear that rustc pads out the file for two bytes and places "nothing" at `0x0`.

DWARF does not talk much about overlapping sequences but it does talk about how sequences have to be contiguous:

> A series of contiguous target machine instructions. One compilation unit may emit multiple sequences (that is, not all instructions within a compilation unit are assumed to be contiguous).  

We currently take advantage of this fact and only consider a single sequence per PC. Right now we accidentally pick up on the first sequence which starts at 0. We can work around this by skipping sequences at zero but it seems to be a bug that this dummy sequence is generated in the first place.

### Meta

```
$ rustc --version --verbose
rustc 1.48.0 (7eac88abb 2020-11-16)
binary: rustc
commit-hash: 7eac88abb2e57e752f3302f02be5f3ce3d7adfb4
commit-date: 2020-11-16
host: x86_64-apple-darwin
release: 1.48.0
LLVM version: 11.0
```

It also happens on nightly:

```
$ rustc +nightly --version --verbose
rustc 1.50.0-nightly (825637983 2020-11-18)
binary: rustc
commit-hash: 8256379832b5ecb7f71e8c5e2018446482223c12
commit-date: 2020-11-18
host: x86_64-apple-darwin
release: 1.50.0-nightly
```
Repository: create-react-app
Issue: Suggest installing types as well as TypeScript
Labels: issue: proposal,needs triage

### Is your proposal related to a problem?

Preface: this is a very small annoyance/suggestion.

I just made a project with CRA. Changed `App.jsx` -> `App.tsx` and `index.js` -> `index.tsx`. When I ran `npm start` it said something along the lines of "it looks like you're using typescript but you don't have typescript installed. Run `npm i typescript`". That was **great**. Perfectly helpful and reasonable (I didn't/can't remember which things CRA does and which it doesn't out of the box). However, I ran it again and it produced an error suggesting I do `npm install --save-dev @types/react`. Again, makes perfect sense, and I did as it suggested, but it would have been nice if, when it said "it looks like you're using typescript, you should install it", it _also_ said "by the way, you'll probably need the types for react too". But whatever, I just installed in and continued...until it failed and said I needed the types for `react-dom` as well 🤦 , which was annoying enough for me to make a GH comment about it.

### Describe the solution you'd like

Presumably if create REACT app is going to remind me to install typescript, it should _also_ remind me to install the types for react and react-dom. If I have neglected to install typescript, I've surely neglected to install those types, and if I'm making a React app, it's probably safe to assume I will be using react and, hence, need those types.

### Describe alternatives you've considered

I mean the alternative is what it is now, which is to run -> fail -> fix -> run -> fail -> fix -> run -> fail -> fix -> run. That's annoying when I feel like I could have done run -> fail -> fix -> run if we just had a bigger suggestion when typescript is detected but not installed.

### Additional context

Look, CRA is a really incredible tool. The fact that it's smart enough to say "hey you're using a .tsx file, install typescript" is pretty awesome. But wherever that string is saved that says "try installing typescript", it seems like it would be reasonable, and just as easy, to say "also you'll probably want to install the react and react-dom types".
Repository: godot
Issue: Texture is black on HTML5 export.
Labels: bug,platform:web,topic:rendering,needs testing

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
<!-- Specify commit hash if using non-official build. -->
Godot 3.2.3 (released September 17, 2020)


**OS/device including version:**
<!-- Specify GPU model, drivers, and the backend (GLES2, GLES3, Vulkan) if graphics-related. -->
NVIDIA GTX960M, running a GLES2 project.


**Issue description:**
<!-- What happened, and what was expected. -->
Weird problems loading some textures in Godot HTML5 export.
The problem isn't at the image as I far as I swap the EditCharacterMouth.png (black) with another EditCharacterBody.png (or any other), the problem persist with the new image with the name EditCharacterMouth.png.

_Godot Editor:_
![image](https://user-images.githubusercontent.com/25259582/100238183-ab01c680-2f0e-11eb-8701-e0d886fc4f66.png)
![image](https://user-images.githubusercontent.com/25259582/100238202-b05f1100-2f0e-11eb-8439-783e27bbca16.png)

_HTML5 Export:_
<img src="https://user-images.githubusercontent.com/25259582/100237680-01bad080-2f0e-11eb-8930-d3f261b61955.png" height="256">

When I load the specific scene with that problem, this is the message I'm getting: "**WebGL: INVALID_ENUM: bindTexture: invalid target**"

What I have tried:
- Reimporting with different import settings.
- Deleting the image and reimporting it manually (deleting all remanent .IMPORT files).
- Reopening Godot.
- Editing the image in GIMP and exporting it with different settings. (As I said, the problem isn't in the image, as I far I swap its name with another's one, the other image stops working too).
- Redoing the nodes again with other names.
I know I can create another image and ignore this. But AFAIK I've done everything as always and this should not happen.
Any other way to troubleshoot it?


**Steps to reproduce:**
_Sorry, but I don't know how to reproduce this, because when I was making the "minimal reproduction project" with the same nodes, worked perfectly. I uploaded one anyways._


**Minimal reproduction project:**
<!-- A small Godot project which reproduces the issue. Drag and drop a zip archive to upload it. -->
Project: [FF ERROR PROJECT.zip](https://github.com/godotengine/godot/files/5598950/FF.ERROR.PROJECT.zip)
Export to HTML5: [HTML.zip](https://github.com/godotengine/godot/files/5597117/HTML.zip)
The project that should be with errors: [TheZip.zip](https://github.com/godotengine/godot/files/5597119/TheZip.zip)
The project I'm actually getting errors: You can test it in the [Itch.io](https://tibi4.itch.io/food-friends) I uploaded, as you can't reach that part of the project without login in. **(Email: noob; Password: 1234)**. _Login_ **>** _Click bottom right "Your room" button_ **>** _Click bottom t-shirt button._
Repository: create-react-app
Issue: react-scripts 4.0.1 absolute components import doesn't work 
Labels: needs triage,issue: bug report

### Describe the bug
Absolute components import doesn't work in 4.0.1 CRA version.

For example:
```javascript
import React, { useState } from 'react';
import Todo from 'components/Todo';
```
I get this error `Module not found: Can't resolve 'components/Todo' in '.../cra-project/src'

Folder `components` is nested to `src` folder.

The file `.env` was added in the project root.
`.env` file content
```
NODE_PATH=src/
```

When I change `react-scripts`  version from `4.0.1` to  `3.4.4` absolute imports work fine.
 ### Did you try recovering your dependencies?
Yes.


### Environment

Environment Info:

  current version of create-react-app: 4.0.1
  running from /home/sergey-sedykh/.npm/_npx/12865/lib/node_modules/create-react-app

  System:
    OS: Linux 5.4 Ubuntu 18.04.3 LTS (Bionic Beaver)
    CPU: (4) x64 Intel(R) Core(TM) i5-3330 CPU @ 3.00GHz
  Binaries:
    Node: 14.6.0 - /usr/local/bin/node
    Yarn: 1.22.4 - /usr/bin/yarn
    npm: 6.14.6 - /usr/local/bin/npm
  Browsers:
    Chrome: 85.0.4183.121
    Firefox: 83.0
  npmPackages:
    react: ^17.0.1 => 17.0.1 
    react-dom: ^17.0.1 => 17.0.1 
    react-scripts: 4.0.1 => 4.0.1 
  npmGlobalPackages:
    create-react-app: Not Found


### Steps to reproduce

1. Install project with CRA
2. Create the file `.env`  in the project root.
4. Add to the `.env` file next content `NODE_PATH=src/`
5. Use absolute components import


### Expected behavior

Absolute module imports should work.
Repository: rust
Issue: Rustdoc doctests should have their file/lines remapped when using `-Zinstrument-coverage`
Labels: T-rustdoc,C-enhancement,T-compiler,A-code-coverage

I have a workspace with `crate_a` (and `crate_b`, but its not used for this example), and use the following env vars set to have my rustdoc tests run through code coverage:

`RUSTDOCFLAGS="-Z instrument-coverage -Z unstable-options --persist-doctests=C:\Users\swatinem\AppData\Local\Temp\_rustdoc`

Running the result later through `llvm-cov` gives me errors for my rustdocs, and unexpected results:

```
> llvm-cov show -format=html -instr-profile=coverage/coverage.profdata -object=C:\Users\swatinem\AppData\Local\Temp\_rustdoc\crate_a_src_somemod_someothermod_mod_rs_1_0\rust_out

error: src\somemod\someothermod\mod.rs: no such file or directory
warning: The file 'src\somemod\someothermod\mod.rs' isn't covered.
```

When using `export -format=lcov`, I get the following:
```
SF:src\somemod\someothermod\mod.rs
FN:3,_RNvCs4fqI2P2rA04_8rust_out4main
FNDA:1,_RNvCs4fqI2P2rA04_8rust_out4main
FNF:1
FNH:1
DA:3,1
DA:4,1
LF:2
LH:2
end_of_record
```

This is not really a problem per-se, but note that the filename is not relative to my **workspace**, but to the **crate inside the workspace**, which creates problems down the road, because uploading that report to `codecov` actually finds the correct file for some reason, but then highlights lines *3* and *4*.

So ideally, the coverage support should similarly re-map line numbers such as compile errors in doctests do, and the filename should be relative to the workspace (but that seems to be a separate issue with rustdoc I guess).

@richkadel I guess you know the code the best: Is such a re-mapping that I propose possible *at all*? If so, I would be happy to work on this if you point me in the right direction and would be willing to mentor me ;-)
Repository: pytorch
Issue: compile error immintrin.h
Labels: module: build,triaged

I want to compile Pytorch 1.6 and 1.7. But when I running 
```
export NO_CUDA=1
export NO_DISTRIBUTED=1
export NO_MKLDNN=1
export NO_QNNPACK=1
export USE_FFMPEG=1
export MAX_JOBS=8
python3 setup.py sdist bdist_wheel
```
it fails with the error `fatal error: immintrin.h: Datei oder Verzeichnis nicht gefunden
   #include <immintrin.h>
            ^~~~~~~~~~~~~
compilation terminated.`

System:
Raspberry Pi 4 4GB RAM
Raspian Buster
cmake 3.17.20200504-g8541628

If you wonder why I want to compile two versions, I do it to upload them to my [repository](https://github.com/Ben-Faessler/Python3-Wheels).

cc @malfet @seemethere @walterddr
Repository: go
Issue: proposal: net/http/pprof/v2: disallow package to register to the default mux
Labels: v2,Proposal,NeedsInvestigation,compiler/runtime

`net/http/pprof` registers handlers to the default mux at init time. In order to register the handlers on a custom mux, you still have to import to package and have the debug handlers registered to the default mux. This creates the situation everyone who has a direct or transient dependency to the net/http/pprof package has the debug handles registered. 

This creates security issues and long-term maintenance problems where you want to 100% avoid the use of the default mux to make sure debug endpoints are never exposed to the Internet accidentally.  Instead of the current model, export a new API that registers these handlers to the default mux if users want to opt in.

(I remember seeing a similar issue but couldn't find it, filing another one but please close if it's a duplicate.)
Repository: go
Issue: syscall: StartProcess should accept Desktop property for StartupInfo for Windows
Labels: OS-Windows,NeedsInvestigation,compiler/runtime

# Feature Request

## Purpose

This is meant to be a feature request. I'm trying to gauge whether people agree this would be an acceptable/beneficial addition, and if the team would be willing to work on it or if it would be generally accepted by an outside contributor (me) if a PR was submitted.

### Problem Statement

To give a quick context: `os/exec`'s `Command`'s `Run` func calls `os.StartProcess`, which ends up calling `syscall.StartProcess`.

For Windows, [`syscall.StartProcess`](https://github.com/golang/go/tree/go1.15.5/src/syscall/exec_windows.go#L233) calls `syscall.CreateProcess` (or `syscall.CreateProcessAsUser`), which calls the [`CreateProcessW`](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-createprocessw) Win32 API method.

`CreateProcessW` accepts a [`STARTUP_INFOW`](https://docs.microsoft.com/en-us/windows/win32/api/processthreadsapi/ns-processthreadsapi-startupinfow) param, which is nicely constructed in the `syscall.StartProcess` func via a [`syscall.StartupInfo`](https://github.com/golang/go/tree/go1.15.5/src/syscall/types_windows.go#L464). One of `STARTUP_INFOW`'s properties is a `LPWSTR lpDesktop`. Unfortunately, nothing around `syscall.StartProcess` allows for this to be provided or set on the underlying `syscall.StartupInfo`, even though that struct already has the property defined.

I've had to generally rewrite the overall logic of `syscall.StartProcess` in my company's application because we **need** to be able to set the `lpDesktop` property. It would be nice to have it part of Go so we can use `os/exec`'s `Command`.

### Proposed Solution

Of the `syscall.StartProcess` func, In the `attr` (`*syscall.ProcAttr`) param,  there is a `Sys` (`*syscall.SysProcAttr`) property. I think a `Desktop string` property should be added there. This will be an optional value and only used in the `syscall.StartupInfo` **if** it's provided, which _should_ make it fully backwards compatible.

So, in `syscall.StartProcess`, something like the following can be done:

```go
var desktopp *uint16
if len(sys.Desktop) != 0 {
	desktopp, err = UTF16PtrFromString(sys.Desktop)
	if err != nil {
		return 0, 0, err
	}
}
```

and then used like this:

```go
si.Desktop = desktopp
```

and I think that should be it!
Repository: rust
Issue: Inaccurate error message for const operations in type parameters
Labels: A-diagnostics,T-compiler,C-bug,A-const-generics,D-confusing

I tried this code:

```rust
#![feature(min_const_generics)]

struct X<const S: usize>;

impl<const S: usize> X<S> {
    const LEN: usize = S + 1;
}

struct Y<const S: usize> {
  stuff: [u8; { S + 1 }],
}
```

This gave an error message:

```
error: generic parameters may not be used in const operations
  --> src/lib.rs:10:17
   |
10 |   stuff: [u8; { S + 1 }],
   |                 ^ cannot perform const operation using `S`
   |
   = help: const parameters may only be used as standalone arguments, i.e. `S`
   = help: use `#![feature(const_generics)]` and `#![feature(const_evaluatable_checked)]` to allow generic const expressions
```

But you can see in `X::LEN` that you _can_ perform const operations using `S`, the restriction this hits is more subtle in that you cannot perform const operations using generic parameters _when these will impact the type system_ (as I understand it, I may be wrong). This also comes up if a generic parameter is used in defining an associated type.
Repository: create-react-app
Issue: how to run custom scripts inside react project
Labels: stale,needs triage,issue: bug report

### Describe the bug

I have a project created using `create-react-app xxx --template typescript`.

I want to add some custom scripts to to miscellaneous things. 

Here is my script in `scripts/xxx.ts`

``` ts
import fs from "fs";
console.log("ttt", fs.readFile);
```


### Steps to reproduce


1. `create-react-app xxx --template typescript`
2. add the script
3. `ts-node scripts/xxx.ts`

### Expected behavior

script runs successfully 

### Actual behavior

```$ ts-node scripts/tt.ts 
(node:50658) Warning: To load an ES module, set "type": "module" in the package.json or use the .mjs extension.
/Users/kdong007/Desktop/projects/tapin-monorepo/test-react/scripts/tt.ts:1
import fs from "fs";
^^^^^^

SyntaxError: Cannot use import statement outside a module
    at wrapSafe (internal/modules/cjs/loader.js:1053:16)
    at Module._compile (internal/modules/cjs/loader.js:1101:27)
    at Module.m._compile (/Users/kdong007/.config/yarn/global/node_modules/ts-node/src/index.ts:1043:23)
    at Module._extensions..js (internal/modules/cjs/loader.js:1157:10)
    at Object.require.extensions.<computed> [as .ts] (/Users/kdong007/.config/yarn/global/node_modules/ts-node/src/index.ts:1046:12)
    at Module.load (internal/modules/cjs/loader.js:985:32)
    at Function.Module._load (internal/modules/cjs/loader.js:878:14)
    at Function.executeUserEntryPoint [as runMain] (internal/modules/run_main.js:71:12)
    at main (/Users/kdong007/.config/yarn/global/node_modules/ts-node/src/bin.ts:225:14)
    at Object.<anonymous> (/Users/kdong007/.config/yarn/global/node_modules/ts-node/src/bin.ts:512:3)
```
### Reproducible demo

<!--
  If you can, please share a project that reproduces the issue.
  This is the single most effective way to get an issue fixed soon.

  There are two ways to do it:

    * Create a new app and try to reproduce the issue in it.
      This is useful if you roughly know where the problem is, or can’t share the real code.

    * Or, copy your app and remove things until you’re left with the minimal reproducible demo.
      This is useful for finding the root cause. You may then optionally create a new project.

  This is a good guide to creating bug demos: https://stackoverflow.com/help/mcve
  Once you’re done, push the project to GitHub and paste the link to it below:
-->

(Paste the link to an example project and exact instructions to reproduce the issue.)

<!--
  What happens if you skip this step?

  We will try to help you, but in many cases it is impossible because crucial
  information is missing. In that case we'll tag an issue as having a low priority,
  and eventually close it if there is no clear direction.

  We still appreciate the report though, as eventually somebody else might
  create a reproducible example for it.

  Thanks for helping us help you!
-->
Repository: rust
Issue: `ptr::copy_nonoverlapping`/`ptr::copy` docs mention order difference between memcpy/memmove but fail to note count unit difference
Labels: C-enhancement,T-libs-api,A-docs

The docs for `ptr::copy_nonoverlapping` and `ptr::copy` say things like:

> copy is semantically equivalent to C's memmove, but with the argument order swapped

and

> copy_nonoverlapping is semantically equivalent to C's memcpy, but with the argument order swapped.

This is true, but I just encountered code where these were more-or-less used as:

```rust
ptr::copy_nonoverlapping(a, b, size_of::<T>() * n);
```

and the author (and myself) were confused about the issue here due to this basically looking right. The problem here is that *unlike `memcpy`/`memmove`* the `size_of::<T>() * n` should just be `n`, since it's the number of `T`s to copy.

I've filed a clippy lint for this: https://github.com/rust-lang/rust-clippy/issues/6381, but the docs should be updated to clarify this difference.