sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: [tool] Stop using pkg:usage
Labels: P2,c: tech-debt,team-tool,triaged-tool

(Rewritten by @andrewkolos)

- [X] Remove dependency on package:usage in the g3 `flutter` tool (or at least get the OK to delete it)
  - b/361811035
- [ ] Remove code dependent on package:usage in the `flutter` tool (packages/flutter_tools). Fix pre-existing bugs along the way.
  - https://github.com/flutter/flutter/pull/159705
  - https://github.com/flutter/flutter/pull/160060
  - https://github.com/flutter/flutter/pull/160369
  - https://github.com/flutter/flutter/pull/160663
  - https://github.com/flutter/flutter/pull/162279
- [ ] Remove package:usage dependency from packages/flutter_tools

## Original description (Jun 20)

The package is deprecated.
The analytics configuration is gone.

Zero reason to keep it, right?
Repository: rust
Issue: NFC normalisation of lifetimes and labels
Labels: A-Unicode,T-lang,T-compiler

The lexer NFC-normalises identifiers, as described in [rfc2457]. For example, `K` (`LATIN CAPITAL LETTER K`) and `K` (`KELVIN SIGN`) are treated as representing the same identifier.

But this doesn't happen for lifetimes or labels, so `'K` and `'K` are different as lifetimes or labels.

For example, [this][playground-lifetime] compiles (without warning) in Rust 1.79, while [this][playground-ident] doesn't compile.

I'm not sure whether this should be considered a bug.

rfc2457 doesn't explicitly mention lifetimes or labels.

The Reference describes the current behaviour: it treats identifiers and lifetimes/labels as parallel forms of token, and documents normalisation as happening for identifiers only.

On the other hand it seems surprising, and some of the discussion around #126452 has expressed the view that "lifetimes are identifiers".


[rfc2457]: https://rust-lang.github.io/rfcs/2457-non-ascii-idents.html

[playground-lifetime]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=31fc06e4d678e1a38d8d39f521e8a11c
[playground-ident]: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=aad27eb75b2774f16fc6b0981b770d56
Repository: go
Issue: proposal: go/doc: ignore leading and trailing whitespace in the directive arguments
Labels: Proposal

### Proposal Details

#51082 and #37974 standardized Go directive comments as line comments whose content matches `^(line |extern |export |[a-z0-9]+:[a-z0-9])(.*)$` where the first group is the directive and the second group is the argument to the directive.

This makes leading and trailing whitespace part of directive comments.

Trailing whitespace is almost always removed and should never be semantic so it is already de facto not part of the argument.

One space is required for the old (line/export/extern) directives and additional leading whitespace is presumably ignored [have not tested this, will update if incorrect].

Someone writing a general `//x:y` directive in their code will likely add whitespace between the directive and argument even if not syntactically required so anyone parsing directives will likely ignore at least one leading space regardless.

Someone reading the directive `//x:yZ` would assume that `x:yZ` is the directive name rather than it is the directive `x:y` with argument `Z` so having whitespace here would clarify.

I propose changing the argument syntax from `.*$` to `[ \t]*([^ \t]*)[ \t]*$` where the leading and trailing whitespace is ignored.

This would allow two things
1. The iterator proposed in #68021 could trim the arguments automatically so no one using the official API for parsing directives will need to worry about this
2. (not proposed here but enabled by this change) gofmt could insert a clarifying space when necessary, normalize leading whitespace, or even line up arguments to multiple directives
Repository: flutter
Issue: Support macOS-style Switch
Labels: c: new feature,f: cupertino,P2,team-design,triaged-design

### Use case

The existing widget for iOS-styled switches is CupertinoSwitch:

<img width="453" alt="iOS switch" src="https://github.com/flutter/flutter/assets/77553258/d23aea14-d23e-4315-9bf0-9ed8e0cb0618">

This switch has size 51x31, animates (by lengthening) the thumb on press/drag, and has a default green track color.

However, switches on macOS have a different look and feel:

<img width="227" alt="macOS switch" src="https://github.com/flutter/flutter/assets/77553258/85262984-8d28-4422-a211-152beddf9ee7">

