sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: terminal
Issue: Some Unicode characters appear to be recognised incorrectly
Labels: Product-Conpty,Area-Input,Issue-Bug,Needs-Attention,Product-Terminal,Priority-2

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

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: 10.0.19041.0 Microsoft Windows NT 10.0.19041.0
Windows Terminal version (if applicable): 1.5.10411.0
```

Any other software?
I used UnicodeInput from [here](https://www.fileformat.info/tool/unicodeinput/index.htm) to enter Unicode characters, but other utilities for entering Unicode produce the same issue.


# Steps to reproduce

Open a Windows terminal window using cmd or Powershell
Enter a character ﬀ (fb00). I did this using `Alt-+` to run UnicodeInput, and then entered the code fb00.
The character displayed at the prompt is 翿, not ﬀ.

# Expected behavior

The ﬀ character gets entered

# Actual behavior

The 翿 character is displayed

# Analysis

The character code for 翿 is 32767, and indeed any character with a code greater than 32767 appears to be replaced with 翿. So it looks like what is happening is that there is something masking the character to a 16-bit value, rather than accepting a full Unicode character.

Other applications, including Notepad and the basic command prompt (outside of Windows Terminal) don't do this, so it looks like a Windows Terminal specific issue.

Using cut and paste to enter the ﬀ character works fine, it's only when a character is entered "directly" that there is an issue.
Repository: storybook
Issue: Cannot import external object into Simple component
Labels: bug,react,block: source

**Describe the bug**
Hello. I created a simple component that searches for items in the api - if I pass a prop defining this action as true.
I generally abstract my api requests into services, so to do this search I import a service into the component. Whenever I try to import it the storybook breaks, returning the error message below:

![image](https://user-images.githubusercontent.com/11527271/109429678-bc5de180-79db-11eb-9102-75531259928c.png)

**To Reproduce**
Steps to reproduce the behavior:

1. Create a service.js;
```javascript
import { axios as client } from './drivers';

const Service = (resource = '') => {
  function sanitizeUrl(slug) {
    return slug ? `${resource}/${slug}` : resource;
  }

  const get = async (id, options) => client.get(sanitizeUrl(id), options);
  const list = async (slug, options) => client.get(sanitizeUrl(slug), options);
  const store = async (slug, body, options) =>
    client.post(sanitizeUrl(slug), body, options);
  const update = async (id, body, options) =>
    client.put(sanitizeUrl(id), body, options);
  const destroy = async (id, options) =>
    client.delete(sanitizeUrl(id), options);

  return {
    get,
    list,
    store,
    update,
    destroy,
  };
};

export default Service;
```
2. Create a simple component:
```javascript
import Service from '@services/base';
import { useEffect } from 'react';

function SimpleComponent(props) {
  function getFromAPI() {
    const users = Service().list('users');
   // ...
  }
  useEffect(() => {
    if(props.callAPI) {
      getFromAPI();
    }
  }, [props.callAPI]);
}
```

3. Open Storybook and see error.

**Expected behavior**
Expected the storybook would not break with the message attached above, and that it could visually test my component.

**System**
    OS: macOS Mojave 10.14.5
Storybook version: ^6.1.16
React version: 17.0.1
Repository: rust
Issue: Error diagnostics for associated items are different with `-Z unstable-options`
Labels: A-diagnostics,T-compiler,C-bug,requires-nightly

I tried this code: https://github.com/rust-lang/rust/blob/573a697a6197abaad5a2d7208dbf1bbc77f4dcf3/src/test/ui/associated-types/defaults-cyclic-fail-1.rs

I expected to see this happen: The error output is the same with and without -Z unstable-options

Instead, this happened: -Z unstable-options reports more errors than without.

```diff
diff --git a/src/test/ui/associated-types/defaults-cyclic-fail-1.stderr b/src/test/ui/associated-types/defaults-cyclic-fail-1.stderr
index 5e98520b411..c2887ccac74 100644
--- a/src/test/ui/associated-types/defaults-cyclic-fail-1.stderr
+++ b/src/test/ui/associated-types/defaults-cyclic-fail-1.stderr
@@ -4,12 +4,6 @@ error[E0275]: overflow evaluating the requirement `<bool as Tr>::B == _`
 LL |     type A = Box<Self::B>;
    |     ^^^^^^^^^^^^^^^^^^^^^^
 
