sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Tracking Issue for `feature(packed_bundled_libs)`
Labels: A-linkage,T-compiler,C-tracking-issue

This is a tracking issue for the fix for issue "Linking modifier `whole-archive` and link time `cfg` are not supported on bundled static libraries" (https://github.com/rust-lang/rust/issues/99429).
The feature gate for the issue is `#![feature(packed_bundled_libs)]`.

Currently to combine `+bundle` native libraries with `+whole-archive` or `cfg` a new representation of bundled native libraries in a rlib used, in which the library is packed into the archive as a whole (and wrapped into an object file for technical reasons), and then unpacked when you need to link to it.

Other representations are also possible, e.g. keeping the bundled lib in the old "unpacked" format as a set of object files, and adding some description file telling which object files belong to which library, it would be more complex though.

It may be quite reasonable to support both packed and unpacked representations, both have their uses
- the packed representation minimizes differences with classic non-bundled (`-bundle`) static libraries
- the unpacked representation is needed when the rlib actually *provides* missing symbols to the native static lib, not just depends on it, as can be seen from the breakage report in https://github.com/rust-lang/rust/pull/102832

Stabilizing the `+bundle,+whole-archive` combination doesn't need specifying any of these details, we just need to promise that it somehow works.

### About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however *not* meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

### Steps

- [x] Implement the RFC (cc @rust-lang/XXX -- can anyone write up mentoring
      instructions?)
- [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide])
- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide])

