sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Design Meeting Notes, 10/11/2024
Labels: Design Notes


# Conditional Type Narrowing

#56941

* Today, we check an expression like

  ```ts
  arg === 1 ? "someString" : 37
  ```

  by getting the type of both branches and unioning them - and we can't make a determination about how either branch corresponds to the condition.
* In the experimental PR, each branch is checked the expected type.
  * This is a breaking change, but it catches some desirable breaks.
  * For example:

    ```
    // Currently the expression's type is `any` and we check that against `number`,
    // but checked individually, the `string` is correctly caught.
    let x: number = arg === 1 ? "someString" : getAnAny() as any;
    ```
* Breaks?
    * Most are true bugs
    * Good chunk are moves in error positions (breaks `ts-expect-error`)
    * Some unlikely to be real bugs.
* The motivation was conditional type narrowing - if you think of first principals, you could consider that the *conditional expression* creates a conditional type.
    * Not too hard to do, but
        * Need to be able to "crack into" each branch of the conditional type for the `return` statement case as well.
        * You also might not get the "right" conditional type. For example

          ```
          function f(x: T): T extends string ? string : number {
              return x === undefined ? someString : someNumber;
          }
          ```
            * Do you end up synthesizing `T extends string ? ... : ...` or do you create `T extends undefined ? ... : ...`?
        * Also, error messages won't be quite as good.
* Out of time

# Slim AST Experiments with Shared Structs in the Compiler

#59992

* Partially inspired by https://github.com/microsoft/TypeScript/pull/59190
* Uses flagged functionality for `SharedStruct`s via API (no syntax for shared structs yet).
* Idea: every Node is has single a fixed layout.
    * Also experimenting with a version that uses shared structs.
* Separately: a different experiment Uses a "slim AST" which creates a facade to the real AST for API compat.
* Experimental parser that uses this.
* You get a speed-up similar to #59190, though it's at the expense of more memory.
    * Much more (why?)
* If you use shared structs as the backing store for the slim AST, you lose some speed (we anticipate more optimizations with collaboration from V8), but possibly win back some memory and are able to run across multiple threads and you get a net perf win.

  |  Node Type  |        Allocation Source        | Time (seconds) |
  |-------------|---------------------------------|----------------|
  | Current AST | Plain objects                   | 1.76           |
  | slim-ast    | plain objects                   | 1.562          |
  | slim-ast    | shared structs                  | 2.013          |
  | slim-ast    | shared structs across 8 workers | 1.082          |
Repository: TypeScript
Issue: Design Meeting Notes, 10/18/2024
Labels: Design Notes

# Conditional Type Narrowing

#56941

* Shouldn't be any perf impact for existing code because most code doesn't actually use a conditional type as the return type of a function, or it just casts.
* It is a semantic check on the return type (not syntax - you can use type aliases).
* If we want to support this kind of narrowing, we need to dive into the conditional expression and check each branch separately.
    * Original PR did this for every function, caught bugs - but maybe we generalize there later on. For now, the current check is only when checking against a a conditional return type.
* How does this work with contextual types?

  ```ts
  function makeEquals<T extends string | number>(x: T):
      T extends string
          ? (x: string) => boolean
          : (x: number) => boolean {

      // are these well-typed?
      return typeof x === "string" ? (y => x === y) : (y => x === y);
  }
  ```
    * Currently it does work. See PR for details.
* Seems like no objections to current design - plan for 5.8.
Repository: flutter
Issue: Dialog widget requires roles, ARIA properties, and keyboard support (Accessibility)
Labels: c: new feature,framework,f: material design,a: accessibility,platform-web,c: proposal,P1,customer: castaway,team-accessibility,triaged-accessibility

### Use case

The Dialog widget requires roles, ARIA properties, and expected keyboard support to meet accessibility compliance requirements outlined in the Web Content Accessibility Guidelines (WCAG).

### Proposal

### WAI-ARIA Roles, States, and Properties
- The element that serves as the dialog container has a `role="dialog"`
- All elements required to operate the dialog are descendants of the element that has `role="dialog"`
- The dialog container element has `aria-modal="true"`
- Provide a label for the dialog by using `aria-label` OR `aria-labelledby="[IDREF]"` on the container element, with [IDREF] referencing the unique ID of the element that describes the purpose of the dialog