-error[E0275]: overflow evaluating the requirement `<usize as Tr>::A == _`
-  --> $DIR/defaults-cyclic-fail-1.rs:32:5
-   |
-LL |     type B = &'static Self::A;
-   |     ^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-error: aborting due to 2 previous errors
+error: aborting due to previous error
```

There are similar issues with other errors related to associated items; see https://github.com/rust-lang/rust/commit/320530363be811dfadbc739da8157fbdf7aea950 for details.

cc @matthewjasper - do you have any idea what's going on here?
Repository: rust
Issue: Error diagnostics for lints are duplicated with `-Z unstable-options`
Labels: A-diagnostics,T-compiler,C-bug

I tried this code: https://github.com/rust-lang/rust/blob/573a697a6197abaad5a2d7208dbf1bbc77f4dcf3/src/test/ui/deduplicate-diagnostics.rs

I expected to see this happen: The same error output with and without `unstable-options`.

Instead, this happened: One of the errors is duplicated three times instead of only twice:

```diff
diff --git a/src/test/ui/deduplicate-diagnostics.duplicate.stderr b/src/test/ui/deduplicate-diagnostics.duplicate.stderr
index 3b100b59995..cd4700c7a7c 100644
--- a/src/test/ui/deduplicate-diagnostics.duplicate.stderr
+++ b/src/test/ui/deduplicate-diagnostics.duplicate.stderr
@@ -22,12 +22,6 @@ error[E0452]: malformed lint attribute input
 LL | #[deny("literal")]
    |        ^^^^^^^^^ bad attribute argument
 
-error[E0452]: malformed lint attribute input
-  --> $DIR/deduplicate-diagnostics.rs:8:8
-   |
-LL | #[deny("literal")]
-   |        ^^^^^^^^^ bad attribute argument
-
-error: aborting due to 5 previous errors
+error: aborting due to 4 previous errors
 
 For more information about this error, try `rustc --explain E0452`.
```

There are many other affected tests, see https://github.com/rust-lang/rust/pull/82639/commits/320530363be811dfadbc739da8157fbdf7aea950 for details.

cc @petrochenkov, do you know what's going wrong here?
Repository: pytorch
Issue: Tracker: pytest-related test improvements
Labels: module: tests,triaged,tracker

xref https://github.com/pytorch/pytorch/issues/11578#issuecomment-787485279 for the current status on using `pytest`.

- [x] improve the pytest output on test failures (probably through settings in a `pytest.ini` in the root of the repo):
    - [x] make it not print docstrings (gh-3791)
    - [x] make tracebacks shorter (`--tb=short` is probably about right, see [the pytest docs](https://docs.pytest.org/en/stable/usage.html?highlight=traceback#modifying-python-traceback-printing))
    - [x] address the issue where `pytest` suppresses `stderr` on startup (gh-39503, will likely also address gh-46276). 
- [ ] resolve open test running issues
    - [ ] `distributed` tests:
        - [ ] gh-41337, "distributed tests fail with pytest"
        - [ ] gh-46272, "`test_distributed_*` does not work with `run_test.py -i` option"
    - [x] gh-39523, "[JIT] Cannot directly run tests in `test_module_interface`"
- [ ] ensure `pytest` is installed in all CI jobs. `hypothesis` is a hard test dependency, so just make sure to treat `pytest` the same as `hypothesis` and that should be enough (note: needs to be done in the `pytorch/builder` repo).
- [ ] Compare `unittest` and `pytest` runs, ensuring the number of tests run matches (or differences make sense) and that test time is equivalent or better with `pytest`.
- [ ] Improve documentation
    - [ ] Write some docs on how to integrate `pytest`-based tests into `test/run_test.py` and on how to start using `pytest` features in existing test files (only if there's a good reason to do so of course).
    - [ ] Update https://github.com/pytorch/pytorch/blob/master/CONTRIBUTING.md#unit-testing



cc @mruberry @VitalyFedyunin @walterddr
Repository: rust
Issue: Suggest a braced-variant when seeing named fields in a tuple-variant
Labels: A-diagnostics,T-compiler

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur. 
-->

Given the following code: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=b13a063d22518585fb862ee27d3c4b6a

```rust
#[derive(Debug)]
enum Message {
    Move(x: i32, y: i32),
    Echo(String),
    ChangeColor(i8, i8, i8),
    Quit
}
```

The current output is:

```
error: expected one of `!`, `(`, `)`, `+`, `,`, `::`, or `<`, found `:`
 --> src/lib.rs:3:11
  |
3 |     Move(x: i32, y: i32),
  |           ^ expected one of 7 possible tokens
```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error: field names are not allowed in tuple variants
 --> src/lib.rs:3:11
  |
3 |     Move(x: i32, y: i32),
  |          ^^ unexpected field name
  = help: perhaps you want a braced variant?
3 |     Move { x: i32, y: i32 },
```