[stabilization-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#stabilization-pr
[doc-guide]: https://rustc-dev-guide.rust-lang.org/stabilization_guide.html#documentation-prs

### Unresolved Questions

None yet.

### Implementation history

- Implemented in https://github.com/rust-lang/rust/pull/105601.
Repository: TypeScript
Issue: TypeScript generated invalid types if `esModuleInterop` is enabled
Labels: Needs Investigation

# Bug Report

When a package is typed using `module.exports =`, the correct way to type it is `export =`. The correct way to import this, in either `.ts` or `.d.ts` files, is `import identifier = require('module')`. For example `import React = require('react')`.

If a user enables `esModuleInterop`, they are allowed to use `import React from 'react'`. When compiling to CJS, this will output JavaScript that used either `module.exports.default` or `module.exports`.

```js
"use strict";
var __importDefault = (this && this.__importDefault) || function (mod) {
    return (mod && mod.__esModule) ? mod : { "default": mod };
};
Object.defineProperty(exports, "__esModule", { value: true });
const react_1 = __importDefault(require("react"));
```

IMO This isn’t great, but it works.

What is bad, is that it generates a default import in the type definitions.

```ts
import React from 'react';
```

Whereas it should be typed as this:

```ts
import React = require('react');
```

If this is library code, that means the user of the library now is also enforced to use `esModuleInterop`, whether they like it or not.

### 🔎 Search Terms

`esModuleInterop`

### 🕗 Version & Regression Information

This is the behavior in every version I tried, and I reviewed the FAQ for entries about [_Common "Bugs" That Aren't Bugs_](https://github.com/Microsoft/TypeScript/wiki/FAQ#common-bugs-that-arent-bugs)

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?#code/JYWwDg9gTgLgBAJQKYEMDG8BmUIjgcilQ3wChSkAPSWONCAOwGd4kAbJEJB+AXkWIwAdGiIoYSAKIcuPABT4AJsABu+AJSkgA) (Look at the `.d.ts` output)

### 💻 Code

The following code requires `esModuleInterop` to be enabled.

```ts
import React from 'react'

export const element = React.createElement('div')
```

### 🙁 Actual behavior

This is the generated type definition:

```ts
import React from 'react';
export declare const element: React.DetailedReactHTMLElement<React.HTMLAttributes<HTMLElement>, HTMLElement>;
```

### 🙂 Expected behavior

This is the correct type definition:

```ts
import React = require('react');
export declare const element: React.DetailedReactHTMLElement<React.HTMLAttributes<HTMLElement>, HTMLElement>;
```
Repository: rust
Issue: Tracking Issue for const `RangeBounds` and const `RangeX::contains`
Labels: T-libs-api,C-tracking-issue,F-const_trait_impl,S-tracking-blocked

<!--
Thank you for creating a tracking issue!

Tracking issues are for tracking a feature from implementation to stabilization.

Make sure to include the relevant RFC for the feature if it has one.

If the new feature is small, it may be fine to skip the RFC process. In that
case, you can use use `issue = "none"` in your initial implementation PR. The
reviewer will ask you to open a tracking issue if they agree your feature can be
added without an RFC.
-->

Feature gate: `#![feature(const_range_bounds)]`

This is a tracking issue for making `RangeBounds` `#[const_trait]`, implementing it for all Range types and allowing range.contains() and associated functions to be called form a const context.

<!--
Include a short description of the feature.
-->

### Public API

<!--
For most library features, it'd be useful to include a summarized version of the public API.
(E.g. just the public function signatures without their doc comments or implementation.)
-->

```rust
// core::ops::RangeInclusive
impl<Idx> RangeInclusive<Idx> {
   pub const fn into_inner(self) -> (Idx, Idx)
}
```

### Steps / History

<!--
For larger features, more steps might be involved.
If the feature is changed later, please add those PRs here as well.
-->

- [ ] Implementation: #...
- [ ] Wait for `#![feature(const_trait_impl)]` to become stable #67792
- [ ] Final comment period (FCP)[^1]
- [ ] Stabilization PR

<!--
Once the feature has gone through a few release cycles and there are no
unresolved questions left, the feature might be ready for stabilization.

If this feature didn't go through the RFC process, a final comment period
(FCP) is always needed before stabilization. This works as follows:

A library API team member can kick off the stabilization process, at which point
the rfcbot will ask all the team members to verify they agree with
stabilization. Once enough members agree and there are no concerns, the final
comment period begins: this issue will be marked as such and will be listed
in the next This Week in Rust newsletter. If no blocking concerns are raised in
that period of 10 days, a stabilzation PR can be opened by anyone.
-->

### Unresolved Questions

<!--
Include any open questions that need to be answered before the feature can be
stabilised. If multiple (unrelated) big questions come up, it can be a good idea
to open a separate issue for each, to make it easier to keep track of the
discussions.

It's useful to link any relevant discussions and conclusions (whether on GitHub,
Zulip, or the internals forum) here.
-->

- None yet.

[^1]: https://std-dev-guide.rust-lang.org/feature-lifecycle/stabilization.html
Repository: next.js
Issue: ISR not refreshing cache when updating in dynamic pages
Labels: bug

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

    Operating System:
      Platform: linux
      Arch: x64
      Version: #64~20.04.1-Ubuntu SMP Fri Jan 6 16:42:31 UTC 2023
    Binaries:
      Node: 16.10.0
      npm: 7.24.0
      Yarn: N/A
      pnpm: 7.0.1
    Relevant packages:
      next: 13.1.6
      eslint-config-next: 13.1.6
      react: 18.2.0
      react-dom: 18.2.0



### Which area(s) of Next.js are affected? (leave empty if unsure)

Data fetching (gS(S)P, getInitialProps)

### Link to the code that reproduces this issue

https://github.com/pkawula/next-isr-bug

### To Reproduce

Clone the linked repo, install dependencies, then run build and start a production build.

### Describe the Bug

I've created a dynamic page `[id].tsx` under the `pages` folder.
I run in there `getStaticPaths` with empty array to not fetch and generate any pages in build time.
Also you can find there `getStaticProps` which is responsible for fetching "data" for current page.

If your read the code you can easily see that we're making a request to the api route which is inside `pages/api`.
The generated page is cached by default for 20 seconds, and the first time you go into http://localhost:3000/1 you'll get a correct response. Then after the 20s API will return a response with 302 status with a Location header to redirect to different route. You can see in your server console that the `catch` function propery read the response, but Next doesn't redirected to given location.
If you will refresh the page further you can see that the old cached version is served until you manually remove cached values (json and html files) from `.next` folder.
However, next will succesfully replace the cache if you serve a redirect on first api call but only this way. Also if you'll make same use case on no dynamic route, the cache will be updated successfully too.

The issue here is only when my `next.config.js` includes:
```
const nextConfig = {
  reactStrictMode: true,
  swcMinify: true,
  experimental: {
    isrMemoryCacheSize: 0
  },
  i18n: {
    defaultLocale: "en",
    locales: ["en", "pl"],
    localeDetection: false
  }
}
```
But it still exists if you remove the experimental flag for ISR.
    

### Expected Behavior

The ISR should always update the cache, even if dynamic routes returns redirect after refreshing.

### Which browser are you using? (if relevant)

Chrome 109

### How are you deploying your application? (if relevant)

Amazon AWS
Repository: angular
Issue: Registering testabilities of micro frontend
Labels: area: testing,area: elements,needs: clarification

### Which @angular/* package(s) are relevant/related to the feature request?

elements

### Description

Hello,
We are implementing a micro frontend application using @angular/elements. The method for waiting for Angular testabilities to be stable that we use in our test solution, does not catch instabilities in the testabilities of the micro app that is called from the main application.
We tried emitting tetabilities from micro app and registered them in the main app, but it didn't work.
Please let us know if there is a way already, or accept that as a feature request.

### Proposed solution

Testabilities of the micro application to be registered automatically.

### Alternatives considered

Here is how we tried registering testabilities:
micro app:
```
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent implements OnInit {
  @Output() testability: EventEmitter<any> = new EventEmitter<any>(); 

  ngOnInit() {
    this.router.initialNavigation();
    this.testability.emit(window.getAllAngularTestabilities()[0]);
  }
}
```

main app html:
```
<micro-app (testability)="onTestability($event)"</micro-app>
```
main app ts:
```
@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
  styleUrls: ['./app.component.scss']
})
export class AppComponent {
  constructor( private testRegistry: TestabilityRegistry) {  }

  onTestability(event: any): void {
    let microApp= document.getElementsByTagName('micro-app');
    this.testRegistry.registerApplication(microApp, event?.detail);
  }
}
Repository: angular
Issue: Mixing FormControl and FormArray in FormGroup throws `control.setValidators is not a function`
Labels: area: forms,P4

### Which @angular/* package(s) are the source of the bug?

forms

### Is this a regression?

Yes

### Description

When creating FormGroups dynamically and adding the to a FormGroup which has `FormControl` in it, the error is thrown.

### Please provide a link to a minimal reproduction of the bug

https://stackblitz.com/edit/angular-ujiq1x

### Please provide the exception or error you saw

```true
Please see this - [https://stackoverflow.com/q/75461339/2896495](https://stackoverflow.com/q/75461339/2896495)
```


### Please provide the environment you discovered this bug in (run `ng version`)

```true
Angular CLI: 15.1.5
Node: 18.13.0
Package Manager: npm 9.4.2
OS: win32 x64

Angular: 15.1.4
... animations, cdk, common, compiler, compiler-cli, core, forms
... localize, material, platform-browser
... platform-browser-dynamic, router
```


### Anything else?

_No response_
Repository: pytorch
Issue: Optimizer "Lion" in  Symbolic Discovery of Optimization Algorithms
Labels: module: optimizer,triaged,needs research

### 🚀 The feature, motivation and pitch

A new optimizer "Lion" was proposed in Symbolic Discovery of Optimization Algorithms
https://arxiv.org/pdf/2302.06675.pdf

It is simple, memory efficient and have a faster runtime.
I think it can be a great addition to the Pytorch optimizer algorithms' collection as 
it directly compares to AdamW which is already available. 

the optimizer is a single file
https://github.com/google/automl/blob/master/lion/lion_pytorch.py

Pseudo Code:
$$
\begin{algorithm}
    \caption{\name{} Lion}
    \begin{algorithmic}
    \State \textbf{given} $\beta_1$, $\beta_2$, $\lambda$, $\eta$, $f$
    \State \textbf{initialize} $\theta_0$, $m_0\leftarrow 0$
    \While{$\theta_t$ not converged}
        \State $g_t \leftarrow \nabla_\theta f(\theta_{t-1})$
        \State \textbf{update model parameters}
        \State $c_t \leftarrow \beta_1 m_{t-1} + (1-\beta_1)g_t$
        \State $\theta_t \leftarrow \theta_{t-1} - \eta_t(\text{sign}(c_t) + \lambda\theta_{t-1})$
        \State \textbf{update EMA of $g_t$}
        \State $m_t \leftarrow \beta_2 m_{t-1} + (1 - \beta_2)g_t$
    \EndWhile
    \State \textbf{return} $\theta_t$
    \end{algorithmic}
    \label{alg:ours}
\end{algorithm}
$$

### Alternatives

_No response_

### Additional context

_No response_

cc @vincentqb @jbschlosser @albanD @janeyx99
Repository: material-ui
Issue: [material-ui] Styles does not apply in same order
Labels: support: question,component: text field,package: material-ui

### Duplicates

- [X] I have searched the existing issues

### Latest version

- [X] I have tested the latest version

### Steps to reproduce 🕹

Link to live example: https://codesandbox.io/s/nifty-night-37fimk?file=/src/App.tsx

Steps:

1. Customize e.g. TextField background (filled variant) by adding `& .MuiFilledInput-root { background: "white" }`
2. Check how it render and how hover/focus behave (hover and focus from Mui override our custom background white) (Screen 1)
3. Now add original Mui TextField before the customized one and refresh page. Now check how the hover/active behave (hover and focus from Mui now DOES NOT override our custom background white - our custom style has higher priority than before) (Screen 2)

Screen 1:
<img width="814" alt="image" src="https://user-images.githubusercontent.com/13498526/219073404-647d67d0-60d5-4e22-b614-4f24cb0f172a.png">

Screen 2:
<img width="961" alt="image" src="https://user-images.githubusercontent.com/13498526/219073687-f757a015-3791-43fb-97c8-3c61116ef27e.png">



### Current behavior 😯

Custom styled element does not always looks the same.

### Expected behavior 🤔

Custom styled element should always looks the same.

### Context 🔦

Want to the same styles always behave in the same way. Want styled element to be deterministic - the same style do the same thing every time.

### Your environment 🌎

<details>
  <summary><code>npx @mui/envinfo</code></summary>

```
  Don't forget to mention which browser you used.
  Output from `npx @mui/envinfo` goes here.
  
  Browser: Chrome 109
  
  "dependencies": {
    "@emotion/react": "11.10.5",
    "@emotion/styled": "11.10.5",
    "@mui/material": "5.11.8",
    "react": "18.0.0",
    "react-dom": "18.0.0",
    "react-scripts": "4.0.3"
  },
```
</details>
Repository: TypeScript
Issue: Extend "no comparison with NaN" check to cover "Number.NaN" 
Labels: Suggestion,Awaiting More Feedback

# Suggestion

## 🔍 Search Terms

x === Number.NaN
disallow comparing with Number.NaN

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [?] This wouldn't be a breaking change in existing TypeScript/JavaScript code - _**this would break code containing the error**_
* ✅  This wouldn't change the runtime behavior of existing JavaScript code
* ✅ This could be implemented without emitting different JS based on the types of the expressions
* ✅ This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* ✅  This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

Extend check added for https://github.com/microsoft/TypeScript/issues/49962 to include `Number.NaN` in addition to global `NaN`.

## 📃 Motivating Example

```typescript
function useVersionNumber(value: string) {
    let versionNumber = Number(value);
    if (versionNumber === Number.NaN) {
        return;
    }
    console.log(versionNumber + 1);
}
```
## 💻 Use Cases

Catching a developer error (incorrect NaN handling).
Repository: rust
Issue: Accessing field .offset inside test crashes test harness if incorrect
Labels: S-waiting-on-author,A-libtest,C-bug,S-needs-repro

While writing this bug report I realised a bug in my code that I never wrote to the file.
After I fixed that the tests summaries start to show up, but the details (stdout per failed test) are still missing.

Am I not allowed to call a symbol offset?

* [CI Job](https://git.coredump.ch/dns2utf8/encrypted_filesystem_storage/-/jobs/994)
* [Corresponding commit](https://git.coredump.ch/dns2utf8/encrypted_filesystem_storage/-/commit/e43af43401fa3f11f3812f82ed71e68f5ed79956)
* [Full file at that commit](https://git.coredump.ch/dns2utf8/encrypted_filesystem_storage/-/blob/e43af43401fa3f11f3812f82ed71e68f5ed79956/aead_vfs/src/secure_file.rs#L125)
<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.
-->

I tried this code:

```rust
pub struct ActiveFile {
    /// Clonable needed for metadata
    pub(crate) id: FileTag,
    /// The actual data buffer
    data: Vec<u8>,
    /// seekable
    offset: usize,
    /// Locked file
    real_file: File,
}

impl Drop for ActiveFile { ... }
impl Write for ActiveFile { ... }

#[cfg(test)]
mod tests {
    use super::*;
    use ring::aead::{BoundKey, UnboundKey};
    use std::path::PathBuf;
    
    #[test]
    fn simple_write() {
        let mut key = test_key();
        let mut a = ActiveFile::open_rwlocked(&path("simple_write.bin"), FileTag(1), &mut key)
            .expect("unable to open test file");

        a.write(b"abc").unwrap();
        println!("a.data: {:?}", a.data);
        assert_eq!(3, a.data.len());
    }
```

I expected to see this happen: *explanation*

Instead, this happened: 
The code compiles starts running and crashes without printing the test cases (passed or failed).
The only way to get them to work is by removing `assert_eq!(3, a.offset);` from the test

```bash
(signal: 6, SIGABRT: process abort signal)
```

### Meta
<!--
If you're using the stable version of the compiler, you should also check if the
bug also exists in the beta or nightly versions.
-->

`rustc --version --verbose`, tried it with nightly too -> same result:
```
rustc 1.67.1 (d5a82bbd2 2023-02-07)
binary: rustc
commit-hash: d5a82bbd26e1ad8b7401f6a718a9c57c96905483
commit-date: 2023-02-07
host: x86_64-unknown-linux-gnu
release: 1.67.1
LLVM version: 15.0.6
```


There is no backtrace, just the short message

```
running 1 test
thread panicked while panicking. aborting.
error: test failed, to rerun pass `-p aead_vfs --lib`

Caused by:
  process didn't exit successfully: `$HOME/rust/encrypted_filesystem_storage/target/debug/deps/aead_vfs-dbf5b5fd9b41c8b0 secure_file` (signal: 6, SIGABRT: process abort signal)
```
Repository: go
Issue: x/build: add linux-arm to the trybot set
Labels: Builders,NeedsInvestigation,arch-arm

The linux-arm-aws trybots were removed in [go.dev/cl/468535](https://go.dev/cl/468535) because they were not completing within the time allocated to trybot runs #54679. Trybots for Linux ARM coverage should be added when they become available.

@golang/release
Repository: pytorch
Issue: [numpy] mean & nanmean should support int dtypes
Labels: triaged,module: numpy,module: reductions

### 🚀 The feature, motivation and pitch

#### NumPy
```python
>>> import numpy as np
>>> k = np.array([1, 2, 3], dtype=np.int32)
>>> np.mean(k)
2.0
>>> np.nanmean(k)
2.0
```
#### PyTorch
```python
>>> import torch
>>> k = torch.tensor([1, 2, 3], dtype=torch.int32)
>>> torch.mean(k)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: mean(): could not infer output dtype. Input dtype must be either a floating point or complex dtype. Got: Int
>>> torch.nanmean(k)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
RuntimeError: nanmean(): expected input to have floating point dtype but got Int
```
As discussed here: https://github.com/pytorch/pytorch/pull/93199#issuecomment-1431169963

### Alternatives

_No response_

### Additional context

_No response_

cc @mruberry @rgommers
Repository: godot
Issue: GPUParticles3D parameter local_coords not working with doubles builds of the engine
Labels: bug,topic:rendering,confirmed,topic:3d,topic:particles

### Godot version

4.0.dev (double precision) ( f2aae8fa5c2e9d9323832fb43c8446c2e518d698 [f2aae8f])

### System information

Win10, RTX3060, Vulkan

### Issue description

If i set local_coords to false, particles still moves with the GPUParticles3D node, but don't rotate. When local_coords  is true, particles moves(with a node) and rotates(around himselves, what is wrong compared to RC2) .

### Steps to reproduce

Create scene. Add GPUParticles3D node, set local_coords to fale, create particle material with shader code and move node.
```
shader_type particles;
uniform float rows = 10.;
uniform float spacing = 2.;
void start() {
	vec3 pos = vec3(0.0, 0.0, 0.0);
	pos.z = float(INDEX);
	pos.x = mod(pos.z, rows);
	pos.z = (pos.z - pos.x) / rows;
	TRANSFORM[3][0] = pos.x*spacing;
	TRANSFORM[3][1] = 0.;
	TRANSFORM[3][2] = pos.z*spacing;
}

void process() {
}
```


### Minimal reproduction project

N/A
[TestParticles.zip](https://github.com/godotengine/godot/files/10746165/TestParticles.zip)