sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: TypeScript
Issue: Process suggestion: describe breaking changes to .d.ts files in "Announcing TypeScript 4.x" blog posts
Labels: Docs

# Suggestion

## 🔍 Search Terms

blog announcing release notes announcement downlevel-dts breaking changes

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

The TypeScript project's release announcement blog posts (like [this one for 4.8](https://devblogs.microsoft.com/typescript/announcing-typescript-4-8/)) are excellently crafted documents. I look forward to reading each one. They teach me about new features with motivating examples, and describe breaking changes that I may have to deal with.

However, there's one class of changes that I can't easily learn about from these release posts (and I don't believe there's anywhere else that answers the same question).  I don't know an easy way to answer the questions "If I upgrade to this version, build a library, and publish its .d.ts files, will my library's users also have to use this new version? Does this answer depend on whether I use new features or whether I set specific settings?

For example, in TS 4.7, using variance annotations would require consumers of `.d.ts` files to upgrade to TS 4.7; the upgrade isn't required if you don't use the feature.

On the other hand, I don't think TS 4.8 contains any syntax changes to generated `.d.ts` files.

In a sense, I'm looking for an easy way to learn about whether the release introduces any changes for which [`downlevel-dts`](https://github.com/sandersn/downlevel-dts) might be helpful.  I think this would go well in the announcement blog post, or somewhere else that's easy to find for each release.

## 📃 Motivating Example

Being able to tell the difference between features like variance annotations (which require consumers of `.d.ts` files to upgrade TS) and other features.

## 💻 Use Cases

Understanding when I upgrade TypeScript or use new features if I am also forcing consumers of my library to upgrade TypeScript.
Repository: godot
Issue: CharacterBody2D doesn't interact with RigidDynamicBody2D
Labels: bug,topic:physics

### Godot version

4.0 dev

### System information

Windows 11 - Vulkan

### Issue description

Setting up a simple scene with a simple chain made of simple links joined together with PinJoin2D. A player, instantiated from a CharacterBody2D is unable to move the chain. As soon as the player is instantieted from a RigidDynamicBody2D, the interaction between the player and the chain is restored. This behavior is not reproducible in Godot 3.5, where the KynematicBody2D interact flawlessly with the RigidBody2D. Is this an expected behaviour in Godot 4? I dont't think so.

### Steps to reproduce

Use the attached project.

Player 1 is RigidDynamicBody2D - Control is JOYPAD LEFT STICK
Player 2 is CharacterBody2d - Control is JOYPAD RIGHT STICK

### Minimal reproduction project