(Or however that should correctly look -- you'll probably come up with better strings and formatting than that strawman.)

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->
Repository: rust
Issue: Wrong error on wrapping arithmetic with -Zmir-opt-level=2
Labels: T-compiler,C-bug,A-mir-opt,A-mir-opt-inlining

I tried this code with `-Z mir-opt-level=2`:

```rust
fn main() {
    println!("{}", 1_u32.wrapping_sub(2_u32));
}
```

It compiles and runs without mir-opt, but with `-Z mir-opt-level=2` or above I get:

```
error: this arithmetic operation will overflow
   --> src/main.rs:2:13
    |
2   |       println!("{}", 1_u32.wrapping_sub(2_u32));
    |                      ^^^^^^^^^^^^^^^^^^^^^^^^^ attempt to compute `1_u32 - 2_u32`, which would overflow
    |
```

### Meta

`rustc --version --verbose`:
```
rustc 1.52.0-nightly (0148b971c 2021-02-18)
binary: rustc
commit-hash: 0148b971c921a0831fbf3357e5936eec724e3566
commit-date: 2021-02-18
host: x86_64-apple-darwin
release: 1.52.0-nightly
LLVM version: 11.0.1
```
Repository: godot
Issue: Implement Camera module for webcam access on all platforms (currently only for iOS and macOS)
Labels: enhancement,platform:windows,platform:linuxbsd,platform:web,platform:android,topic:porting,confirmed

**Godot version:**
Any version

**OS/device including version:**
Anything other than ios/osx

**Issue description:**
Godot's [Camera Server](https://docs.godotengine.org/de/stable/classes/class_cameraserver.html) and module only have support for ios and OSX. This means that trying to interact with a webcam on other platforms always fails.

There have been efforts to add support for other platforms, but none of these attempts have ever been successful.
The most promising one (#44498) attempts to add support for Windows using Media Foundation but is currently only compatible with msvc.

**Steps to reproduce:**
Try to use the camera server on any non apple platform

**Minimal reproduction project:**
https://github.com/BastiaanOlij/godot3_test_projects/tree/master/TestCameraServer

**UPDATE:**
There are a couple of different open PRs.
Windows: #49763 (3.x only, but should be easily portable to master)
Linux: #47967 and #53666
Repository: neovim
Issue: sign define default similar to highlight default
Labels: enhancement

Hey guys 👋 

Many 3rd party plugins make use of custom highlight groups and signs for the left column. For highlight groups there is this neat feature with the `default` parameter. This simply allows plugin developers to add highlight groups with sane defaults, but the user can easily customize them. This can happen before the plugin gets loaded or afterwards. The plugin must not provide any logic or setup function to support this. It just works out of the box.
It would be amazing if the same mechanism could work for `sign define`. It makes the customization of plugins stupid simple for the user without headache for plugin developers.

Looking forward to habe productive discussions regarding this feature request. Thanks!
Repository: node
Issue: Modules loaded multiple times because "Module._findPath()" returns different  upper/lower-case file-paths
Labels: module,windows

Node.js 14.15.3
Microsoft Windows NT 10.0.18363.0 x64
Typescript 4.0.2. target = ES2018, module = commonjs

### Problem
A module is imported from other modules. In some cases, the module gets loaded twice which results in different JS objects which results in unexpected side-effects (like missing initialization of the loaded module).

It happens during debugging with  VS-Code with the "pwa-node" or the "node" option.

### What steps will reproduce the bug?
We use following source code locations for our modules:

- c:\dev\comp\MR\mrBase
- c:\dev\comp\MR\mrUtils
- c:\dev\comp\MR\mrutilsCommon
- c:\dev\comp\MR\mrutilsSrv

The paths are camel-case but the module-names in the package.jsons are all in lowercase.
We use npm link during development to re-use the packages without the need for a registry.

**The File "C:\dev\comp\MR\mrutilsSrv\src\OS.ts" imports from "mrbase":**
`import { Assert } from "mrbase";`

This causes => `Module.require(...)` => `Module._load(...)` => `Module._resolveFileName(...)` =>  `Module._findPath(...)` =>  where it comes down to "`filename = tryPackage(...)`" 

basePath == "c:\\dev\\comp\\MR\\mrutilsSrv\\node_modules\\mrbase" (lowercase "c:" and lowercase "b" in "mrbase").
exts == ['.js', '.json', '.node']
isMain == false
request == "mrbase" 

=> Results in filename "`C:\\dev\\comp\\MR\\mrbase\\index.js`" (uppercase "**C:**" and lowercase "**b**" in "mrbase")

**The File "C:\\dev\\comp\\MR\\mrbase\\index.js" imports from "mrbase", too:**
`import { ILogger, LogLevel, ILogAppender, LogType, isGroup } from "mrbase"; `

This causes (again) => `Module.require(...)` => `Module._load(...)` => `Module._resolveFileName(...)` =>  `Module._findPath(...)` =>  where it comes down to "`filename = tryPackage(...)`" 

basePath == "C:\\dev\\comp\\MR\\mrutilscommon\\node_modules\\mrbase"  (uppercase "C:" and lowercase "b" in "mrbase").
exts == ['.js', '.json', '.node']
isMain == false
request == "mrbase" 

=> Results in filename "`c:\\dev\\comp\\MR\\mrBase\\index.js`" (lowercase "**c:**" and uppercase "**B**")

**As one can see, the file-names do not match and therefore the module gets loaded twice, because it cannot be found in the cache.**

Windows file/folder-names are not case-sensitive but Unix-names are but this is very strange in any way, because the algorithm for building a file-name should always be the same: either it respects upper/lowercase-names or not.
Repository: terminal
Issue: Color Escape Codes displayed incorrectly
Labels: Issue-Docs,Area-VT,Product-Meta,Priority-3

<!-- 
🚨🚨🚨🚨🚨🚨🚨🚨🚨🚨

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.

-->


# The problem:
###Microsoft Terminal with errors:
![image](https://user-images.githubusercontent.com/210185/109440111-ac073000-79f6-11eb-8bc0-8916fcd570ce.png)

### Git Bash Terminal
![image](https://user-images.githubusercontent.com/210185/109440141-c4774a80-79f6-11eb-91f7-cce25dc2b97f.png)

### Cmder Terminal
![image](https://user-images.githubusercontent.com/210185/109440225-1ae48900-79f7-11eb-93ab-e56ad0093faa.png)


Same behavior with Microsoft Terminal and bash shell used by Cmder.

# Environment

```
Platform ServicePack Version      VersionString
-------- ----------- -------      -------------
 Win32NT             10.0.18362.0 Microsoft Windows NT 10.0.18362.0
```

# Steps to reproduce

```npm run [some script] ```

Where the script produces terraform errors.

<!-- A description of how to trigger this bug. -->

# Expected behavior

Normal display

# Actual behavior

Non-interpreted escape codes
Repository: pytorch
Issue: lr_scheduler _triangular2_scale_fn calculation is overflowed
Labels: needs reproduction,module: optimizer,triaged

## 🐛 Bug

<!-- A clear and concise description of what the bug is. -->

## To Reproduce

Steps to reproduce the behavior:

1. train use lr_schedular

`scheduler = torch.optim.lr_scheduler.CyclicLR(optimizer, base_lr=0.00005,
                                            step_size_up=5, max_lr=0.0001,
                                            gamma=0.5, mode='triangular2', cycle_momentum=False)
`


epoch : 0, loss : 1.70, cer : 0.76, **learning_rate : [5e-05]** :  15%|████▌                          | 10239/70036 [2:09:07<12:34:05,  1.32it/s]
Traceback (most recent call last):
  File "train.py", line 103, in <module>
    train(opt)
  File "train.py", line 43, in train
    loss, cer = train_on_epoch(train_loader, vocab, model, device, i, metric, optimizer, criterion)
  File "train.py", line 75, in train_on_epoch
    scheduler.step()
  File "C:\Users\sanma\.conda\envs\xray_pytorch\lib\site-packages\torch\optim\lr_scheduler.py", line 154, in step
    values = self.get_lr()
  File "C:\Users\sanma\.conda\envs\xray_pytorch\lib\site-packages\torch\optim\lr_scheduler.py", line 906, in get_lr
    lr = base_lr + base_height * self.scale_fn(cycle)
  File "C:\Users\sanma\.conda\envs\xray_pytorch\lib\site-packages\torch\optim\lr_scheduler.py", line 878, in _triangular2_scale_fn
    return 1 / (2. ** (x - 1))
OverflowError: (34, 'Result too large')

-> _triangular2_scale_fn return error because calculate float operation is overflowed

<!-- If you have a code sample, error messages, stack traces, please provide it here as well -->

## Expected behavior
working normally

<!-- A clear and concise description of what you expected to happen. -->

## 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.7.1
 - OS (e.g., Linux): windows10 pro
 - How you installed PyTorch (`conda`, `pip`, source): conda
 - Build command you used (if compiling from source): 
 - Python version: 3.8
 - CUDA/cuDNN version: 11.0
 - GPU models and configuration: rtx 3080
 - Any other relevant information: 

## Additional context

<!-- Add any other context about the problem here. -->


cc @vincentqb