sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: tauri
Issue: [bug] tauri android can't connect to tauri.localhost,dns error
Labels: type: bug,status: needs triage,platform: Android

### Describe the bug

After Android apk package is built and installed, the web page that displays: https://tauri.localhost error tying to connect :dns error;failed to lookup adress.

```
error sending request for url
(http://tauri.localhost/): error trying to connect: dns error: failed to lookup address information: No address associated with hostname
```

### Reproduction

_No response_

### Expected behavior

_No response_

### Full `tauri info` output

```text
[✔] Environment
    - OS: Mac OS 14.3.0 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.75.0-nightly (9d83ac217 2023-10-31)
    ✔ cargo: 1.75.0-nightly (b4d18d4bd 2023-10-31)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: nightly-aarch64-apple-darwin (default)
    - node: 21.6.1
    - pnpm: 8.15.1
    - yarn: 1.22.21
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.2
    - tauri-build [RUST]: 2.0.0-beta.1
    - wry [RUST]: 0.35.2
    - tao [RUST]: 0.25.0
    - tauri-cli [RUST]: 2.0.0-alpha.17
    - @tauri-apps/api [NPM]: 2.0.0-beta.0
    - @tauri-apps/cli [NPM]: 2.0.0-beta.1

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ["../dist"]
    - framework: React
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: rust
Issue: Consider linting against 00B7 aka interpunct aka middle dot
Labels: A-diagnostics,T-lang,finished-final-comment-period,disposition-postpone

### Code

```Rust
#![allow(dead_code)]
#![deny(uncommon_codepoints)]
const COL·LECCIÓ: () = ();// This is Catalan

// The below is not allowed by the lexer today...
// const ·START: () = ();

// ... but this is allowed today ...
const MID·DLE: () = ();

// ... and this is also allowed today
const END·: () = ();