### Focus management
- Set focus to either the dialog’s main heading or the first interactive element within the dialog. There must be a visible focus indicator.
- Maintain focus within the modal dialog until the dialog is closed.
- Upon closing the dialog, send focus back to the control that prompted it, or to the next logical place on the page. There must be a visible focus indicator.

### Keyboard navigation
- **Tab**: 
  - Moves focus to the next tabbable element inside the dialog.
  - If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog.
- **Shift + Tab**:
  - Moves focus to the previous tabbable element inside the dialog.
  - If focus is on the first tabbable element inside the dialog, moves focus to the last tabbable element inside the dialog.
- **Esc**: Closes the dialog.
Repository: flutter
Issue: AlertDialog widget requires roles, ARIA properties, and keyboard support (Accessibility)
Labels: c: new feature,framework,f: material design,a: accessibility,platform-web,c: proposal,P1,customer: castaway,team-accessibility,triaged-accessibility

### Use case

The AlertDialog widget requires roles, ARIA properties, and expected keyboard support to meet accessibility compliance requirements outlined in the Web Content Accessibility Guidelines (WCAG).

### Proposal

### WAI-ARIA Roles, States, and Properties
- The element that serves as the alert dialog container has a `role="alertdialog"`
- All elements required to operate the alert dialog are descendants of the element that has `role="alertdialog"`
- The alert dialog container element has `aria-modal="true"`
- Provide a label for the alert dialog by using `aria-label` OR `aria-labelledby="[IDREF]"` on the container element, with [IDREF] referencing the unique ID of the element that describes the purpose of the alert dialog
- The element with `role="alertdialog"` has a value set for `aria-describedby` that refers to the element containing the alert message.

### Focus management
- Set focus to either the alert dialog’s main heading or the first interactive element within the dialog. There must be a visible focus indicator.
- Maintain focus within the alert dialog until the dialog is closed.
- Upon closing the alert dialog, send focus back to the control that prompted it, or to the next logical place on the page. There must be a visible focus indicator.

### Keyboard navigation
- **Tab**: 
  - Moves focus to the next tabbable element inside the alert dialog.
  - If focus is on the last tabbable element inside the alert dialog, moves focus to the first tabbable element inside the alert dialog.
- **Shift + Tab**:
  - Moves focus to the previous tabbable element inside the alert dialog.
  - If focus is on the first tabbable element inside the alert dialog, moves focus to the last tabbable element inside the alert dialog.
- **Esc**: Closes the dialog.
Repository: flutter
Issue: [Impeller] libImpeller: Crash in FreeType during release of a typography context.
Labels: P3,e: impeller,team-engine,triaged-engine,e: libimpeller

Reported when creating and releasing a single typographer context:

```
#1  0x00007ffff7ce42b1 in SkTypeface_FreeTypeStream::~SkTypeface_FreeTypeStream() () from libimpeller.so
#2  0x00007ffff7ce42e9 in SkTypeface_FreeTypeStream::~SkTypeface_FreeTypeStream() () from libimpeller.so
#3  0x00007ffff7d4b58d in skia::textlayout::TypefaceFontStyleSet::~TypefaceFontStyleSet() () from libimpeller.so
#4  0x00007ffff7d4b436 in skia::textlayout::TypefaceFontProvider::~TypefaceFontProvider() () from libimpeller.so
#5  0x00007ffff7e8b086 in txt::FontCollection::~FontCollection() ()
   from libimpeller.so
#6  0x00007ffff7a8dbd9 in impeller::interop::TypographyContext::~TypographyContext() () from libimpeller.so
```

cc @lyceel

