sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [flutter_tools] PathNotFoundException: Cannot open file, path = '.../core_device_list.json' (OS Error: No such file or directory, errno = 2)
Labels: tool,P2,c: flake,team-tool,triaged-tool

This is happening both in the wild and on CI.

A crash report in beta/3.19.0-0.2.pre:

```
PathNotFoundException: Cannot open file, path = '/var/folders/kl/hdgxgrc93gs870zyrkz0dc_m0000gn/T/flutter_tools.iWDQmn/core_devices.RElIQa/core_device_list.json' (OS Error: No such file or directory, errno = 2)
at _File.throwIfError(file_impl.dart:675)
at _File.openSync(file_impl.dart:490)
at _File.readAsBytesSync(file_impl.dart:574)
at _File.readAsStringSync(file_impl.dart:624)
at ForwardingFile.readAsStringSync(forwarding_file.dart:99)
at IOSCoreDeviceControl._listCoreDevices(core_devices.dart:83)
at <asynchronous gap>(async)
at IOSCoreDeviceControl.getCoreDevices(core_devices.dart:114)
at <asynchronous gap>(async)
at XCDevice.getAvailableIOSDevices(xcdevice.dart:487)
at <asynchronous gap>(async)
at IOSDevices.startPolling(devices.dart:108)
at <asynchronous gap>(async)
```

The CI overall_experience_test.dart flake:

```
 10:21 +54 -1: test/integration.shard/overall_experience_test.dart: flutter run handle SIGUSR1/2 [E]                                                                                                    
   Expected: [
               'Performing hot reload...                                        ',
               <a string starting with 'Reloaded 0 libraries in '>,
               'Performing hot restart...                                       ',
               <a string starting with 'Restarted application in '>,
               '',
               'Application finished.',
               'ready'
             ]
     Actual: WhereIterable<String>:[
               'Performing hot reload...                                        ',
               'Reloaded 0 libraries in 45ms (compile: 4 ms, reload: 0 ms, reassemble: 31 ms).',
               'Performing hot restart...                                       ',
               'Restarted application in 247ms.',
               '',
               'Application finished.',
               '',
               'Oops; flutter has exited unexpectedly: "PathNotFoundException: Cannot open file, path = \'/Volumes/Work/s/w/ir/x/t/flutter_tools.OnrQMu/core_devices.VRAibL/core_device_list.json\' (OS Error: No such file or directory, errno = 2)".',
               'ready'
             ]
      Which: at location [6] is '' instead of 'ready'
   
   package:matcher                                            expect
   test/integration.shard/overall_experience_test.dart 111:7  main.<fn>
```
Seen in presubmit 
https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8758444597475340193/+/u/run_test.dart_for_tool_integration_tests_shard_and_subshard_4_4/test_stdout

cc @vashworth
Repository: go
Issue: runtime: TestGdbBacktrace failures
Labels: help wanted,NeedsInvestigation,compiler/runtime

