sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Display inlay hints with defining variables by destructuring assignment
Labels: Suggestion,Awaiting More Feedback

### 🔍 Search Terms

inlay hints
vscode
destructuring assignment

### ✅ 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 feature would agree with the rest of our Design Goals: https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals

### ⭐ Suggestion

In the following example, inlay hints are not shown in VSCode.
```TypeScript
const [value, setValue] = useState("");
```
I hope inlay hints will look like this.
```TypeScript
const [value /*: string */, setValue /*: React.Dispatch<React.SetStateAction<string>> */] = useState("");
```

### 📃 Motivating Example

It allows you to know the type without hovering, improving development efficiency.

### 💻 Use Cases

1. What do you want to use this for? 
I want to display inlay hints with defining variables by destructuring assignment in VSCode.
2. What shortcomings exist with current approaches?
I can't know the inference types without hovering.
3. What workarounds are you using in the meantime?
I hover and look at the types.
Repository: godot
Issue: Editor dropdown button should have consistent margins on all sides
Labels: discussion,topic:editor

### Godot version

4.x

### System information

Windows 11 - Godot 4.x

### Issue description

Not sure if it's conscious design decision (feel free to close this if it is), but the margins on all sides of a dropdown button should be the same for consistency. It also looks pretty bad with rounded corners IMO.
 
How it looks now:

