sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: godot
Issue: Performance Issue in VideoStreamPlayer on Linux Exports Without Debug Mode Enabled
Labels: bug,needs testing,topic:gui,performance

### Tested versions

Tested in 4.3dev6 mono and 4.2.stable mono (reproducible in both)

### System information

Ubuntu 22.04.4 LTS 22.04 - Wayland - Vulkan (Forward+) - integrated Intel(R) Graphics (ADL-N) () - Intel(R) N95 (4 Threads)

### Issue description

When running my exported project with Debug Mode turned off I am experiencing major frame rate issues only when a VideoStreamPlayer is playing. It acts as though it is locked at 20 FPS and is not fluctuating at all. During any other animations or process my game runs at the 60 FPS limit. When running the game in the editor or when exported with Debug Mode turned on everything works great and I never drop below the max 60 FPS in my project when a VideoStreamPlayer is playing. I will note that when I run this on my much stronger AMD Ubuntu machine I'm not seeing this issue. I only notice it on my low end intel Ubuntu computer using integrated graphics.

### Steps to reproduce

Add a VideoStreamPlayer to your scene and ensure it will be playing a video. Export it for Linux with 'Export With Debug' not checked.

### Minimal reproduction project (MRP)

[mrp.zip](https://github.com/godotengine/godot/files/15193207/mrp.zip)
Repository: angular
Issue: Computed signals and Effects should produce runtime warning if dependencies reaches zero
Labels: area: core,core: reactivity,cross-cutting: signals

### Which @angular/* package(s) are relevant/related to the feature request?

Core (signals)

### Description

An easy pitfall to encounter with computed signals and effects is creating a function that only gets called once because it depends on non-signal conditions.  Especially for devs new to signals (almost everyone at this point), it can be a counter-intuitive problem source to debug.  And there are already issues reported that can be traced to this.

https://github.com/angular/angular/issues/51180

Here's some example code that I wrote that caused non-obvious problems for me:

```ts
constructor() {
  effect(() => {
    this.calendarRef?.setInput('selected', this.range());
  });
}
```

`this.range` is a signal, and `this.calendarRef` is possibly undefined.  I expected any changes to `range` to trigger the effect, but the optional chaining on the `calendarRef` (which was undefined) prevented `range()` from ever being evaluated and thus tracked as a dependency.  And I believe that even if it wasn't undefined for the first run, if it _ever_ reached undefined while the effect was evaluated, the effect would never run again.

### Proposed solution

_At the least_, if the first run of a computed() or effect() callback produces no dependencies (invokes no signals), a runtime warning should show in the console to warn the user that their computed signal/effect will not run again.

It might also be useful to warn them if their dependency count drops from >1 to 0, which again means the computed signal/effect will not be evaluated again.

Similar to `allowSignalWrites`, the dev could remove these training-wheels warnings by positively expressing that they are intentionally designing a callback that will only be called once/stop being updated at some point.

### Alternatives considered

It would likely be harder to implement, but static code analysis could detect the _possibility_ of a zero-dependency computed signal/effect.

Regardless of whether a warning is added, documentation talking about this pitfall would be useful; currently not present as far as I can tell.
Repository: godot
Issue: SpinBox value gets changed by setting limits
Labels: bug,topic:gui

### Tested versions

v4.2.stable.official [46dc27791], v4.2.2.stable.official [15073afe3], v4.3.dev.custom_build [7ebc86641]

### System information

Godot v4.2.stable - macOS 14.4.1 - Vulkan (Forward+) - integrated Apple M2 - Apple M2 (8 Threads)

### Issue description

I create a SpinBox via code. It's for a relatively fine float value: min 0.001, max 2, step 0.001, default value 0.5 . When I assign the values in this order, it shows up fine. But when I set the **value first** and then the constraints, the value changes to 1.001, which I don't understand.


### Steps to reproduce


Code initializing the spin boxes:

```gdscript
func _ready() -> void:
	# Here I set the properties first
	spin_box.min_value = 0.001
	spin_box.max_value = 2
	spin_box.step = 0.001
	# And then the actual value
	spin_box.value = 0.5
	
	# ----------------
	
	# Here I set the value first
	spin_box_2.value = 0.5
	# and then the properties
	spin_box_2.min_value = 0.001
	spin_box_2.max_value = 2
	spin_box_2.step = 0.001
```

Result:

![Screenshot 2024-05-02 at 22 53 27](https://github.com/godotengine/godot/assets/49688205/50409b86-d37f-41d0-a6da-5c8d5c38cd77)


### Minimal reproduction project (MRP)

[bug-report-spin-box.zip](https://github.com/godotengine/godot/files/15193915/bug-report-spin-box.zip)
Repository: rust
Issue: Improve error output for "expected value, found type parameter"
Labels: A-diagnostics,T-compiler,E-help-wanted,E-needs-mcve,D-terse

### Code

```Rust
pub fn delayed_insert<'a, T, C: Clone + Component>
        (ecommands: &'a mut EntityCommands<'a>,
         delay: Duration, c: C)
        -> &'a mut EntityCommands<'a> {
    ecommands.insert(DelayedInsert<T, C>::new(delay, c))
}
```


### Current output

```Shell
error[E0423]: expected value, found type parameter `T`
  --> src/delay.rs:22:36
   |
18 | pub fn delayed_insert<'a, T, C: Clone + Component>
   |                           - found this type parameter
...
22 |     ecommands.insert(DelayedInsert<T, C>::new(delay, c))
   |                                    ^ help: a local variable with a similar name exists: `c`
```


### Desired output

```Shell
error[E0423]: expected value, found type parameter `T`
  --> src/delay.rs:22:36
   |
18 | pub fn delayed_insert<'a, T, C: Clone + Component>
   |                           - found this type parameter
...
22 |     ecommands.insert(DelayedInsert<T, C>::new(delay, c))
   |                                    ^ help: a local variable with a similar name exists: `c`
   |                                    ^ alternate help: Substituting ::< for < may fix this
```


### Rationale and extra context

In some cases rustc correctly suggests that the turbofish syntax is required.

Here, however, it looks like user intent is ambiguous and the compiler expects a comparison operator (which expects a value on the right of the < operator) but the error help doesn't offer the "correct" suggestion. So it may be helpful to offer an aldditional suggestion whenever the output is "expected value, found type parameter": use turbofish syntax.

I suspect this shouldn't require gathering or printing any more information than the compiler already has at-hand in this context -- a static, alternative, suggestion is likely all that'd be needed.

### Other cases

_No response_

### Rust Version

```Shell
rustc 1.77.2 (25ef9e3d8 2024-04-09)
binary: rustc
commit-hash: 25ef9e3d85d934b27d9dada2f9dd52b1dc63bb04
commit-date: 2024-04-09
host: x86_64-unknown-linux-gnu
release: 1.77.2
LLVM version: 17.0.6
```


### Anything else?

Might be as easy to close this issue as looking for that string in the rustc source and modifying an existing output string.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

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

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: next.js
Issue: Standalone export broken
Labels: bug,Output (export/standalone)

### Link to the code that reproduces this issue

https://github.com/shimizu-izumi/broken-standalone-export

### To Reproduce

1. Create a new project using `npx create-next-app@latest`
2. Use the following settings:
ESLint: Yes
Tailwind CSS: Yes
`src/` directory: Yes
App Router: Yes
customize the default import alias (@/*): Yes
import alias: ~/*
3. Set the output to `standalone` in the `next.config.js`
4. Build the project
5. Start the project using `node .next/standalone/server.js`

### Current vs. Expected behavior

Following the reproduction steps should result in the CSS and JS missing, the expected result would be a fully functional build that misses nothing.

### Provide environment information

```bash
Operating System:
  Platform: win32
  Arch: x64
  Version: Windows 11 Pro
  Available memory (MB): 32509
  Available CPU cores: 32
Binaries:
  Node: 20.12.2
  npm: 10.7.0
  Yarn: N/A
  pnpm: N/A
Relevant Packages:
  next: 14.2.3 // Latest available version is detected (14.2.3).
  eslint-config-next: 14.2.3
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.4.5
Next.js Config:
  output: standalone
```


### Which area(s) are affected? (Select all that apply)

Output (export/standalone)

### Which stage(s) are affected? (Select all that apply)

next start (local), Other (Deployed)

### Additional context

_No response_
Repository: flutter
Issue: [Impeller] TextureSourceVK::SetLayout API is hard to use correctly.
Labels: P3,e: impeller,team-engine,triaged-engine

If the new layout is the same as the old layout, the barrier is never inserted. This may cause issues if the transition is elided. And the caller may depend on the barrier being inserted. The method must return if a transition was actually performed.
Repository: TypeScript
Issue: Design Meeting Notes, 3/29/2024
Labels: Design Notes

# When should you be able to implicitly return `undefined`

https://github.com/microsoft/TypeScript/pull/57912

* We allow people to implicitly return when a type
    * is `undefined`.
* But no implicit returns when you have `4 | undefined`
    * More importantly, you can't do `Promise<undefined> | undefined`.
* Let's revisit.

# Knip

https://github.com/microsoft/TypeScript/pull/56817

* Unused code detector - unused code, unreferenced dependencies, etc.
* Used on DefinitelyTyped tools.
* Is able to flag/fix utilities that shouldn't be exported.
* We do like the idea of adding this - the CI time is a bit higher and that does make our workflow for bisecting a bit painful.
    * Considering adding it purely in CI and purely on-demand by the team; but not part of `devDependencies`.

# Using const enums in value space when using `--preserveConstEnums`

https://github.com/microsoft/TypeScript/pull/57996

* We have all these restrictions around being able to reference const enum declarations as direct values.

  ```ts
  const enum E {
    A = 123,
  }

  let x = E; // ❌
  ```
    * We get around this by writing `(ts as any).SomeEnum`
    * It works because we use `preserveConstEnums`.
* Recently #57914 got merged, says that you can reference `const enum` members from another project under `isolatedDeclarations` if the project has `preserveConstEnums` enabled.
    * This effectively gives us some of the same checks to determine if it's safe to reference the enum declaration itself across files.
        * Something we could do within a project before, but not across. Now we can do both.
* We need this ourselves to enable `isolatedDeclarations`
* Doesn't esbuild just inline enums unconditionally? Regardless of const-ness?
    * Could just switch these all to regular enums, turn off `preserveConstEnums`
    * That means we'd always take a perf hit in `services` from enums declared in `compiler`.
        * Or in general?
        * Maybe acceptable.
    * What happens if we start emitting to pure ESM with no bundling?
        * Perf hit!
* In principal, don't like looking up compiler settings from dependency projects.
* Well we can do what we want, but the request came externally.
* We preserved originally only for debugging purposes.
* Not totally against, this, but some of us feel like our own codebase would be better served from dropping `const` from our `enum`s.
* Also you want consumers not to inline, but you also don't want `@foo/package-a` and `@foo/package-b` not to inline between each other.
* Revisit.
Repository: TypeScript
Issue: Design Meeting Notes, 4/16/2024
Labels: Design Notes


# The `configDir` Configuration Variable

https://github.com/microsoft/TypeScript/issues/57485

* Configuration variable for directory of the current `tsconfig.json`
    * We are leaning towards `configDir`
    * We are also looking towards using `${` and `}` as the delimiters.
        * This is awful because lint rules.
* `<` and `>` avoid conflicts, but we kinda like.
* Why `configDir`? Why not `projectDir`?
    * Shrug.
* We like that it matches VS Code's style and matches intuitions JS template strings.

# Correctly Check `this` Type Predicates

#57341

* We were not correctly checking `this` type predicates.
* This PR actually performs the checking.
* Unfortunate that this breaks:

  ```ts
  interface Animal {
    isDog() this is Dog;
  }

  interface Dog {
    isDog(): true;
  }
  ```
* Kind of weird that someone wrote this

  ```ts
  interface Animal {
    isDog() this is Dog;
  }

  interface Dog {
    isDog(): this is never;
  }
  ```
    * But this is wrong - type predicates have to be invariant.
        * Wait really?
        * Yes really.
        * Why?
        * Because type predicates returning false implies that the type should be narrowed to the negative cases.
        * If you had `Poodle` say `this is Poodle`, then returning false implies that you don't have a Dog if you have a `BorderCollie`.
* Is there a similar problem for assertion function?
* This seems correct.

# Perf Suites Benchmarking Additions/Modifications

https://github.com/microsoft/typescript-benchmarking/issues/32

* We are trying to fix up our perf suite to get representative tests.
* Also, moving away from internal testing. Huge pain to maintain.
* Need to put out a call for test cases.
    * Medium-sized (compiles between 10s to 30s)
    * Modern (works on the latest version)
    * Exhibits usage of diverse features
        * Module modes (nodenext, bundler, preserve)
        * JSX
        * Decorators
        * ...

# `noCheck` (or `skipCheck`?)

* Will we be adding this as a `--build` option in the future?
* We will probably need it for ourselves.
* However, if you run this from the command line, there's no way to know how to do this incrementally.
    * So you'd have to have 2 `tsconfig.json`s for each project.
* What exaclty is going wrong?
    * `tsc -b --skipCheck` outputs all `.d.ts` files.
    * Then when you run `tsc -b`, all the outputs are newer so it doesn't try to rebuild!
* We would need different metadata to be stored to make this work. 
* Also: likely won't work with `noEmitOnError`.
    * Or at least - it may work awkwardly with `noEmitOnError`.
* On the CLI, we don't feel like the UX makes sense *yet*, but we want to add this internally.
Repository: TypeScript
Issue: Design Meeting Notes, 4/23/2024
Labels: Design Notes

*Notes courtesy of @RyanCavanaugh*

* #58264
   * Disallow truthy checks on enum values since they're not variable
   * Yep, seems good
* #58261 `transpileDeclaration`
   * Emits .d.ts instead of .js like `transpileModule`
   * Implies additional required flags, of course
   * We need a minimal lib file to make everything work out for `Symbol.` references
   * Quick discussion of symbol freshness under ID
   * This is the requested "reference implementation" of a syntactic declaration emitter
   * Yep, seems good
   * Merge whenever (pre- or post-beta)
   * Jake to review
* #58296 `--enforceReadonly`
   * Long has it been rumored
   * Changes the subtype relation to disallow mutable properties to alias readonly ones
   * Tweaks the definition of `as const` to also "fit" the contextual type by relaxing `readonly` inferences that would have caused a failure
   * Most other work is in making the lib compile again, particularly `prototype`
   * This is heckin' breaky but tends not to find many real issues since aliased mutation is rare
   * Need to update the DOM generator
   * What's the uptake plan?
     * Hope your dependencies did a good job
     * `skipLibCheck` might let you get away with it
   * What's the plan for DT?
     * Turn it on in new types
     * Roll out as people are able to
     * Patience!
     * Maybe try automating adding `readonly` "everywhere" and back it off from tests
       * Are we really doing 8,000 PRs??
   * What about methods overwritten by a readonly property?
     * Currenty allowed, but probably shouldn't be
     * Confusing because methods are only *mostly* not mutated
Repository: TypeScript
Issue: tsc --init update 2024
Labels: Discussion

### Acknowledgement

- [X] I acknowledge that issues using this template may be closed without further explanation at the maintainer's discretion.

### Comment

Following up from #58417

Note: This is only for *argumentless* `tsc --init`. We know that it's physically possible to write text after `--init` and that text could do something, but that's a separate issue. Since `tsc --init` should do *something*, this issue is only about what that something is.

General consensus from the design meeting + external discussion:
 * No one likes the huge wall of text
 * Not many people like the commented-out options, and certainly not the "terrible idea" commented-out options
 * `"module": "commonjs"` is a hard no

Other live issues:
 * #39354 - set `types` to `[]` - yes
 * #49206, #39308 - increase default target - also yes
 * #39311 - set `udfcf` - I would argue moot by now since we should set the target high enough that this doesn't matter
 * #51207 - consult `package.json` - it's not obvious that your `package.json` is configured yet at the time you run `tsc --init`, this seems marginal

Other things we didn't get to:
 * `rootDir`, `outDir`: These are generally a good idea; no one likes the default side-by-side JS emit buuut there aren't strictly universal conventions here

Proposed new output:
```jsonc
{
    // For more info, see https://aka.ms/tsconfig
    // Or use the tsc-init wizard: https://aka.ms/tsc-init
    "compilerOptions": {
        "target": "es2022",
        "module": "nodenext",
        "rootDir": "./src",
        "outDir": "./dist",

        // For nodejs, add "node" to this array,
        // and remove "dom" from "lib"
        "types": [],
        "lib": ["dom", "es2022"],

        // Other outputs
        "sourceMap": true,
        // "declaration: true,

        // Typechecking options
        "noUncheckedIndexedAccess": true,
        "exactOptionalPropertyTypes": true,

        // Style options
        // "noImplicitReturns": true,
        // "noImplicitOverride": true,
        // "noUnusedLocals": true,
        // "noUnusedParameters": true,
        // "noFallthroughCasesInSwitch": true,
        // "noPropertyAccessFromIndexSignature": true,

        // We recommend all of these options
        "verbatimModuleSyntax": true,
        "isolatedModules": true,
        "moduleDetection": "force",
        "skipLibCheck": true,
        "strict": true
    }
}
```
I tried to order this from "most likely to edit" to "least likely to edit"
Repository: godot
Issue: Minimized window instantly re-minimizes itself when project is configured to use the Minimized window mode on startup
Labels: bug,platform:linuxbsd,topic:porting

- *Related to https://github.com/godotengine/godot/issues/82295
and https://github.com/godotengine/godot/issues/84905.*

### Tested versions

- Reproducible in: 4.0.3.stable, 4.1.2.stable, 4.2.1.stable, 4.3.dev b9e022302

### System information

Godot v4.3.dev (d282e4f0e) - Fedora Linux 39 (KDE Plasma) - X11 - GLES3 (Compatibility) - NVIDIA GeForce RTX 4090 (nvidia; 550.76) - 13th Gen Intel(R) Core(TM) i9-13900K (32 Threads)

### Issue description

When you configure a project to use the **Minimized** window mode, it starts minimized correctly. However, when you alt-tab to it or click it in the taskbar, it will show up for a split second and minimize itself again. You need to click it one more time (sometimes more) for it to show up again permanently.

This occurs with all rendering methods, both when the project is run from the editor and run from the command line. I've only tested this on Linux/X11 so far, but it's likely this issue is OS-specific.

### Steps to reproduce

- Set **Display > Window > Size > Mode** to **Minimized** in the Project Settings.
- Run the project. You may need to do this several times to reproduce the issue for sure, but here it occurs 100% of the time.

### Minimal reproduction project (MRP)

[test_minimized.zip](https://github.com/godotengine/godot/files/15194881/test_minimized.zip)
Repository: vscode
Issue: Provide API to access Profiles
Labels: feature-request,api,user-profiles

<!-- ⚠️⚠️ Do Not Delete This! feature_request_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- Please search existing issues to avoid creating duplicates. -->

<!-- Describe the feature you'd like. -->
Hi,

I'm adding a feature to my [Project Manager](https://marketplace.visualstudio.com/items?itemName=alefragnani.project-manager) extension that will allow the user to manually assign a **Profile** to any of its projects. To do this, today, the user must type the Profile's name, like this:

```json
        {
		"name": "vscode-separators",
		"rootPath": "~/sources/vscode-separators",
		"paths": [],
		"tags": [
			"Personal"
		],
		"enabled": true,
		"profile": "Copilot"
	},
```

It would be great the user could select the Profile from a `QuickPick`, similar to the one displayed when the user wants to switch Profiles (`Profiles: Switch Profile...`). Or, if my extension could automatically use the current profile name, which is already been requested in #177463. This would be specially useful not only in a UX standpoint, but also because profile's name are case sensitive, and any typo end up with a new profile.

Profiles contents, on the other hand, are not necessary, at least not for my use case. But maybe other extension authors could enjoy. Maybe even Copilot could use list of extensions contained in each profile, to _suggest_ the profile that better match the project that the user is using/saving.

Thanks in advance
Repository: terminal
Issue: Terminal weirdness after using vim 9.1
Labels: Area-Output,Issue-Bug,Product-Terminal

### Windows Terminal version

1.20.10822.0

### Windows build number

22631.3447

### Other Software

vim 9.1 with cmd.exe

### Steps to reproduce

Launch vim
Exit vim

### Expected Behavior

Terminal behaves normally

### Actual Behavior

After I exit vim, my cursor gets positioned 3 lines before the last line. Also, if I ever try to use cmd tab completion or backspace etc, my cursor moves up 3 lines above where I was typing, so I am now typing against some random text while my real command is 3 lines below. I have another machine with vim 9.0 installed and it does not repro there.