sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Comparison of different enumeration types error
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

"enums", "enum comparison"

### ✅ Viability Checklist

- [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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

Show type-check error on different enumeration types comparing

### 📃 Motivating Example

```ts
enum Month {
    Jan, Feb, Mar, Apr, May, Jun,
    Jul, Aug, Sep, Oct, Nov, Dec
}

enum Week { Mon, Tue, Wed, Thu, Fri, Sat, Sun }

console.log('Month vs Month', Month.May > Month.Nov) // false
console.log('Week vs Week', Week.Wed > Week.Mon) // true

console.log('Equals', Week.Sun === Month.Nov) // false (type-check error)
console.log('Week vs Month', Week.Sun > Month.Nov) // false (expected type-check error?)
```

Comparing the equality of different enums results a type-check error:
```
This comparison appears to be unintentional because the types 'Week' and 'Month' have no overlap. (2367)
```

But no error on `>`, `<` or `>=`, `<=`

Error examples:
`C`
![Screenshot 2023-11-23 164017](https://github.com/microsoft/TypeScript/assets/64013347/8a5bd350-e9e2-4c66-b260-fdd540d5e11c)

`Rust`
![_rust](https://github.com/microsoft/TypeScript/assets/64013347/36970865-6dc6-441b-a0f1-34864a8549bc)


### 💻 Use Cases

1. What do you want to use this for?
Comparison operations between non-overlapping enum types
Repository: vscode
Issue: Using vscode.dev viatunnel, markdown internal link can not be opened
Labels: bug,markdown

When using vscode.dev via a tunnel in the browser and editing markdown, internal links do not work.

Simple example:
```
# cat test.md 
[test](test.md)
```
Opening the preview and clicking the link opens a new browser tab with `https://vscode-remote+tunnel-002b<TUNNEL_NAME>.vscode-resource.vscode-cdn.net/<LOKAL_PATH>/test.md` which results in an NS_ERROR_UNKOWN_HOST.

Expected behavior is to open the markdown-file inside the already running browser tab.

![grafik](https://github.com/microsoft/vscode/assets/22013217/ddfbfd9d-9bc1-4e7f-9259-4ca63c7caee1)
![grafik](https://github.com/microsoft/vscode/assets/22013217/76aa7562-1a6d-436b-8416-989903e04958)

Same error when trying to link to another file.

Version: 1.84.2
Commit: 1a5daa3a0231a0fbba4f14db7ec463cf99d7768e
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/115.0
Embedder: vscode.dev

<!-- generated by web issue reporter -->
Repository: deno
Issue: Error thrown within a microtask swallows any error previously thrown in a macrotask during the current eventloop tick
Labels: bug,deno_core

```js
function test() {
  queueMicrotask(() => {throw new Error("microtask error");});
  throw new Error("macrotask error");
}
```

## Current
### Deno
```bash
$ deno run /tmp/test.js 
error: Uncaught Error: microtask error
  queueMicrotask(() => {throw new Error("microtask error");});
                              ^
    at file:///tmp/test.js:2:31
    at ext:core/01_core.js:608:9
```

## Expected
### Firefox
![image](https://github.com/denoland/deno/assets/4871949/c79c97cd-7d58-4cf3-8799-516f2ddf1d92)


### Bun
```bash
$ bun /tmp/test.js 
1 | function test() {
2 |   queueMicrotask(() => {throw new Error("microtask error");});
                                  ^
error: microtask error
      at /private/tmp/test.js:2:30
1 | function test() {
2 |   queueMicrotask(() => {throw new Error("microtask error");});
3 |   throw new Error("main task error");
            ^
error: main task error
      at test (/private/tmp/test.js:3:8)
      at /private/tmp/test.js:6:0
```

##
Repository: node
Issue: Apply source maps to profiles
Labels: feature request,source maps

### What is the problem this feature will solve?

When debugging bundled/compiled/minified code, it's difficult to read a profile as locations and many function names point to the compiled code.

### What is the feature you are proposing to solve the problem?

Apply source maps to profiles (perhaps when `--enable-source-maps` is passed).

### What alternatives have you considered?

post-augmentation (via the [source-map](https://www.npmjs.com/package/source-map) package), or other tools (such as [speedscope](https://www.speedscope.app/)) which claim to be able to apply sourcemaps (but dont [always work](https://github.com/jlfwong/speedscope/issues/446)).
Repository: stable-diffusion-webui
Issue: [Feature Request]: Setting the grid margin of txt2img or img2img
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

Currently you can set the grid margin in xyz plot, but not in txt2img or img2img. 
![image](https://github.com/AUTOMATIC1111/stable-diffusion-webui/assets/33342388/b920088b-4d31-4c3d-b231-522776e01d0c)

Is it possible to add a new option similar to the one in xyz plot?

### Proposed workflow

1. Setting the grid margin of txt2img or img2img like xyz plot.



### Additional information

_No response_
Repository: TypeScript
Issue: Incorporating exhaustiveness analysis into the control flow of if statements.
Labels: Possible Improvement

### 🔍 Search Terms

"initialization", "variable", "inference", "assignment", "assigned", "automatic detection"

### ✅ Viability Checklist

- [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 isn't a request to add a new utility type: https://github.com/microsoft/TypeScript/wiki/No-New-Utility-Types
- [X] This feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

One's code may implicitely involve that all cases have been processed in an if-else structure. TS does detect it with switch statements, however it does not detect it with if-else clauses.

Consider the following example:

```ts
type Dinosaur = "triceratops" | "brachiosaurus"

const myCollectionOfDinosaurs: Dinosaur[] = ["triceratops", "brachiosaurus"]

const randomKey = Math.floor(Math.random() * myCollectionOfDinosaurs.length)
const randomlyChosenDinosaur: Dinosaur = myCollectionOfDinosaurs[randomKey]

let dinosaurGreeting: string

if (randomlyChosenDinosaur === "triceratops") dinosaurGreeting = "Hello triceratops!"
else if (randomlyChosenDinosaur === "brachiosaurus") dinosaurGreeting = "Hello brachiosaurus!"

console.log(dinosaurGreeting)
```

TS complains on the last line because it says dinosaurGreeting is used before being assigned.

Replacing the if-else clause with a switch statement fixes the problem. However it would be great if TS did support this feature for if-else clauses too.

### 📃 Motivating Example

I'd use the dinosaurs example above, and assert that this feature would remove unnecessary constraints in the language.

### 💻 Use Cases

1. What do you want to use this for?
Writing some meaningful code with less constraints, shaping it more precisely and remaining safe from type-related problems.
3. What shortcomings exist with current approaches?
Most current approaches involve working around the way you intend your code to work. For example I can use !: when typing the variable, or initialize the variable with a default variable, or define it anywhere it is initialized, but all these solutions would imply thinking the code differently, in a way that is less compatible with my need.
The best approach is using a switch statement instead of an if-else clause, which doesn't impact the logic of the code.
5. What workarounds are you using in the meantime?
Replacing the if-else clause with a switch statement.
Repository: godot
Issue: "Reload Current Project" doesn't reload the project
Labels: bug,platform:windows,topic:editor,confirmed

### Godot version

v4.1.2.stable.official

### System information

Godot v4.1.2.stable - Windows 10.0.19045 - Vulkan (Forward+) - integrated AMD Radeon(TM) R7 Graphics (Advanced Micro Devices, Inc.; 27.20.20913.2000) - AMD A8-7600 Radeon R7, 10 Compute Cores 4C+6G (4 Threads)

### Issue description

When clicking the "Reload Current Project" Button under "Project" in the menu bar, the project doesn't load again after closing.
It just happens with my main project and all the other projects works fine.

**Video demonstrating the issue:**

https://github.com/godotengine/godot/assets/94475453/b088952d-37d9-4b0f-809d-dea3dfab082a

(I am not sure if this should be reported as a bug as it happens with only one project but well just in case) 

### Steps to reproduce

N/A

### Minimal reproduction project

N/A
Repository: go
Issue: io/fs: document optional interfaces in manner consistent with package io
Labels: Documentation,NeedsInvestigation

### Proposal Details

I would like to propose improving the documentation of the "optional" interfaces in [`package fs`](https://pkg.go.dev/io/fs) (e.g., [`fs.ReadDirFS`](https://pkg.go.dev/io/fs#ReadDirFS),  [`fs.ReadFileFS`](https://pkg.go.dev/io/fs#ReadFileFS), [`fs.StatFS`](https://pkg.go.dev/io/fs#StatFS), and [`fs.SubFS`](https://pkg.go.dev/io/fs#SubFS)).  Namely, the documentation around these interfaces and the types that use them should be made symmetric.

To demonstrate what I mean by symmetric, look at the documentation of [`package io`](https://pkg.go.dev/io) with [`io.Copy`](https://pkg.go.dev/io#Copy) and [`io.WriterTo`](https://pkg.go.dev/io#WriterTo):
* `io.Copy` mentions "If src implements the WriterTo interface, the copy is implemented by calling src.WriteTo(dst)."
* `io.WriterTo` mentions "The Copy function uses WriterTo if available."

We can observe the following in the aforementioned interfaces in `package fs`:
* `fs.ReadFileFS` mentions "ReadFileFS is the interface implemented by a file system that provides an optimized implementation of ReadFile."  That doesn't directly tell the reader that (package) function ReadFile calls this API if the file system implements this.  Note how this is stylistically very different from what `io.WriterTo` mentions above.
* `fs.ReadDirFS` is identical to the previous.
* `fs.StatFS` mentions nothing about how [`fs.Stat`](https://pkg.go.dev/io/fs#Stat) will call this API if it is implemented.
* `fs.SubFS` identical to the previous, except with [`fs.Sub`](https://pkg.go.dev/io/fs#Sub).

So the net effect, I think, should be this:

1. All APIs in `package fs` that act (e.g., [type assertions at runtime](https://go.dev/ref/spec#Type_assertions)) on these optional interfaces (documentation for consumers) should mention that they do.  The way they do so, probably should be consistent in logical structure and verbiage.
2. All APIs in `package fs` that define the optional interfaces (documentation for API producers) should mention what consumer APIs act on them.  Again, how the APIs that could act differently with these behaviors are enumerated should be consistent in structure.

`package io` documents this well, and I think can be used as a model here.  Without the consistency and symmetry, it's not super clear whether the optional APIs are something that casual API consumers of the package need to consider.
Repository: go
Issue: io/fs: provide package-level documentation for the package
Labels: Documentation,NeedsInvestigation

### Proposal Details

Related to #64373, I would like to recommend that [`package fs`](https://pkg.go.dev/io/fs) gets some more top-level package documentation.  At present, **all** that it states is:

> Package fs defines basic interfaces to a file system. A file system can be provided by the host operating system but also by other packages.

This provides no information about the package's use and philosophy.  There is a proposal document for `package fs`'s design, but that would not be a suitable drop-in replacement to describe use.  A couple of things come to mind that are worth mentioning that are not obvious:

1. For casual use, the a user of the package should primarily rely upon the package's top-level functions when they exist versus specialized interface methods.  For instance, use function `fs.ReadFile` on a `fs.FS` instead of caring whether a `fs.FS` implements `fs.ReadFileFS` (runtime type assertion) and then calling `(fs.ReadFileFS).ReadFile` directly on the asserted value.
2. The package's documentation should suggest/tease a couple of common entrypoints for file system access and creation:

    * `os.DirFS` creates a filesystem around an ordinary POSIX file system.
    * `package embed` can provide embedded file systems in the binary.

    Without this information, it leaves a reader to wonder whether there are any batteries included, which is not a good developer experience.

3. The package's top-level documentation should demonstrate some common workflows, too.  That would help make many of these points non-issues.  There is one package example in the documentation (for `WalkDir`).  If a user's new to this package, the `WalkDir` example may not be the best foray to demonstrate it.

There are enough symbols floating around in this package's identifier space that it's rather hard to tease apart critical API versus secondary API, which hinders overall comprehension of the package.
Repository: godot
Issue: Addon node name disappears / gets clipped on specific scale of scene tree view
Labels: bug,topic:editor,topic:plugin

### Godot version

v4.1.3.stable.arch_linux

### System information

Arch Linux

### Issue description

![Screenshot 1](https://github.com/godotengine/godot/assets/90388353/cffa10f5-1836-4436-b66c-43311c2a357f)
![Screenshot 2](https://github.com/godotengine/godot/assets/90388353/b19e8772-f5d6-48df-9387-72ba07dc9d56)
![Screenshot 3](https://github.com/godotengine/godot/assets/90388353/dfd6f9f7-531a-4851-89b3-7bd63c0288bc)
This only happens when the node is from an addon.

### Steps to reproduce

1. Create a new project
2. Install [this addon](https://godotengine.org/asset-library/asset/2362) through the asset library. I suspect any plugin with a similarly named node would work tho.
3. Add a `Form` Node to a scene tree.
4. Save & close
5. Reopen the project
6. Resize the Scene view pane

### Minimal reproduction project

[squishy.zip](https://github.com/godotengine/godot/files/13459546/squishy.zip)
Repository: vscode
Issue: Don't hide useful information from the suggestions list
Labels: feature-request,ux,suggest

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
When the suggest list contains several similar entries, not all information fits unless you increase the width of the list a lot:
<img width="343" alt="image" src="https://github.com/microsoft/vscode/assets/2737650/94023e0a-9489-45a2-936f-ebd7672df089">
In this case, the most useful information I'm looking for is exactly what's missing.
I think with the path the most useful info is always at the end, so it would make sense if hide the start, not the end of the path.

With the class name this is a bit more difficult, because the most useful information is not always at the end.
But an alternative fix could be to place the name and path on two separate lines, which would look something like this:
<img width="343" alt="image" src="https://github.com/microsoft/vscode/assets/2737650/e71fd039-9de9-48c2-a654-110fcfe4960c">

Ideally this would be a user preference of course, or maybe only entries that don't fit should be rendered like this.
Repository: flutter
Issue: [EditableText] value should be selectable via double click on web in edit mode
Labels: a: text input,framework,has reproducible steps,P2,team-framework,triaged-framework,found in release: 3.16,found in release: 3.17

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Steps to reproduce

1. run sample on web platform ( I did not try other platforms)
2. click "hello to enter edit"
3. try selection with double click 


### Expected results

text selection

### Actual results

no text selection

### Code sample

```dart
import 'package:flutter/material.dart';

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(
        scaffoldBackgroundColor: darkBlue,
      ),
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        body: Center(
          child: MyWidget(),
        ),
      ),
    );
  }
}

final controller = TextEditingController(text: 'hello world');
final focusNode = FocusNode();

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return EditableText(
      controller: controller,
      focusNode: focusNode,
      backgroundCursorColor: Colors.yellow,
      cursorColor: Colors.red,
      style: const TextStyle()
    );
  }
}

```

### Screenshots or Video

_No response_

### Logs

_No response_

### Flutter Doctor output

tried in dart pad master and stable channels, respectively 3.16.0 and 3.17.0
Repository: godot
Issue: Particle Shader calls velocities displacement
Labels: regression,topic:particles

### Godot version

4.2

### System information

Fedora, RX 590

### Issue description

A lot of places of the particle shader call "displacement" some thing that are velocities. Names should be adapted to reflect this

### Steps to reproduce

/

### Minimal reproduction project

/
Repository: vscode
Issue: File links: Support opening files with relative "file://" paths
Labels: feature-request,editor-contrib

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->

In VSCode, you can click links in comments like 
```md
file:///<full path>\package.json
```

It would be really great for documentation, comments, code linking inside a repo to be able to link to file not knowing the full path

Such as
```md
file:///..\../package.json
```

Because otherwise it can only work for the current machine or a machine with the exact same root paths
Repository: stable-diffusion-webui
Issue: [Bug]: Inconsistent Case for VENV_DIR Environment Variable
Labels: bug-report

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

The VENV_DIR environment variable exhibits an inconsistency in its letter casing. According to the documentation, it should be in uppercase as "VENV_DIR," but in the codebase, it is defined in lowercase as "venv_dir." This inconsistency can lead to confusion and misunderstanding when working with the variable.



### Steps to reproduce the problem

1. Refer to the documentation where the environment variable is mentioned as "VENV_DIR" in uppercase.
https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki/Command-Line-Arguments-and-Settings

2. Examine the codebase where the environment variable is defined as "venv_dir" in lowercase.
https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/master/webui.sh

### What should have happened?

The environment variable should maintain consistent letter casing, either in uppercase ("VENV_DIR") or in lowercase ("venv_dir"), to avoid confusion for users.

### Sysinfo

Linux

### What browsers do you use to access the UI ?

_No response_

### Console logs

```Shell
no
```


### Additional information

_No response_
Repository: flutter
Issue: [EditableText] should have a `selectionForegroundColor` parameter
Labels: a: text input,c: new feature,framework,c: proposal,P3,team-framework,triaged-framework

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

related : https://github.com/flutter/flutter/issues/138978

### Use case

EditableText has a parameter `selectionColor`, which allows to set the color of the selection background but there is no such parameter for the foreground color.

This is a problem when the background color has not enough contrast with the foreground color. For example try selecting the text in this sample:

![image](https://github.com/flutter/flutter/assets/22280985/9c9e128e-70f1-41e8-a7ea-adae3d39cab4)


```dart

import 'package:flutter/material.dart';

const Color darkBlue = Color.fromARGB(255, 18, 32, 47);

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      theme: ThemeData.dark().copyWith(
        scaffoldBackgroundColor: darkBlue,
      ),
      debugShowCheckedModeBanner: false,
      home: Scaffold(
        body: Center(
          child: MyWidget(),
        ),
      ),
    );
  }
}

final controller = TextEditingController(text: 'hello world');
final focusNode = FocusNode();

class MyWidget extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return EditableText(
      controller: controller,
      focusNode: focusNode,
      backgroundCursorColor: Colors.yellow,
      cursorColor: Colors.red,
      style: const TextStyle(),
      selectionColor: Colors.black,
    );
  }
}

```

### Proposal

 - add `selectionForegroundColor`
 - rename `selectionColor` to `selectionBackgroundColor`.
Repository: material-ui
Issue: [material-ui][Popover] How to not make the click away event close it?
Labels: support: question,component: Popover,package: material-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Summary 💡

I want to have the popover such that it does not close when i click outside the popover such that the user has the flexibility to choose whether he wants to close it on outside click or not.



### Examples 🌈

_No response_

### Motivation 🔦

_No response_