sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: angular
Issue: Injection Context for `loadChildren` and `loadComponent` functions
Labels: feature,effort1: hours,area: router,router: lazy loading,feature: under consideration

### Which @angular/* package(s) are relevant/related to the feature request?

router

### Description

### What I have
- host application
- micro front-end applications that are loaded using `loadChildren` and `loadConponent`
- localization using `@angular/localize`

### Problem
Need to load micro-frontend module or component with host application locale.

The `LOCALE_ID` token is used to determine the current locale. The first thing that comes to mind is to use the `inject` function to get the token value from the injector.

```ts
{
  path: '...',
  loadChildren: () => loadRemoteModule(`module-${inject(LOCALE_ID)}`, 'Module')
}
```

But in the `loadChildren` and `loadComponent` functions, using the inject function causes an error. 

```
NG0203: `inject()` must be called from an injection context, such as a constructor, a factory function, a field initializer, or a function used with `runInInjectionContext`.
```


### Proposed solution

I propose to create an injection context for `loadChildren` and `loadComponent` functions when calling them

### Alternatives considered

I am setting the locale to the window object as a fast solution.

```ts
{
      provide: APP_INITIALIZER,
      multi: true,
      useFactory: () => {
        const locale = inject(LOCALE_ID);
        const windowRef = inject(WINDOW);

        windowRef.__LOCALE_ID__ = AvailableLocales.includes(
          locale as AvailableLocale
        )
          ? locale
          : AvailableLocale.EN;
        return () => undefined;
      },
    }
```

And then load micro-frontend:

```ts
{
  path: '...',
  loadChildren: () => loadRemoteModule(
    `module_${window.__LOCALE_ID__}`,
    moduleName
  )
}
```

But for SSR, I will have to get another solution.
Repository: pytorch
Issue: Enhanced Available Backend Discovery and Selection in PyTorch 2
Labels: triaged,enhancement,module: python frontend

### 🚀 The feature, motivation and pitch

New utility functions are proposed to make backend selection more intuitive and efficient in PyTorch 2:

Avoid this type of constructs:
DEVICE = torch.device("cuda" if torch.cuda.is_available() else "cpu")
DEVICE = torch.device("cuda" if torch.cuda.is_available() else ("mps" if torch.has_mps else "cpu"))

By introducing for example:
torch.backends.get_available() -> List[str]: Returns a sorted list of available backends based on a set of predefined compatibility and performance metrics.

torch.backends.select_optimal() -> str: Automatically selects the most compatible and efficient backend for the current system configuration. (The first one from the sorted get_available() list.)


The feature aims to categorize and sort available computational backends, such as CUDA, MPS, and CPU, based on their computational power or other suitable criteria.

### Alternatives

_No response_

### Additional context

_No response_

cc @albanD
Repository: go
Issue: x/website/tour: use system setting prefers-color-scheme
Labels: NeedsInvestigation,website