```
#!watchflakes
default <- pkg == "runtime" && test == "TestGdbBacktrace"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/ui/b/8758592503289784065)):

    === RUN   TestGdbBacktrace
    === PAUSE TestGdbBacktrace
    === CONT  TestGdbBacktrace
        runtime-gdb_test.go:81: gdb version 12.1
        runtime-gdb_test.go:489: GDB command timed out after 5m21.961754265s: /usr/bin/gdb -nx -batch -iex add-auto-load-safe-path /home/swarming/.swarming/w/ir/x/w/goroot/src/runtime -ex set startup-with-shell off -ex break main.eee -ex run -ex backtrace -ex continue /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/a.exe
        runtime-gdb_test.go:494: gdb output:
            Loading Go Runtime support.
            Breakpoint 1 at 0x6979c: file /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go, line 17.
            [New LWP 370763]
            [New LWP 370764]
            [New LWP 370766]
            [New LWP 370767]
            
            Thread 1 "a.exe" hit Breakpoint 1, 0x000000000006979c in main.eee (~r0=<optimized out>) at /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go:17
            17	func eee() bool { return true }
            #0  0x000000000006979c in main.eee (~r0=<optimized out>) at /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go:17
            #1  0x000000000006978c in main.ddd (~r0=<optimized out>) at /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go:14
            #2  0x0000000000069750 in main.ccc (~r0=<optimized out>) at /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go:11
            #3  0x0000000000069720 in main.bbb (~r0=<optimized out>) at /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go:8
            #4  0x00000000000696f0 in main.aaa (~r0=<optimized out>) at /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go:5
            #5  0x00000000000697c8 in main.main () at /home/swarming/.swarming/w/ir/x/t/TestGdbBacktrace964012512/001/main.go:22
            [LWP 370767 exited]
            [LWP 370766 exited]
            [LWP 370763 exited]
            [LWP 370761 exited]
        runtime-gdb_test.go:513: gdb exited with error: signal: killed
    --- FAIL: TestGdbBacktrace (324.28s)


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: transformers
Issue: PatchTST and PatchTSMixer categorical features and exogenous variables
Labels: Feature request,Time Series

### Feature request

Include categorical features and exogenous variables as input for the PatchTST and PatchTSMixer timeseries foundation models

### Motivation

Categorical features and exogenous variables are key components in timeseries modelling

### Your contribution

-
Repository: rust
Issue: Tracking Issue for enum access in offset_of
Labels: T-lang,T-libs-api,C-tracking-issue,F-offset_of_enum,I-lang-radar

Feature gate: `#![feature(offset_of_enum)]`

This is a tracking issue for using enum variants in offset_of. Enum variants themselves do not have an offset within their type, so the macro will not give an offset for them, but their fields do. For example, the standard library uses the offset of the content of the `Some` variant of `Option` to implement `Option::as_slice`. The original RFC for offset_of was https://github.com/rust-lang/rfcs/pull/3308.

### Public API

```rust
pub macro offset_of($Container:ty, $($fields:expr)+ $(,)?) { ... }

const OFFSET: usize = offset_of!(Option<u32>, Some.0);
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [x] Implementation: #114208
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilization PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- Should the syntax for enum variants differ from the syntax for field names in offset_of? https://rust-lang.zulipchat.com/#narrow/stream/213817-t-lang/topic/.60offset_of!.60.20Syntax/

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: rust
Issue: Variable named `∇x` gives "unknown start of token" compiler error
Labels: C-enhancement,A-Unicode,T-lang

I tried this code:
```rust
let ∇x = 1;
```

I expected the code to compiles but instead I get the compiler error message "unknown start of token \u{2207}".

This is surprising as variable names starting with Greek letters are fine:
```rust
let Δλ = 1;
```

I believe the cause is that Rust identifiers need to start with a `XID_Start` unicode characters, however the "Nabla" ∇ (0x2207) does not seem to be on that list.

It would be great to have the "Nabla" operator as a valid start token for identifier as it very commonly used in physics and mathematics to denote the derivative of a multi-variable function.

A possible workaround is to use the "Canadian syllabics e" ᐁ (0x1401).
Repository: tauri
Issue: [bug] Clicking on notification does not unminimize the app.
Labels: type: bug,status: needs triage

### Describe the bug

When the tauri app is running in the background[as in not in focus], and a notification is clicked, it brings the app to the front[puts it in focus]. But when the app is minimized [from the - in title bar], clicking on the notification does not unminimize it like other desktop apps.

Also, are there any plans to support click handlers on notifications to perform certain action? I can see some open issues around it, not sure if they are still relevant or handled already. 

### Reproduction

1. Create an app that sends native notifications. 
2. Minimise the app.
3. Click on native notification, and nothing happens.

### Expected behavior

If the app is minimized, and a notification is clicked, it should unminimise the app, and bring it to focus.

### Full `tauri info` output

```text
> tauri info


