sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Macos TLS not giving the struct requested alignment?
Labels: O-macos,A-thread-locals,C-bug

I've only gotten bug reports from other users, and seen this as a failure in CI - only on macos. [(Original matrixmultiply bug report)](https://github.com/bluss/matrixmultiply/issues/55). Haven't tested on the actual platform myself.

We setup a buffer in a struct with 32-alignment, put it in thread local storage.
And before doing the critical stuff, there's a debug assertion that ensures the pointer has the required 32-alignment;
this debug assertion fails about half the time on macos, apparently. (So the struct is probably 16-aligned in reality).


```rust
use std::cell::UnsafeCell;

// set up buffer for masked (redirected output of) kernel
const KERNEL_MAX_SIZE: usize = 8 * 8 * 4;
const KERNEL_MAX_ALIGN: usize = 32;

#[repr(align(32))]
struct MaskBuffer {
    buffer: [u8; KERNEL_MAX_SIZE],
}

thread_local! {
    static MASK_BUF: UnsafeCell<MaskBuffer> =
        UnsafeCell::new(MaskBuffer { buffer: [0; KERNEL_MAX_SIZE] });
}
```


I expected the buffer to be 32-byte aligned after this.

The alignment is tested with the following code:

```rust
let ptr_outer = MASK_BUF.with(|buf| buf as *const _);
let ptr = MASK_BUF.with(|buf| (*buf.get()).buffer.as_mut_ptr());

debug_assert_eq!(ptr_outer as usize % KERNEL_MAX_ALIGN, 0, "thread local's alignment failed");
debug_assert_eq!(ptr as usize % KERNEL_MAX_ALIGN, 0, "thread local->buffer align");
```

(Could it be debated here - can we expect `&MaskBuffer.buffer` to be 32-byte aligned, or just `&MaskBuffer` itself? Anyway, to be sure, the CI reproducer tests the alignment of `&MaskBuffer` itself, that's `ptr_outer` (well, `&UnsafeCell<MaskBuffer>`, but should be same thing?).


The problem is reproduced in matrixmultiply's CI here: https://github.com/bluss/matrixmultiply/pull/60 in [this macos build](https://github.com/bluss/matrixmultiply/runs/4200502196?check_suite_focus=true). The build log shows the alignment debug assertion tripping. This is not an active bug in that crate, it's been worked around.

I'm not sure what's happening. All the alignments [look correct when I try to make a simple reproducer](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c0ba2f4528951c3ce3cb59bb648b280c) and read the alignments in the emitted llvm-ir file (target `x86_64-apple-darwin`).
Repository: pytorch
Issue: Changing the type of dtype argument in softmax, log_softmax, and softmin is possibly BC-breaking.
Labels: module: bc-breaking,triaged,module: norms and normalization,topic: bc breaking

## Issue description

https://github.com/pytorch/pytorch/pull/68336 changes the type of `dtype` argument of `softmax`, `log_softmax`, and `softmin` from `Optional[int]` to `Optional[DType]` where `DType = torch.types._dtype if typing.TYPE_CHECKING else int` to support MyPy and TorchScript.

This change may be BC-breaking but no evidence so far.

cc @ezyang @gchanan
Repository: rust
Issue: User-created 'core' crate confusingly shadows std 'core' crate
Labels: A-diagnostics,A-resolve,T-compiler,D-confusing,D-newcomer-roadblock

<!--
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.
-->

This user reported a confusing error about `core` namespace not implementing an expected trait: https://twitter.com/Luminoth82/status/1459602117803450368

```
error[E0433]: failed to resolve: could not find `marker` in `core`
 --> runner-gui/src/app.rs:6:41
  |
6 | #[derive(Debug, Copy, Clone, PartialEq, EnumIter)]
  |                                         ^^^^^^^^ could not find `marker` in `core`
  |
  = note: this error originates in the derive macro `EnumIter` (in Nightly builds, run with -Z macro-backtrace for more info)
```

The root issue turned out to be that they had defined their own `core` crate which was shadowing the standard `core` crate. But the confusing error seems like it could be improved.

<!-- The following is not always necessary. -->
Ideally the output should look like:

```
error[E0433]: failed to resolve: could not find `marker` in `core`
 --> runner-gui/src/app.rs:6:41
  |
6 | #[derive(Debug, Copy, Clone, PartialEq, EnumIter)]
  |                                         ^^^^^^^^ could not find `marker` in `core`
  |
  = note: this error originates in the derive macro `EnumIter` (in Nightly builds, run with -Z macro-backtrace for more info)
  = note: the `core` crate is defined in `runner-gui\Cargo.toml`
```

Or some other additional note clarifying exactly which `core` is being built, or mentioning that there are shadowed `core` crates in scope, etc.

<!--
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: PowerToys
Issue:  Add command line switch to run a powertoy
Labels: Idea-Enhancement,Area-Runner

### Description of the new feature / enhancement

This is mostly about powertoys run, but it would be nice to be able to do `powertoys.exe --run 'name-of-toy'` and have that power toy run. It looks like this is already done for opening the settings dialog directly, so implementation shouldn't be too complex (if i can figure out how i'll open a PR)