Since [509116](https://go.dev/cl/509116), the Tour has a dark mode, which is awesome.

However, it shows up in light mode by default, even if my OS/browser settings say I prefer dark.

The rest of the website has had the same problem at first, and it has been fixed. The user may click a top-right icon to toggle the light/dark theme, and this explicitl user choice is persisted. However, the default theme (without any user action) should acknowledge the system-wide preference.

![image](https://github.com/golang/go/assets/13508141/7db0f4b6-ed33-4e07-a719-c4bb42321b2d)
Repository: storybook
Issue: Release tooling: Race condition on prereleases
Labels: bug

When you do a prerelease, if somebody merges to `next` before the release has completed, the action will create a new prerelease for the previous prerelease version. Then, the next time the release preparation script is triggered, it will create a new prerelease for the proper version.

Either the release preparation script should wait for the release to complete before running, OR the release script should lock the `next` branch when it starts and unlock it when it finishes.
Repository: go
Issue: x/vuln/cmd/govulncheck: add quiet output or a cli flag
Labels: NeedsDecision,vulncheck or vulndb

### What version of Go are you using (`go version`)?
```
$ go version
go version go1.20.7 freebsd/amd64
```
### Does this issue reproduce at the latest version of golang.org/x/vuln?
Yes (`govulncheck@v1.0.1` as of this time).

### What did you do?
```
$ govulncheck ./..
Scanning your code and 175 packages across 11 dependent modules for known vulnerabilities...

No vulnerabilities found.

Share feedback at https://go.dev/s/govulncheck-feedback.
```
### What did you expect to see?
No output upon "success", like the other go commands.

### Proposal
I would like to have silent output by default (kind of like the other go commands) or at least a CLI flag to silence this verbose "success" message.
Repository: vscode
Issue: Unlucky Diff - Semantic Diffing?
Labels: feature-request,diff-editor

Maybe we can use the outline model to improve diffing here.
The dynamic programming diffing algo for lines could prefer aligning lines that have the same parent symbols.

[Monaco Editor Repro](https://microsoft.github.io/monaco-editor/playground.html?source=v0.42.0-dev-20230828#XQAAAAKqDQAAAAAAAABBqQkHQ5NjdMeMm-jY7SIQ9S7DNlzs5W-mwj0fe1ZCDRFc9ws9XQE0SJE1jc2VKxhaLFIw9vEWdz-byd325pLQLUmB0X6j-R7bMgYvalhHXmMiZh8xVVN1Yktj-AroE-VyAJgWtxQcrH7MmxugHvUEO4vHZcm7f3Odsel8PQaXKv8W8YZZuqw18N8EZ8xk61IzwcCr1C4eeFcxfE9L7JmY0rxRrLYaZoozMvgard1hTC1I_dEHTiFCNj8KXtJMVyTRXI3sFw5MmG6yJBU1NYFwYwALk5RCVmfGwBFkOGf5IXCuh95z9OiPaB5GkgIybYKuJemsUWb0oFP5ZjAjHQ2sJlTCCVKGiUlC1ZbiKbvaRU36ec7NddocuPF5saKhULC681zagaoYvW9Og1JKXR-uxgkulIL7tkwOHUQlOdfCgEVXcoc548aVEDvL8fKQXDmb3d2msC4gXirBM0QcpnISNB72pxXtCzbeoFd_n-DTFrwaeKshRdelp09Ytdsd9nHEk91Ku8x8RkbMI0eXZRGJ1EGIotzHghzke8ph0g8acxutzUCPjEra6tt777ULr7s_QZ3xGBueaAg04VoEf38vsmQiQim7d-xKmQ7brfzubPy0btlx7GgqDnwSPTNZ6viydG9zO5Loc6iuPqu62R1ZWhgvDlDEoVLfVCeWZ0flttd4tA_pJhHBfaJO096ofqJJI5SxfEsoO4tH9f7uNgAAFbnJEDY-TV6RAgl63-JDFdbWwT6p3AAySKx2LgLIJrqUT8GGEmtVsaJdjMFfI04BfzhriMLNbpdJImq_5YsReqddl8uydnmLS3Iu3AEKCDZWsTfcyTBs0bze0xQISuhBBaJPHBDizJFCPtzHr2H1sxE3ZUcFp0-eMjPGqPRtbwhbVTCjxgzRPkHh9oS7pjb-kBswx2L-33BWl4vtlV6LQn3THD8zLVvALHI44v8zE31CTDCqUEtApi3Kn8gTLtvqdbcuLafkjmSPi7_sVMrBJjmLdwBRGPgmm-DEh1TQGb4jTo-NJoR87AB7n7dNqy2bpaC6hGnTjawQLHjK2KpByp0szt0sR4SPSNdEvsf1yaMYh9vUt1_66P1ngzDDP1TI8EbeshnCQ2hAYr52pTnG5QOAvpHSwTwR8lSCAwtuc0nLXkwN1TdJadet6ehzxxrbPhJ6Hdp3QClxqFtrzeK-3nQ5B7fP62R3YnHCfrSSc1okn6u5pYRUu8G4gYuJFYmoQNibS5P7N1iA13GA-s6rOIO2fWxNgzF2yxoELI1ePbszyl0bOgHasxC6539nVs9o8rQzXTwqSNZaBXD-Rg_phOCnbtGvrzSlGiW9PhqNjT9v5aXiLFjvbg1GSUL_C3viK9H6y1yB9KediU6drxFMrwLrl6KU2fOpNhFIuPjaM99IAjvJVkONi1ej9Ew0vN9p_s7d4zP3_6_dm8wPVDWC3dLFrpoDFkkcgKv6hFxkpDkwqL-c5PztMMyT_37KagA)

![chrome_Wmqgvd0Px4](https://github.com/microsoft/vscode/assets/2931520/d8b6b0b8-34cf-4068-9fd8-bee08d91aeab)
Repository: next.js
Issue: sitemap.ts not working with custom pageExtensions
Labels: bug,Metadata,linear: next

### Verify canary release

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

### Provide environment information

```bash
Operating System:
      Platform: linux
      Arch: x64
      Version: #1 SMP PREEMPT_DYNAMIC Sun Aug  6 20:05:33 UTC 2023
    Binaries:
      Node: 16.17.0
      npm: 8.15.0
      Yarn: 1.22.19
      pnpm: 7.1.0
    Relevant Packages:
      next: 13.4.19
      eslint-config-next: N/A
      react: 18.2.0
      react-dom: 18.2.0
      typescript: 5.2.2
    Next.js Config:
      output: N/A
```


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

App Router

### Link to the code that reproduces this issue or a replay of the bug

https://codesandbox.io/p/sandbox/nervous-gould-p2j5xj

### To Reproduce

Start app in dev mode
`yarn dev`

Go to path `/sitemap.xml`

will return 404 not found

if you rename the `sitemap.ts` to `sitemap.next.ts` (according to pageExtensions) it will fail as it does not know how to parse it

![image](https://github.com/vercel/next.js/assets/2400723/033aa610-5b7f-4abf-af96-94bbe02ff9cf)


### Describe the Bug

When starting the app, and `pageExtensions` are set in `next.config`, the `sitemap.ts` is not working unless you add its extension.

So, in next.config.js

```
  pageExtensions: ['next.tsx', 'next.ts', 'next.jsx', 'next.js', 'ts'],
```
and `sitemap.ts`
will work

```
  pageExtensions: ['next.tsx', 'next.ts', 'next.jsx', 'next.js'],
```
and `sitemap.ts`
will fail

```
  pageExtensions: ['next.tsx', 'next.ts', 'next.jsx', 'next.js'],
```
and `sitemap.next.ts`
will fail

I guess that as `sitemap` file is a file threated by next framework, it could be handled the same way as layout, page... etc

Maybe this is not a bug, it is a feature request. Apologize in that case and please move the issue to its respective category.

### Expected Behavior

When you have `pageExtensions` enabled, those rules should apply to `sitemap` as well as other nextJS reserved files

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

_No response_

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

_No response_

<sub>[NEXT-1634](https://linear.app/vercel/issue/NEXT-1634/sitemapts-not-working-with-custom-pageextensions)</sub>
Repository: PowerToys
Issue: Add Ability To Customize How The Mouse Highlighter Looks
Labels: Idea-Enhancement,Needs-Triage,Product-Mouse Utilities

### Description of the new feature / enhancement

You would be able to make more customizations to the mouse highlighter perhaps make it like a circle around the mouse for example, kind of like the screenshot below : 

![image](https://github.com/microsoft/PowerToys/assets/109022579/7d21c117-bd5b-4f67-bc84-c80bb0d25722)

### Scenario when this would be used?

Potentially used when screen recording tutorials on a computer and for other mouse highlighter uses.

### Supporting information

_No response_
Repository: material-ui
Issue: Analysis: 33% of dependency updates in this repository can be merged.
Labels: dependencies

Hey there :wave:<br><br>Our bot, Adaptly, found that 4 out of 12 currently open dependency update PRs can be merged.<br>That's 33% right there:<details><summary>View Safe to Merge PRs</summary>1. [Bump babel to ^7.22.11](https://github.com/mui/material-ui/pull/38662)<br>2. [Bump prettier to ^3.0.2](https://github.com/mui/material-ui/pull/37886)<br>3. [Bump stylis to ^4.3.0](https://github.com/mui/material-ui/pull/37791)<br>4. [Lock file maintenance](https://github.com/mui/material-ui/pull/34538)<br></details><br><img width='370' alt='feels' src='https://i.imgur.com/ceikuMr.png'><h3>:mag_right: &nbsp; How does Adaptly know this?</h3>It analyses changelogs of dependencies updated in a PR.<br>If no breaking changes are found in the changelogs, PR is marked as good to merge.<h3>:sparkles: Try Adaptly yourself</h3>Feel free to [try Adaptly](https://github.com/marketplace/adaptly) on your repositories and finally<br>merge dependency update PRs. Let us know if you have any questions.<br><br>Best of luck with your projects,<br>Lauris<br>lauris@adaptly.dev
Repository: stable-diffusion-webui
Issue: Add multi gpu support (i can provide GPU farm for development)
Labels: enhancement

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What would your feature do ?

hi, @AUTOMATIC1111  i saw somewhere that you sayed that you don't have GPU farm, i can provide farm with 8 GPU nvidia geforce gtx 1070 for multi gpu development. if you need let me know, or close this feature request, thanks, best regards.

### Proposed workflow

1. Go to .... 
2. Press ....
3. ...


### Additional information

_No response_
Repository: go
Issue: x/website/tour: add links to the Playground
Labels: NeedsInvestigation,FeatureRequest,website

Per [#1437](https://github.com/golang/tour/issues/1437) and #62323, the [Go Tour](https://go.dev/tour) code box is not accessible to developers who are blind or visually impaired.

A mitigation would be to add a link in each lesson to the same code in the [Playground](https://go.dev/play/), which is more accessible.
Repository: flutter
Issue: [packages] Clean up manual Pigeon enum wrappers
Labels: p: webview,p: local_auth,package,team-ecosystem,P2,c: tech-debt,triaged-ecosystem

Now that https://github.com/flutter/flutter/issues/87307 is implemented we should update packages that had manual wrappers to work around it. Looking for references to 87307 in the codebase, it looks like that's:
- [x] local_auth_android
- [x] local_auth_ios
- [x] webview_flutter_android
- [ ] webview_flutter_wkwebview

/cc @tarrinneal in case you want to do this as a follow-up.
Repository: stable-diffusion-webui
Issue: [Bug]: The Project cannot work with GPU acceleration on MacOS Sonoma of beta version.
Labels: bug-report,platform:mac

### Is there an existing issue for this?

- [X] I have searched the existing issues and checked the recent builds/commits

### What happened?

Recently I update my MacBook's system to Sonoma version where the WebUI cannot work well.
I can only use CPU to generate the image, otherwise the terminal will return some error information.
I hope it can appropriate with the new system version in future as quickly as impossible.
Thanks! :)

### Steps to reproduce the problem

Recently I update my MacBook's system to Sonoma version where the WebUI cannot work well.
I can only use CPU to generate the image, otherwise the terminal will return some error information.
I hope it can appropriate with the new system version in future as quickly as impossible.
Thanks! :)

### What should have happened?

Recently I update my MacBook's system to Sonoma version where the WebUI cannot work well.
I can only use CPU to generate the image, otherwise the terminal will return some error information.
I hope it can appropriate with the new system version in future as quickly as impossible.
Thanks! :)

### Version or Commit where the problem happens

the latest version of SD WebUI

### What Python version are you running on ?

Python 3.10.x

### What platforms do you use to access the UI ?

MacOS

### What device are you running WebUI on?

CPU, Other GPUs

### Cross attention optimization

Automatic

### What browsers do you use to access the UI ?

Apple Safari

### Command Line Arguments

```Shell
./webui.sh
```


### List of extensions

none.

### Console logs

```Shell
none.
```


### Additional information

_No response_
Repository: material-ui
Issue: [docs-infra] Header flex wrap issue
Labels: bug 🐛,scope: docs-infra

### Steps to reproduce 🕹

https://github.com/mui/material-ui/pull/38528#issuecomment-1695872483

<img width="795" alt="Screenshot 2023-08-28 at 17 10 48" src="https://github.com/mui/material-ui/assets/3165635/4a688150-07bd-4aed-ac0b-a4ac32aae6a3">

### Current behavior 😯

_No response_

### Expected behavior 🤔

_No response_

### Context 🔦

_No response_

### 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.
```
</details>
Repository: go
Issue: x/website/tour: toggle code editor off
Labels: NeedsInvestigation,FeatureRequest,Tools,website

Per [#1437](https://github.com/golang/tour/issues/1437) and #62323, the [Go Tour](https://go.dev/tour) code box is not accessible to developers who are blind or visually impaired.

A useful mitigation would be to let the user choose to use the Tour in "read-only" mode:
- lesson text contents unchanged
- remove code editor
- replace it with a plain text listing
  - screen reader friendly
- keep the [Run] button
- remove the [Reset], [Format] buttons

This choice would persist in the user browser, like other existing settings.
Repository: flutter
Issue: Long-term solution to replacing `ios-deploy`
Labels: platform-ios,tool,e: OS-version specific,P2,team-ios,triaged-ios

Starting with Xcode 15 and iOS 17, `ios-deploy` no longer works on iOS 17+ physical devices and [sounds like ios-deploy will not be supporting it](https://github.com/ios-control/ios-deploy/issues/588#issuecomment-1667938056).

We added a workaround-like solution to fix https://github.com/flutter/flutter/issues/128531, but the solution is undesirable since it involves having Xcode open.

Xcode 15 did release a new tool called `devicectl`, which provide a lot of the functionality that Flutter requires. However, it's missing a key piece of being able to start a `debugserver` on the device, which is required for Flutter debug mode because `debugserver` [will ptrace the process](https://github.com/flutter/engine/blob/805162c18b32c8352c71d9e832a812fc40058020/runtime/ptrace_check.cc#L13-L16). This is required [due to the Dart VM being JIT and dependent on tracing](https://github.com/flutter/engine/pull/20980).

Ideally, Apple will provide a way to start a `debugserver` and connect with lldb through `devicectl`, but no sign of that yet as far as I know.
Repository: godot
Issue: `OS.get_cmdline_args()` does not include `--rendering-method` CLI argument
Labels: bug,topic:core,needs testing

### Godot version

v4.1.1.stable.official [bd6af8e0e]

### System information

Godot v4.1.1.stable - Manjaro Linux - Vulkan (Mobile) - integrated AMD Radeon Vega 10 Graphics (RADV RAVEN) - AMD Ryzen 7 3700U

### Issue description

I am trying to determine if the rendering method has been overridden on the command line, like this:
```bash
./game --rendering-method gl_compatibility
```

I am printing the result of `OS.get_cmdline_args()`, so the expected behaviour when I run the game is that the printed array contains something like this:
```
["--rendering-method", "gl_compatibility"]
```

However, when just this argument is set, I get an empty array.  I've tried using `OS.get_cmdline_user_args()` and running the game from the editor with the argument set in `editor/run/main_run_args`, but these give the same result.

If this is intentional, I can't find mention of it in the docs.  Other CLI arguments might also be affected by this.

### Steps to reproduce

1.  Create a simple project with a Node2D and this script attached:
```
extends Node2D

func _ready():
    print(OS.get_cmdline_args())
```
2. Set `editor/run/main_run_args` in the Project Settings to `--rendering-method gl_compatibility`
3. Run the game from the editor.  Only the main scene argument is in the printed array
4. Export the project, and run it with the above argument.  The printed array is empty

### Minimal reproduction project

N/A
Repository: rust
Issue: Socket error on MacOS when sending huge buffers over TCP socket
Labels: O-macos,C-bug,T-libs

<!--
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
use std::{
    io::{Read, Write},
    net::{TcpListener, TcpStream},
    thread,
    time::Duration,
};

fn main() {
    let listener = TcpListener::bind("127.0.0.1:42000").unwrap();
    thread::spawn(move || {
        for s in listener.incoming() {
            let mut conn = s.unwrap();
            loop {
                let mut buf = [0 as u8; 16384];
                conn.read(&mut buf).unwrap();
            }
        }
    });
    thread::sleep(Duration::from_secs(1));
    let buf = vec![0 as u8; 2_200_000_000]; // ~2.2GB, causes "Invalid argument"
    // let buf = vec![0 as u8; 2_100_000_000]; // ~2.1GB, works fine
    let mut socket = TcpStream::connect("127.0.0.1:42000").unwrap();
    let res = socket.write_all(&buf);
    println!("Result: {res:?}");
}

```

I expected to see this happen: The whole 2.2GB buffer is sent over the TCP socket.

Instead, this happened: Socket write fails with `Result: Err(Os { code: 22, kind: InvalidInput, message: "Invalid argument" })`

The problem is that `TcpStream` uses a presumably incorrect way to determinate the maximum allowed size of the socket buffer https://github.com/rust-lang/rust/blob/c587fd418521c841f8683c58872293475b8d9b3b/library/std/src/sys_common/net.rs#L289 which ends up in 64bit `usize::MAX` for all targets. Whereas the proper way seems to be using `macos` specific `READ_LIMIT` https://github.com/rust-lang/rust/blob/c587fd418521c841f8683c58872293475b8d9b3b/library/std/src/sys/unix/fd.rs#L39 which is using `i32::MAX` under the hood. See: https://github.com/rust-lang/rust/blob/c587fd418521c841f8683c58872293475b8d9b3b/library/std/src/sys/unix/fd.rs#L250

#### Fix proposal:
Maybe `TcpStream` should use `Socket::write` which forwards the call to the `FileDesc` ? The same applies for other similar places in the Rust stdlib which use Posix `write` call directly instead of `FileDesc` wrapper.

### 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`:
```
rustc --version --verbose
rustc 1.73.0-nightly (db7ff98a7 2023-07-31)
binary: rustc
commit-hash: db7ff98a72f3e742b641f9cb16d0e8c285e87e9b
commit-date: 2023-07-31
host: aarch64-apple-darwin
release: 1.73.0-nightly
LLVM version: 16.0.5
```
Repository: flutter
Issue: Draft the Infrasture Triage Timeline for new issues
Labels: team-infra,P1,triaged-infra

Need to define a process on how we are going to triage issues and when we are going to be working on them and prioritize this work.
Repository: rust
Issue: Slow compilation of async fn that creates a vector with many Strings created from string literals, even with no .await
Labels: P-medium,I-compiletime,T-compiler,I-compilemem,A-async-await,AsyncAwait-Triaged,WG-async


```rust
fn main() {
    make_menagerie();
}

async fn make_menagerie() -> Vec<String> {
    vec![
        "monster".to_string(), // <=== repeat this line 1000 to 10000 times.
    ]
}
```

Build with `cargo build`. I'm using Rust 1.72 on aarch64-apple-darwin.

In addition to the slow compilation time, I also see large memory usage. With 2500 lines, my OS reported `rustc` as consuming 20GB.

# Exploration

## Different versions

There was no obvious correlation.

Version | Time (sec)
-- | --
1.63 | 18.984
1.64 | 19.224
1.65 | 18.797
1.66 | 18.993
1.67 | 18.917
1.68 | 17.994
1.69 | 18.349
1.70 | 21.379
1.71 | 20.655
1.72 | 22.587

<img width="881" alt="image" src="https://github.com/rust-lang/rust/assets/174509/a9e9d39d-97dd-4f9a-8775-d31dba5cad4b">

## Different numbers of lines

This appears to show time is proportional to (number of lines)^2

Lines | Time
-- | --
500 | 0.133
1000 | 2.831
1500 | 6.512
2000 | 13.545
2500 | 22.404
3000 | 35.894

<img width="647" alt="image" src="https://github.com/rust-lang/rust/assets/174509/0979daa4-73cf-4fc8-b792-1981c5df12fc">

## String slices

Switching to returning a `&'static str` instead of `String` resulted in fast compilation (<250 ms).

## Using a function

Creating a helper function and calling it inside of `vec![]` resulted in fast compilation (<250 ms).

```rust
fn make_string() -> String { "monster".to_string() }
```

## Using another method

Switching to returning a `usize` instead of a `String` has reduced compilation time but still surprisingly slow (2.5 sec).

```rust
vec![
    "monster".len(),
]
```

## Avoiding `async fn`

Removing `async` from `make_menagerie` has reduced compilation time (<750 ms)

# Test case generation

For trying different things, I used two files

**main.rs**

```rust
fn main() {
    make_menagerie();
}

async fn make_menagerie() -> Vec<String> {
    include!("repeat.rs")
}
```

And to generate 2500 lines:

```
(echo 'vec!['; yes '"monster".to_string(),' | head -n 2500; echo ']') > src/repeat.rs
```