sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: go
Issue: proposal: x/sys/windows/mkwinsyscall: support UTF16 functions not ending with W
Labels: Proposal

## Background
Microsoft normally provides two parallel sets of APIs, one for ANSI strings, whose function names end with `A`, and the other for Unicode strings, whose function names end with `W` ([source](https://docs.microsoft.com/en-us/windows/win32/learnwin32/working-with-strings#unicode-and-ansi-functions)).

This pattern is well supported in `x/sys/windows/mkwinsyscall`: function parameters of type `string` are transformed using `syscall.UTF16PtrFromString` if the function names ends with `W`, and using `syscall.BytePtrFromString` otherwise:

https://github.com/golang/sys/blob/2edf467146b5fc89e484991587e3032c8421ae8c/windows/mkwinsyscall/mkwinsyscall.go#L616-L622

## Problem

Newer libraries that were created after Windows introduced Unicode tend to provide just the UTF16 API set without the `W`-ending convention. In my particular case, I'm creating bindings for the [BCrypt library](https://docs.microsoft.com/en-us/windows/win32/api/bcrypt), in which all functions accepting strings expect them to be UTF16 encoded even when the function name does not end with `W`.

This forces me to define the //sys functions using `*uint16` instead of `string` and to do the conversion outside the autogenerated code.

## Request

Add a knob to `x/sys/windows/mkwinsyscall` to decide if a string parameter should be transformed to ASCII or Unicode.

Two complementary solutions come to mind:

- Add a cli flag, i.e. `-utf16`, which changes the code generation behavior from
*everything is ASCII unless the function name ends with W*
to
*everything is UTF16 unless the function name ends with A*.

- Add a new optional condition to each function definition, i.e. `[encoding=utf16/ascii]`, which will override the encoding selected from the function name or the cli flag (if finally added).

The first solution will probably be enough to cover all cases, as new Windows APIs are Unicode by default and only legacy APIs expect ASCII strings, in which case they already provide the both API sets.

cc @zx2c4
Repository: opencv
Issue: Using OpenCV 4.5.5 DNN on the super-resolution ONNX model on CPU and GPU reasoning results are not the same!
Labels: incomplete,category: dnn

I used the CPU to reason and got a perfectly correct output image, but when I used the GPU to reason the output image was an all black image. And I printed part of the pixel value of the input image, which is normal on the CPU, but all changed to: -INF on the GPU. Why is that?

I loaded the model onto CUDA using the following three lines of code:
```
cv::cuda::setDevice (gpu_index_);
net_. SetPreferableBackend (cv::within DNN: DNN_BACKEND_CUDA);
net_. SetPreferableTarget (cv::within DNN: DNN_TARGET_CUDA);
```
Repository: TypeScript
Issue: TS Server: find all references didn't find ref in .d.ts with 'import * as '
Labels: Needs Investigation

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
typescript version: 4.6.2
### ⏯ [Playground Link](https://www.typescriptlang.org/dev/bug-workbench/?ts=4.6.2#code/PTAEAEDMEsBsFMB2BDAtvAXKALgTwA7wDOAdNkQFDwAe+A9gE7ajSLbwOTIDG8oAkgBVizAN4VQoAG7JYAV0yhEc1ACMOAbgoBfChRAQYCFOix5CpACbxusZA2TZodRCUtlK0VPSagAVKDIRDgExKCQDHSooABEJMDmxDFa1rb2fADmsHSqsqDikibE+Dx8iMEFkqA0PmIhFqDaWpK6uvpgUHBIaIqs1tQeFNwuRMzso1jlZKGkQiKgALz5EtKyClgAjAA0OhpAA)

### 💻 Code

**File Structure**

**src/types.ts**
```ts
export interface ITest {
  value: number;
}
```
**src/types.declaration.d.ts**
```ts
import * as types from "./types";
declare global {
  namespace ns {
    export { types };
  }
}

```
**src/index.ts**
```ts
const test: ns.types.ITest = {
  value: 1,
};
```
**tsconfig.json**
```json
{
  "compilerOptions": {
    "rootDir": "./src/"
  }
}

```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
In vscode, open "src/index.ts", then right click "Find All References " on word "ITest", it will only find interface ITest declaration in "src/types.ts", reference in "src/index.ts" can't be found;

### 🙂 Expected behavior
"Find All References" will find both interface ITest declaration in "src/types.ts" and reference in "src/index.ts" .

If I add 'import * as _ from  './types';' on the top of file "src/index.ts", it all works.

<!-- What you expected to happen instead, and why -->

### ⭕️ Maybe Related
https://github.com/microsoft/vscode/issues/106419
Repository: flutter
Issue: [android][add2app][image_picker] : app throws `PlatformException(already_active, Image picker is already active, null, null)`
Labels: platform-android,a: existing-apps,p: image_picker,package,has reproducible steps,P2,found in release: 2.10,found in release: 2.13,team-android,triaged-android

There are many issues with the plugin on Android (tested on a real device, Android 10). On iOS it sort of works, it's very slow. On either an iOS or an Android simulator it doesn't work at all. 

When trying to take a photo with the camera, the photo is taken, the selection is confirmed, and then the app crashes. 

When trying to pick a file, the file is picked correctly, however, upon returning to the app, nothing happens. When trying to open the file picker again, the following is written in the output: `Unhandled Exception: PlatformException(already_active...`

Reproduction:  https://github.com/ljmatan/samples/tree/master/add_to_app/multiple_flutters

Flutter doctor: 
```
[√] Flutter (Channel master, 2.13.0-0.0.pre.91, on Microsoft Windows [Version 10.0.19042.1586], locale en-US)
[√] Android toolchain - develop for Android devices (Android SDK version 31.0.0)
[√] Chrome - develop for the web
[X] Visual Studio - develop for Windows
    X Visual Studio not installed; this is necessary for Windows development.
      Download at https://visualstudio.microsoft.com/downloads/.
      Please install the "Desktop development with C++" workload, including all of its default components
[√] Android Studio (version 2021.1)
[√] VS Code (version 1.65.2)
[√] VS Code (version 1.66.0-insider)
[√] Connected device (4 available)
[√] HTTP Host Availability
```
Repository: node
Issue: Invalid Date generated by `toLocaleString('en-gb', ...)`
Labels: i18n-api

### Version

v13.14.0

### Platform

Darwin .... 21.3.0 Darwin Kernel Version 21.3.0: Wed Jan  5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_ARM64_T6000 arm64

### Subsystem

Always on Node >= 13.

### What steps will reproduce the bug?

```sh
nvm use 13
Now using node v13.14.0 (npm v6.14.4)
node -p "new Date().toLocaleString('en-GB', { timeZone: 'Europe/Amsterdam' })"
18/03/2022, 14:30:20
node -p "new Date(new Date().toLocaleString('en-GB', { timeZone: 'Europe/Amsterdam' }));"
Invalid Date
```

### How often does it reproduce? Is there a required condition?

_No response_

### What is the expected behavior?

```sh
nvm use 12
Now using node v12.22.10 (npm v6.14.16)
node -p "new Date().toLocaleString('en-GB', { timeZone: 'Europe/Amsterdam' })"
3/18/2022, 2:29:41 PM
node -p "new Date(new Date().toLocaleString('en-GB', { timeZone: 'Europe/Amsterdam' }));"
2022-03-18T13:33:38.000Z
```

For the record, so far I have only found `en-GB` to have this problem, `en-US` works as expected, see below:
```sh
nvm use 13
Now using node v13.14.0 (npm v6.14.4)
node -p "new Date().toLocaleString('en-US', { timeZone: 'Europe/Amsterdam' })"
3/18/2022, 2:52:37 PM
node -p "new Date(new Date().toLocaleString('en-US', { timeZone: 'Europe/Amsterdam' }));"
2022-03-18T13:52:47.000Z
```

### What do you see instead?

`Invalid Date`

### Additional information

The day and month are swapped as of Node 13 for the `en-GB` locale. 

For `en-GB` Node 13 seems to use the correct format day/month/year, whereas Node 12 uses month/day/year.

The problem is: in Node 12 you could create a `Date` instance based on the output of `.toLocaleString('en-GB', ...)`. As of Node 13 this returns `Invalid Date`.

Node 12: the following results in a valid `Date` instance.
```js
"new Date(new Date().toLocaleString('en-GB', { timeZone: 'Europe/Amsterdam' }));"
```

Node 13: the following results in an "Invalid Date" error.
```js
"new Date(new Date().toLocaleString('en-GB', { timeZone: 'Europe/Amsterdam' }));"
```
Repository: bitcoin
Issue: [flatpak]  - I cannot choose or change datadir when running from flatpak
Labels: Bug

<!-- This issue tracker is only for technical issues related to Bitcoin Core.

General bitcoin questions and/or support requests are best directed to the Bitcoin StackExchange at https://bitcoin.stackexchange.com.

For reporting security issues, please read instructions at https://bitcoincore.org/en/contact/.

If the node is "stuck" during sync or giving "block checksum mismatch" errors, please ensure your hardware is stable by running memtest and observe CPU temperature with a load-test tool such as linpack before creating an issue! -->

<!-- Describe the issue -->

flatpak run org.bitcoincore.bitcoin-qt -choosedatadir 



<!--- What behavior did you expect? -->

The -choosedatadir Should allow me to choose the datadir. But it is not. It immediately starts downloading headers from the peers.
The chooses a predefined datadir in 

```
~/.var/app/org.bitcoincore.bitcoin-qt$ ls
cache  config  data
```

* I am unable to modify the datadir location when I run the client using flatpak (on PopOS).

**To reproduce**

1. Install flatpak client
2. try the command

flatpak run org.bitcoincore.bitcoin-qt -choosedatadir 

<!--- How reliably can you reproduce the issue, what are the steps to do so? -->

Everytime.

**System information**

<!-- What version of Bitcoin Core are you using, where did you get it (website, self-compiled, etc)? -->

1. PopOS, Flatpak version. Client information
```
$ flatpak run org.bitcoincore.bitcoin-qt -version
Bitcoin Core version v22.0.0
Copyright (C) 2009-2021 The Bitcoin Core developers

Please contribute if you find Bitcoin Core useful. Visit
<https://bitcoincore.org/> for further information about the software.
The source code is available from <https://github.com/bitcoin/bitcoin>.

This is experimental software.
Distributed under the MIT software license, see the accompanying file COPYING
or <https://opensource.org/licenses/MIT>

```
<!-- What type of machine are you observing the error on (OS/CPU and disk type)? -->

<!-- GUI-related issue? What is your operating system and its version? If Linux, what is your desktop environment and graphical shell? -->

<!-- Any extra information that might be useful in the debugging process. -->
<!--- This is normally the contents of a `debug.log` or `config.log` file. Raw text or a link to a pastebin type site are preferred. -->
Repository: pytorch
Issue: Warning: "Specified kernel cache directory could not be created"
Labels: triaged,module: jiterator

### 🐛 Describe the bug

I am getting this warning with the newest version of PyTorch (1.11.0+cu113). In the case shown, we are running the program inside a container that has access to the cache directory mentioned.

I am getting the same warning on different environments that use different cache directories, and all are writeable by the user running the program.
```
/opt/python/lib/python3.9/site-packages/redacted/redacted.py:577: UserWarning: Specified kernel cache directory could not be created!
This disables kernel caching. Specified directory is /root/.
    return half * torch.erfc(const * inputs) 
```

### Versions

1.11.0+cu113

cc @mruberry @ngimel
Repository: tauri
Issue: [bug] Event naming differences
Labels: scope: api.js,type: feature request

### Describe the bug

The rust API names the resized event `WindowEvent::Resized` while  the JavaScript API calls it `tauri://resize`.
Similarly the rust API names file drop events `Dropped` `Hovered` and `Cancelled` while javascript names are present tense: `file-drop-hover`,  `file-drop` and `file-drop-cancelled`. (Notice how the last is actually a different tense too)

The naming is not horribly off, but we should consider making it consistent.

### Reproduction

_No response_

### Expected behavior

_No response_

### Platform and versions

```shell
N/A
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: godot
Issue: Linux headless server does not export to macOS properly in Docker container
Labels: bug,platform:linuxbsd,platform:macos,topic:export

### Godot version

3.3.4+

### System information

Mac OS Monterey for host machine, Alpine Linux for Docker

### Issue description

Hi! I'm trying to export a Mac OSX export from the linux headless build on docker.

The image that i have on my public registry is the following:
https://gist.github.com/lelandhwu/bd21f0a0faecda70de87f3ce061aa2a5

it works great, the headless linux server works great for multiplayer. Exporting the linux version works (for obvious reasons), but the thing is for my CI/CD builds when i try to export a mac osx version using the following command: godot --export "Mac OSX" file.dmg, it becomes corrupted. I've tested this by spinning up a local docker container running headless godot, exporting the file, and then running a docker cp to get the file back onto my host machine. I've also tested this with a fresh project with nothing on it. The .dmg file still gets corrupted

any ideas? next thing im thinking about is bumping the godot version on my public registry. I'd love some ideas from you guys though. 

Thanks so much! 

### Steps to reproduce

1. Create a doctor image with the following code: https://gist.github.com/lelandhwu/bd21f0a0faecda70de87f3ce061aa2a5
we've tried version 3.3.4. The highest we'll go is 3.4.3 for now 

2. Push it up to a registry. We'll be using this as a base image for our future builds.
 
3. Create a simple godot project with a main scene. We'll use this to test. Create a Dockerfile in the root directory of tha tproject that looks like this: https://gist.github.com/lelandhwu/b8233f352c616b23ff0a6325189a14f7
This is the other part of the file, just in a separate docker image

4. build the docker image:  docker build . -f Dockerfile
5. run the image in a separate process: docker run -it image-id /bin/bash
6. In a separate process, cp the exported the artifact onto your host machine. docker cp container-id:/godotapp/hz.dmg .
7. try and run the dmg file

### Minimal reproduction project

[test_project.zip](https://github.com/godotengine/godot/files/8306058/test_project.zip)
Repository: rust
Issue: Watch out for modules privacy when proposing traits to associate with an item
Labels: A-diagnostics,A-resolve,A-visibility,T-compiler,A-suggestion-diagnostics,D-invalid-suggestion

Working on suricata https://github.com/OISF/suricata/pull/7150

The current output is:

```
error[E0599]: no associated item named `MAX` found for type parameter `T` in the current scope
   --> src/detect.rs:109:18
    |
109 |         x < <T>::MAX
    |                  ^^^ associated item not found in `T`
    |
    = help: items from traits can only be used if the type parameter is bounded by the trait
help: the following traits define an item `MAX`, perhaps you need to restrict type parameter `T` with one of them:
    |
104 | fn detect_parse_uint_start_greater<T: lexical_core::util::num::Float + std::str::FromStr>(i: &str) -> IResult<&str, DetectUintData<T>> {
    |                                    ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
104 | fn detect_parse_uint_start_greater<T: lexical_core::util::num::Integer + std::str::FromStr>(i: &str) -> IResult<&str, DetectUintData<T>> {
```

This proposal looks interesting but when It tried it, I was disappointed :

 ```error[E0603]: module `util` is private
   --> src/detect.rs:41:51
    |
41  | fn detect_parse_uint_start_equal<T: lexical_core::util::num::Integer>(i: &str) -> IResult<&str, DetectUintData<T>> {
    |                                                   ^^^^ private module
    |
note: the module `util` is defined here
   --> /Users/catena/.cargo/registry/src/github.com-1ecc6299db9ec823/lexical-core-0.7.6/src/lib.rs:189:1```

```

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
"the following traits define an item `MAX`, you could restrict the type parameter,  but it is private so you can't"?
```
Repository: rust
Issue: `$crate` is not a valid new identifier for `::proc_macro::Ident::new()`
Labels: A-macros,C-bug,A-proc-macros

<!--
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
use ::proc_macro::{Ident, Span};

Ident::new("$crate", Span::mixed_site());
```

#### I expected to see this happen

That it generate a `Ident { sym: "$crate", span: Span::mixed_site() }` correctly, since that's something that a proc-macro can already do once they receive a `$crate` identifier from a `macro_rules!` caller (where they can edit the span to get their own `mixed_site()` span).

#### Instead, this happened

The constructor panics:

```console
error: proc macro panicked
    <snip>
  = help: message: `"$crate"` is not a valid identifier
```

  - [Playground](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=15e099b29dc3cd402f34e3a53e4347dd)

### Context

Ever since proc-macros got stable access to `Span::mixed_site()`, it was expected for them to be able to behave like `macro_rules!` macros do (w.r.t. hygiene). This ought to include `$crate`.

Granted, the interest for `$crate` in `proc-macro = true` crates is **severely limited**, since `$crate` would then refer to the backend proc-macro crate rather than the frontend (which is where the non-proc-macro stuff will be accessible), since a procedural macro can technically directly call another one directly as a function.

Still, there may be some specific cases where being able to call a "companion" proc-macro using macro syntax may be a desirable capability, with no real reason for it to be denied.

Indeed, [if we take the proc-macro example above, and reversed the `if true` switch](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=f1f1605c97e3bb05499bcc7bce534119), we have a fully functional demo where the proc-macro "hijacks" a genuine `$crate` that a `macro_rules!` caller provided.

@rustbot modify labels: A-macros A-proc-macros
Repository: PowerToys
Issue: [REQUEST] Fancy Zones -- Option For An Instant Feedback Experience
Labels: Idea-Enhancement,FancyZones-Dragging&UI,Product-FancyZones,Needs-Triage,Needs-Team-Response

### Description of the new feature / enhancement

- ### **STATEMENT**

Visual feedback is important to show users when their interactions are detected, interpreted, and handled.

- ### **PROBLEM**

Fancy Zones in its current state provides a delayed-feedback experience. The user drags the window to the intended zone, but the cannot preview where the window will snap until it is finished dragging.

- ### **EXAMPLE**

**Current Fancy Zones Snapping:**

![Current-Fancy-Zones](https://user-images.githubusercontent.com/28659816/159042519-63ef84db-0d0b-45e0-a71c-5caa24504709.gif)

- ### **PROPOSED SOLUTION**

An option to enable previewed snapped position would facilitate a more efficient visual feedback experience with Fancy Zones.

- ### **BENEFIT IN ACTION**

**Instant Zone Snapping:**

![Instant-Zone-Snap](https://user-images.githubusercontent.com/28659816/159042504-3934ff16-4d54-411a-a6cd-c9acfc0541ab.gif)






### Scenario when this would be used?

An added option to instantly snap windows to zones within Fancy Zones would be useful in nearly every use-case scenario.

### Supporting information

The screen recording in the second GIF is from a similar program called [WinDock](https://www.ivanyu.ca/windock/) but is no longer being updated.
Repository: deno
Issue: [feature request] Support header hints for newer versions and known vulnerabilities
Labels: suggestion

I thought a long time for the best way to allow yarn like "update all", listing of outdated dependencies and showing known vulnerabilities in deno without introducing central entities or being non idiomatic for deno and this is what i came up with:

support two  new http headers on code download:

given i reference a code file similar to: 

`import { green } from 'https://deno.land/std@0.126.0/fmt/colors.ts'`

when deno would fetch this file, whenever the following http headers are present log a realtime warning:

for hinting to a later version:
`Link: <https://deno.land/std@0.128.0/fmt/colors.ts>; rel="latest-version"`

for warning about known vulnerabilities:
`Link: <https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-1472>; rel="vulnerability", <https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-1474>; rel="vulnerability"`


additionally deno would do a  cheap http HEAD request upon using  a locally cached resources to warn about outdated or vulnerable dependencies, with cached result to not do a check more than once x days. this also has the nice effect that the head request would discover availability issues of external referenced dependencies so we could warn that a rebuild/refetch would fail.

additionally we can introduce a 'deno scan' or 'deno outdated' command that does an ad hoc refetch of the headers for all referenced files.

Considered alternatives:
- well known path of json file with versions and vulnerabilities, pros: no need for server support to add the headers, cons: we would have to find a way to know at what point of the path we need to check for this file and this would put a strict structure expectation of what a "package" is but this is much more flexible in deno than nodejs, also this would mean noise when trying to load the version and vulnerability files from servers that don't have those, similar to annoying search engine requests to robots.txt on all webservers

- checking in a reposity/service, pros: would have a central configurable source of truth similar to how artifactory etc. are setup, cons: this would bring back a lot of annoyances from npm  that we tried to get rid of such as having to configure a package server and complex setups for multiple sources of code
Repository: kubernetes
Issue: Log sampled successful probe execution with higher verbosity
Labels: priority/backlog,sig/node,kind/feature,sig/instrumentation,triage/accepted

/sig node
/sig instrumentation
/kind feature
/priority backlog

It will be useful to log successful probes execution details with higher verbosity once in a while. With the default verbosity no information on successful probe execution is reported. Which is fine as it typically very verbose and rarely needed. However if somebody investigating a problem with probes and cannot make sense why they are not failing when expected to fail, logs would be very interesting.

One suggestion may be to log successful probe execution logs with higher verbosity once in 15 minutes or so. This will make sure that logs are not too verbose, while allowing troubleshooting without changing verbosity to higher level.