[✔] Environment
    - OS: Mac OS 14.1.2 X64
    ✔ Xcode Command Line Tools: installed
    ✔ rustc: 1.75.0 (82e1608df 2023-12-21)
    ✔ cargo: 1.75.0 (1d8b05cdd 2023-11-20)
    ✔ rustup: 1.26.0 (5af9b9484 2023-04-05)
    ✔ Rust toolchain: stable-aarch64-apple-darwin (default)
    - node: 18.19.0
    - pnpm: 5.5.3
    - yarn: 1.22.4
    - npm: 10.2.3

[-] Packages
    - tauri [RUST]: 1.4.1
    - tauri-build [RUST]: 1.3.0
    - wry [RUST]: 0.24.3
    - tao [RUST]: 0.16.1
    - @tauri-apps/api [NPM]: 1.5.3
    - @tauri-apps/cli [NPM]: 1.5.9

[-] App
    - build-type: bundle
    - CSP: unset
    - distDir: ../dist
    - devPath: https://app.struct.ai/
    - framework: React (Next.js)
    - bundler: Webpack
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: flutter
Issue: Add test that covers Flutter.groovy ABI code and/or migrate the code to kotlin 
Labels: a: tests,tool,t: gradle,P2,c: tech-debt,team-android,triaged-android

https://github.com/flutter/flutter/issues/141897 found that type errors are not caught unless the code is executed. Add a test covering the abi behavior or make flutter.groovy compile static or migrate the abi code to kotlin so that is statically checked.
Repository: flutter
Issue: [Impeller] `impeller_Play_AiksTest_CanRenderOffscreenCheckerboard_Vulkan` renders line artifact
Labels: P2,e: impeller,team-engine,triaged-engine

Notice the weird black line being drawn across the circle.

<img width="1268" alt="Screenshot 2024-01-19 at 1 24 27 PM" src="https://github.com/flutter/flutter/assets/30870216/9050586c-c34c-4b24-8825-af3fb65a73b7">

## version
ebee709bc5497b1b9a3813afc2192ef0bbb2f6fc
Repository: rust
Issue: effective visibilities: Count types leaked through trivial type aliases as reexported
Labels: C-enhancement,A-lints,A-visibility,T-compiler,L-unnameable_types

```rust
mod m {
    pub struct A {}
    pub struct B {}
}

pub use m::A as U;
pub type V = m::B;
```

In the example above `struct A` will be marked as reexported, but `struct B` will only be marked as reachable.
(This can be tested with `#[rustc_effective_visibility]` attribute.)

It may make sense to consider `B` reexported too, because there's not much difference between a `use` item and a trivial type alias.
This will remove some part of false positives from the `unnameable_types` lint in particular, because `B` is clearly nameable here.

The "promotion" to reexported should only happen when the alias is trivial - no generic parameters/where-clauses/bounds/etc, the RHS should also be a module-relative path without any generic arguments, including implicit ones.

There may be some unexpected consequences from doing this change.
For example, some import inlining code in rustdoc may assume that if `B` is reexported, then a reexport chain leading to `B` exists.
(Need to implement the change and see what breaks.)

This is a follow up to https://github.com/rust-lang/rust/issues/48054.
Repository: pytorch
Issue: Flight Recorder - feature requests
Labels: oncall: distributed,triaged

