sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: create-react-app
Issue: Inconsistency between the docs (`running-tests`) and the code.
Labels: needs triage,issue: bug report

In the [testing components section](https://create-react-app.dev/docs/running-tests#testing-components) of the docs, there is an example for a simple smoke test: 
```javascript
it('renders without crashing', () => {
  const div = document.createElement('div');
  ReactDOM.render(<App />, div);
});
```
It also mentions that `this is the test you will find in 'src/App.test.js'.`

While in fact, the test that exists in [`src/App.test.js`](https://github.com/facebook/create-react-app/blob/fddce8a9e21bf68f37054586deb0c8636a45f50b/packages/cra-template/template/src/App.test.js) and in [`src/App.test.tsx`](https://github.com/facebook/create-react-app/blob/fddce8a9e21bf68f37054586deb0c8636a45f50b/packages/cra-template-typescript/template/src/App.test.tsx) is:

```javascript
test('renders learn react link', () => {
  render(<App />);
  const linkElement = screen.getByText(/learn react/i);
  expect(linkElement).toBeInTheDocument();
});
````
Repository: create-react-app
Issue: Inconsistency between the docs (React Testing Library) and the code
Labels: needs triage,issue: bug report

In the [React Testing Library](https://create-react-app.dev/docs/running-tests#testing-components) it is recommended to add both `@testing-library/react` &  `@testing-library/jest-dom` in order to start testing with React Testing Library.

While in fact, `React Testing Library` is shipped out of the box when installing CRA or CRA-TS, as can be seen here: [normal template `package.json`](https://github.com/facebook/create-react-app/blob/fddce8a9e21bf68f37054586deb0c8636a45f50b/packages/cra-template/template.json) and in [typescript template `package.json`](https://github.com/facebook/create-react-app/blob/fddce8a9e21bf68f37054586deb0c8636a45f50b/packages/cra-template-typescript/template.json)
Repository: TypeScript
Issue: this type checking with conditional types
Labels: Suggestion,In Discussion

# Bug Report

<!--
  Please fill in each section completely. Thank you!
-->

### 🕗 Version & Regression Information

ts 4.3.2

### ⏯ Playground Link

1) [reproduce bug](https://www.typescriptlang.org/play?ts=4.3.2#code/C4TwDgpgBACgTge0nYBLCBnAQiAKuCAHlwBooBVAPigF4oBvAKChagG0BpKVAOygGsIIBADMouALoAucZwlQIAD2AQeAEwwUoAfihcZPCADcIcANxQA9JahqEmKDwTAoAdwRx+zVtc7c+gsJikjIcFtZuHvxQIrwQjAC+bIGi4hKMGYwAxgA2AIYYmgCyIADC+YUsTKxQYACuAEY5qFlQGMBwvADm8Egy7Z08XbRQAOSjZt4s9U0tbR3dAIJOwAAWpr1g-QtDI+OTNTPNrTx1ALYNG4hbjueXcCMALJNTUFkIPAN1WcAeUAAUAEoGK8amtUBgAHQiHj-UYDbqbUaAg6sBIZGowgE8PJnCAyTamNCYHD4SCEcEYMgIoaUYHVNGJDK5ArFEAAZTqyHKrIUylUGigJR5lQZ00ax3mgy6nOQm220r2EwxrHenw631+DyBIJqNQwXNMQJeetYlOhsPhOxlhrgSJRr3R6MYOQgLjOIAAank4ATrkT0Ng8ARCMKKlSpd1qHQrdKkS9GEA)

2) [work fine without condition type, disabled type filtration](https://www.typescriptlang.org/play?ts=4.3.2#code/C4TwDgpgBACgTge0nYBLCBnAQiAKuCAHlwBooBVAPigF4oBvAKChagHo2BtAaSlQDsoAawggEAMyi4AugC4pPaVAgAPYBH4ATDBSgB+KL3n8IANwhwA3OzZRNCTFH4JgUAO4I4Q5qx59BImKSMvLc1hzunkJQ4gIQjAC+nIESUtKMGYwAxgA2AIYYOgCyIADC+YUsTKxQYACuAEY5qFlQGMBwAgDm8Ejy7Z38XbRQAOSjlj4s9U0tbR3dAILOwAAWFr1g-QtDI+OTNTPNrfx1ALYNG4hbTueXcCMALJNTUFkI-AN1WcCeUAAUAEoGK8amtUBgAHTifj-UYDbqbUaAg6sBIZGowgH8PJnCDyTYWNCYHD4SCEcEYMgIoaUYHVNGJDK5ArFEAAZTqyHKrOUag02igJR5lQZ00ax3mgy6nOQm220r2EwxrHenw631+DyBIJqNQwXIsQJeetYlOhsPhOxlhrgSJRr3R6MYOQgrjOIAAank4ATrkT0Ng8ARCMKKlSpd1qHQrdKkS9GEA)

``

### 🙁 Actual behavior

Compilation error
Argument of type 'string' is not assignable to parameter of type 'PropertiesByType<this, string>'.(2345)

### 🙂 Expected behavior

Have no errors.
Repository: material-ui
Issue: Tooltip text jumps on scaled screen
Labels: bug 🐛,component: tooltip

<!-- Provide a general summary of the issue in the Title above -->
Issue is reproduced on 80, 90, 110, 120% of scale. When element is hovered and tooltip shows up, the tooltip content text jumps a bit. 

- [x] The issue is present in the latest release.
- [x] I have searched the [issues](https://github.com/mui-org/material-ui/issues) of this repository and believe that this is not a duplicate.

## Current Behavior 😯

This behaviour can be check on material-ui page.

![Peek 2021-06-11 14-18](https://user-images.githubusercontent.com/5927665/121685639-775c4780-cac0-11eb-9539-682835ad1996.gif)


## Expected Behavior 🤔

No jumping, text is displayed with no issues.

## Steps to Reproduce 🕹

Since I found it even on material-ui page I assume codesandbox is not required to verify.

Steps:

1. Scale the page to be either 80%, 90%, 110% or 120%
2. Find element wrapped with Tooltip
3. Hover over this element
Repository: rust
Issue: Confusing error when borrowing members in an automatic dereference
Labels: A-diagnostics,A-borrow-checker,T-compiler,D-confusing,D-newcomer-roadblock,D-terse

<!--
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.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur. 
-->

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=f3f0df13f266b9a222fbeedc4a8f6168

```rust
struct X
{
    pub a: i32,
    pub b: i32,
}


fn main() {
    let y = std::sync::Mutex::new(X{a:1, b: 2});
    
    let g = &mut (y.lock().unwrap());
    
    let a = &mut g.a;
    let b = &mut g.b;

    assert!(*a + *b == 3);
}
```

The current output is:

```
error[E0499]: cannot borrow `*g` as mutable more than once at a time
  --> src/main.rs:14:18
   |
13 |     let a = &mut g.a;
   |                  - first mutable borrow occurs here
14 |     let b = &mut g.b;
   |                  ^ second mutable borrow occurs here
15 | 
16 |     assert!(*a + *b == 3);
   |             -- first borrow later used here

error: aborting due to previous error

For more information about this error, try `rustc --explain E0499`.
error: could not compile `playground`
```

<!-- The following is not always necessary. -->
Ideally the output should tell the user that `g.` is not a simple "member access", which is why they can't borrow multiple members. It could even, in principle, tell them to capture `*g` first, then access it's `a` and `b` members, but I suspect that isn't simple (or even legal) in general.
Repository: electron
Issue: [Feature Request]: Use wayland backend if Xorg is not available
Labels: enhancement :sparkles:,wayland

### Preflight Checklist

- [X] I have read the [Contributing Guidelines](https://github.com/electron/electron/blob/master/CONTRIBUTING.md) for this project.
- [X] I agree to follow the [Code of Conduct](https://github.com/electron/electron/blob/master/CODE_OF_CONDUCT.md) that this project adheres to.
- [X] I have searched the [issue tracker](https://www.github.com/electron/electron/issues) for a feature request that matches the one I want to file, without success.

### Problem Description

When running under Wayland, electron apps use XWayland by default, and native rendering is hidden behind a feature flag.

If XWayland is not running, electron applications simply crash on startup.

### Proposed Solution

If `$DISPLAY` is unset, it doesn't make sense to try and use Xorg/XWayland. Rather than flat out crashing, fall back to using wayland (if `$WAYLAND_DISPLAY` is set).

That is:

```
if DISPLAY is set:
  use Xorg
else if WAYLAND_DISPLAY is set:
  use Wayland
else:
  crash
```

### Alternatives Considered

Enabling native Wayland support by default would likely be best, but I'm sure there's a reason for it to be behind a feature flag. I haven't found any open issue for that though, so it might make sense to have a separate ticket to track enabling wayland out-of-the-box, or discuss what's blocking there.

### Additional Information

n/a
Repository: kubernetes
Issue: Support setting owner references declaratively 
Labels: sig/api-machinery,kind/feature,lifecycle/frozen,triage/accepted

<!-- Feature requests are unlikely to make progress as an issue.

Instead, please suggest enhancements by engaging with SIGs on slack and mailing lists.

A proposal that works through the design along with the implications of the change can be opened as a KEP:
https://git.k8s.io/enhancements/keps#kubernetes-enhancement-proposals-keps
-->

#### What would you like to be added:

It'd be nice to setup owner references declaratively when creating a suite of resources using `kubectl apply -f` 

#### Why is this needed:

Users tend to try to clean up a Knative installation by deleting the 'namespace' in contrast using `kubectl delete -f`. Deleting the namespace leaves a bunch of cluster scoped resources around.

If we could setup owner references properly we could enable this user flow. But we obviously don't know the owner uids and can't do this declaratively at this moment.
Repository: flutter
Issue: Add missing semantics to licenses page
Labels: c: new feature,framework,a: accessibility,c: proposal,P2,team-framework,triaged-framework

## Issue
When using a screen reader, `ListTile`s that navigate to license details are not announced as interactive. It is not intuitive that these elements reveal more information.


## Proposal
Announce these elements as buttons or links using the `Semantics` widget.

https://github.com/flutter/flutter/blob/master/packages/flutter/lib/src/material/about.dart#L665-L728
Repository: PowerToys
Issue: [Color Picker] Triggering with single function keys not possible
Labels: Idea-Enhancement,Help Wanted,Product-Color Picker

I have a keyboard with 24 function keys, it would be very useful to open the color picker with one of those.

When I enter F13 into the keyboard shortcut mask it's being displayed but as soon as I leave it the value resets to the previous one.
![powertoys-f-keys](https://user-images.githubusercontent.com/1711691/121702950-9bc11f80-cad2-11eb-969d-d8945d21616d.jpg)
Repository: TypeScript
Issue: Type narrowing is lost when using logical OR assignment
Labels: Bug

# Bug Report

### 🔎 Search Terms

logical assignment, narrowing

### 🕗 Version & Regression Information

The behaviour is consistent across all versions since the introduction of logical assignment operators in TypeScript 4.0.
Checked range from 4.0.5 to Nightly, no changes in behaviour observed.

### ⏯ Playground Link

[Playground link with relevant code](https://www.typescriptlang.org/play?ts=4.3.2#code/C4TwDgpgBAYlC8UAUBKBA+KA7ArgWwCMIAnAbgFgAoK0SKAJQSgG8qooBtKADwC4oAzsGIBLLAHMoAXX6MAPrCgKcWACYQAZmIiqqAXypUAxgHssQqCIEwVRpgB4AKlAjdgENQOQA6XwENicQF+PywQDik0eExQkHQkPD8QIl4VAGssEwB3LDR+ROToKyhnaKhaCBMNKAKiBHhEACINW2ARM0aKakpTc2AoIwALCCM0piQRWSjMVm72ABsIfuA8MF5GRBEutihF-qMcYmImFbAORoETPCXBsXFGqW3KdhENJEtrW3sYeIOjtDQxCWhywT3Yf2OAHpIQwlFAVOotFgdAAaFzcSBGdy6OblVZMCFKBRIQmIZh6FBgvFgAmHY5yORkvRPZlAA)

### 💻 Code

```ts
type F = () => number;

type R = {
  [ x: string ]: R | F | undefined
}

const isFunc = <T extends (...args: any[]) => any>(maybe:unknown) : maybe is T => typeof maybe === "function";

const check = (i: R) => {

  let tmp:R = i;

  let curr = tmp["something"]; // R | F | undefined, expected

  if( isFunc<F>(curr) ) return;

  curr // R | undefined, expected

  tmp = curr || (curr = {}); //ok, expected

  tmp = curr ||= {}; // Type 'R | F' is not assignable to type 'R'.
};
```

### 🙁 Actual behavior

Error 2322 on the second `tmp` assignment because `R | F` is not narrowed to `R` as with the `curr || (curr = {})`

### 🙂 Expected behavior

No error since both assignments to `tmp` are functionally equivalent 
(I might be missing something obvious about how logical assignment is intended to work from the type system standpoint)
Repository: node
Issue: new vm.Script only evaluates cachedData once
Labels: vm,v8 engine

`new vm.Script()` only evaluates cachedData once when called multiple times with the same js-code. It uses an undocumented, internal cache.

* **16.3.0**:
* **Darwin XXXXXXX 19.6.0 Darwin Kernel Version 19.6.0: Thu May  6 00:48:39 PDT 2021; root:xnu-6153.141.33~1/RELEASE_X86_64 x86_64 i386 MacBookPro15,1 Darwin**:
* **vm**:

### What steps will reproduce the bug?

run the following code in a file or repl:
```javascript
const vm = require('vm');
const b = Buffer.alloc(0);
console.log(new vm.Script("", {cachedData: b});
console.log(new vm.Script("", {cachedData: b});
```

### Reproducible: always

### What is the expected behavior?

Script { cachedDataRejected: true }
Script { cachedDataRejected: true }

### What do you see instead?

Script { cachedDataRejected: true }
Script { cachedDataRejected: false }

### Additional information

Also reproducible in versions as far back as NodeJs 8.16 and on Linux
Repository: terminal
Issue: Sometimes maximized conhost/cmd windows have the bottom line(s) off the bottom of the screen
Labels: Product-Conhost,Help Wanted,Area-Interaction,Issue-Bug,Priority-3

### Windows Terminal version (or Windows build number)

10.0.22117.0

### Other Software

_No response_

### Steps to reproduce

I am TS'ed to my dev machine at work. I maximize a [traditional conhost] cmd window (running razzle, then pwsh+PSReadLine on top of that). I disconnect, then reconnect later, and the cmd window is still maximized as expected. But *sometimes* the active prompt is below the visible portion of the window, usually by several lines--I can't see what I am typing while I type it; but when I hit [enter] and the buffer scrolls up, then I can see what I just typed. If I restore the window then re-maximize it, the problem is gone. The rest of the window UI looks fine (like the scrollbar on the right); the problem is not the outer window becoming the wrong size.

What should I gather to help troubleshoot this? It only happens *sometimes*, and I can't repro on-demand. Is there some low-impact tracing I can leave on, or should I just gather dumps of the associated processes?

### Expected Behavior

I expect that when I reconnect to my TS session, and type into my maximized cmd window, I can see the text I am typing, as I type it.

### Actual Behavior

The text I am typing is happening below the bottom of the cmd window--if I press enter a few times, it gets scrolled up into the part of the buffer I can see.
Repository: excalidraw
Issue: url hash gets replaced with random elements ids
Labels: bug

Every now and then my url gets replaced with what I assume our some of our elements `id` attributes (which the browser must think we're trying to scroll to).

E.g.:

```
https://excalidraw.com/#root
```

or

```
https://excalidraw.com/#canvas
```

(back when we used `id="canvas"`, I suppose).

It didn't use to happen in the past, only in the last month(s).

This is especially annoying when you're in a collab session.
Repository: flutter
Issue: [scheduler] GitHub checks are not being updated correctly
Labels: team-infra,P2,triaged-infra

No pubsub data was sent for 7735 - https://ci.chromium.org/ui/p/flutter/builders/try/Mac%20module_test/7735/overview (see https://github.com/flutter/flutter/pull/84408)

This caused the engine roll to be stuck on a pending build. We should create a cron vacuum that will manually checking pending tests and verify their status with LUCI.
Repository: go
Issue: cmd/go: suggest 'go get' instead of 'go mod tidy' when indirect dependencies are missing
Labels: NeedsFix,modules,BadErrorMessage

(Noticed while testing #45979.)

If a lazy module (#36460) is missing explicit requirements on indirect dependencies, we currently emit the error message:
```
go: updates to go.mod needed; to update it:
	go mod tidy
```

This advice is correct, but it's too big a hammer — we should instead suggest `go get` on the specific packages within the main repo whose transitive dependencies are missing.

CC @jayconrod @matloob
Repository: rust
Issue: The `check_abi` function in typeck is not called for ABIs in trait declarations or type aliases
Labels: T-compiler,C-bug,A-ABI

Consider the following code:

```rs
trait T {
    extern "amdgpu-kernel" fn mu();
}

type TAU = extern "amdgpu-kernel" fn();
```

The `check_abi` function… 

https://github.com/rust-lang/rust/blob/0a8629bff642c3c3b84bb644c0099194f063b627/compiler/rustc_typeck/src/check/check.rs#L37-L59

… is not called for the following two ABI lines, meaning that the checks present therein do not activate, potentially allowing circumvention of the checks this function implements. In particular one thing that is allowed is taking the `TAU` function pointer as an argument and calling it on architectures where this ABI is unsupported.

This becomes especially relevant after #86231 lands.
Repository: go
Issue: cmd/compile: Optimise branches that could be behind other branches, to avoid running those branches when known to be false
Labels: Performance,NeedsInvestigation,compiler/runtime

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version 1.16.3

</pre>

### Does this issue reproduce with the latest release?

Yes

### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jaap/.cache/go-build"
GOENV="/home/jaap/.config/go/env"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/jaap/go/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/jaap/go"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/lib/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.16.5"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/jaap/Projects/posit/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build1569966214=/tmp/go-build -gno-record-gcc-switches"
</pre></details>

### What did you do?
```
type ui uint32
func foo(a,b ui) ui{
  if a == 1<<31 || b.num == 1<<31 {
    return 1 << 31
  }
  
  aneg := a.num&(1<<(32-1)) != 0
  if aneg {
    a.num = ui(-int32(a.num))
  }
  
  xneg := aneg
  bneg := b.num&(1<<(32-1)) != 0
  if bneg {
    xneg = !xneg
    b.num = ui(-int32(b.num))
  }
  ... // lots more code
}
```


### What did you expect to see?

I expected this code to be compiled to something equivalent to
```
func foo(a,b ui) ui{
  aneg := a.num&(1<<(32-1)) != 0
  if aneg {
    if a == 1<<31 {
      return 1 << 31
    }
    a.num = ui(-int32(a.num))
  }
  
  xneg := aneg
  bneg := b.num&(1<<(32-1)) != 0
  if bneg {
    if b.num == 1<<31 {
      return 1 << 31
    }
    xneg = !xneg
    b.num = ui(-int32(b.num))
  }
  ... // lots more code
}
```
to avoid checking for `a == 1<<31 || b.num == 1<<31` when it is known to not be true.

Of course this is only possible when all the operations in between are known to not affect the return, or have any other side-effects.

### What did you see instead?

This optimization is not applied.
Repository: pytorch
Issue: Autograd engine current graph_task should be in the TLSState
Labels: module: autograd,triaged

The current graph task [here](https://github.com/pytorch/pytorch/blob/e41bc31eb2b66b15c586d2c1c26eaba9c35480b0/torch/csrc/autograd/engine.cpp#L88-L92) should actually be in the TLSState to be properly propagated if the backward ops actually do threading.

It would need to be specially handled for the engine threads like grad_mode to ensure they don't conflict.



cc @ezyang @albanD @zou3519 @gqchen @pearu @nikitaved @soulitzer @Lezcano
Repository: rust
Issue: ptr-meta: DynMetadata and Pointee::Metadata are not UnwindSafe
Labels: C-enhancement,A-DSTs,T-libs-api,A-lang-item,requires-nightly,A-raw-pointers

[`DynMetadata`](https://doc.rust-lang.org/nightly/std/ptr/struct.DynMetadata.html) is only [`UnwindSafe`](https://doc.rust-lang.org/std/panic/trait.UnwindSafe.html) if its `Dyn` type argument is as well. This is a bit strange as `DynMetadata` is, data-wise, just a `&'static` to an immutable virtual table. There's not a way to observe broken invariant involving such a reference unless somehow the shared library containing the vtable is unloaded -- which violates `'static`, would be super-mega-bad, and probably shouldn't be happening during unwind.

https://rust-lang.github.io/rfcs/2580-ptr-meta.html (#81513) states that `Pointee::Metadata` is `Copy + Send + Sync + Ord + Hash + Unpin`. Given these constraints, as well as the current types being `()`, `usize`, and `DynMetadata`, it seems reasonable to me that `Pointee::Metadata` also therefore be `UnwindSafe`.

I understand that `UnwindSafe` is currently in `std`, but with #84662 it will move into `libcore`. Provided that we indeed want it as a bound of `Pointee::Metadata`, we should definitely land this before exposing the ability for users to create custom metadata types.

Changing the bounds on `Pointee::Metadata` is explicitly mentioned as a concern in [these meeting minutes](https://github.com/rust-lang/lang-team/blob/master/design-meeting-minutes/2020-11-04-RFC-2580-and-custom-dst.md#assumptions).

(Also, the shared library unloading thing may indicate that we may want to drop the `&'static` in favor of `*const`.)
Repository: transformers
Issue: [Performance] Tracking open Issues and PRs (pytorch transformers)
Labels: Good First Issue,Performance,Good Difficult Issue

Let's use this Issue to track performance issues and enhancement requests, so it's easier to prioritize the work.

**This is for pytorch `transformers`**

Also I will label it as a `Good Difficult Issue` in case someone is ready for a challenging but rewarding experience of figuring things out. If you do want to take the challenge comment in the corresponding Issue/PR that resonates with you so others would know you're working on it.

If I missed any other relevant open performance-related Issues/PRs that need attention please comment below.

## Regression:
- [ ] https://github.com/huggingface/transformers/pull/11218 Regression after Bart-like refactoring - need to compare the original Bart refactoring PR since most likely the regression happened there.
- [ ]

## Odd slowness:
- [ ] https://github.com/huggingface/transformers/issues/10816 figuring out why eval with --fp16_full_eval is 25% slower
- [ ]

## Fused kernels possibilities:
- [ ] https://github.com/huggingface/transformers/issues/11368 Megatron fused CUDA kernels to improve Hugging Face model classes' scalability 
- [ ] research pytorch kernels?
- [ ] I know Deepspeed has various kernels that we might be able to use

## Faster / leaner startup / module loading
- [ ] https://github.com/huggingface/transformers/issues/12274 - skip storage allocation which gets dropped for pretrained weights

## Faster optimizers
- [ ] https://github.com/huggingface/transformers/issues/12084 - a proposal to port `MemoryEfficientFP16Optimizer` from fairseq
- [ ] https://github.com/huggingface/transformers/issues/9965 - `torch.optim._multi_tensor` faster optimizers - having some bottleneck in the test script - need to profile

## Scalability
- [ ] https://github.com/huggingface/transformers/issues/10321 Tensor Parallelism

## Deepspeed-specific features
- [ ] https://github.com/huggingface/transformers/issues/9606 a list of features that can be integrated
- [ ] https://github.com/huggingface/transformers/issues/12273 - make `from_pretrained` loading faster

## Tests
- [ ] No issue yet, but we really need to add performance regression tests