![before](https://github.com/godotengine/godot/assets/18116695/1815a308-8042-4e73-90e3-0ad9ef2d29ed)

How it should look like:

![after](https://github.com/godotengine/godot/assets/18116695/7d347e42-c17e-4a19-a329-2e4ad043130d)


### Steps to reproduce

1. Open a new project.
2. Add a new 3D scene.
3. Add a new mesh instance.
4. Click on the mesh property dropdown button and add a new mesh.
5. Look at the margins of the dropdown button.

### Minimal reproduction project

N/A
Repository: tensorflow
Issue: The `mask` dtype should be asserted to be boolean in `tf.compat.v1.boolean_mask` (and `tf.boolean_mask`)
Labels: awaiting review,type:bug,comp:ops,TF2.14

### Issue type

Bug

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

binary

### TensorFlow version

2.14.0-rc1

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

The `mask` dtype should be asserted to be boolean in `tf.compat.v1.boolean_mask` (and `tf.boolean_mask`).
The documentation [`tf.boolean_mask`](https://www.tensorflow.org/api_docs/python/tf/boolean_mask) states that the `mask` is a K-D boolean Tensor, K <= N and K must be known statically.
However, currently, the `mask` dtype is not asserted to be boolean in `tf.compat.v1.boolean_mask` (and `tf.boolean_mask`) and cast to boolean if it is not a boolean Tensor, which may lead to unexpected results.
Generally, only the `0` and `1` values in the `mask` can be directly treated as `False` and `True` respectively, while other values should be determined by certain rules in different scenarios (_e.g._ negative values can be treated as `False` in some scenarios, or close to `0` values can be treated as `False` in some other scenarios).

I think it's worth updating the documentation to state that the `mask` will be cast to boolean if it is not a boolean Tensor, or warning users that the `mask` dtype should be boolean.
As mentioned in #54412, it is better to raise an InvalidArgumentError Exception when the `mask` dtype is not boolean, which forces users to cast the `mask` to boolean explicitly.


### Standalone code to reproduce the issue

```python
import tensorflow as tf
print(tf.version.GIT_VERSION, tf.version.VERSION, flush=True)
print(tf.config.list_physical_devices(), flush=True)


try:
    tensor = [0,1,2,3]
    mask = tf.random.uniform([4], dtype=tf.float64)
    x1 = tf.compat.v1.boolean_mask(tensor, mask) 
    print(x1, flush=True)
except Exception as e:
    print("Success! Error:", str(e), flush=True)
else:
    print("Failed!", flush=True)
```


### Relevant log output

```text
v2.14.0-rc0-34-gdd01672d9a9 2.14.0-rc1
[PhysicalDevice(name='/physical_device:CPU:0', device_type='CPU'), PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]
tf.Tensor([0 1 2 3], shape=(4,), dtype=int32)
Failed!
```
Repository: next.js
Issue: (Next.js + Jest) Import breaks when alias uses same name as relative import
Labels: bug,Testing

### Link to the code that reproduces this issue or a replay of the bug

https://github.com/martenbjork/next-conflict-reproduce

### To Reproduce

1. Set up nextjs. Use default import alias (`@/`)
2. Set up jest using instructions in Next.js docs (app router). `next/js` copies the import aliases from `tsconfig`.
3. Set up the following structure:

```
utils.ts
/components
    something.ts
    something.test.ts
    utils.ts
```

Inside the local utils, we export a value:

```
export const LOREM = 123;
```

Inside the global `utils.ts`, we export a value

```
export const IPSUM = 456;
```

Now, inside `something.ts`, we attempt to import the values from the 2 separate `utils.ts`:

```
import { LOREM } from "./utils";
import { IPSUM } from "@/utils";

console.log({ LOREM, IPSUM }};
```

4. Run `yarn jest`

### Current vs. Expected behavior

Current: console.log log returns `{LOREM: 123, IPSUM: undefined}`
Expected: console.log returns `{LOREM: 123, IPSUM: 456}`

### My take
- `@/` resolves to the literal string `./`
- That means that jest thinks both paths resolve to `./utils`
- Jest gets confused

### Hacky workaround
- Change the import alias in `tsconfig` from `@/(.*)$` to `@/lol/../(.*)$`
- The strings now resolve to the same paths as before, but they look different to jest
- Imports work

### Fix
- Jest should know the difference between the imported paths

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 22.6.0: Wed Jul  5 22:21:53 PDT 2023; root:xnu-8796.141.3~6/RELEASE_ARM64_T6020
    Binaries:
      Node: 18.17.0
      npm: 9.6.7
      Yarn: 1.22.19
      pnpm: N/A
    Relevant Packages:
      next: 13.4.20-canary.23
      eslint-config-next: 13.4.19
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A
```


### Which area(s) are affected? (Select all that apply)

Jest (next/jest)

### Additional context

_No response_
Repository: tensorflow
Issue: Does TensorFloat-32 support `tf.compat.v1.nn.depthwise_conv2d_native`? How can I identify whether an op is supported by TensorFloat-32?
Labels: stat:awaiting tensorflower,type:support,comp:ops,type:performance,TF2.14

### Issue type

Performance

### Have you reproduced the bug with TensorFlow Nightly?

Yes

### Source

binary

### TensorFlow version

2.14.0-rc1

### Custom code

Yes

### OS platform and distribution

_No response_

### Mobile device

_No response_

### Python version

_No response_

### Bazel version

_No response_

### GCC/compiler version

_No response_

### CUDA/cuDNN version

_No response_

### GPU model and memory

_No response_

### Current behavior?

I'm trying to use TensorFloat-32 to accelerate my model.
But I found that `tf.compat.v1.nn.depthwise_conv2d_native` is not currently supported by TensorFloat-32, by comparing the output with and without TensorFloat-32.

The [documentation](https://www.tensorflow.org/api_docs/python/tf/config/experimental/enable_tensor_float_32_execution) says _"Note TensorFloat-32 is not always used in supported ops, as only inputs of certain shapes are supported. Support for more input shapes and more ops may be added in the future."_
I also found that #46168 and #58047 mention some ops that are not supported by TensorFloat-32.
So I'm wondering if there is a way to identify whether an op is supported by TensorFloat-32?


### Standalone code to reproduce the issue

```python
import numpy as np
import tensorflow as tf
print(tf.version.GIT_VERSION, tf.version.VERSION, flush=True)
print(tf.config.list_physical_devices(), flush=True)


x_in = np.random.rand(1,7,7,16)
kernel_in = np.random.rand(3,3,16,16)

tf.config.experimental.enable_tensor_float_32_execution(True)
x = tf.constant(x_in, dtype=tf.float32)
kernel = tf.constant(kernel_in, dtype=tf.float32)
res_tf32 = tf.compat.v1.nn.depthwise_conv2d_native(x, kernel, strides=[1, 1, 1, 1], padding='VALID')

tf.config.experimental.enable_tensor_float_32_execution(False)
x = tf.constant(x_in, dtype=tf.float32)
kernel = tf.constant(kernel_in, dtype=tf.float32)
res_full = tf.compat.v1.nn.depthwise_conv2d_native(x, kernel, strides=[1, 1, 1, 1], padding='VALID')

print("res_tf32==res_full:", np.all(res_tf32==res_full))
```


### Relevant log output

```text
v2.14.0-rc0-34-gdd01672d9a9 2.14.0-rc1
[PhysicalDevice(name='/physical_device:CPU:0', device_type='CPU'), PhysicalDevice(name='/physical_device:GPU:0', device_type='GPU')]
res_tf32==res_full: True
```
Repository: vscode
Issue: Feature Request: Typing enter to close an openning bracket
Labels: feature-request,editor-autoclosing

<!-- ⚠️⚠️ 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. -->

It will be convient sometimes if user can type enter to close an openning bracket (**an existing one**). 

It will be much better if there is a toggle to control this feature.


In jetbrains' IDE series, they support this feature by default: 
![Jetbrains](https://github.com/microsoft/vscode/assets/70520782/33bbcbaa-5104-4539-8683-c6c833704b3c)

VSCode doesn't support this kind of operation as far as I know:
![VSCode](https://github.com/microsoft/vscode/assets/70520782/f84ff29b-e3f3-4448-b2e8-98519ac64a51)

I actually notice this "problem" when using Copilot in VSCode, when you accpet the suggetion of Copilot to complete a function signature, it will add a `{` at last, and you press enter, the openning `{` is not closed, you **have to manually** type a `}` to avoid compile errors caused by the openning `{`

There is a short demo:
![CopilotInVSCode](https://github.com/microsoft/vscode/assets/70520782/e889210a-dbf6-4d17-95ec-6b456444077c)

However, in Jetbrains' IDE, the experience will be much better:
![CopilotInJetbrains](https://github.com/microsoft/vscode/assets/70520782/8f5181e6-8a74-4db3-9a3f-cc7da4c5148b)

They automatically close the `{` when you press enter, there is no compile error caused by **the unclosed bracket**

By the way, after reading  #136452, it seems the property `completeBracketPairs` in Copilot is false by default, and there is no way to change this property.
Repository: next.js
Issue: Request memoization sometimes doesn't work
Labels: bug,Pages Router

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/distracted-bush-42yd2t?file=/app/(main)/layout.tsx:27,1-28,19

### Description

For some reason, request memoization doesn't work for identical requests in the same render pass.

> In the examples below, I added logs `react.shared-subset.development.js` to display React's current cache.
>
> ![image](https://github.com/vercel/next.js/assets/10157660/d66a81c6-f6e6-421e-a343-dc2c1e0ab9ee)


In the first video, we can see that request memoization works as expected when we start the application and open the page for the first time:

https://github.com/vercel/next.js/assets/10157660/2868373b-9ff9-43f4-b779-8a76ed2c8f20

In the second video, we can see that request memoization doesn't work for the next page reload:

https://github.com/vercel/next.js/assets/10157660/0cec9b16-5ae9-4d3e-b909-747488924c6d

> See updates below for more context.

### Current vs. Expected behavior

I expected request memoization to work for identical requests in the same render pass for `layout.ts` but it only worked on initial start and didn't work for the following page reloads.

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
From the example on the video:

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP Fri Jan 27 02:56:13 UTC 2023
Binaries:
  Node: 20.1.0
  npm: 9.6.4
  Yarn: 1.22.19
  pnpm: 8.1.0
Relevant Packages:
  next: 13.4.20-canary.23
  eslint-config-next: 13.4.19
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


### Which area(s) are affected? (Select all that apply)

App Router, Data fetching (gS(S)P, getInitialProps)

### Additional context

#### Update 2023-09-09 14:31

Request memoization works fine when I set runtime to Edge:

```ts
export const runtime = 'edge';
```

#### Update 2023-09-09 14:37

It seems the issue is in how Next.js loads modules.

> Note that on the videos below I use Next.js v13.4.19 but I'm sure it's applicable to canary version as well.

In the first video, I set runtime to `edge` and we can see that it loads modules once and request memoization works properly:

https://github.com/vercel/next.js/assets/10157660/c673e91a-04a5-43a1-a611-41ec48467270

However, when the runtime is `nodejs`, it loads modules more than necessary (and also for some reason `react-server-dom-webpack-server.edge.development.js` but I'm not sure if it's wrong) and after each `getData` which means it overwrites React's request storage:

https://github.com/vercel/next.js/assets/10157660/e4f7a290-29fd-411c-b668-8807a334a959
Repository: godot
Issue: Multiple issues with indentation in particle process material shader
Labels: bug,topic:codestyle,topic:particles

### Godot version

4.2

### System information

Fedora, RX 590

### Issue description

Post https://github.com/godotengine/godot/pull/79527, a lot of indentation issues have been introduced in thegenerated shader of the particle process material. They need to be fixed.

### Steps to reproduce

n/a

### Minimal reproduction project

n/a
Repository: PowerToys
Issue: Automated File organization
Labels: Idea-New PowerToy

### Description of the new feature / enhancement

Automatically organize files with If Then rules Like Hazel for Mac or File juggler for Windows and maybe some ai capabilities in the future like auto tagging and auto color palette generation like eagle https://en.eagle.cool/
and automatically importing a project Folder Structure template into every new folder in the c:/projects folder for example, like posthaste https://www.digitalrebellion.com/posthaste/

### Scenario when this would be used?

Keeping computer clean and saving time on organizing and focusing on the actual work

### Supporting information

Hazel https://www.noodlesoft.com/
file juggler https://www.filejuggler.com/
Repository: flutter
Issue: Make Windows plugin APIs thread-safe
Labels: engine,platform-windows,a: desktop,P2,a: plugins,team-windows,triaged-windows

Currently many core plugin APIs in Windows are platform-thread only, as on other platforms. However, as discussed in https://github.com/flutter/engine/pull/31134#pullrequestreview-991213668 and https://github.com/flutter/flutter/issues/79213 this doesn't work well on Windows, both in terms of OS APIs to facilitate it (there aren't any, unlike other platforms), and convention (Win32 APIs generally don't care what thread you are on). To better match platform conventions, we should make APIs like sending channel messages internally thread safe (by having the embedding internally post them to the platform thread, which we already have a mechanism for).

This may well be straightforward for the C API, but we'll need to make the C++ wrapper that almost all code actually uses that safe as well, which may require some locking.

(We would only do one of https://github.com/flutter/flutter/issues/79213 and this.)
Repository: deno
Issue: Option to disable `node:` specifiers
Labels: suggestion

The original proposal that's misunderstood entirely: #18494

Please add options to completely disable Node.js compatibility in CLI and in `deno.json`. It is redundant for projects already supporting Deno natively, and is problematic when developing a Deno-native port of an existing project.

On top of the original proposal on `deno.json`, please also add an option `--no-node` in `deno run` and `deno repl`.
Repository: rust
Issue: unsized_fn_params should not accept types that don't have a dynamically fixed size (such as `extern` types)
Labels: T-compiler,F-extern_types,F-unsized_fn_params

The following code should not be accepted:
```rust
#![feature(extern_types)]
#![feature(unsized_fn_params)]

extern {
    type E;
}

fn test(e: E) {}

fn calltest(e: Box<E>) {
    test(*e)
}
```
In terms of MIR semantics I think we want to view a function call as making copies of its arguments. This requires at least dynamically determining the size of the argument, and therefore we shouldn't accept `extern type` arguments.

I was extremely surprised earlier today when I learned that this code is getting accepted.

There is no generic bound to distinguish `extern` types from other unsized types, so the options we have are
- require the unsized type to be concrete enough that we can determine its tail, and ensure it is not `extern`
- raise the error during monomorphization / codegen

Trying to actually build any such code will lead to ICEs such as
```
error: internal compiler error: compiler/rustc_codegen_llvm/src/type_of.rs:306:13: TyAndLayout::scalar_pair_element_llty(TyAndLayout { ty: *mut E, layout: Layout { size: Size(8 bytes), align: AbiAndPrefAlign { abi: Align(8 bytes), pref: Align(8 bytes) }, abi: Scalar(Initialized { value: Pointer(AddressSpace(0)), valid_range: 0..=18446744073709551615 }), fields: Primitive, largest_niche: None, variants: Single { index: 0 }, max_repr_align: None, unadjusted_abi_align: Align(8 bytes) } }): not applicable
```
or
```
thread 'rustc' panicked at compiler/rustc_codegen_llvm/src/builder.rs:491:9:
assertion `left == right` failed
  left: false
 right: true
```
Repository: electron
Issue: [Bug]: Safestorage detection fails on linux outside of predefined desktop environments
Labels: platform/linux,blocked/need-info ❌,bug :beetle:,status/confirmed,25-x-y,26-x-y

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/main/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/main/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a bug report that matches the one I want to file, without success.

### Electron Version

25.6

### What operating system are you using?

Other Linux

### Operating System Version

Arch Linux

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

If libsecret is present, safestorage uses libsecret
if kwallet is present, safestorage uses kwallet

### Actual Behavior

unless the variable `XDG_CURRENT_DESKTOP` is set to a handful  of predefined values, using safestorage fails.


https://github.com/microsoft/vscode/issues/185212
https://github.com/theripper93/fvtt-player-client/issues/7

### Testcase Gist URL

_No response_

### Additional Information

Instead of reading this variable for this, electron should look for the presence of `libsecret` or `kwallet`in order to properly detect this. This has been reported on the VSCode github repo a bunch, tho this affects electron as a whole, including a project I contribute to.
Repository: flutter
Issue: [quick_actions] Add getMaxShortcutCount method for iOS and Android.
Labels: p: quick_actions,package,team-ecosystem,P3,triaged-ecosystem

### 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)

### Use case

In [quick_actions package](https://pub.dev/packages/quick_actions), there is no method to getMaxShortcutCount.

Android.
You can get that count by calling getMaxShortcutCountPerActivity.
https://developer.android.com/reference/androidx/core/content/pm/ShortcutManagerCompat#getMaxShortcutCountPerActivity(android.content.Context)

iOS
Maximum: 4

> People tend to expect every app to provide at least one useful quick action; you can provide a total of four.

https://developer.apple.com/design/human-interface-guidelines/home-screen-quick-actions#Best-practices


### Proposal

Implement getMaxShortcutCount method for each platform based on above things.
Repository: vscode
Issue: The `alembic` icon is not rendered properly
Labels: confirmed

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
Version: 1.81.1 (Universal)
Commit: 6c3e3dba23e8fadc360aed75ce363ba185c49794
Date: 2023-08-09T22:20:33.924Z
Electron: 22.3.18
ElectronBuildId: 22689846
Chromium: 108.0.5359.215
Node.js: 16.17.1
V8: 10.8.168.25-electron.0
OS: Darwin arm64 22.6.0

<img width="487" alt="image" src="https://github.com/microsoft/vscode/assets/3254987/19717792-fa51-452d-b730-3d19160a1a14">

The `alembic` icon is not rendered properly in VSCode editing mode of markdown.

Compare to what's in chrome/github:

https://github.com/unional/type-plus/blob/main/type-plus/README.md

<img width="937" alt="image" src="https://github.com/microsoft/vscode/assets/3254987/11091e30-7dda-4de3-a8bc-2e0133102fb8">