Player 1 is RigidDynamicBody2D - Control is JOYPAD LEFT STICK
Player 2 is CharacterBody2d - Control is JOYPAD RIGHT STICK
[test.zip](https://github.com/godotengine/godot/files/9435770/test.zip)
Repository: next.js
Issue: Cannot access ... before initialization
Labels: bug,Testing

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```
yarn next info

    Operating System:
      Platform: darwin
      Arch: arm64
      Version: Darwin Kernel Version 21.6.0: Sat Jun 18 17:07:22 PDT 2022; root:xnu-8020.140.41~1/RELEASE_ARM64_T6000
    Binaries:
      Node: 16.16.0
      npm: 8.11.0
      Yarn: 3.2.0
      pnpm: N/A
    Relevant packages:
      next: 12.2.4
      eslint-config-next: 12.2.0
      react: 17.0.2
      react-dom: 17.0.2

warn  - Latest canary version not detected, detected: "12.2.4", newest: "12.2.6-canary.5".
        Please try the latest canary version (`npm install next@canary`) to confirm the issue still exists before creating a new issue.
        Read more - https://nextjs.org/docs/messages/opening-an-issue
```

### What browser are you using? (if relevant)

Chrome

### How are you deploying your application? (if relevant)

yarn jest

### Describe the Bug

Between 12.2.0 and 12.2.1 a big chunk of our unit tests broke. Any test using `jest.requireActual('')` to not mock some of the modules fails with an error like this:

```
    ReferenceError: Cannot access 'buildError' before initialization

      81 |
    > 82 | export const buildError = {
```

I tried to debug this, but sadly am not able to view the swc compiled source files.

Additionally all tests using `jest.mock('next/router')` have to be changed to:

```tsx
jest.mock('next/router', () => ({
  useRouter: jest.fn(),
});
```

Because that now yielded the following error:

```
No router instance found.
    You should only use "next/router" on the client side of your app.
```

### Expected Behavior

`jest.requireActual('')` to keep working.

### Link to reproduction

Tried to reproduce in simple repo but wasn't able to get the same behaviour

### To Reproduce

This part of the test that breaks:

```tsx
jest.mock('./bla', () => ({
  ...jest.requireActual('./bla'),
  useBla: jest.fn(),
});

describe('SomeComponent', () => {
  const getComponent = (): ShallowWrapper => shallow(<SomeComponent />);

  it('should bla', () => {
    const component = getComponent();

    expect(component.html()).toBeNull();
  });
});
```

```tsx
export const SomeComponent: React.FC = () => {
  const bla = useBla();

  return bla;
};
```

```tsx
export const buildError = {
  build: () => 'test',
};

export const useBla = () => 'bla';
```

Compiler options:

```
    compiler: {
      styledComponents: {
        cssProp: false,
      },

      emotion:
        // Don't compile with jest otherwise all emotion components become EmotionCSSPropInternal
        phase === PHASE_TEST
          ? null
          : {
              sourceMap: true,
              autoLabel: 'dev-only',
              labelFormat: 'local',
            },

      removeConsole:
        phase === PHASE_PRODUCTION_BUILD || phase === PHASE_PRODUCTION_SERVER,
    },
```
Repository: pytorch
Issue: Please include virtual/physical batch sizes in the tutorials
Labels: module: docs,triaged

### 📚 The doc issue

The tutorials in the website, e.g. the [CIFAR10 tutorial](https://pytorch.org/tutorials/beginner/blitz/cifar10_tutorial.html) only refer to the batch size when initializing the dataloader. The batch size used for the dataloader is the same batch size used for the optimization step:

```
batch_size = 4

trainset = torchvision.datasets.CIFAR10(root='./data', train=True,
                                        download=True, transform=transform)
trainloader = torch.utils.data.DataLoader(trainset, batch_size=batch_size,
                                          shuffle=True, num_workers=2)
```

However, when using a single GPU, people may sometimes want to simulate rather large virtual batch sizes, i.e., compute the gradients of many small "physical" batches, which are feasible to compute on their GPU, but only take the optimization step when reaching the desired amount of samples in the "virtual" batch. It is not trivial, since it turns out that the [gradients of the small batches are summed](https://discuss.pytorch.org/t/how-are-losses-aggregated-over-multiple-computed-batches/160041). This means that the optimization step size taken using the final gradient will be K times larger than the user-specified learning rate, which may be undesirable in most cases. The losses of the small batches should therefore be multiplied by their relative size, so the final gradient will exactly simulate a large batch.



### Suggest a potential alternative/fix

### I'd change the code as follows:

## Dataloader initialization
```
optimization_batch_size = 16
physical_batch_size = 4

trainset = torchvision.datasets.CIFAR10(root='./data', train=True,
                                        download=True, transform=transform)
trainloader = torch.utils.data.DataLoader(trainset, batch_size=optimization_batch_size,
                                          shuffle=True, num_workers=2)
```

## Training
```
running_loss = 0.0
for i, data in enumerate(trainloader, 0):
    # get the inputs; data is a list of [inputs, labels]
    inputs, labels = data
    
    # zero the parameter gradients
    optimizer.zero_grad()

    # run batch
    batch_loss = 0.0
    # compute all physical batches
    for j in range(0, len(inputs), physical_batch_size):
        end_index = min(j + physical_batch_size, len(inputs))
        inputs_j = inputs[j:end_index]
        labels_j = labels[j:end_index]
        # forward + backward
        outputs_j = net(inputs_j)
        loss = criterion(outputs_j, labels_j) * len(inputs_j) / float(len(inputs))
        batch_loss += loss.item()
        loss.backward()
    # optimize whole batch
    optimizer.step()

    # print statistics
    running_loss += batch_loss
    if i % 2000 == 1999:    # print every 2000 mini-batches
        print(f'[{epoch + 1}, {i + 1:5d}] loss: {running_loss / 2000:.3f}')
        running_loss = 0.0
```


cc @svekars @holly1238
Repository: rust
Issue: Codegen weirdness for `sum` of `count_ones` over an array
Labels: A-LLVM,I-slow,A-codegen,O-x86_64,P-high,T-compiler,regression-from-stable-to-stable,C-bug,WG-llvm,A-autovectorization

(Issue loosely owned by @wesleywiser and @pnkfelix monitoring https://github.com/llvm/llvm-project/issues/57476 )

### Original Description below

```rust
pub fn f(arr: [u64; 2]) -> u32 {
    arr.into_iter().map(u64::count_ones).sum()
}
```

Before 1.62.0, this code correctly compiled to two popcounts and an addition on a modern x86-64 target.

```asm
example::f:
        popcnt  rcx, qword ptr [rdi]
        popcnt  rax, qword ptr [rdi + 8]
        add     eax, ecx
        ret
```

Since 1.62.0 (up to latest nightly), the codegen is... [baffling at best.](https://godbolt.org/z/G9fa4Y8T7)

```asm
.LCPI0_0:
        .zero   16,15
.LCPI0_1:
        .byte   0
        .byte   1
        .byte   1
        .byte   2
        .byte   1
        .byte   2
        .byte   2
        .byte   3
        .byte   1
        .byte   2
        .byte   2
        .byte   3
        .byte   2
        .byte   3
        .byte   3
        .byte   4
example::f:
        sub     rsp, 40
        vmovups xmm0, xmmword ptr [rdi]
        vmovdqa xmm1, xmmword ptr [rip + .LCPI0_0]
        vmovdqa xmm3, xmmword ptr [rip + .LCPI0_1]
        vmovaps xmmword ptr [rsp], xmm0
        vmovdqa xmm0, xmmword ptr [rsp]
        vpand   xmm2, xmm0, xmm1
        vpsrlw  xmm0, xmm0, 4
        vpand   xmm0, xmm0, xmm1
        vpshufb xmm2, xmm3, xmm2
        vpxor   xmm1, xmm1, xmm1
        vpshufb xmm0, xmm3, xmm0
        vpaddb  xmm0, xmm0, xmm2
        vpsadbw xmm0, xmm0, xmm1
        vpshufd xmm1, xmm0, 170
        vpaddd  xmm0, xmm0, xmm1
        vmovd   eax, xmm0
        add     rsp, 40
        ret
```

The assembly for the original function is now a terribly misguided autovectorization. And, just to make sure (even though it's pretty obvious), I did run a benchmark - the autovectorized function is ~8x slower on my Zen 2 system.

Calling that function from a different function brings back normal assembly. `-Cno-vectorize-slp` does nothing. I don't know exactly what `-Cno-vectorize-loops` does, but it's not good.

If you change the length of the array to 4, both functions get autovectorized. `-Cno-vectorize-slp` fixes the second function now. Adding `-Cno-vectorize-loops` causes the passthrough function to generate the worst assembly.

Changing `into_iter` to `iter` fixes length 2, but doesn't fix length 4.

I could go on, but in short it's a whole mess.

I found a workaround that consistently works for all lengths: `iter` and `-Cno-vectorize-slp`.

@rustbot modify labels: +regression-from-stable-to-stable -regression-untriaged +A-array +A-codegen +A-iterators +A-LLVM +A-simd +I-slow +O-x86_64 +perf-regression
Repository: pytorch
Issue: [Quant] Reference get_default_qconfig_mapping in docs/tutorials
Labels: oncall: quantization,triaged

Right now the recommended flow for FX graph mode quantization is:
```
from torch.ao.quantization import get_default_qconfig_mapping
from torch.ao.quantization.quantize_fx import prepare_fx, convert_fx
...
qconfig_mapping = get_default_qconfig_mapping("fbgemm")
model = prepare_fx(model, qconfig_mapping, example_inputs)
model(...) # calibrate
model = convert_fx(model)
```
However, `get_default_qconfig_mapping` is not documented or referenced (same for `get_default_qat_qconfig_mapping`). We should make sure this is easily accessible in the following places:
- https://pytorch.org/docs/master/quantization-support.html
- https://pytorch.org/docs/master/generated/torch.quantization.quantize_fx.prepare_fx.html#torch.quantization.quantize_fx.prepare_fx
- https://pytorch.org/tutorials/prototype/fx_graph_mode_ptq_static.html

cc @jerryzh168 @jianyuh @raghuramank100 @jamesr66a @vkuzo @jgong5 @Xia-Weiwen @leslie-fang-intel
Repository: flutter
Issue: [camera] The camera plugin is crashing the Android app
Labels: c: crash,platform-android,p: camera,package,has reproducible steps,P2,c: fatal crash,found in release: 3.0,found in release: 3.1,team-android,triaged-android

## Steps to Reproduce

<!-- Please include full steps to reproduce so that we can reproduce the problem. -->
I am developing a complex app, based on the camera plugin example. Despite following the example closely, it is occasionally running into conditions which are crashing the native code, mainly "java.lang.IllegalArgumentException: Surface was abandoned". These do not get caught by the native code, and thus result in a crash of the overall app.


**Expected results:** native code catches all native exceptions and forwards them to Flutter code

**Actual results:** native code only catches CameraAccessException, allowing any other exception to crash the app.

I am proposing to make the catch-statement in Camera onOpened less specific, in order to catch any exception and send it to Flutter for handling.

```kotlin
public void onOpened(@NonNull CameraDevice device) {
            cameraDevice = new DefaultCameraDeviceWrapper(device);
            try {
              startPreview();
              dartMessenger.sendCameraInitializedEvent(
                  resolutionFeature.getPreviewSize().getWidth(),
                  resolutionFeature.getPreviewSize().getHeight(),
                  cameraFeatures.getExposureLock().getValue(),
                  cameraFeatures.getAutoFocus().getValue(),
                  cameraFeatures.getExposurePoint().checkIsSupported(),
                  cameraFeatures.getFocusPoint().checkIsSupported());
            } **catch (CameraAccessException e) {**
              dartMessenger.sendCameraErrorEvent(e.getMessage());
              close();
            }
```
Repository: PowerToys
Issue: [PT Run] [Time zone plugin] Requesting Search improvements for time zone names & offsets
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage,Run-Plugin

### Description of the new feature / enhancement

I love the PT Run Time zone plugin, great idea. 

Searching doesn't always work quite as well as I'd hope. Searching for `EST` doesn't turn up US/Eastern anywhere near the top of the list... and trying to scroll through with keyboard shows some janky behavior. (This "janky behavior" is described in bug #18693 - I'm assuming that behavior is more a general PT Run bug than anything specific to this plugin.)  

Searching for `UTC` should also return Zulu time, but doesn't (nor does `universal`). I've seen that zone pop up occasionally but _not_ when I searched for `UTC` or `Universal`! 

I also would expect typing `& UTC-5` would give me a list of the zone names that are in that offset, but it does nothing. But just "& -5" does work on its own...

I have more requests for this plugin, but per the project guidelines, I will file them as separate github issues.

### Scenario when this would be used?

Improving the search logic should help make the extension more usable for all.

### Supporting information

_No response_
Repository: PowerToys
Issue: [PT Run] [Time zone plugin] Time is always displayed in 24h / does not respect Localization settings
Labels: Idea-Enhancement,Product-PowerToys Run,Needs-Triage,Run-Plugin

### Description of the new feature / enhancement

I use standard US display settings on my system, including 12h time with AM/PM. 

I don't necessarily _dislike_ that the Time zone plugin is displaying 24h time, because most of the time when I'm doing TZ conversion work, I'm also looking at logs that are in 24h time. But, it would be much more user-friendly if the plugin had a toggle option to either follow the user's L10n/i18n setting, or have a "forced mode" (just for the plugin, separate from system settings).

### Scenario when this would be used?

It's always good to offer a choice! 
I don't mind the default being 24h, but a simple drop-down for "12h / 24h / Use System Setting" would be ideal.

### Supporting information

_No response_
Repository: TypeScript
Issue: IntelliSense autocomplete doesn't provide suggestions for contextual types in nested functions
Labels: Suggestion,Help Wanted,Experience Enhancement

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🔎 Search Terms

<!--
  What search terms did you use when trying to find an existing bug report?
  List them here so people in the future can find this one more easily.
-->
intellisense autocomplete nested

### 🕗 Version & Regression Information

<!-- When did you start seeing this bug occur?

"Bugs" that have existed in TS for a long time are very likely to be FAQs; refer to
  https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs

If possible, please try testing the nightly version of TS to see if it's already been fixed.
For npm: `typescript@next`
This is also the 'Nightly' version in the playground: http://www.typescriptlang.org/play/?ts=Nightly

Note: The TypeScript Playground can be used to try older versions of TypeScript.

Please keep and fill in the line that best applies:
-->
- This is the behavior in every version I tried, and I reviewed the FAQ for entries about intellisense.

### ⏯ Playground Link

<!--
  A link to a TypeScript Playground "Share" link which shows this behavior

  The TypeScript Workbench can be used for more complex setups, try
  https://www.typescriptlang.org/dev/bug-workbench/

  As a last resort, you can link to a repo, but these will be slower for us to investigate.
-->
[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.7.4#code/PTAEFEA0EEFkAUAy4CwAodATApgYwDYCGATtqAGYCuAdrgC4CWA9taLqYXdgDwAqo2AB5dqmAM6gA5OSZNJoAD5SARiUkA+ABQA3QvkrYAXKF4BKY7wDc6LHiKkKNes1aE+W3fqMnzJ62hwCEjIqWkYWUGV3HT0DC18rGzQQUEJKOiZcJgBbAAd8bC5QAHcmYgBrMXR2bE5sTUJNaVlJU1N-dBS0jKy8gqLMJmwxakk6ErLy6o4uBs1lJpk5NvaklPhoACVeAEloRFAAdQB5TYBpLeOAVQA5ABEkugBPXLIbph3qcmxid1AAXhMAmE2FEEgYXx+oCuoAA-NDQMZqNhtD8OgE7MFHGEXKkAEzRTxxUDvT7fX68dQJdFddKZHL5QpkUoVCTKdKgZ6vSJ4HLDUA0crUJjFajTWqzQh4+aLForSxAA)

### 💻 Code

<!-- Please post the relevant code sample here as well-->
```ts
// EXAMPLE

declare function create<T extends 'foo' | 'bar'>(value: T): T;

declare function a<T>(value: T): T;
declare function b<T>(value: T): T;

// autocomplete works
create(a('foo'));

// autocomplete doesn't work
create(a(b('foo')));

// PARTIAL WORKAROUND

type NoInfer<T> = T extends infer U ? U : never;

declare function a2<T>(value: NoInfer<T>): T;

// autocomplete works but type becomes unknown
create(a2(b('foo')));
```

### 🙁 Actual behavior

<!-- What happened, and why it was wrong -->
When functions are nested the types flow through and are checked correctly but autocomplete doesn't provide suggestions.

### 🙂 Expected behavior

<!-- What you expected to happen instead, and why -->
I would like autocomplete to provide suggestions for arguments in nested functions, based on the underlying return type. My actual use case involves more complex functions that are used to build nested objects.
Repository: youtube-dl
Issue: Erocast
Labels: site-support-request,Good first issue

- [v ] I'm reporting a new site support request
- [v ] I've verified that I'm running youtube-dl version **2021.12.17**
- [v ] I've checked that all provided URLs are alive and playable in a browser
- [v ] I've checked that none of provided URLs violate any copyrights
- [v ] I've searched the bugtracker for similar site support requests including closed ones


## Example URLs

<!--
Provide all kinds of example URLs support for which should be included. Replace following example URLs by yours.
-->

 https://erocast.me/track/4254/intimate-morning-with-your-wife


## Description

Popular website for adult voice actors from /r/gonewildaudio
Repository: godot
Issue: Pasting TileMap node pastes tile pattern at the same time
Labels: bug,topic:editor,usability,topic:2d

### Godot version

[4808d01](https://github.com/godotengine/godot/commit/4808d01b2bcda54db15e1e2649e0a38c37886ee1)

### System information

Windows 10 x64

### Issue description

![godot_FzRdFO4F1M](https://user-images.githubusercontent.com/2223172/187005014-f6ec68ee-f195-408e-b58b-c11357deac96.gif)
You won't believe how many times I accidentally placed random tiles due to this.

Pretty sure it can be used by adding a `call_deferred()` somewhere, like always.

### Steps to reproduce

1. Have some TileMap with tiles
2. Select some tiles
3. Copy them
4. Cancel
5. Copy the TileMap
6. Paste the TileMap
7. Just as you pasted, the TileMap is selected and also pastes the tiles you copied before
8. If you don't notice it and click somewhere accidentally, the pattern is "randomly" added to your newly pasted TileMap

### Minimal reproduction project

_No response_

EDIT:
Ok, I know the reason why this happens accidentally so much. Clicking outside editor viewport will still paste the tiles.
![godot_Kd8tqQmJ7i](https://user-images.githubusercontent.com/2223172/187007783-0e768de9-9f0b-45a4-b367-cdea5153bd97.gif)
Repository: godot
Issue: RichTextLabel remove_line() doesn't work properly when using push_* methods without pop()
Labels: bug,topic:gui

### Godot version

3.5.stable, 4.0.alpha14

### System information

Windows 11

### Issue description

### What doesn't work?
In the RichTextLabel node the remove_line() method doesn't work properly when using the push_* methods without terminating the tags.
When using remove_line() without terminating tags, it terminates the tags instead of the line.
I don't know whether it's a intended, a bug or it's just not documented.

### How do you expect it to work instead?
That the line gets removed without terminating the tags

### Preview:
Left: Works, using pop()
Right: Doesn't work, without pop()
![Godot_v3 5-stable_win64_lWNgeCFwvm](https://user-images.githubusercontent.com/5958083/187005583-541433a1-448b-47f2-9a3e-256c5adc96a7.png)


### Steps to reproduce

Use the attached project for 3.5.stable

### Minimal reproduction project

[G3RTL.zip](https://github.com/godotengine/godot/files/9436974/G3RTL.zip)