sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: App output different in Terminal than conhost with null characters
Labels: Issue-Question,Product-Conpty,Area-Output,Area-VT

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

I ACKNOWLEDGE THE FOLLOWING BEFORE PROCEEDING:
1. If I delete this entire template and go my own path, the core team may close my issue without further explanation or engagement.
2. If I list multiple bugs/concerns in this one issue, the core team may close my issue without further explanation or engagement.
3. If I write an issue that has many duplicates, the core team may close my issue without further explanation or engagement (and without necessarily spending time to find the exact duplicate ID number).
4. If I leave the title incomplete when filing the issue, the core team may close my issue without further explanation or engagement.
5. If I file something completely blank in the body, the core team may close my issue without further explanation or engagement.

All good? Then proceed!
-->

<!--
This bug tracker is monitored by Windows Terminal development team and other technical folks.

**Important: When reporting BSODs or security issues, DO NOT attach memory dumps, logs, or traces to Github issues**.
Instead, send dumps/traces to secure@microsoft.com, referencing this GitHub issue.

If this is an application crash, please also provide a Feedback Hub submission link so we can find your diagnostic data on the backend. Use the category "Apps > Windows Terminal (Preview)" and choose "Share My Feedback" after submission to get the link.

Please use this form and describe your issue, concisely but precisely, with as much detail as possible.

-->

# Environment

```none
Windows build number: 21280
Windows Terminal version (if applicable): 1.5.3242.0 (Preview)

Any other software? 
```

# Steps to reproduce

Run the project in https://github.com/asklar/textlogo
The program initializes a text buffer, draws something in it, then prints it to stdout.
It looks like Terminal treats `Console.WriteLine('\0')` as a no-op when it should be interpreting it as "write a space".
If I initialize my buffer to spaces, then the bug goes away, but this should not be necessary and it's a breaking behavior between conhost and terminal.

