sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: vscode
Issue: CSHTML Razor syntax highlighting suboptimal
Labels: feature-request,grammar

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- VS Code Version: 1.92.1
- OS Version: Win 11 ARM

Steps to Reproduce:

1. Open .cshtml with Model\Razor syntax

Razor syntax is off in VSCode vs Visual Studio

Here's VSCode
![image](https://github.com/user-attachments/assets/b2e21c62-b896-4384-987e-ef930378573a)

Here's VS2022
![image](https://github.com/user-attachments/assets/0950609f-161f-4806-b2ff-f6837bbc5f64)

It's much much harder to do anything in Razor with VSCode.

Even things like this, that model directive is just invisible

![image](https://github.com/user-attachments/assets/fac1edc6-7741-4802-9a98-ebaa63196f85)
Repository: storybook
Issue: [Documentation]: docs/get-started/frameworks/nextjs needs draftMode mock example
Labels: help wanted,documentation

### Describe the problem

The documentation gives examples on how to mock headers for app router based Next.JS, but not how to use the draftMode mock.

### Additional context

_No response_
Repository: tauri
Issue: [bug]the windows title bar button can not be removed or disabled, or window can not be maximized as configured.
Labels: type: bug,status: needs triage

### Describe the bug

![image](https://github.com/user-attachments/assets/ba896c21-e3f7-4e79-8f19-ee51b0ac54e0)
button is like above,
config like following:
"resizable": false,
"maximized":true,
"width":1024,
"height":768,
"decorations":true

when button clicked, window becomes 1024*768, click again, restore to maximized.


### Reproduction

_No response_

### Expected behavior

window should kept maximized whenever button clicked or not

### Full `tauri info` output

```text
[✔] Environment
    - OS: Windows 10.0.19045 X64
    ✔ WebView2: 126.0.2592.113
    ✔ MSVC:
        - Visual Studio Community 2019
        - Visual Studio Community 2022
    ✔ rustc: 1.82.0-nightly (28a58f2fa 2024-07-31)
    ✔ cargo: 1.82.0-nightly (257b72b8a 2024-07-30)
    ✔ rustup: 1.24.3 (ce5817a94 2021-05-31)
    ✔ Rust toolchain: nightly-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 18.0.0
    - npm: 9.6.6

[-] Packages
    - tauri [RUST]: 2.0.0-beta.22
    - tauri-build [RUST]: 2.0.0-beta.17
    - wry [RUST]: 0.40.1
    - tao [RUST]: 0.28.1
    - tauri-cli [RUST]: 2.0.0-beta.21
    - @tauri-apps/api : not installed!
    - @tauri-apps/cli [NPM]: 2.0.0-beta.21

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist
    - devUrl: http://localhost:1422/
```


### Stack trace

```text
no
```


### Additional context

_No response_
Repository: ollama
Issue: Context window size cannot be changed
Labels: bug

### What is the issue?

I see this issue has been partially reported, but none of the previous reports seem to be extensive in their tests of possible methods to set this option. 

The problem: 
Ollama server truncates the input to 2048 tokens regardless of the chat completion API used.

My setup: 
I tried Ollama on my local computer with Windows and CPU only
As well as on a Linux machine, CPU only

 I tried several models: llama3, gemma2, mistral

I tried several APIs: ollama's, Langchain, OpenAI

I see Ollama server starts by default on my two machines with a context window size of 8192.
`
level=INFO source=server.go:617 msg="waiting for server to become available" status="llm server loading model"
llama_new_context_with_model: n_ctx      = 8192
`

But just in case, I also tried: 
`/set parameter num_ctx 8192`
Which, as a side note, on Linux machine ends up setting a window size of 4*8192, so I had to restart the server.

The code I use for getting a chat completion:
`completion = self.llm_client.chat(model=self.model, messages=[`
`    {"role": "system", "content": self.context},`
`    {"role": "user", "content": question}`
`    ],`
`    options=dict(temperature=temperature, n_ctx=n_ctx)`
`)`
This is ignored regardless of which API I use (ollama, langchain or openAI) or on which machine I run (Windows or Linux).
The server logs show:
`INFO [update_slots] input truncated | n_ctx=2048 n_erase=3157 n_keep=4 n_left=2044 n_shift=1022 tid="139731362228096" timestamp=1723208612`

The only way I can get ollama to use a context window of a given size is by not using an API and just making the call directly through the **requests** library. But this is much slower than using langchain API (which seems to be the fastest of the 3). 

`url = base_url + "/api/chat"`
                `model = self.model`

                `payload = {
                    "model": model,
                    "messages": [
                        {"role": "system", "content": self.context},
                        {"role": "user", "content": question}
                    ],
                    "stream": False,
                    "options": {
                        "num_ctx": n_ctx,
                        "temperature": self.temperature,
                        "max_tokens": self.max_tokens
                    }
                }
                headers = {
                    "Content-Type": "application/json"
                }
                response = requests.post(url, data=json.dumps(payload), headers=headers)
                response.raise_for_status()`




### OS

Linux, Windows

### GPU

_No response_

### CPU

_No response_

### Ollama version

0.3.4
Repository: go
Issue: build: build failure on x_tools-gotip-darwin-amd64_13
Labels: NeedsInvestigation

```
#!watchflakes
default <- builder == "x_tools-gotip-darwin-amd64_13" && repo == "tools" && mode == "build"
```

Issue created automatically to collect these failures.

Example ([log](https://ci.chromium.org/b/8740108907552657873)):

    Building Go cmd/dist using /Users/swarming/.swarming/w/ir/cache/tools/go_bootstrap. (go1.20.6 darwin/amd64)
    Building Go toolchain1 using /Users/swarming/.swarming/w/ir/cache/tools/go_bootstrap.
    Building Go bootstrap cmd/go (go_bootstrap) using Go toolchain1.
    Building Go toolchain2 using go_bootstrap and Go toolchain1.
    Building Go toolchain3 using go_bootstrap and Go toolchain2.
    Building packages and commands for darwin/amd64.
    # internal/bytealg
    # [internal/bytealg]
    asm: writing output: write $WORK/b164/index_amd64.o: device error
    internal/goexperiment: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b170/importcfg: device error
    ...
    internal/cfg: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b456/importcfg: device error
    vendor/golang.org/x/crypto/cryptobyte/asn1: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b493/importcfg: device error
    internal/nettrace: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b517/importcfg: device error
    vendor/golang.org/x/crypto/internal/alias: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b500/importcfg: device error
    internal/trace/traceviewer/format: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b542/importcfg: device error
    internal/trace/event: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b644/importcfg: device error
    cmd/vendor/golang.org/x/tools/internal/bisect: write /Users/swarming/.swarming/w/ir/x/t/go-build3228806733/b719/importcfg: device error
    # runtime
    compile: writing output: write $WORK/b010/_pkg_.a: device error
    go tool dist: FAILED: /Users/swarming/.swarming/w/ir/x/w/goroot/pkg/tool/darwin_amd64/go_bootstrap install cmd: exit status 1


— [watchflakes](https://go.dev/wiki/Watchflakes)
Repository: pytorch
Issue: [Inductor] Some way of dynamically annotating inputs to a custom op or triton kernel as requiring certain strides
Labels: triaged,oncall: pt2,module: inductor,module: user triton

Use case:
- you have a triton kernel or custom operator
- Inductor will make one of the following assumptions: "all inputs must have the same exact strides as the traced FX graph", "all inputs must have the same dense stride order as traced FX graph", "the operator/kernel is stride agnostic". For custom operators this is configurable at the creation of the operator, for triton kernels this is not currently configurable today
- The assumption inductor makes might be different from what the user wanted, so ideally the user should be able to override the configuration.

I'm not sure what the API for this should look like. Options:
```py
# Option 1: some config outside of the compiled region
torch._inductor.override_stride_constraints(op_or_kernel, "arg", REQUIRE_FIXED_STRIDES)

# Option 2: some annotation inside the compiled region:
custom_op(torch._inductor.stride_hint(x, "require_exact"), y)
```
annotation on a per-call level is probably better for debugging?

Thoughts? @eellison @FindHao @oulgen 

cc @ezyang @chauhang @penguinwu @voznesenskym @EikanWang @jgong5 @Guobing-Chen @XiaobingSuper @zhuhaozhe @blzheng @wenzhe-nrv @jiayisunx @ipiszy @yf225 @chenyang78 @kadeng @muchulee8 @ColinPeppler @amjames @desertfire @oulgen @aakhundov
Repository: angular
Issue: control flow migration: remove imports property when the list of imports is empty.
Labels: area: migrations,core: control flow

### Which @angular/* package(s) are the source of the bug?

Don't known / other

### Is this a regression?

No

### Description

When the control flow migration results in the empty `imports` array in the `@Component` decorator we could remove the `imports` property.

### Please provide a link to a minimal reproduction of the bug

_No response_

### Please provide the exception or error you saw

_No response_

### Please provide the environment you discovered this bug in (run `ng version`)

_No response_

### Anything else?

_No response_
Repository: vscode
Issue: Incorrect color on carets and interfaces when using multiple lines
Labels: bug,javascript,bracket-pair-colorization

<!-- ⚠️⚠️ Do Not Delete This! bug_report_template ⚠️⚠️ -->
<!-- Please read our Rules of Conduct: https://opensource.microsoft.com/codeofconduct/ -->
<!-- 🕮 Read our guide about submitting issues: https://github.com/microsoft/vscode/wiki/Submitting-Bugs-and-Suggestions -->
<!-- 🔎 Search existing issues to avoid creating duplicates. -->
<!-- 🧪 Test using the latest Insiders build to see if your issue has already been fixed: https://code.visualstudio.com/insiders/ -->
<!-- 💡 Instead of creating your report here, use 'Report Issue' from the 'Help' menu in VS Code to pre-fill useful information. -->
<!-- 🔧 Launch with `code --disable-extensions` to check. -->
Does this issue occur when all extensions are disabled?: Yes

<!-- 🪓 If you answered No above, use 'Help: Start Extension Bisect' from Command Palette to try to identify the cause. -->
<!-- 📣 Issues caused by an extension need to be reported directly to the extension publisher. The 'Help > Report Issue' dialog can assist with this. -->
- Version: 1.92.1 (Universal)
- Commit: eaa41d57266683296de7d118f574d0c2652e1fc4
- Date: 2024-08-07T20:16:39.455Z
- Electron: 30.1.2
- ElectronBuildId: 9870757
- Chromium: 124.0.6367.243
- Node.js: 20.14.0
- V8: 12.4.254.20-electron.0
- OS: Darwin arm64 23.6.0

It is a visual bug, in TypeScript, the first caret loses its color, also the interfaces and the last caret turns red.
As you can see, the second method does not lose the colors because it is on a single line.

<img width="740" alt="Screenshot 2024-08-09 at 8 26 50 a m" src="https://github.com/user-attachments/assets/4fb4b0bb-65fc-43ed-b8f3-fac466c4ed14">


Steps to Reproduce:

1. Copy and paste the code below into the online editor and you will be able to see the issue.

https://vscode.dev/

```
import { baseApi as api } from "./baseApi";
const injectedRtkApi = api.injectEndpoints({
  endpoints: (build) => ({
    accountsOrganizationsList: build.query<
      AccountsOrganizationsListApiResponse,
      AccountsOrganizationsListApiArg
    >({
      query: () => ({ url: `/api/accounts/organizations/` }),
    }),
    accountsUsersList: build.query<AccountsUsersListApiResponse, AccountsUsersListApiArg>({
      query: () => ({ url: `/api/accounts/users/` }),
    }),
  }),
});

```
Repository: next.js
Issue: Instrumentation files not included in standalone output
Labels: bug,Output (export/standalone),linear: next,Instrumentation

### Link to the code that reproduces this issue

https://github.com/moshie/nextjs-issue

### To Reproduce

1. Pull down the repo: https://github.com/moshie/nextjs-issue
2. run `npm install`
3. run `npm run build`
4. See in the .next/standalone/node_modules folder that the `@splunk/otel` prebuilds folder is not included

### Current vs. Expected behavior

When using the `@splunk/otel` package in the instrumentation file the standalone output doesn't include the prebuilds from: `node_modules/@splunk/otel/prebuilds/linux-x64/@splunk+otel.abi115.node`

That results in this error:

![Screenshot 2024-08-08 at 17 30 08](https://github.com/user-attachments/assets/298e04c1-e60c-496d-b292-aeacfc7b8c08)

Since `outputFileTracingIncludes` seems like it's tied to the pages and app directories I am not sure how best to include this file into my build?

I've tried in my docker file to include something similar to this:
```
COPY --chown=nonroot --from=builder /opt/application/node_modules/@splunk ./node_modules/@splunk
COPY --chown=nonroot --from=builder /opt/application/node_modules/.pnpm/@splunk+otel@2.10.0_@opentelemetry+api@1.9.0 ./node_modules/.pnpm/@splunk+otel@2.10.0_@opentelemetry+api@1.9.0
```

But this isn't a very elegant solution since the path names contain versions and this would need to be updated everytime we update the @splunk/otel package.

I suppose this might have solved my issue but it's been removed (I don't know if it copied whole folders?):
```
unstable_includeFiles: ['node_modules/@splunk/otel'],
```



### Provide environment information

```bash
Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 23.4.0: Fri Mar 15 00:10:42 PDT 2024; root:xnu-10063.101.17~1/RELEASE_ARM64_T6000
  Available memory (MB): 32768
  Available CPU cores: 10
Binaries:
  Node: 20.16.0
  npm: 10.8.1
  Yarn: 1.22.22
  pnpm: 9.7.0
Relevant Packages:
  next: 14.2.5
  eslint-config-next: N/A
  react: 18.3.1
  react-dom: 18.3.1
  typescript: 5.5.4
Next.js Config:
  output: standalone
```


### Which area(s) are affected? (Select all that apply)

Instrumentation, Output (export/standalone)

### Which stage(s) are affected? (Select all that apply)

next build (local), next start (local)

### Additional context

My app is dockerised and is using distoless. I thought about just running `pnpm install @splunk/otel` directly in the standalone folder but that didn't seem like it would work with distroless and also it's not very elegant either.
Repository: rust
Issue: Unexpected unsizing coercion introduced by unsafe block
Labels: A-MIR,T-types,T-opsem

Consider [this example](https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=a5400c33cb7e257b0d795cbdb4b7a389):
```rust
pub fn testcase() -> *const dyn Bar {
    let baz: &dyn Baz = &1;
    // Unexpected coercion in the next line
    let baz_fake = unsafe { std::mem::transmute::<_, *const dyn Bar>(baz) };
    baz_fake
}
```
The initial MIR after MIR building is
```
    bb0: {
        StorageLive(_1);
        StorageLive(_2);
        StorageLive(_3);
        StorageLive(_4);
        StorageLive(_5);
        _5 = const 1_i32;
        _4 = &_5;
        _3 = &(*_4);
        _2 = move _3 as &dyn Baz (PointerCoercion(Unsize));
        StorageDead(_3);
        FakeRead(ForLet(None), _2);
        AscribeUserType(_2, o, UserTypeProjection { base: UserType(1), projs: [] });
        StorageDead(_4);
        StorageLive(_6);
        StorageLive(_7);
        StorageLive(_8);
        _8 = _2;
        _7 = transmute::<&dyn Baz, *const dyn Bar>(move _8) -> [return: bb1, unwind: bb2];
    }

    bb1: {
        StorageDead(_8);
        _6 = move _7 as *const dyn Bar (PointerCoercion(Unsize));
        StorageDead(_7);
        FakeRead(ForLet(None), _6);
        StorageLive(_9);
        _9 = _6;
        _1 = move _9 as *const dyn Bar (PointerCoercion(Unsize));
        StorageDead(_9);
        StorageDead(_6);
        StorageDead(_5);
        StorageDead(_2);
        _0 = move _1 as *const dyn Bar (PointerCoercion(Unsize));
        StorageDead(_1);
        return;
    }
```
Notice the no less than *three* coercions in `bb1`, all of which coerce from `*const dyn Bar` to `*const dyn Bar`. I would have expected to see zero of them; the `transmute` returns exactly the type we want so there's no reason to insert a coercion.

This came up because Miri actually considers such coercions to be a simple form of upcast that can introduce UB, so unexpected coercions can lead to unexpected UB. We can just change the MIR opsem to make identity coercions true NOPs, but we don't do this for any other kind of coercion so it's an odd special case.

Cc @rust-lang/types @rust-lang/opsem
Repository: TypeScript
Issue: compilerOptions.plugins accepts missing plugins without any logging or error information
Labels: Suggestion,Awaiting More Feedback

### 🔎 Search Terms

compilerOptions, plugins, missing, module, plugin

### 🕗 Version & Regression Information

- This is the behavior in every version I tried, and I reviewed the FAQ for entries about missing plugins

### ⏯ Playground Link

https://www.typescriptlang.org/play/?#code/MYewdgzgLgBAHjAvDAjAbiA

### 💻 Code

tsconfig.json:

```json
{
  "compilerOptions": {
    "plugins": [
      {
        "name": "missing"
      }
    ]
  }
}
```


### 🙁 Actual behavior

TypeScript doesn't produce any debugging hints, or an error, if compilerOptions.plugins includes a reference to a missing plugin.

### 🙂 Expected behavior

When a `tsconfig` contains a `compilerOptions.plugins` entry that points to a plugin that could not be found, TypeScript should log or produce an error saying that it couldn't be found.

### Additional information about the issue

_No response_
Repository: PowerToys
Issue: run plugins options randomly expand and collapse while scrolling
Labels: Issue-Bug,Product-Settings,Area-User Interface,Needs-Triage

### Microsoft PowerToys version

0.83.0

### Installation method

GitHub

### Running as admin

None

### Area(s) with issue?

PowerToys Run, Settings

### Steps to reproduce

1.expand calculator
2.scroll down to windows walker
3.expand windows walker
4.scroll back up

### ✔️ Expected Behavior

expanded settings stays expanded
collapsed settings stays collapsed

### ❌ Actual Behavior

calculator is collapse, windows search is expanded
![Animation](https://github.com/user-attachments/assets/17cb73d3-9728-42f7-b9df-5632fb213938)


### Other Software

_No response_
Repository: rust
Issue: Compile a crate from its source archive directly
Labels: T-compiler,C-feature-request

### Problem

Today, crates provided by e.g. crates.io are downloaded in a (somewhat loosely defined?) archive format, with a `.crate` extension. Example: https://static.crates.io/crates/clap/clap-3.0.6.crate
> clap-3.0.6.crate: gzip compressed data, was "clap-3.0.6.crate", max compression, original size modulo 2^32 1110528

This gets stored as a local cache and is also extracted in a nearby folder, which then gets fed to `cargo` / `rustc` for compilation.

I (and surely others) am developing a `$RUSTC_WRAPPER` that has to deal with these archives and thus have to replicate the handling of said `.crate`s. Given these open issues, and for optimization reasons, I would like for `cargo` (or `rustc`) to be able to take in these archives directly, without prior extraction:
* https://github.com/rust-lang/cargo/issues/2948
* https://github.com/rust-lang/cargo/issues/2526
* https://github.com/rust-lang/cargo/issues/9455


### Proposed Solution

I am not familiar with the inner workings of either `cargo` nor `rustc` so this is a high level take.

Basically, I'm asking that today's call to `rustc` be seamlessly interchangeable from:
> rustc --crate-name clap ......  $HOME/.cargo/registry/src/index.crates.io-6f17d22bba15001f/clap-3.0.6/src/lib.rs ....

to

> rustc --crate-name clap ......  $HOME/.cargo/registry/cache/index.crates.io-6f17d22bba15001f/clap-3.0.6.crate ...

thus moving the crate archive handling code to within the boundary of (I guess) `rustc`.

This in turn
* encapsulates the archive format
* allows me (and others) to just pass archives down from crates.io straight to `rustc`

### Notes

I realize this issue may need to move to `rustc`. But hey let's have a small discussion first :)
Repository: flutter
Issue: [et]: add flag that will print out rbe stats
Labels: P2,team-engine,triaged-engine,e: engine-tool

There is some file on disk that has the stats for RBE but I can't remember where it is.  It would be nice if we had an easy way to access it.
Repository: go
Issue: x/tools/gopls: ApplyFix: "no file for edit position" bug in suggestedFixToDocumentChange (via telemetry)
Labels: Documentation,NeedsInvestigation,gopls,Tools,gopls/telemetry-wins

```
#!stacks
"bug.Errorf" && "golang.suggestedFixToDocumentChange:+10"
```

This stack `Di2gNg` was [reported by telemetry](https://storage.googleapis.com/prod-telemetry-merged/2024-08-06.json):

```
gopls/bug
golang.org/x/tools/gopls/internal/util/bug.report:+35
golang.org/x/tools/gopls/internal/util/bug.Errorf:+2
golang.org/x/tools/gopls/internal/golang.suggestedFixToDocumentChange:+10
golang.org/x/tools/gopls/internal/golang.ApplyFix:+47
golang.org/x/tools/gopls/internal/server.(*commandHandler).ApplyFix.func1:+1
golang.org/x/tools/gopls/internal/server.(*commandHandler).run.func2:+3
golang.org/x/tools/gopls/internal/server.(*commandHandler).run:+73
golang.org/x/tools/gopls/internal/server.(*commandHandler).ApplyFix:+2
golang.org/x/tools/gopls/internal/protocol/command.Dispatch:+25
golang.org/x/tools/gopls/internal/server.(*server).ResolveCodeAction:+21
golang.org/x/tools/gopls/internal/protocol.serverDispatch:+46
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.ServerHandler.func3:+5
golang.org/x/tools/gopls/internal/lsprpc.(*streamServer).ServeStream.handshaker.func4:+52
golang.org/x/tools/gopls/internal/protocol.Handlers.MustReplyHandler.func1:+2
golang.org/x/tools/gopls/internal/protocol.Handlers.AsyncHandler.func2.2:+3
runtime.goexit:+0
```
```
golang.org/x/tools/gopls@v0.16.1 go1.22.0 darwin/arm64 other,vscode (3)
```

Issue created by golang.org/x/tools/gopls/internal/telemetry/cmd/stacks.
Dups: jFMuhg hN-HyA