From @bmaurer
- [x] 1 The top level pickle object should be a dict rather than an array. Right now we have: [<nccl op 1>, …]. I’m suggesting {operations:[<nccl opt 1]}
- [x] 2 With the use of a dict above, we should make the file self describing (i.e., it should have a record of which rank it was, host name, MAST job, attempt, etc).
- [x] 3 Consider adding a data version tag (file format version 3) in the dict to make tooling versioning easier
- [ ]  4 Different ranks will have different “starting” points for their trace. In other words, rank 1 and rank 2 might both have executed an operation in PG 1 with seq_id 5. But rank 2 might have had this sequence fall off of their buffer. Maybe we should record the “last dropped record” for each PG so that we can know to avoid analyzing those cases
- [ ] 5 It’s impossible to tell what the members of a given PG ID are (and if PG IDs are expected to be unique across the job or if you might have two PG ID “1”s with distinct sets of ranks. I know we’ve done some optimizations in initialization that could lead to this”
- [x] 6 Consider recording time in nanoseconds vs micros — it’s a nit but nanos is how you get time from the kernel so anything else is doing extra division, losing data, and still a uint64
- [ ] 7 Consider adding a completion time (e.g. to help highlight cases where a given rank is always late in joining / completes the collective “too fast”)
- [ ] 9 had to tweek timeouts to get a dump from all ranks (TORCH_NCCL_WAIT_TIMEOUT_DUMP_MILSEC  from 2 sec -> 60)

From @jackphelanmeta
- [ ] 8 support writing the dump as chrome tracing format

Bugs/  code refactors
- fut.get() waits forever instead of timeout (fix: https://github.com/pytorch/pytorch/pull/118142)
- waitForDumpOrTimeout is overly complicated, we should simplify to not have 2 timevals
- launchAsyncDebugDump is called from several places. why not just call it from one place in heartbeat monitor and use tcpstore to signal it?
- ~ProcessGroupNCCL calls abort, which can hang, we might want to move that to destroy_process_group api instead (and get it out of the path of exceptions shutting down python turning into a collective hang)
- avoid symbolize() if dumping from ~ProcessGroupNCCL
- should we check how many people wrote the dump and log that?
- 

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu @penguinwu @fegin @XilunWu @wanchaol @fduwjj @wz337 @tianyu-l @yf225 @chauhang @d4l3k @rohan-varma @zdevito @shuqiangzhang @wconstab
Repository: pytorch
Issue: Foreach Where support
Labels: feature,module: optimizer,triaged,actionable,module: mta,oncall: pt2,module: pt2 optimizer

### 🚀 The feature, motivation and pitch

Currently we don't have a foreach_where op equivalent to `torch.where`. This would help in supporting https://github.com/pytorch/pytorch/issues/117807


cc @vincentqb @jbschlosser @albanD @janeyx99 @crcrpar @mcarilli @ezyang @msaroufim @bdhirsh @anijain2305 @zou3519 @chauhang 

### Alternatives

_No response_

### Additional context

_No response_
Repository: rust
Issue: effective visibilities: Split reachable into "reachable through interfaces" and "reachable through bounds"
Labels: A-lints,A-visibility,T-compiler,L-private_interfaces,L-private_bounds

We currently have two lints as a part of https://github.com/rust-lang/rust/issues/48054 - `private_interfaces` and `private_bounds`, the former being the stronger one.
```rust
struct A {}
struct B {}

pub fn leak() -> A // Warning: private_interfaces
    where B: Sized // Warning: private_bounds
{
    A {}
}
```
The detailed distinction is documented in the RFC, but the general idea is that with `private_interfaces` we can get our hands on a value of the private type `A` (which will result in a hard error), and with `private_bounds` we cannot.

In the effective visibility table it is likely reasonable to make exactly the same distinction - items reachable through interfaces (higher level of reachability), and items that are only reachable through bounds (less reachable).

In particular, the `unnameable_types` lint will only want to report types reachable through private interfaces, to reduce false positives.

This is a follow up to https://github.com/rust-lang/rust/issues/48054.
Repository: flutter
Issue: Consider making the source directory readonly on CI
Labels: team-infra,P2,triaged-infra

### Type of Request

feature request

### Infrastructure Environment

I am not sure, sorry. Whatever does git clone/gclient sync.

### What is happening?

Given that we reuse/cache builds, it's possible for naughty tests or scripts to "scribble" (edit, delete, add) to the source directory, causing hermetic issues for other tests or environments. For example:

https://github.com/flutter/engine/blob/main/tools/clang_tidy/test/header_filter_regex_test.dart reads a [regular expression from `$ENGINE/src/flutter/.clang_tidy`](https://github.com/flutter/engine/blob/83076ac70d2433783d982c638e4cd41f6475bccf/.clang-tidy#L63), and verifies that the regular expression matches folders in `$ENGINE/src/flutter/*`.

This test became flaky (https://github.com/flutter/flutter/issues/141907), which was root-caused to (and caused a revert of) https://github.com/flutter/engine/pull/49847, because a script was writing `$ENGINE/src/flutter/codecoverage`, and that directory was being persisted/cached (I think both across tests, and even longer due to caches).



### Steps to reproduce

_No response_

### Expected results

One suggested result is making the source directory readonly, at least after `gclient sync`.

That would stop tests from writing to source and causing problems like this in the future.
Repository: electron
Issue: [Bug]: Window decorations not right-clickable under Wayland
Labels: bug :beetle:,blocked/upstream ❌,28-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

28.1.2

### What operating system are you using?

Other Linux

### Operating System Version

Fedora  39

### What arch are you using?

x64

### Last Known Working Electron version

_No response_

### Expected Behavior

Right click on window decorations, list of options show up (take screenshot, etc).

### Actual Behavior

Nothing.

### Testcase Gist URL

_No response_

### Additional Information

Slack and Discord are the applications I'm observing this behavior with, both use Electron. Slack has the Electron version I mentioned in the issue. From what I understand Electron is responsible for drawing the decorations.
Repository: rust
Issue: ! can't be cast to Fn(_) -> _
Labels: F-never_type,C-discussion

<!--
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
#[derive(Debug)]
pub struct SharedBufferRng<const WORDS_PER_SEED: usize, const SEEDS_CAPACITY: usize, SourceType: Rng,
FallbackFn: Send + Sync + Clone + Fn() -> SourceType> {
    receiver: Receiver<DefaultableAlignedArray<WORDS_PER_SEED, u64>>,
    calling_thread_fallback: Option<FallbackFn>
}
impl<
        const WORDS_PER_SEED: usize,
        const SEEDS_CAPACITY: usize,
        SourceType: Rng + Send + Debug + 'static,
        FallbackFn: Sync + Send + Clone + Fn() -> SourceType
    > SharedBufferRng<WORDS_PER_SEED, SEEDS_CAPACITY, SourceType, FallbackFn>
    where [(); WORDS_PER_SEED * size_of::<u64>()]:, [(); WORDS_PER_SEED * SEEDS_CAPACITY * size_of::<u64>()]:
{
    /// Creates an RNG that will have a new dedicated thread reading from [source] into a new buffer that's shared with
    /// all clones of this [SharedBufferRng].
    pub fn new(mut source: SourceType, fallback: Option<FallbackFn>) -> Self {/*...*/}
}
#[test]
fn test() {
     let seeder: SharedBufferRng<8, 4, _, _> =
         SharedBufferRng::new(BlockRng64::new(source.clone()), None::<!>);
}
```

I expected to see this happen: the code would compile. `Option<!>` would be a valid type with zero size, and would cast to `Option<T>` for all T, because the `Some` variant would be eliminated during monomorphization. In fact `None` would always be of type `Option<!>` unless and until the compiler found a way for it to become `Some`.

Instead, this happened: it didn't compile until I changed the turbofish to `::<fn(_) -> _>`
### Meta
<!--
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.
-->

`rustc --version --verbose`:
```
rustc 1.77.0-nightly (fb5ed726f 2023-12-28)
binary: rustc
commit-hash: fb5ed726f72c6d16c788517c60ec00d4564b9348
commit-date: 2023-12-28
host: x86_64-apple-darwin
release: 1.77.0-nightly
LLVM version: 17.0.6
```

<!--
Include a backtrace in the code block by setting `RUST_BACKTRACE=1` in your
environment. E.g. `RUST_BACKTRACE=1 cargo build`.
-->
<details><summary>Backtrace</summary>
<p>

```
<backtrace>
```

</p>
</details>
Repository: pytorch
Issue: canonical way to normalize torch.device?
Labels: module: cuda,triaged,module: python frontend

There are several copies of ways to normalize a device in torch.  Is there one that i'm not aware of (in c++/pybind or torchscript bindings perhaps) or should we provide one in py layer for torch.Device to uniformly deal with string to Device obj and add index when missing?


cc @ptrblck @albanD