# Expected behavior
In conhost, this prints:
![image](https://user-images.githubusercontent.com/22989529/103350829-1a129380-4a56-11eb-9bc7-a8a97f50e894.png)

<!-- A description of what you're expecting, possibly containing screenshots or reference material. -->

# Actual behavior
In Terminal, this prints:
![image](https://user-images.githubusercontent.com/22989529/103350854-30b8ea80-4a56-11eb-9f13-0d8ad75f0a49.png)


<!-- What's actually happening? -->
Repository: vscode
Issue: Git - Vscode swaps theirs/ours on deleted file during rebase
Labels: bug,git

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
Version: 1.52.1 (system setup)
Commit: ea3859d4ba2f3e577a159bc91e3074c5d85c0523
Date: 2020-12-16T16:34:46.910Z
Electron: 9.3.5
Chrome: 83.0.4103.122
Node.js: 12.14.1
V8: 8.3.110.13-electron.0
OS: Windows_NT x64 10.0.19042

Steps to Reproduce:
1. Modify file in local branch and commit
2. Rebase onto master that has that same file deleted
3. Code shows file as "deleted by Us"

![20201230_144509](https://user-images.githubusercontent.com/20091488/103356056-32170100-4ab0-11eb-943b-a12dfd13e44d.jpg)
4. Pycharm shows the file as deleted by "them" which is the way it should be in my opinion
![image](https://user-images.githubusercontent.com/20091488/103356070-39d6a580-4ab0-11eb-8a61-eb98bc4bfb5c.png)

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes
Repository: node
Issue: ECONNRESET at TLSWrap.onStreamRead
Labels: tls

* **Version**: v15.5.0
* **Platform**: Darwin Marcels-MBP.fritz.box 20.2.0 Darwin Kernel Version 20.2.0: Wed Dec  2 20:39:59 PST 2020; root:xnu-7195.60.75~1/RELEASE_X86_64 x86_64
* **Subsystem**:

### What steps will reproduce the bug?

Implement castv2-client as in the example.

On Internet-Router (Fritzbox 7490) configure a port forwarding. Expose the whole Host (Google-Cast-Device).

Try to cast to the device via the public IP.

Connection fails, with the following error:
Error: read ECONNRESET
  at TLSWrap.onStreamRead (node:internal/stream_base_commons:213:20) {
    errno: -54,
    code: 'ECONNRESET',
    syscall: 'read'
  }

Casting to the device by local IP is working.

### How often does it reproduce? Is there a required condition?
always

### What is the expected behavior?
Cast-Device is playing


### Additional information

Casting to the device by local IP is working.
Repository: godot
Issue: File logging fails silently if the log folder can't be created (happens with `res://` paths)
Labels: bug,topic:core

**Godot version:**
3.2.3

**OS/device including version:**
Win 7

**Issue description:**
File logging doesn't create logs if the destination directory doesn't exist.
Either:
1) Godot should create the requisite directory structure
2) Issue a Warning level error to let the user know that they need to fix it.

**Steps to reproduce:**
* Enable file logging
* Set log path to: res://logs/godot.log
* Make sure that is to a directory that does *not* exist.
* Run application

**Minimal reproduction project:**
n/a
Repository: node
Issue: OOM
Labels: memory

When out of maximum ram capacity, process can be trimmed so parts that requires allocation of new memory goes later into a quee and it's waited until some event loop action triggers garbage collection cycle.
Repository: godot
Issue: Logging file rotation renames old files with the current date rather than the date they were created on
Labels: discussion,topic:core,confirmed

**Godot version:**
3.2.3

**OS/device including version:**
Win 7

**Issue description:**
When godot does log rotation, it renames godot.log and appends the ISO timestamp:
Problem is, the ISO timestamp isn't the one you'd expect.

The godot.log file from the **last** run is renamed and given a name with the timestamp of right now (as in, **this** run). This is very odd and not at all the timestamp you'd expect, and the logs are now misnamed.

I'd expect the godot.log from the **last** run to be renamed with either:
* Timestamp it was originally **Created** (this is how it's usually done)
* Timestamp it was last **Modified**

I've never seen timestamped logs use the timestamp they were **renamed** (what's happening now).

(Also, rather than simply renaming the file, it looks like the rotation actually creates an entirely new file so you lose the original file timestamp metadata. I'd suggest that's another part of this bug too (possibly even the cause).)

**Steps to reproduce:**
* Enable file logging
* Run application and stop it
* Wait 1 or more minutes
* Run application - the first godot.log file will have been renamed and will have the timestamp that you started *this* run.

**Minimal reproduction project:**
n/a
Repository: rust
Issue: Confusing error message with circular "use" statements.
Labels: C-enhancement,A-diagnostics,A-resolve,T-compiler,D-confusing

<!--
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
mod a {
    pub use b::foo as bar;
}

mod b {
    pub use a::bar as foo;
}

fn main() {
}
```

I expected to see this happen: Error due to recursive use statements.

Instead, this happened: 
```
error[E0432]: unresolved import `a::bar`
 --> test.rs:6:13
  |
6 |     pub use a::bar as foo;
  |             ^^^^^^^^^^^^^ no `bar` in `a`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0432`.
```

This is confusing because there _is_ in fact a `bar` in `a`; it's just defined circularly.

### 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.51.0-nightly (158f8d034 2020-12-29)
binary: rustc
commit-hash: 158f8d034b15e65ba8dc0d066358dd0632bfcd6e
commit-date: 2020-12-29
host: x86_64-unknown-linux-gnu
release: 1.51.0-nightly
```

<!--
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: godot
Issue: Impossible to select tilemap region that requires scrolling
Labels: bug,topic:editor

**Godot version:**
3.2.3

**OS/device including version:**
Win 7

**Issue description:**
If you load a large timemap and try to select its region, if you scroll down with the mouse button, the selection feature still works, but when you let go of the mouse button nothing will be selected.

Edit: After further experimentation: When you release LMB it selects only the things that were under the selection box before you started scrolling.

**Steps to reproduce:**
Add a timemap
Create a new Tileset
Add a large sprite (i.e. below)
Try and select a region. Should work fine.
Now try and select a region that requires you scroll down (or go to the bottom and try scrolling up). The selection tool will still be active, but when you release the LMB, nothing will be selected


![mapPack_tilesheet_2X](https://user-images.githubusercontent.com/72134064/103375887-27ba2e80-4ad3-11eb-9386-99e1aead2d4d.png)
Repository: rust
Issue: Support `_` for const inference with const generics
Labels: A-diagnostics,T-compiler,C-bug,A-const-generics

Currently, users may specify `_` in place of a type: the compiler will then suggest the intended type. This ought to work for consts too, but currently does not (see https://github.com/rust-lang/rust/issues/79557).

```rust
fn foo<const N: usize, const K: usize>(data: [u32; N]) -> [u32; K] {
    [0; K]
}

fn main() {
    let a = foo::<_, 2>([0, 1, 2]);
}
```
The difficulty is that the intended use of `_` (as either a type or const) is ambiguous until type checking, so runs into the same problems as #66615 and #77773.
Repository: godot
Issue: Add tooltips for many of the tilemap features (TilesetEditorContext, region/collision/etc buttons)
Labels: enhancement,topic:editor,usability

**Your Godot version:**
3.2.3

**Issue description:**
There seem to be no tooltips for the following:

* Any of the inspector options for the TilesetEditorContext
* The buttons ("Region", "Collision", etc) have tooltips that only repeat the text of the button and the hotkey. No abbreviated hint at what the function is for.
Repository: rust
Issue: MIR body serialization may be a bottleneck
Labels: A-metadata,I-compiletime,T-compiler,A-MIR,A-incr-comp,A-mir-opt,A-mir-opt-inlining

During MIR inlining, we end up producing larger MIR bodies each, as inlining often causes an increase in MIR for non-trivial functions being inlined. [This perf run](https://perf.rust-lang.org/compare.html?start=bbcaed03bf5505f3fed351887769ed1531599502&end=8fe9cff5eef9b4a216c991f66db2e749426888f3) shows that in the incremental cases, we lose some time to `optimized_mir` as expected but this is often offset by wins in `codegen`. 

However the other place we regress is time spent dealing with the incremental cache. That suggests to me that our MIR is larger due to inlining which causes more time to be spent during serialization/deserialization. 

It might be worth exploring if there's any optimizations we can make to the serialized `Body` representation.

_Originally posted by @wesleywiser in https://github.com/rust-lang/rust/issues/68828#issuecomment-752782277_
Repository: vscode
Issue: Git - quick diff indicator does not work with global textconv
Labels: bug,help wanted,git

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->
<!-- Also please test using the latest insiders build to make sure your issue has not already been fixed: https://code.visualstudio.com/insiders/ -->

<!-- Use Help > Report Issue to prefill these. -->
- VSCode Version: 1.53.0-insider
- OS Version: Ubuntu 20.10

Steps to Reproduce:

1. Clone the repository at https://github.com/septatrix/vscode-git-attributes-filter
2. Copy the commented section from `.gitconfig` to `~/.gitconfig`.
3. Open the directory in vscode and then open the file `sample.txt`
4. Even though everything is up to date vscode will show the first line as _new_.

<!-- Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<hr>

Other info:

The corresponding output from git itself:
```shell
$ cat sample.txt
# global diff textconv
# local diff textconv
$ tail -n 2 ~/.gitconfig
[diff "globaltxt"]
        textconv = "grep -v '^# global'"
$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean
$ git show :sample.txt
# global diff textconv
# local diff textconv
$ git show --textconv :sample.txt
# local diff textconv
```

When changing the `diff` attribute in `.gitattributes` to `localtxt` everything works as expected.
This may be some special case of #83232 when the text conversion (like `diff` or `filter`) is globally defined.
Repository: rust
Issue: ./x.py: cranelift source paths not mapped to repo root
Labels: T-bootstrap,C-bug

When `./x.py` builds librustdoc for example, all paths are originating from the repo root:
`    --> src/librustdoc/passes/collect_intra_doc_links.rs:2191:16`
This this is not the case for recently added cranelift but I guess it should be..?
`   --> src/intrinsics/mod.rs:827:14`
This shouldn't this be `   --> compiler/rustc_codegen_cranelift/src/intrinsics/mod.rs:827:14`?
Repository: TypeScript
Issue: Report better errors on return expressions for immediately-assigned functions
Labels: Suggestion,Help Wanted,Effort: Moderate,Domain: Error Messages,Experience Enhancement,Experimentation Needed

# Suggestion

## 🔍 Search Terms

`return type label:"Domain: Error Messages"`

## ✅ 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

Error reporting for mismatches between a functions return type and what is being returned by a particular `return` statement should be consistently reported a the location of the offending `return`.

## 📃 Motivating Example

[TypeScript Playground](https://www.typescriptlang.org/play?#code/C4TwDgpgBAYg9nKBeKAKAlgOzAV2ALigGdgAnLAcwEpkA+KTHAWwCMJSBuAKC4GM5MJKADMEheIhQZseGknoBvLlGIB3dMF4ALNFlzAaSlSt4BDItABEARkv5lxlaQjAcpTFGvdHZi1EsATHYOjs6u7v5B3sYAJhDCpjgANgQhxmFuHgCSmMJYGiDRAL5cJXwCQiympMi6MgTEZJRUhIys7HRQRmoa2nX6hmm+Vrb2jk4umZ7RJuZWQWPjGRGBljNQcQnJqeNQy9m5+aDFpUA)

```typescript
type Foo = (input: string) => number;

const foo: Foo = (input) => {
  switch (input) {
    case "1":
      return 1;
    case "2":
      return "2";
    default:
      return Infinity;
  }
}
```

The following error is reported on the declaration of `foo`.
```
const foo: Foo
Type '(input: string) => number | "2"' is not assignable to type 'Foo'.
  Type 'number | "2"' is not assignable to type 'number'.
    Type 'string' is not assignable to type 'number'.(2322)
```

```typescript
const bar = (input: string): number => {
  switch (input) {
    case "1":
      return 1;
    case "2":
      return "2";
    default:
      return Infinity;
  }
}
```

The following error is reported on `return "2"`:
```
Type 'string' is not assignable to type 'number'.(2322)
```

## 💻 Use Cases

In the second example it's much easier to see where the problem is.  In larger functions for more `returns it can be even hard to pin down which one is causing the issue.  These two examples are very similar and I would expect the same error to be reported for each.
Repository: rust
Issue: regression processing c-style doc comments in proc macros between 1.46 and 1.47
Labels: A-parser,P-medium,T-compiler,regression-from-stable-to-stable,E-needs-bisection,A-proc-macros

When a proc macro is applied to an item that has an associated c-style doc comment the contents of the `TokenStream` changed between 1.46 and 1.47. In particular the surrounding `*` and newlines were previously elided (mostly), but as of 1.47 they are not.

### Code

Here's a little repo I put together to demonstrate and reproduce the issue: https://github.com/ahl/cdoc_regression. It contains a proc macro that looks like this:

```rust
#[proc_macro_attribute]
pub fn return_as_is(_attr: TokenStream, item: TokenStream) -> TokenStream {
    for token in item.clone() {
        match token {
            TokenTree::Group(group) if group.delimiter() == Delimiter::Bracket => {
                println!("{:}", group)
            }
            _ => {}
        }
    }
    item
}
```

Here's the output:

```
$ cargo +1.46.0 run --example test
   Compiling fun v0.1.0 (/Users/ahl/src/cdoc_regression)
[doc = " This is a multi-"]
[doc = " line comment."]
[doc = " This is another multi-\n line comment."]
    Finished dev [unoptimized + debuginfo] target(s) in 0.30s
     Running `target/debug/examples/test`
$ cargo +1.47.0 run --example test
   Compiling fun v0.1.0 (/Users/ahl/src/cdoc_regression)
[doc = " This is a multi-"]
[doc = " line comment."]
[doc = "\n * This is another multi-\n * line comment.\n "]
    Finished dev [unoptimized + debuginfo] target(s) in 0.27s
     Running `target/debug/examples/test`
```

In both cases, the first multiline comment is for a `///`-style comment and the second is for a `/**`-style comment.

### Version it worked on

```
rustc 1.46.0 (04488afe3 2020-08-24)
binary: rustc
commit-hash: 04488afe34512aa4c33566eb16d8c912a3ae04f9
commit-date: 2020-08-24
host: x86_64-apple-darwin
release: 1.46.0
LLVM version: 10.0
```

### Version with regression


```
rustc 1.47.0 (18bf6b4f0 2020-10-07)
binary: rustc
commit-hash: 18bf6b4f01a6feaf7259ba7cdae58031af1b7b39
commit-date: 2020-10-07
host: x86_64-apple-darwin
release: 1.47.0
LLVM version: 11.0
```

<!--
If you know when this regression occurred, please add a line like below, replacing `{channel}` with one of stable, beta, or nightly.

@rustbot modify labels: +regression-from-stable-to-{channel} -regression-untriaged
-->
Repository: TypeScript
Issue: When the overloaded function has a generic type, the prompt of the code cannot be responded to in time
Labels: Bug,Domain: Completion Lists

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

generic、overloaded function

### 🕗 Version & Regression Information
typescript@4.1.3
vscode@1.52.1
webstorm@2020.3
ts-playground

### ⏯ Playground Link
 
[Playground link with relevant code](https://www.typescriptlang.org/play?#code/FASwdgLgpgTgZgQwMZQAQAVUG9itWBAWygH4AuVAZwhnAHMBuYAX1ElkRVQEFtdUArpVjk+ePAWKjqtMI37MmrNtHjI0AITGoAFlAA2+gPaic41AjqkKYAYQBGsJnkUtgKjup68oAD2hgACaUGAA0PNjK4Kqcmlp+AcFhqFpYyn4ADkYwEKjRnlwAEtoAPAAqAHwAFEYZECBGYJQU3NwAlBRlzqjloQAi1bX1jc0pGh2oXW7ASCO59hTFALz4AoYWIQhgAJ5MwPZVWOLMbe5AA)

### 💻 Code
 

![tttttt](https://onecoc-common.oss-cn-hangzhou.aliyuncs.com/Kapture%202020-12-31%20at%2010.46.55.gif)

![ttttt](https://onecoc-common.oss-cn-hangzhou.aliyuncs.com/Kapture%202020-12-31%20at%2010.49.49.gif)

### 🙁 Actual behavior

When my overloaded function has a generic type, the prompt of the code cannot respond in time

### 🙂 Expected behavior

When my overloaded function has a generic type, the prompt of the code should respond in time
Repository: rust
Issue: Don’t insert coverage counters for unreachable!() code
Labels: T-compiler,C-feature-request,A-code-coverage

With the introduction of source based code coverage, I ran into this quirk:

![73A8B6C2-5494-4D7C-AA02-6AC39614CA60](https://user-images.githubusercontent.com/3190108/103397119-77612000-4afc-11eb-9412-1a3c5de45afe.jpeg)

This seems like it should be a fully covered function but an unreachable counter has been placed on the invocation of the unreachable!() macro.

Would it be possible to make calls to unreachable skip the insert of the counter?
Repository: create-react-app
Issue: Where can I find the list of breaking changes between v9 and v10 of babel-preset-react-app?
Labels: needs triage

Where is the CHANGELOG (if one exists) for `babel-preset-react-app` located? I saw there is a major version change to v10 available, but can't seem to find what breaking changes might exist going from v9 to v10. Thank you.
Repository: godot
Issue: String to float doesn't work as expected
Labels: topic:core,documentation

**Godot version:**
v3.2.3.stable.official

**Issue description:**
After creating a number from a string that number doesn't equal itself


**Steps to reproduce:**
```
# 1. Multiple values comparison test
var tests = [
	["1.3", 1.3],
	["1.23", 1.23],
	["1", 1]
]

for test in tests:
	var num = float(test[0])
	
	if num == test[1]:
		print(str(test[0]) + " and " + str(test[1]) + " are equal") # only 1 will be equal
	else:
		print(str(test[0]) + " and " + str(test[1]) + " are not equal") # 1.23 and 1.3 will not be equal


# 2. Checking for a whole number
var string = "1.3" # 1.3
var number = float(string) * 10 # 13

if fmod(number, 1) == 0.0:
	print("whole number")
else:
	print("not whole number because the result is: ", fmod(number, 1)) # 1 instead of 0
	

# 3. Simple comparison test
var extra_string = "1.3" # 1.3
var extra_number = float(extra_string) * 10 # 13

if extra_number == 13:
	print("expected")
else:
	print("not expected")
```

I also tested the ``#3`` test using php and I got the expected behavior.

My main use case is to find if the number is whole or not. I understand that I can compare float using a method like this

```
const FLOAT_EPSILON = 0.00001

static func compare_floats(a, b, epsilon = FLOAT_EPSILON):
    return abs(a - b) <= epsilon
```