fn main() {
println!("{}", r#"
COL·LECCIÓ
·START
MID·DLE
END·
"#)
}
```


### Current output

```Shell
COL·LECCIÓ
·START
MID·DLE
END·
```

but note that visual of the first line is font-dependent, in terms of how the columns of a fixed-width font line up; the [playpen](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=2ea3908857f167a11806a7aaf5d22ba1) collapses the L·L into a single glyph that occupies one character width.



### Desired output

I'm not certain. I just want to make sure we follow-up on PR #120695

The options I see are either:

1. Leave things as they are (00B7 is hard-rejected as an initial character, and silently accepted in all other contexts)
2. Adopt something like what was proposed in PR #120695: continue hard-rejecting 00B7 as an initial character; lint against its occurrence as a final character, and silently accept it as a "medial" character
3. Something more aggressive than PR #120695, like linting against 00B7 in all contexts (except perhaps when it occurs in between two L's, to accommodate Catalan, as suggested by Manish [here](https://github.com/rust-lang/rust/pull/120695#issuecomment-1932984685))
4. Other options? (We probably don't get any benefit from deviating far from Unicode committee recommendations, so we probably do not want to start *accepting* 00B7 as an initial character)


### Rationale and extra context

_No response_

### Other cases

_No response_

### Rust Version

```Shell
Stable channel

Build using the Stable version: 1.76.0
```


### Anything else?

_No response_
Repository: go
Issue: proposal: x/sys/windows: allow specifying Security Capabilities in SysProcAttr
Labels: OS-Windows,Proposal

### Proposal Details

Allow adding [Security Capabilities](https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-security_capabilities) to [`SysProcAttr`](https://pkg.go.dev/syscall?GOOS=windows#SysProcAttr) on Windows. Note this is separate from the existing [`SecurityAttributes`](https://pkg.go.dev/syscall?GOOS=windows#SecurityAttributes) struct which can be set as the `ProcessAttributes` or `ThreadAttributes` field.

**Motivation**

Recently as part of work to sandbox a subprocess, the [Nomad](https://github.com/hashicorp/nomad) team at HashiCorp needed to add a `SECURITY_CAPABILITIES` struct to the `StartupInfoEx` for a process. Because this is not exposed in `SysProcAttr` this involved writing an unfortunate amount of code, much of which had to be simply lifted from the `os/exec` stdlib. See [`helper/winexec/create.go`](https://github.com/hashicorp/nomad/commit/df865033494574de14da687c999d66b799899b21#diff-ef39dacf2c7aed84b516ce9df08878bdb872c557e469b89a41474b6cd11987c8)

**Implementation Notes**

Previously a proposal was implemented to add a `ParentProcess` field to `SysProcAttr` for Windows https://github.com/golang/go/issues/44011. This was discussed around the same time as a rejected proposal to add the full `StartupInfoEx` struct https://github.com/golang/go/issues/44005.

One of the reasons why the `StartupInfoEx` proposal was rejected was because it resulted in ambiguity around how one would merge any default attributes with ones provided by the user. There are two options to work around this:

**Option 1: Extensible**

Our implementation referenced above adds a `ProcThreadAttributes` field to the forked `os/exec.Cmd` which is a slice of `ProcThreadAttribute`. This instead could be added to `SysProcAttr` as an extensible way of adding more attributes:

```
type SysProcAttr struct {
    // ...
    ProcThreadAttributes []ProcThreadAttribute
}

type ProcThreadAttribute struct {
	Attribute uintptr
	Value     unsafe.Pointer
	Size      uintptr
}
```

When the `StartupInfoEx` struct is built, we call `newProcThreadAttributeList` with a count of `len(ProcThreadAttributes) + 2` (taking the default attributes from [`syscall/exec_windows.go`](https://cs.opensource.google/go/go/+/refs/tags/go1.22.0:src/syscall/exec_windows.go;l=335)). Any `ProcThreadAttributes` that come from the user override those defaults if using the same `Attribute` field, which makes for unambiguous behavior.

**Option 2: SecurityAttributes only**

An alternative would be to add a `SecurityCapabilities` field to `SysProcAttr` and

```
type SysProcAttr struct {
    // ...
    SecurityCapabilities SecurityCapabilities
}

type SecurityCapabilities struct {
	AppContainerSid uintptr // PSID *windows.SID
	Capabilities    uintptr // SID_AND_ATTRIBUTES *windows.SIDAndAttributes
	CapabilityCount uint32
	Reserved        uint32
}
```

It would then be up to `syscall/exec_windows.go` to create the appropriate attributes for `StartupInfoEx`, as we do already for the parent handle, etc.
Repository: pytorch
Issue: Inability to represent size-like expressions causes us to choke when users use list of offsets representation
Labels: triaged,oncall: pt2,module: dynamic shapes

### 🐛 Describe the bug

Internal xref: https://fb.workplace.com/groups/6829516587176185/permalink/6829896033804907/

For dealing with packed sequence representations (e.g., KJT), one typically has a problem of how to represent the lengths of each packed sequence inside the tensor. There are two obvious choices: list of sizes and list of offsets.

List of sizes representation seems to work pretty well with our unbacked SymInt reasoning (using this representation, I was able to trace through nontrivial KJT torchrec code in torchrec_dlrm).

However, list of offsets representation works less well. The problem is that when you want to use a start and end offset to construct a tensor view for a specific sequence inside the packed sequence, the resulting tensor has size `end - start`. We would like to represent this size as size-like. But per https://github.com/pytorch/pytorch/pull/119043 we can't actually represent arbitrary expressions as size-like. In fact, in this case, @PaulZhang12 has reported that allocating a new symbol to represent `end - start` and constraining it as size like is sufficient to make our code go through (this makes sense, because we know list of sizes rep works). But it would be nice for the framework to do this automatically somehow.

At some point need to get a self-contained repro in OSS, Paul's example is pretty short but it is using a variant of KJT called IntTensor KJT.

cc @msaroufim @bdhirsh @anijain2305 @zou3519 @lezcano 

### Versions

main
Repository: storybook
Issue: [Bug]: import statements in Source block not available as input to transform function
Labels: feature request,help wanted,block: source

### Describe the bug

My team manages a Lerna monorepo of React component packages.  We use the `Source` block component in our MDX documentation.  Due to the location of the `stories.tsx` files relative to the component itself, they are often imported like this:

```
import {Tabs} from '../tabs.react-component';
```

In our `Source` block, the "Show code" section shows something like this:

```
import { Tabs } from '../tabs.react-component';

<Tabs title="foo" content="bar" />
```

^ We have feedback from developers that the relative path import in the code block is not as helpful as if they were listed by the actual npm package they are shipped with, for example:

```
import { Tabs } from '@foo/react-tabs-component';
```

We have tested out using imports like this in storybook, and they DO work, but it breaks hot re-loading of the page (without having Lerna rebuild packages), so it diminishes my teams ability to maintain these components.

I attempted to use the `transform` option as part of the Source component, but quickly realized that the `import` statements in the code block are not provided as part of the actual string passed in as the first parameter (the second is StoryContext type).  

Searching through the source code I couldn't easily determine where these import statements were being applied or if there was a way I could tie into some existing functionality to just modify the imports for our developers.  I'm open to any suggestions as well. Thanks!


### To Reproduce

_No response_

### System

```bash
storybook@7.6.13
```


### Additional context

_No response_
Repository: go
Issue: x/net/internal/quic/cmd/interop: TestTransfer failures
Labels: NeedsInvestigation

```
#!watchflakes
default <- pkg == "golang.org/x/net/internal/quic/cmd/interop" && test == "TestTransfer"
```

Issue created automatically to collect these failures.

Example ([log](https://build.golang.org/log/5ce22bd9618e5aeb7653f3bf54c912c296e738c3)):

    --- FAIL: TestTransfer (10.04s)
        main_test.go:66: run server: [-listen localhost:0 -cert /tmp/workdir/tmp/TestTransfer3219762341/003/cert.pem -key /tmp/workdir/tmp/TestTransfer3219762341/003/key.pem -root /tmp/workdir/tmp/TestTransfer3219762341/001]
        main_test.go:81: server: 2024/02/08 18:27:03 listening on 127.0.0.1:26879
        main_test.go:66: run client: [-output /tmp/workdir/tmp/TestTransfer3219762341/002 https://localhost:26879/source]
        main_test.go:81: client: 2024/02/08 18:27:03 listening on [::]:26879
        main_test.go:81: client: 2024/02/08 18:27:13 localhost:26879: closed connection: CONNECTION_REFUSED: "handshake timeout"
        main_test.go:90: client done
        main_test.go:143: reading downloaded file: open /tmp/workdir/tmp/TestTransfer3219762341/002/source: no such file or directory
        main_test.go:90: server done


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: rust
Issue: Feature gates for renamed features hard error, breaking "nightly-detecting" crates
Labels: A-diagnostics,T-compiler

A common pattern in the wild is to do this kind of thing in `build.rs`:

```rust
        if channel == "nightly" {
            println!("cargo:rustc-cfg=feature=\"something\"");
        }
```

Where `something` is a Cargo feature that is used in code as `#![cfg_attr(feature = something, feature(cool_new_feature))]`.

This is generally considered an anti-pattern. However, despite being proscribed, it is found often in the ecosystem.

A more advanced version that actually build-tests some code with the feature is found in [some popular crates](https://docs.rs/crate/proc-macro2/latest/source/build.rs); that version is less problematic as it will silently fall back to the stable behavior when the feature changes.

This leads to a really bad situation when the feature is has its name changed or split up into smaller features. It is currently occuring with the ahash crate, as can be seen in https://github.com/tkaitchuck/aHash/issues/200.

People depending on the crate and running nightly get a hard error with the crate because the feature flag "no longer exists". If the crate removes the feature flag, that's an immediate MSRV bump for everyone else since the crate uses still-unstable APIs.

It's particularly annoying in CI where people typically have a single Cargo.lock.

------

Most of the time a nightly feature has its name changed; there's a decent gap between the point in time in the name changes and when actual changes to the APIs behind it happen. Which means in most of these cases, the _only_ thing broken about this code on nightly is the `feature(cool_new_feature)` line, the rest will still work.


Given that this is a technique found in the wild, would it make sense to have this error behave according to `cap-lints` instead, at least in the short run after a feature is renamed, with some tracking of the rename? Every time I've seen this cause breakage there's a whole lot of should-be-unnecessary scrambling to fix transitive dependencies.
Repository: pytorch
Issue: Document how to override autocast rules properly
Labels: triaged,module: amp (automated mixed precision)

Since autocast is implemented as a dispatcher feature, and each rule is a relatively simple kernel being registered on the right key for the right kernel.

Overriding these rules can be done today by replacing the kernel registered by default with a custom one that does the appropriate casting before redispatching down in a similar way as it is done in the generic kernel we use https://github.com/pytorch/pytorch/blob/def572929b2311b769ef79e66aebc70384b0f456/aten/src/ATen/autocast_mode.h#L467-L473 .

All the tools are available to do this from a C++ extension via TORCH_LIBRARY* macros
Missing pieces for python when using torch.library:
- A way to call cached_cast from python https://github.com/pytorch/pytorch/blob/def572929b2311b769ef79e66aebc70384b0f456/aten/src/ATen/autocast_mode.cpp#L200C8-L200C19
- A public way to disable keys in python to enable calling down

cc @mcarilli @ptrblck @leslie-fang-intel @jgong5
Repository: pytorch
Issue: Extend functionality of torch.nn.functional.fold to apply to sequences (1D tensors + batch & channels) not just images (2D tensors + batch & channels)
Labels: module: nn,triaged

### 🚀 The feature, motivation and pitch

`torch.nn.functional.unfold` can be applied to sequences (1D tensors + batch & channels) and it would be helpful to be able to reverse this operation (up to addition in overlapping regions which can be addressed via a division -- see documentation for `torch.nn.functional.fold`) using `torch.nn.functional.fold`, however `torch.nn.functional.fold` only works on images (2D tensors + batch & channels) so this is not possible at present.
I suggest that `torch.nn.functional.fold` is generalised so that it can reverse `torch.nn.functional.unfold` in general (or at least for sequences), not just for images.

### Alternatives

I have found a way to do this using `Tensor.index_add` (sketched out below):
```
a = torch.tensor(range(1,18))
print(a)

b = a.unfold(0, 5, 2)

out = torch.zeros_like(a)
indices = b.flatten()-1
out = out.index_add(0, indices, b.flatten())
x = out

a = torch.ones((17,))
b = a.unfold(0, 5, 2)
out = torch.zeros_like(a)
out = out.index_add(0, indices, b.flatten())
y = out

z = x / y
print(z)
```
It would be nice to abstract these details away and just call `torch.nn.functiona.fold`, and I expect that this kind of approach is far from optimal.

### Additional context

_No response_

cc @albanD @mruberry @jbschlosser @walterddr @mikaylagawarecki
Repository: PowerToys
Issue: Powertoys Run stops starting or response time slows down.
Labels: Issue-Bug,Product-PowerToys Run,Area-Quality,Needs-Triage

### Microsoft PowerToys version

0.78.0

### Installation method

PowerToys auto-update

### Running as admin

Yes

### Area(s) with issue?

PowerToys Run

### Steps to reproduce

[PowerToysReport_2024-02-09-04-23-59.zip](https://github.com/microsoft/PowerToys/files/14213748/PowerToysReport_2024-02-09-04-23-59.zip)

First of all, there is no clear reproduction procedure and it may depend on my personal environment, so please delete the report if it is inappropriate.

The steps to reproduce it are unknown.
This occurs when the PC is left on for a long time and PowerToys Run is used frequently.
The problem will be resolved by restarting the PC or terminating all Powertoys processes using the task manager.
By the way, when you end the Powertoys process in Task Manager, all other Powertoys-related processes will also end, but only Powertoys Run will remain, so you will need to end the processes individually.

### ✔️ Expected Behavior

I expect it to work properly at all times.

### ❌ Actual Behavior

Powertoys Run stops starting or response time slows down.

### Other Software

_No response_
Repository: flutter
Issue: clang-tidy roll to version c58bc24fcf67 is failing
Labels: engine,P1,team-engine,triaged-engine

The roll of the current release of Clang is failing due to issues related to clang-tidy.

(See roll PR https://github.com/flutter/engine/pull/50109)

* The `clang-analyzer-optin.core.EnumCastOutOfRange` check is producing warnings on some third-party headers (vulkan-headers and GTK).  I suspect that these are false positives.

* clang-tidy is segfaulting when processing some source files in the engine tree

@zanderso @chinmaygarde
Repository: godot
Issue: Wayland: Editor crashes trying to load any project.
Labels: bug,platform:linuxbsd,topic:porting,needs testing,crash

### Tested versions

- Reproducible in Godot 4.3 dev 3

### System information

Ubuntu 22.04.3 LTS using Wayland.

### Issue description

If configured to use Wayland, the editor crashes when trying to load any project. It works as usual when using x11.
The console output is:
```
================================================================
handle_crash: Program crashed with signal 11
Engine version: Godot Engine v4.3.dev3.official (36e943b6b20cb7a8a89bc30489c4a81c3e149d74)
Dumping the backtrace. Please include this when reporting the bug to the project developer.
[1] /lib/x86_64-linux-gnu/libc.so.6(+0x42520) [0x7fb750c42520] (??:0)
[2] /lib64/ld-linux-x86-64.so.2(+0x324d) [0x7fb750f8e24d] (??:0)
[3] /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_exception+0x88) [0x7fb750d74a98] (??:0)
[4] /lib/x86_64-linux-gnu/libc.so.6(_dl_catch_error+0x33) [0x7fb750d74b63] (??:0)
[5] /lib/x86_64-linux-gnu/libc.so.6(+0x9012e) [0x7fb750c9012e] (??:0)
[6] /lib/x86_64-linux-gnu/libc.so.6(dlclose+0x28) [0x7fb750c8fe58] (??:0)
[7] /lib/x86_64-linux-gnu/libnvidia-vulkan-producer.so(ProducerCleanup+0x4d) [0x7fb724c01e0d] (??:0)
[8] /lib/x86_64-linux-gnu/libnvidia-vulkan-producer.so(ProducerInit+0x2bb) [0x7fb724c020db] (??:0)
[9] /lib/x86_64-linux-gnu/libnvidia-glcore.so.535.154.05(+0x1819db2) [0x7fb72ba19db2] (??:0)
[10] /lib/x86_64-linux-gnu/libnvidia-glcore.so.535.154.05(+0x18440ff) [0x7fb72ba440ff] (??:0)
[11] /lib/x86_64-linux-gnu/libnvidia-glcore.so.535.154.05(+0x186811d) [0x7fb72ba6811d] (??:0)
[12] /lib/x86_64-linux-gnu/libGLX_nvidia.so.0(+0x9cb50) [0x7fb748161b50] (??:0)
[13] /lib/x86_64-linux-gnu/libvulkan.so.1(+0x34c4e) [0x7fb74875ac4e] (??:0)
[14] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x1035e41] (??:0)
[15] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x103cd99] (??:0)
[16] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x432dac] (??:0)
[17] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x47f1a6] (??:0)
[18] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x4ada19] (??:0)
[19] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x4af152] (??:0)
[20] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x407ee7d] (??:0)
[21] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x50d447] (??:0)
[22] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x4077924] (??:0)
[23] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x41fc5b] (??:0)
[24] /lib/x86_64-linux-gnu/libc.so.6(+0x29d90) [0x7fb750c29d90] (??:0)
[25] /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80) [0x7fb750c29e40] (??:0)
[26] /home/jcarlos/Godot/Godot_v4.3-dev3_linux.x86_64() [0x42be2a] (??:0)
-- END OF BACKTRACE --
================================================================
```

### Steps to reproduce

Launch Godot with the --display-driver wayland option. Create a new project and try to load it.

### Minimal reproduction project (MRP)

N/A
Repository: deno
Issue: WebSocketStream fails op sanitizers
Labels: bug,tests,ext/websocket

In #22355, we restored a websocketstream_test that was being ignored. The op sanitizer complains about quite a few methods in here, suggesting that we're leaking ops or the code is not functioning properly.

We need to clean up WebSocketStream and ensure all these tests pass cleanly.
Repository: ollama
Issue: Provide logits or logprobs in the API
Labels: feature request,api

Feature request:
How can i get logits (probabilites of each next token), during generation, just like I can do it in Open AI API (logprobs)? This feature will be helpfull for apps, that use logprobs to measure model avareness and confidence.
Repository: pytorch
Issue: Follow-up #119356: Preserve node names for torch.export.export
Labels: onnx-needs-info,export-triaged,oncall: export

### 🐛 Describe the bug

As commented https://github.com/pytorch/pytorch/pull/119356/files#r1481784324 and https://github.com/pytorch/pytorch/pull/119356/files#r1483367633

When models are exported with torch.export.export, input names are renamed to an unintuitive argXXX_YYY.
Preserving naming is great for debugging purposes as it helps the mapping between the original model and the resulting FX graph

### Versions

main

cc @avikchaudhuri @gmagogsfm @zhxchen17 @tugsbayasgalan @angelayi @suo @ydwu4
Repository: godot
Issue: [KDE] Godot doesn't register the touchpad tap-to-click left-clicks to close popup dialogs (when Tap-to-drag is disabled)
Labels: bug,platform:linuxbsd,topic:porting,confirmed

### Tested versions

- Reproducible in every version after 4.0

### System information

Kubuntu 23.10, Godot 4.*, Forward+, AMD Ryzen 5500U

### Issue description

Normal button-clicks don't have this problem and close menus as expected.

This only started happening when I switched to Kubuntu 23.10, it had never appeared before then.

It seems like the kernel versions that 23.10 introduced caused some bugs, because I also had a similar bug to #88113, where I explained my issue in detail, though the most recent kernel update fixed it. Also, as opposed to that one, this one happens both on X11 and Wayland.

### Steps to reproduce

Open up any right-click menu.

### Minimal reproduction project (MRP)

N/A
Repository: go
Issue: all: Linux/ARM builder fail with "'-mfloat-abi=hard': selected architecture lacks an FPU"
Labels: NeedsInvestigation

```
#!watchflakes
default <- goarch == "arm" && goos == "linux" && `'-mfloat-abi=hard': selected architecture lacks an FPU`
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8756862874361796145)):

    === RUN   TestInstall
        carchive_test.go:487: [go tool cgo -objdir /home/swarming/.swarming/w/ir/x/t/carchive_test3149995538/_obj309608086 -exportheader p.h p/p.go]
        carchive_test.go:489: [go install -buildmode=c-archive ./libgo]
        carchive_test.go:489: # runtime/cgo
            cc1: error: '-mfloat-abi=hard': selected architecture lacks an FPU
        carchive_test.go:489: exit status 1
    --- FAIL: TestInstall (8.31s)


— [watchflakes](https://go.dev/wiki/Watchflakes)