### Scenario when this would be used?

Usually for making a shortcut or in automation in general

### Supporting information

_No response_
Repository: pytorch
Issue: [LTC][BE] Fix all compile warnings
Labels: triaged,lazy

Currently there are a lot of warning in the staging branch. We should probably revisit and fix all compile warnings once things get merged.
Repository: pytorch
Issue: [LTC][BE] Make the compile flags more strict
Labels: triaged,lazy

1. The staging branch flags are very loose, for example, it bypasses warnings for missing return statements. Need to investigate if the master flags are the same.
2. Consider treating warnings as error.
Repository: flutter
Issue: Eliminate definition: _SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING
Labels: platform-windows,a: desktop,P2,c: tech-debt,team-windows,triaged-windows

This disables a warning that codecvt_utf8 is deprecated in C++17. This is an issue on Windows. Instead, we should use `MultiByteToWideChar()` and `WideCharToMultiByte()`. See notes on this StackOverflow post: [How do you properly use WideCharToMultiByte](https://stackoverflow.com/questions/215963/how-do-you-properly-use-widechartomultibyte).

We currently define this in:
* [ ] fml/BUILD.gn
* [X] shell/platform/common/BUILD.gn (fixed)
Repository: opencv
Issue: Story: support for oneAPI compilers
Labels: category: build/install,category: infrastructure

Clang, DPC++, ICC on Windows/Linux.

Current status: TBD
Repository: flutter
Issue: CMake always runs `flutter assemble`, which adds ~5 seconds with no work to be done
Labels: tool,platform-windows,c: proposal,a: build,perf: speed,P2,team-tool,triaged-tool

## Use case

```cmd
flutter build windows --release -v
```

Shows extra 5 seconds spend somewhere. Loading the .sln file, using the "Build Logging" 
extensions, shows 5 seconds spend everytime the app is build (Ctrl+Shift+B) from Visual Studio.

This led to the discovery it's due to the `_phony_` target that makes it rebuilt everytime.

Now, while `hot-reload` is great and one of the best selling thing about flutter, a slow initial
build time, or slow in general build time if you work from the C++ side is not great.

Removing the `_phony_` target from `CMakeLists.txt` made the problem go away
(from 11secs -> 6secs compile), but not sure why it was put in the first place, or 
whether it's safe to do so.

## Proposal

Look into whether it'll be possible to shed these 5 secs (50% of the time right now, spent
on my machine to `flutter build windows --release` . 

[with_phony.txt](https://github.com/flutter/flutter/files/7550758/with_phony.txt)
[without_phony.txt](https://github.com/flutter/flutter/files/7550759/without_phony.txt)
Repository: pytorch
Issue: Review disabling tests workflow
Labels: triaged

Today in PyTorch tests can be disabled using issues, which is super quick and convenient.

However, this means that to understand which tests are run developers must check the test itself and see if there's an issue disabling it. It's also a little confusing what the development workflow is for resolving these skips (although we could probably educate developers about how to enable the test on their PRs where appropriate), and what happens when the issue goes away and developer PRs are based on builds without the fix (although GH Actions auto-rebases PRs, which minimizes the impact of this issue).

Ideally there'd be a mechanism as simple as filing an issue that would automagically create a skip next to the test. That way the code would be a readable source of truth that developers could understand and change as usual. Automatically adding these skips can sometimes be complicated, however. We could have OnCalls add the skips manually, or we could investigate a compromise solution where PRs adding test skips are autogenerated but they modify an existing list of tests to skip instead of annotating tests directly. 

I imagine different people will have different opinions about what's best (issues, a list, manually adding skips, some other thing). Personally think we should just have OnCalls and/or test owners quickly land test skips or start by filing an issue disabling a test and then convert it to an actual test skip in the code for simplicity. This is a little more work on the OnCall but means we won't have to build and maintain new infra, and as flakiness goes down we should be bothered by this less and less.
Repository: opencv
Issue: JavaScript: CV_OUT reference parameters are not handled properly
Labels: bug,category: javascript (js),effort: few weeks

reproducer (test case): #21045 ([commit](https://github.com/opencv/opencv/pull/21045/commits/abe0a08f6766e5e18dca7dd9ef8d413238ef5172))

JavaScript doesn't know anything about references. Parameters are passed by values.
So bindings should be updated.

---

#### Design options

Group outputs into:
- &#x2716; "object" (dictionary). Good for debugging (parameter names can be used). User code may not require changes if extra output parameter is added. Parameter rename would break user code.
- &#x2714; Array. Similar to Python (which returns tuple). **Existed JS manual wrappers using this scheme**

**Note:** [ES6 destructuring assignment](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Destructuring_assignment) supports both arrays and objects.

Handling of arrays (OutputArray, InputOutputArray, CV_OUT Mat references):
- &#x2714; - include (Python behaves like that)
- &#x2716; - exclude arrays from result

---

/cc @huningxin
Repository: storybook
Issue: Angular - Values specified in the URL args are not persisted or reflected in the component story canvas
Labels: bug,angular,args

**Describe the bug**
1) Copy/paste from a bug mentionned in Discord from [@Kedar](https://discord.com/channels/486522875931656193/501692020226654208/910288314983129168)

> I implemented Storybook controls for Angular components. 
> The controls selected are getting set as the args  param in the URL. But, when I refresh the page (or open the iframe version), the values specified in the URL args are not persisted or reflected in the component story canvas.
> It is only when I change one of the Controls on the page that all the other values from the URL get reflected on the component canvas.
> Has anyone else faced the same issue? Thanks.

2) As complement and relative to, while switching a control it doesn't update the component. On the 6.3.12 stable release the bug is slightly different as described by [@MarceloBob](https://discord.com/channels/486522875931656193/501692020226654208/911583558211080212)

> Hey, guys. New user here, I'm having show code problems in the stories that are created, when I click show code to show the code, which the component generates, it shows the code, but when I use the controls it changes the generated code, but with a delay .
> Example: when I click on an activation control (boolean) it doesn't change the generated show code, but when I click on another control it changes the previous one.

3) Relative to as well, there is this issue in the documentation side where switching a param doesn't change the previewed component: [https://www.youtube.com/watch?v=W3XgO-Th6U0](https://www.youtube.com/watch?v=W3XgO-Th6U0)

**System**
Windows / Storybook Angular

The 3 issues described here are reproductible on the [shared ](https://github.com/Tim-arts/storybook-repro--issue-build-storybook)reproduction.
Repository: pytorch
Issue: cudnn_convolution_relu is 17x slower for 7x7 convolutions and channels last
Labels: module: cudnn,module: cuda,triaged

## 🐛 Bug

cudnn_convolution_relu fuses conv2d and relu, but appears much slower under certain conditions. This requires manual workarounds. Some options include landing the workaround in PyTorch or improving the performance of these cuDNN kernels.

## To Reproduce

```
import torch


@torch.inference_mode()
def benchmark_torch_function(iters, f, *args, **kwargs):
    f(*args, **kwargs)
    torch.cuda.synchronize()
    start_event = torch.cuda.Event(enable_timing=True)
    end_event = torch.cuda.Event(enable_timing=True)
    start_event.record()
    for i in range(iters):
        f(*args, **kwargs)
    end_event.record()
    torch.cuda.synchronize()
    return start_event.elapsed_time(end_event)


def my_conv2d_relu(inp, weight, bias, stride, padding, dilation, groups):
    x0 = torch.conv2d(inp, weight, bias, stride, padding, dilation, groups)
    return x0.relu_()


def run_benchmark(inp, weight, bias, stride, padding, dilation, groups):
    print("inp.size(): ", inp.size(),
          "weight.size(): ", weight.size(),
          "stride: ", stride,
          "padding: ", padding,
          "dilation: ", dilation,
          "groups: ", groups)
    t0 = benchmark_torch_function(1000, my_conv2d_relu,               inp, weight, bias, stride, padding, dilation, groups)
    t1 = benchmark_torch_function(1000, torch.cudnn_convolution_relu, inp, weight, bias, stride, padding, dilation, groups)
    return t0 / 1000, t1 / 1000

torch.backends.cudnn.benchmark=True
groups = 1
channels_in = 3
channels_out = 64
kernel_size = (7, 7)
dtype = torch.float16
device = torch.device('cuda')
inp = torch.empty((64, 3, 288, 288), dtype=dtype, device=device)
inp = inp.contiguous(memory_format=torch.channels_last)
weight = torch.empty((channels_out, channels_in, kernel_size[0], kernel_size[1]), dtype=dtype, device=device)
weight = weight.contiguous(memory_format=torch.channels_last)
bias = None
print(run_benchmark(inp, weight, bias, (2, 2), (3, 3), (1, 1), groups))
```

The output is

```
inp.size():  torch.Size([64, 3, 288, 288]) weight.size():  torch.Size([64, 3, 7, 7]) stride:  (2, 2) padding:  (3, 3) dilation:  (1, 1) groups:  1
(0.7142583618164062, 12.0811875)
```

## Expected behavior

This shouldn't be 17x slower. Ideally it'd be faster, but at least it should match the performance of the decomposed operator.

## Environment

This was run on an A100 using CuDNN 8.2 as packed with the latest release of PyTorch (1.10), more specifically py3.9_cuda11.3_cudnn8.2.0_0 as found on [PyTorch's conda channel](https://anaconda.org/pytorch/pytorch/files). I can provide further details if needed.

## Additional context

None


cc @csarofeen @ptrblck @xwang233 @ngimel
Repository: rust
Issue: E0432 on lack of entry in [build-dependencies]
Labels: A-diagnostics,T-compiler

I attempted to pre-process data for my application with a build script, but I forgot to copy some `[dependencies]` to `[build-dependencies]` and got a very confusing E0432 when trying to build.


Given the following code: 

```rust
use walkdir::WalkDir;
use serde_json::json;

fn main() {
        for entry in WalkDir::new("crates").into_iter().filter_map(|e| e.ok()) {
[following has been omitted]}}
```

The current output is:

```
error[E0432]: unresolved import `walkdir`
 --> build.rs:1:5
  |
1 | use walkdir::WalkDir;
  |     ^^^^^^^ use of undeclared crate or module `walkdir
```
Ideally there should be a case for handling those few times where a "missing" dependency is spotted under different [ ] 

I know there won't be many cases like that, but I guess it would be helpful for those few scatterbrains like myself.
Repository: electron
Issue: [Feature Request]: Improved Bluetooth device selection experience
Labels: enhancement :sparkles:,component/deviceAccess

### 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 feature request that matches the one I want to file, without success.

### Problem Description

There seems to be insufficient API methods available to build a UI to select a Bluetooth device. 

The serial API has `Serial.getPorts()`, HID has `HID.getDevices()`. Bluetooth has `bluetooth.getDevices()` hidden behind `webPreferences: { experimentalFeatures: true }`.

Calling `await navigator.bluetooth.getDevices()` when `experimentalFeatures` is `true` results in an empty array being returned almost immediately, then the `select-bluetooth-device` event firing with the available devices on the main process a little later: `[ { deviceName: 'Device Name', deviceId: 'FF:FF:FF:FF:FF:FF' } ]`

`navigator.bluetooth.requestDevice` accepts filters, but they don't seem to include the `deviceId`, so even with some creative IPC, it's not possible for the renderer to request a specific device.

****

### Proposed Solution

- Similar to Serial and HID, usage of the `setPermissionCheckHandler` and `setDevicePermissionHandler` APIs to allow the developer to grant permissions for these bluetooth devices on the main process.

- Stabilisation of the `bluetooth.getDevices()` method. Given Bluetooth's scanning characteristics, having a way to abort the scan would also be useful, perhaps with an options bag passed as a first parameter, with an AbortController for cancellation. There's probably some default timeout that would be ignored when the cancellation parameter was passed. A callback to 'stream' BluetoothDevices as they're found would also be useful so they can be displayed as they're found instead of at the end of the timeout. Alternatively some kind of asynchronous iterator could be used with an AbortController?

- A `bluetooth.requestDevice` filter that can specify an exact deviceID would be useful.


### Alternatives Considered

User-space BLE libraries are essentially abandoned (see https://github.com/noble/noble), leaving not much choice other than implementing everything from scratch.

### Additional Information

_No response_
Repository: electron
Issue: [Feature Request]: Renderer SerialPort.getInfo() return full SerialPortObject
Labels: enhancement :sparkles:,component/deviceAccess

### 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 feature request that matches the one I want to file, without success.

### Problem Description

On the renderer process, `SerialPort.getInfo()` returns `{usbProductId: 32798, usbVendorId: 9114}`.

Separately, on the main process, `setDevicePermissionHandler` callback receives:

```
  device: {
    name: 'Trinket M0',
    product_id: 32798,
    serial_number: 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF',
    usb_driver: 'com.apple.driver.usb.cdc.acm',
    vendor_id: 9114
  }
```

It's not possible to correlate this data, since multiple devices can have the same vendor and product IDs. (There's not much stopping devices in the wild even having identical serial numbers, so realistically the comPath is the only way to differentiate between different devices plugged in at the same time.)

It's difficult to produce a UI on the renderer process without this information. The Chrome default UI uses this information to present the device names to the user.

![image](https://user-images.githubusercontent.com/13504878/142136541-bb8aaa5e-51a9-4b96-95d1-75813faa1838.png)



### Proposed Solution

`SerialPort.getInfo()` on the renderer process returns this additional information.



### Alternatives Considered

User-space libraries for serialport interaction do exist (it's what we're using now).


### Additional Information

Interestingly the Chrome UI displays the comPath in the UI, I can't seem to find that information anywhere in these calls. It would be good to also supply that information.
Repository: PowerToys
Issue: Proposal: Shifting how search works in PT Run
Labels: Needs-Community Feedback,Product-PowerToys Run,Area-Quality,Run-Plugin,Run-Plugin Manager

### Description of the new feature / enhancement

I'm proposing we shift on PT Run search works by maybe default, maybe permanent. 
- Program search + Windows settings are only global searches by default
   - Items that don't infer direct hits like Folder search could as well since they require things like `c:\` to be invoked.
- everything else is triggered via plugin activation command

**Why:**
- Some plugins have latency we just can't get around.  Anything that does a web search would also hit this. Since we wait for all results to come back since we have combined results, the slowest result impacts everything. 
   - if we didn't, the UX would 'pop' and rearrange itself as results flowed in causing misclicks
- Simplifies weighting.  Which is more important, a document named "Visual Studio" or the Application "Visual Studio"
- As a searching person, you have context of what you want.  If you want a doc, you know it is a doc. if you want a shell command, you know it.

### Scenario when this would be used?

quick app trigger, more relevant results

### Supporting information

Issues like https://github.com/microsoft/PowerToys/issues/12968 have always been a constant issue against PT Run.