This switch has size 26x15, does not animate the thumb on press/drag, and has a default blue track color.

| iOS behavior   | macOS behavior |
| -------- | ------- |
| ![ezgif com-video-to-gif-converter (3)](https://github.com/flutter/flutter/assets/77553258/5ca6fe19-e153-4602-aca5-c9ac598d79a1) | ![ezgif com-video-to-gif-converter (4)](https://github.com/flutter/flutter/assets/77553258/6fcd5cd1-1c73-484b-b090-85390a416bf8) |

### Proposal

Flutter should support both iOS and macOS-styled switches.
Repository: go
Issue: runtime/trace: missing stacks for trace events emitted when `getg().mp.curg == nil`, like `GoCreate` for `time.AfterFunc`
Labels: NeedsFix,compiler/runtime

Here is a simple program that reproduces the issue:

```
package main

import (
	"log"
	"os"
	"runtime/trace"
	"time"
)

func main() {
	f, err := os.Create("trace.out")
	if err != nil {
		log.Fatal(err)
	}
	defer f.Close()

	trace.Start(f)

	time.AfterFunc(1*time.Second, func() {
		println("hello!")
	})

	time.Sleep(5 * time.Second)

	trace.Stop()
}
```

In this trace, the `GoCreate` event that creates the goroutine to run `println("hello")` will have a stack trace for the new goroutine (really, the start PC) but will *not* have the stack trace in the scheduler/timer code that actually creates the goroutine.

The reason for this is simple: `traceStack`, the function that obtains a stack trace for the tracer, skips taking a stack if it's called from a system stack. This has been true as far back as I can find. The reason why it does this is because it uses the fact that it runs on a system stack as a signal that it should collect `gp.mp.curg`'s stack instead. This is reasonable -- if a goroutine calls into the scheduler to yield, it'll be running on a system stack when we emit the trace event, but we crucially _do not care_ about that location, but where the _user code_ was when we yielded.

The fix here is, I think, straightforward: collect a trace from a system stack if and only if `gp.mp.curg` is nil. This should be sufficient to capture the `time.AfterFunc` case and cases like it.
Repository: go
Issue: x/build: openbsd-ppc64 builder timeouts
Labels: OS-OpenBSD,Builders,NeedsInvestigation,arch-ppc64x

### Go version

tip

### Output of `go env` in your module/workspace:

```shell
GOOS=openbsd
GOARCH=ppc64
```


### What did you do?

I noticed a number of different CI failures in the last week (possibly longer) which indicate a timeout. E.g
[9d33956](https://build.golang.org/log/ee9d983ded799f13e7ad151019077dc93bdab556)  [4f77a83](https://build.golang.org/log/e84397bd5255eeb97e26b9f4d21438f9dd606c44) [2b12bbc](https://build.golang.org/log/98ccd424e1e2be1ad78d56d4f241c8ae72b80c62)

I want to verify there are no problems with the ppc64 backend.

@golang/openbsd @golang/ppc64 



### What did you see happen?

Frequent timeouts, and many tests taking an abnormally long amount of time.

### What did you expect to see?

All the CI tests pass.
Repository: vscode
Issue: New Windows Dialog Box? Crash to Desktop.
Labels: bug,freeze-slow-crash-leak

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->

Does this issue occur when all extensions are disabled?: Unknown (cannot test due to crash)

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->

- VS Code Version: 1.90.0 
- - 89de5a8d4d6205e5b11647eb6a74844ca23d2573
- - x64
- OS Version: 10.0.19045 N/A Build 19045

Steps to Reproduce:

1. Attempt to perform any activity that requires VSCode to use a Windows dialog box (Access VSCode "About" box; attempt to select the "Open Folder" option from the File menu; attempt to begin the "Start Extension Bisect" from the command palette (since that opens a dialog box)
2. Crash

I've attached two .dmp files that I ran today; one from my roaming folder and the other from the local folder.
[VSCode-DMP files.zip](https://github.com/user-attachments/files/15919865/VSCode-DMP.files.zip)
Repository: rust
Issue: Migrate parser to the new span combining scheme
Labels: C-cleanup,A-diagnostics,A-parser,E-mentor,A-macros,T-compiler

#### Summary:
I `a`, `b`, ..., `z` are multiple consecutive *span nodes* that need to be combined into a single new span node, then its combined span should be
```rust
span(a).to(span(b)).to(span(c))....to(span(z))`
```

"Span node" is either an individual token (every token has a span), or some larger AST node having a `Span` field.

#### Examples:
```rust
-10 // an expression
a + 11 // one more expression
a::<u8>::b // a path
```

The combined span for these pieces of code will be
```rust
// expressions are span nodes because they have their own spans in AST, `-` doesn't have a larger AST node so it's treated as a primitive token
span(expr(-10)) = span(token(-)).to(span(expr(10)));
span(expr(a + 11)) = span(expr(a)).to(span(token(+))).to(span(expr(11)));
// the whole generic arg is a span node because it has its own span in AST
span(path(a::<u8>::b)) = span(ident(a)).to(span(token(::))).to(span(generic_arg(<u8>))).to(span(token(::))).to(span(ident(b)));
```

#### Status quo:
Currently the resulting span is typically built like `span_first_token.to(span_last_token)`.
So anything in the middle and the internal structure (i.e. nodes, as opposed to tokens) are ignored.

#### Why we need to change it:
The `to` operation will automatically take macro variables into account, and will try to put the resulting span into the best suitable macro context (this was implemented in https://github.com/rust-lang/rust/pull/119673).
E.g. in `$tt + 5` the combined expression span will be put into the context of the macro using `$tt` as a macro parameter.
Note, that the same thing often happens in the current parser as well, but not consistently, e.g. `$a::$b` will produce an incorrect resulting path span because the `::` in the middle is not considered.
This will also give us some single relatively well predictable rule for combining AST spans.

#### Implementation:
This work should be parallelizable relatively well (but may require a one time initial setup).
I'll review PRs doing this, they can be assigned to me.
It may be convenient to have a rolling value in the `Parser` structure for span of the current (or previous?) span node.
The parser has a lot of bespoke diagnostic logic (including snapshotting) that stands in the way of any systematic improvements like this.

#### How this can be tested:
Make a macro that emits complex nodes using tokens from different contexts, e.g.
```rust
macro m($l:tt $op:tt $r:tt) {
    2 + 3;
    $l + 3;
    2 $op 3;
    2 + $r;
    $l $op 3;
    $l + $r;
    2 $op $r;
    $l $op $r;
}

m!(2 + 3);
```
and emit some diagnostic using those nodes' spans (maybe can add a special internal diagnostic for this testing).


<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"danik292"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: flutter
Issue: Allow calling `runOnPlatformThread()` from helper isolates
Labels: c: new feature,engine,c: proposal,P2,team-engine,triaged-engine

Allow calling `runOnPlatformThread()` from helper isolates (but not for background service isolates). At the moment `runOnPlatformThread()` is only supported on the UI isolate. This is mainly just a matter of plumbing. There's a bunch of state that the platform thread needs access to, to create the platform isolate, that's currently only available on the UI isolate (primarily the task runners).

This issue is a spin off from https://github.com/flutter/flutter/issues/136314
Repository: flutter
Issue: `PlatformIsolateManager` methods should assert they're called on the platform thread
Labels: c: new feature,engine,c: proposal,P2,team-engine,triaged-engine

In `PlatformIsolateManager::RemovePlatformIsolate` and `PlatformIsolateManager::ShutdownPlatformIsolates`, find a way of asserting that we're on the platform thread. This is tricky because there may not be a current `UIDartState`.

This issue is a spin off from https://github.com/flutter/flutter/issues/136314
Repository: pytorch
Issue: extending forward-mode AD docs should really point to an example
Labels: triaged,module: forward ad


example to point to : https://pytorch.org/tutorials/intermediate/forward_ad_usage.html#custom-autograd-function

the docs that don't have a link:
- https://pytorch.org/docs/stable/notes/extending.html#forward-mode-ad
- https://pytorch.org/docs/stable/generated/torch.autograd.Function.jvp.html#torch.autograd.Function.jvp
Repository: flutter
Issue: iOS style zoom page transition
Labels: c: new feature,a: fidelity,f: cupertino,P2,team-design,triaged-design

For WWDC24, Apple showed a new page transition. [Link to a video talking about it](https://www.youtube.com/watch?v=UDaNFV1Ll3E)

Some definitions because talking about page transitions is hard. 
Home page: the top level page when talking about this transition. 
Preview view: the view shown somewhere on the home page. When tapped, it plays a zoom transition going to the next page. Detailed view: the new page after the transition. Shows a full screen version of the preview view. Can have UI elements that were not shown in the preview view.
Sibling view: a detailed view that can be routed to directly from another detailed view. Either page can go directly bake to the home page.

![zoom-transition](https://github.com/flutter/flutter/assets/58190796/cc95cae1-09f9-4a96-8bb2-babe928af222)

The transition starts from a preview view on the previous page. From that preview view, it zooms outwards to fill the whole page. When the view goes back to the original page, then the zoom reverses and ends at the location of the preview image. So the transition needs to adjust based on the dimensions of it's preview.

The underlying page appears to darken and zoom slightly in the opposite direction. The navbar title also does a hero transition upwards to the back button location.

This is all somewhat similar to the CupertinoContextMenu animation, except instead of finishing at a modal view with a menu, it resolves to a full page.

![zoom-transition-drag](https://github.com/flutter/flutter/assets/58190796/3ee3d09b-ab55-419b-8e2f-c3e645aabdca)

The new page can go backwards with a swipe at the edge of the screen on a partial swipe the page transition will match the location of the touch on the screen. On a partial swipe, the page will not finish the pop and return to the detailed view.

![zoom-transition-siblings](https://github.com/flutter/flutter/assets/58190796/456f4990-7636-486d-91f8-c896c4a86c39)

This shows a possibility of going directly from one detailed view to another. The home page has multiple preview views with zoom transitions attatched. The user goes to one detailed view, then goes directly to another sibling detailed view. This transition from detailed view to another detailed view is a standard Cupertino transition that we already support. But when going directly back to the home page, the zoom transition adjusts to finish at the correct preview view for the latest detail view.
Repository: go
Issue: x/tools/gopls: CLI cannot rename directories
Labels: gopls,Tools

In a clean x/tools repo, using tip go1.23 and tip gopls, in VS Code, rename `package frob` in gopls/internal/util/frob/frob.go
to "blorf" using this command:
```
xtools$ gopls rename -w ~/w/xtools/gopls/internal/util/frob/frob.go:#1151 blorf
gopls: getFile: file:///Users/adonovan/w/xtools/gopls/internal/util/frob: read /Users/adonovan/w/xtools/gopls/internal/util/frob: is a directory
```
The error appears to arise from a WorkspaceEdit containing a rename DocumentChange referring to a directory.
Repository: flutter
Issue: iPad style tab bar
Labels: c: new feature,a: fidelity,f: cupertino,P2,a: adaptivity,team-design,triaged-design

WWDC24 showed a new tab bar design specifically for iPadOS. [Link to video](https://www.youtube.com/watch?v=si-7DinDz5c). [Link to documentation](https://developer.apple.com/documentation/uikit/app_and_environment/elevating_your_ipad_app_with_a_tab_bar_and_sidebar).

Native tab bars will now adapt between iOS and iPadOS. iOS tab bars still look the same as our Cupertino version, however the iPad version will now be at the top of the screen instead of the bottom with new visuals. It will now look somewhat like segmented buttons, and will be nestled within a navbar that will can have other controls outside of the tab bar.

<img width="429" alt="Screenshot 2024-06-20 at 3 25 48 PM" src="https://github.com/flutter/flutter/assets/58190796/279d6b6c-ab1d-4dcc-b0fa-99cf6e696358">

Furthermore it will coordinate with the sidebar view that can have a more detailed view of the options in the tab bar. There is an open issue to add a sidebar widget to Cupertino #60762

Some functionalities shown that will likely need to be worked on in multiple PRs:

- A unique transition for opening the sidebar from the tab bar
- Showing different variations on the same icon depending on iPad or iOS
- Being able to drag and drop tabs in order to customize the options in both the tab bar and sidebar
Repository: vscode
Issue: VSCode "Open Editors" causing Logic Apps extension menu context issue
Labels: bug,context-keys,open-editors

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: N/A

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.90.2 and before
- OS Version: Does not matter

"Open Editors" causing menu context to be lost in the Azure Logic Apps Standard extension. It appears that the context key is lost for resourceFilename.

Steps to Reproduce:

1. Install the Azure Logic Apps (Standard) Extension.  
2. Create a new logic app workspace, follow the prompts and create "Logic app" and "Stateful" workflow, and open in new window. Ensure that the "Open Editors" is expanded and visible.
3. Right click on the "workflow.json" and the following options should be seen
![image](https://github.com/microsoft/vscode/assets/124318508/0651e369-ebf7-4832-a9e3-bfc6fa5a3c9d)
4. Select "Open Designer" and wait for the designer to load. Do not click anything until the designer is finished loading.
5. Right click on "workflow.json" and the same menu options are not available.
![image](https://github.com/microsoft/vscode/assets/124318508/e14f7b63-f72f-44ef-a40e-7bfe5e07258a)
6. Double click on "workflow.json" and right click should now show that the correct menu.
7. Minimize "Open Editors" and repeat steps 3-5. The repeated step 5 shows the right menu context.
Repository: deno
Issue: suggestion: simplify internal module specifiers
Labels: deno_core,suggestion

The internal import map for this codebase is defined in [`tools/core_import_map.json`](https://github.com/denoland/deno/blob/main/tools/core_import_map.json). Currently, each import corresponds to an individual script. This means a new entry is needed for every new script, and when one entry is missing, VSCode IntelliSense doesn't work for symbols from that script.

I suggest replacing these single-script imports with directory imports and changing the prefix used in internal module specifiers. This change would automatically cover almost all internal imports with near-zero maintenance. @bartlomieju told me this would require considerable changes to this repo and [`deno_core`](https://github.com/denoland/deno_core) code and, therefore, likely best done after Deno 2.

Please excuse me if I've overlooked some obvious drawbacks to this approach. I have little context on why internal module specifiers were done this way in the first place.

### Currently

https://github.com/denoland/deno/blob/88e3f465d3a95db277ac7e685a0ed239958f8e6e/tools/core_import_map.json#L55-L60

https://github.com/denoland/deno/blob/88e3f465d3a95db277ac7e685a0ed239958f8e6e/ext/node/polyfills/_brotli.js#L29-L32

### Suggestion

```jsonc
// tools/core_import_map.json
{
  "imports": {
    "ext/": "../ext/",
    "ext/node/": "../ext/node/polyfills",
    "ext/runtime/": "../runtime/js/",
    "node:assert": "../ext/node/polyfills/assert.ts",
    "node:assert/strict": "../ext/node/polyfills/assert/strict.ts"
    // ...
  }
}
```

```js
// ext/node/polyfills/_brotli.js
// ...
import { zlib as constants } from "ext/node/internal_binding/constants.ts";
import { TextEncoder } from "ext/web/08_text_encoding.js";
import { Transform } from "node:stream";
import { Buffer } from "node:buffer";
// ...
```
Repository: flutter
Issue: Higher level video support for web
Labels: c: new feature,engine,platform-web,c: proposal,P2,team-web,triaged-web

### Use case

The video_player package handles the common usecase of having a video player, but camera_web, video_player_web, and various other pub.dev packages such as livekit all need to support video. At the moment, the web lacks a good way to handle video across the board. This is made worse by the fact that as changes land to the engine, the best way to render video into a texture is going to change and all these packages will once again need to be updated.

Should dart:ui_web be updated with some kind of videoelement as texture widget? 


### Proposal

A high level video helper should be added to ui_web that can be utilized by packages to get the best video render path currently possible. It should only render the video element into a texture and nothing else, so that packages like video_player_web can continue to serve their function of providing controls and UI on top of the video. Something like:

```dart
class VideoTexture extends StatefulWidget {
   const VideoTexture({ super.key, this.videoElement });
}
```