[This test should be creating a collecting a context](https://github.com/flutter/engine/blob/08170c44b0f8932cadf8c7e01f139781c571530c/impeller/toolkit/interop/impeller_unittests.cc#L248) so it is unclear what is going on here. Debugging.
Repository: vscode
Issue: Cannot style Chinese character into bold text.
Labels: bug,editor-input-IME

<!-- ⚠️⚠️ 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?: No

<!-- 🪓 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: 
- OS Version: 

Steps to Reproduce:

1. the "**" function works well with English, but not Chinese. 
![Image](https://github.com/user-attachments/assets/ce156116-0e45-4e2f-95fd-86c51ed02caa)
![Image](https://github.com/user-attachments/assets/001f2aca-85da-4cb3-b3dd-ccaf8b246f9d)

3. code to reproduce:
`text  
*italic text*  
**bold text**  
**中文加粗** `
Repository: material-ui
Issue: [material-ui][ButtonBase] Allow disabling the ripple when right-clicked (or other buttons)
Labels: new feature,waiting for 👍,component: button,component: ButtonBase,package: material-ui

### Summary

In most cases, a Button doesn't really do something when it's clicked with middle or right buttons. However currently the ripple will still show when clicking a button with any button. I don't think this is really a good idea, since it will mislead the user.

My idea is to add a property similar to 'disableTouchRipple' to all components that have a ripple, but it allows the developer to control which mouse button will let the ripple will be displayed. For example, 

```tsx
// More about mouse button is here: https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/button#value
<Button showTouchRippleOnButton={[0, 3, 4]} {...other}/>
```

And the default value of this property should be [0], which means only the main button (usually the left button) will trigger ripples. This property enables the developer to control it, cause sometimes one may listen to, for example, right-click events. In this scenario, this gives the full-control to adapt different using cases.

### Examples

You can also define an enum for MouseButtons, or a string-union. In our projects we use an enum to represent mouse buttons like this, and you guys can use it as long as you like:

```ts
/**
 * The mouse buttons. This is a subset of the `MouseEvent.button` values.
 * 
 * @remarks buttons may be configured differently to the standard "left to right" layout. 
 * A mouse configured for left-handed use may have the button actions reversed. 
 * Some pointing devices only have one button and use keyboard or other input mechanisms to indicate main, 
 * secondary, auxiliary, etc. Others may have many buttons mapped to different functions and button values.
 * 
 * @link https://developer.mozilla.org/en-US/docs/Web/API/MouseEvent/button#value
 */
export enum MouseButton
{
    /** Main button, usually the left button or the un-initialized state */
    Main = 0,

    /** Auxiliary button, usually the wheel button or the middle button (if present) */
    Auxiliary = 1,

    /** Secondary button, usually the right button */
    Secondary = 2,

    /** Fourth button, typically the Browser Back button */
    Fourth = 3,

    /** Fifth button, typically the Browser Forward button */
    Fifth = 4
}
```

### Motivation

This idea is really important for our projects. If this can be added, we'll be so happy and appreciated.
And when we have some income, we'll considering buying you guys a cup of coffee by donating.

Thanks for your work!

**Search keywords**: ripple, right, button, buttonbase, mouse, click
Repository: ollama
Issue: Windows ARM64 fails when loading model, error code 0xc000001d
Labels: bug,windows

### What is the issue?

I installed the latest Ollama for Windows (ARM64 build) on my 2023 Windows Dev Kit, which has an 8-core ARM processor, a Snapdragon 8cx Gen 3. It's running Windows 11 Pro.

I can pull models, but when I go to run them, I get an error. It doesn't matter what model I run, I've tried several. Here's an example.

```
C:\Users\Mike Chambers>ollama pull gemma2:2b
pulling manifest
pulling 7462734796d6... 100% ▕████████████████████████████████████████████████████████▏ 1.6 GB
pulling e0a42594d802... 100% ▕████████████████████████████████████████████████████████▏  358 B
pulling 097a36493f71... 100% ▕████████████████████████████████████████████████████████▏ 8.4 KB
pulling 2490e7468436... 100% ▕████████████████████████████████████████████████████████▏   65 B
pulling e18ad7af7efb... 100% ▕████████████████████████████████████████████████████████▏  487 B
verifying sha256 digest
writing manifest
success

C:\Users\Mike Chambers>ollama run gemma2:2b
Error: llama runner process has terminated: exit status 0xc000001d

C:\Users\Mike Chambers>
```

### OS

Windows

### GPU

_No response_

### CPU

Other

### Ollama version

0.3.13

[server.log](https://github.com/user-attachments/files/17448637/server.log)
Repository: terminal
Issue: overwritting text
Labels: Product-Conpty,Area-VT,Issue-Bug

### Windows Terminal version

1.22.2912.0

### Windows build number

10.0.22631.0

### Other Software

OpenSSH_for_Windows_9.5p1

### Steps to reproduce

You can repoduce this bug by opening an the preview version of Windows Terminal. I usually have default profile for pwsh, and once inside of terminal open up an ssh session to a remote windows computer with sshd configured. With the preview version of Windows Terminal, when you type something inside of the ssh session overwrites the text over the current folder i.e. `PS C:\Users\Somebody`. When switching back to the non-preview version of Windows Terminal and repeating the same steps everything works normally. 


### Expected Behavior

I expect the terminal not to overwrite to behave in a way it doesn't overwrite current folder i.e. `PS C:\Users\Somebody` part. Presently, it makes it really hard to execute any commands, especially because pwsh also doesn't support clearing the console buffer (some error about invalid cursor handle, I think this implies it's not using vt escape sequences or terminal is not translating these commands). 

### Actual Behavior

When you ssd into an windows machine and for example when you type the clear command, it displays on the screen as `clear\Users\Somebody>`. It doesn't matter what environment you sshd into cmd, powershell, pwsh all had the same problems of overwriting.
Repository: tauri
Issue: [bug] IME window position appears out of input/textarea (cannot inline-input) on Tauri v2 apps in Linux
Labels: type: bug,platform: Linux,status: needs triage

### Describe the bug

Typing in input or textarea with Japanese IME enabled, IME window appears out of the input/textarea.
This is different from #8264 or #5986

- This issue appears only Tauri v2 apps (v1 apps do not have this issue)
- IME window in this issue has both typing area and candidate selection (in previous issues, candidates selection is out of elements)

Screenshot below. IME window (typed "せかい") is placed far right-bottom of app window, overlaying on month display of the screen.
![Screenshot_IME_position_v2_20241019](https://github.com/user-attachments/assets/89884741-ab0f-49a9-820d-0ba99990ac82)

Additional information:
- IMEs : Fcitx/Mozc and iBus/Mozc (Mozc is open-source version of Google Japanese IME)
- OS : tested on Linux Mint 21 (based on Ubuntu 22.04) and 22 (based on Ubuntu 24.04)

### Reproduction

npm create tauri-app@latest
(choosing npm/Vanilla/TypeScript)
cd (projectname)
npm i
npm run tauri dev

type in input element with Japanese IME enabled

### Expected behavior

typed letters are shown in input element

### Full `tauri info` output

```text
[✔] Environment
    - OS: Linux Mint 21.3.0 x86_64 (X64)
    ✔ webkit2gtk-4.1: 2.44.3
    ✔ rsvg2: 2.52.5
    ✔ rustc: 1.81.0 (eeb90cda1 2024-09-04)
    ✔ cargo: 1.81.0 (2dbb1af80 2024-08-20)
    ✔ rustup: 1.27.1 (54dd3d00f 2024-04-24)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.18.0
    - npm: 10.8.2

[-] Packages
    - tauri 🦀: 2.0.4
    - tauri-build 🦀: 2.0.1
    - wry 🦀: 0.46.2
    - tao 🦀: 0.30.3
    - @tauri-apps/api : 2.0.2
    - @tauri-apps/cli : 2.0.3

[-] Plugins
    - tauri-plugin-shell 🦀: 2.0.1
    - @tauri-apps/plugin-shell : 2.0.0

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1420/
    - bundler: Vite
```


### Stack trace

_No response_

### Additional context

_No response_
Repository: godot
Issue: Android editor crash upon loading big project
Labels: bug,platform:android,topic:editor,needs testing,crash,regression

### Tested versions

Reproducible in 4.4 dev. #42224 ( perhanps in 4.3 too since upon restarting game after playing it, it crashes)

### System information

 Sansung s23+ Vulkan Mobile

### Issue description

It seems that upon when i open a big project in godot master branch after the last  dev version( dev3) it seems that while it loads the project at the last instance when like it loads editor layout it crashes in big projects like tps demo( in which before at 4.3 it didn't happen at all)( might post a video later, running out of battery) 

Edit: video 


https://github.com/user-attachments/assets/d9e3bcb0-b1da-4ab0-9323-17a58a8d9d8b


And weirdly enough it also kind of happens in 4.4 dev 3  , but not on the same way as  there it can be reproduced by first playing the game and after that minizing the window and then clicking on the restart game button it crashes too. 

Edit: other one that showcashes this crash on dev 3 


https://github.com/user-attachments/assets/61f3dfd2-8c9e-4439-852b-e486c5d0a6e9






### Steps to reproduce

• Open the roject linked below at mrp section

• Load it ( which at the end crashes on android)

•  If you can't reproduce , then maybr try going by playing game and after that restart , which might trigger another crash

### Minimal reproduction project (MRP)


Not small., but it reproducee it. 

https://drive.google.com/file/d/1wg1PLTlc6pZs-HzFzQEGAkN3Oo7sqAfB/view?usp=sharing
Repository: ui
Issue: Old blocks are not displaying on the website.
Labels: area: request

### Feature description

Old blocks are not displaying on the website. Please add pagination for the blocks


### Affected component/components

https://ui.shadcn.com/blocks

### Additional Context

_No response_

### Before submitting

- [X] I've made research efforts and searched the documentation
- [X] I've searched for existing issues and PRs
Repository: yt-dlp
Issue: Feature: OAuth client with cache process
Labels: enhancement,triage,core:extractor

### DO NOT REMOVE OR SKIP THE ISSUE TEMPLATE

- [X] I understand that I will be **blocked** if I *intentionally* remove or skip any mandatory\* field

### Checklist

- [X] I'm requesting a feature unrelated to a specific site
- [X] I've looked through the [README](https://github.com/yt-dlp/yt-dlp#readme)
- [X] I've verified that I have **updated yt-dlp to nightly or master** ([update instructions](https://github.com/yt-dlp/yt-dlp#update-channels))
- [X] I've searched [known issues](https://github.com/yt-dlp/yt-dlp/issues/3766) and the [bugtracker](https://github.com/yt-dlp/yt-dlp/issues?q=) for similar issues **including closed ones**. DO NOT post duplicates
- [X] I've read the [guidelines for opening an issue](https://github.com/yt-dlp/yt-dlp/blob/master/CONTRIBUTING.md#opening-an-issue)

### Provide a description that is worded well enough to be understood

Hey everyone!

## The problem

Recently I've noticed a PR about YouTube OAuth2 (#11001). This reminds me that I have an unfinished extractor about Sheeta with OAuth support (#9978). Writing OAuth stuff in procedural programming way [^1] makes me headache as the whole thing about OAuth looks "stateful", but implementing an extractor-exclusive OAuth client class in each single .py file to hold status looks overkill. So, that's a bit awkward.

Besides the authorization status, we also need to manually handle things about yt-dlp. The first thing that comes to my mind is the cache. In web browsers the "refresh token" is stored in localStorage, while in yt-dlp we can only use the cache to transfer data across multiple launches. Don't forget that the token is short-term valid (e.g., 300 seconds for Sheeta), so we have to drop cache in time.

## How to improve

Providing universal ways:

- The `InfoExtractor` class has an integrate OAuth client.
- The "_utils.py" file has a helper class about OAuth.
- Add a dependency library about OAuth and some helper functions to process cache things.
- ...

## Other things

You can search `grant_type` [^2] in the repository to see how many extractors are using OAuth.

For now I don't know the difference between OAuth, OAuth1 and OAuth2, so I use the "OAuth" word in the title.

Please correct me if you find anything wrong.

[^1]: Procedural programming - Wikipedia | https://en.wikipedia.org/wiki/Procedural_programming
[^2]: Application Grant Types | https://auth0.com/docs/get-started/applications/application-grant-types

### Provide verbose output that clearly demonstrates the problem

- [ ] Run **your** yt-dlp command with **-vU** flag added (`yt-dlp -vU <your command line>`)
- [ ] If using API, add `'verbose': True` to `YoutubeDL` params instead
- [ ] Copy the WHOLE output (starting with `[debug] Command-line config`) and insert it below

### Complete Verbose Output

_No response_