sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: rust
Issue: Error recovery after errors during macro expansion is usually futile
Labels: A-diagnostics,A-macros,T-compiler,E-medium,D-verbose

### Code

```Rust
// https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=13d58799822d542a2c53296f715ac44c
macro_rules! define {
    (enum $name:ident) => {
        struct $name {}
    };
}

define! {
    struct Hello
}

fn main() {
    Hello;
}
```


### Current output

```Shell
error: no rules expected the token `struct`
 --> src/main.rs:8:5
  |
1 | macro_rules! define {
  | ------------------- when calling this macro
...
8 |     struct Hello
  |     ^^^^^^ no rules expected this token in macro call
  |
note: while trying to match `enum`
 --> src/main.rs:2:6
  |
2 |     (enum $name:ident) => {
  |      ^^^^

error[E0425]: cannot find value `Hello` in this scope
  --> src/main.rs:12:5
   |
12 |     Hello;
   |     ^^^^^ not found in this scope
```


### Desired output

```Shell
error: no rules expected the token `struct`
 --> src/main.rs:8:5
  |
1 | macro_rules! define {
  | ------------------- when calling this macro
...
8 |     struct Hello
  |     ^^^^^^ no rules expected this token in macro call
  |
note: while trying to match `enum`
 --> src/main.rs:2:6
  |
2 |     (enum $name:ident) => {
  |      ^^^^
```


### Rationale and extra context

This is a concrete example, but the problem is very general. When macro expansion goes wrong, _anything_ might have not happened as a result, for example defining types and other things. In my experience, this frequently causes cascading useless errors, mostly but not exclusively from name resolution. This makes it very hard to work with the output of `cargo check` when dealing with macro expansion errors in my experience.

We should, when there are errors during macro expansion, abort compilation after macro expansion without any further recovery. It's impossible to know which errors are actually useful and in many cases there are a lot of useless ones.

With errors during macro expansion I mean any errors that stop macros from being expanded, for example matching mismatches or macros not being found.

Note that errors _before_ macro expansion, like parser errors, tend to be fairly recoverable and we should still do recovery on them, this is specifically about the case where the error count _increases during macro expansion_.

### Other cases

_No response_

### Anything else?

cc @rust-lang/wg-diagnostics 

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":"policeakshithreddy"}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: Godot Android Build Issue stuck at 66%
Labels: bug,platform:android,needs testing,topic:export

### Godot version

4.1.1

### System information

Windows 11

### Issue description

When I try to build project on play button on my phone. Screeen freeze at 66%.

### Steps to reproduce

Build for android in the preview editor.
![Captura de pantalla 2023-09-26 115250](https://github.com/godotengine/godot/assets/103970174/4e8cc7dd-cb83-44ec-ad38-feb4c663f65f)


### Minimal reproduction project

Cannot upload because of size. issue is at build. And cannot include android files.
Repository: godot
Issue: Android remote debug issue
Labels: bug,platform:android,topic:export

### Godot version

4.1.2.rc1

### System information

Godot v4.1.2.rc1 - Windows 10.0.19045 - Vulkan (Mobile) - integrated AMD Radeon(TM) Vega 8 Graphics () - AMD Ryzen 3 2200G with Radeon Vega Graphics (4 Threads)

### Issue description

its android remote debug issue
after remote debug loading finish i got an error


-editor/export/editor_export_platform.h:178 - Export: Building of Android project failed, check output for the error. Alternatively visit docs.godotengine.org for Android build documentation.
-  Cannot remove non-existent file or directory: C:/Users/ASD/AppData/Local/Godot/tmpexport.1695701345.apk

### Steps to reproduce

-editor/export/editor_export_platform.h:178 - Export: Building of Android project failed, check output for the error. Alternatively visit docs.godotengine.org for Android build documentation.
-  Cannot remove non-existent file or directory: C:/Users/ASD/AppData/Local/Godot/tmpexport.1695701345.apk

### Minimal reproduction project

![Screenshot_195](https://github.com/godotengine/godot/assets/146053254/9b13ccdf-b31b-4882-94ee-7fd823199ab9)
![Screenshot_194](https://github.com/godotengine/godot/assets/146053254/3d9b0a03-d74e-4066-b7e2-47a208ba7556)
Repository: godot
Issue: Error: Could not find type "x" in the current scope when duplicating script files
Labels: bug,topic:core,topic:gdscript

### Godot version

v4.1.stable.mono.official [970459615]

### System information

Godot v4.1.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1070 (NVIDIA; 31.0.15.3623) - Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz (8 Threads)

### Issue description

Duplicating a `type_1.gd` file to create a new script `type_2.gd` out of the existing one will cause parser errors like `Could not find type "Type1" in the current scope` for other scripts that depend on the existing `Type1` class.

Reloading the project has no effect but removing the `.godot` folder will fix the issue. In the same way, the attached example doesn't include the `type_2.gd` script because the issue doesn't occur when the project has not been opened before.

### Steps to reproduce

1. Create a main scene and attach a script `main.gd`
2. Create a new script `type_1.gd` with an explicit `class_name Type1`
3. In the `main.gd` script add a variable of type `Type1`
4. Duplicate the `type_1.gd` file to `type_2.gd` and rename the class name to `Type2`
5. Go back to the main scene script or run the game: The parser error will be shown

### Minimal reproduction project

[bug_unresolved_type.zip](https://github.com/godotengine/godot/files/12730971/bug_unresolved_type.zip)
Repository: next.js
Issue: App routes with utf8 names are resulting in a 404
Labels: bug

### Link to the code that reproduces this issue

https://github.com/codeurs/next-utf8-routes

### To Reproduce

```
git clone git@github.com:codeurs/next-utf8-routes.git
cd next-utf8-routes.git
yarn
yarn dev
```

1. Click on `élève`. It will result in a 404 page
2. Go back to the previous page
3. Click on `école`: it will show the école page


### Current vs. Expected behavior

**Current behaviour:**
Clicking the élève link is resulting in a 404 page because the name of the app dir is not encoded.

**Expected behaviour:**
The élève link should result in the élève page.

**Screen capture of the issue:**
![utf8-route-error](https://github.com/vercel/next.js/assets/1882256/3d50e567-9649-436c-a2ab-a6f2338e6d18)

**Current solution:**
For now it's possible to get around this issue by renaming the `élève` app dir into `%C3%A9l%C3%A8ve`, but as you can see it's terrible to read. When you have a lot of routes with specials chars there's totally no overview anymore because you don't know which dir is containing which page. EX:
![image](https://github.com/vercel/next.js/assets/1882256/b836ad82-3239-4d9e-a4c6-8d695db72b23)

**Side note:**
This issue currently only occures locally. When I deploy the code to vercel it's working as expected:
https://next-utf8-routes.vercel.app/



### 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 Fri Apr 2 22:23:49 UTC 2021
Binaries:
  Node: 18.17.1
  npm: 10.0.0
  Yarn: 1.22.19
  pnpm: N/A
Relevant Packages:
  next: 13.5.4-canary.1
  eslint-config-next: 13.5.3
  react: 18.2.0
  react-dom: 18.2.0
  typescript: 5.2.2
Next.js Config:
  output: N/A
```


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

App Router

### Additional context

_No response_
Repository: rust
Issue: `NonNull` should document that `From<&T>` and friends preserve provenance
Labels: A-docs,T-libs

The implementations of `From<&T>` and `From<&mut T>` for `NonNull<T>` preserve pointer provenance. This should be documented as a guarantee so callers can rely on it.

<!-- TRIAGEBOT_START -->

<!-- TRIAGEBOT_ASSIGN_START -->

<!-- TRIAGEBOT_ASSIGN_DATA_START$${"user":null}$$TRIAGEBOT_ASSIGN_DATA_END -->

<!-- TRIAGEBOT_ASSIGN_END -->
<!-- TRIAGEBOT_END -->
Repository: godot
Issue: GUI Button Navigation Bluetooth Gamepad Joystick Repeat
Labels: bug,platform:linuxbsd,topic:porting,topic:input

### Godot version

4.1.2-RC1

### System information

LinuxBSD

### Issue description

I noticed when using a Bluetooth controller on Steam Deck that the left joystick was repeating way too quickly for me to change gui button focus properly (Steam Deck left joystick works properly, it selects the next gui button one time when pressed up)

![Screenshot 2023-09-26 at 2 32 23 PM](https://github.com/godotengine/godot/assets/11281480/b4205f6a-9a3d-4024-8ec3-9b983d62333b)

### Steps to reproduce

Export game to Linux, on Steam Deck go into Desktop Mode, copy app image to Steam Deck, mark app image as executable, add to Steam, go back into Game Mode, connect a bluetooth controller, launch game, and navigate with left stick

### Minimal reproduction project

[Godot4_1_2_RC1_Input_Bug.zip](https://github.com/godotengine/godot/files/12731303/Godot4_1_2_RC1_Input_Bug.zip)
Repository: excalidraw
Issue: can't save Sketch if I use Arrow with text on it
Labels: package:excalidraw

Excalidraw is embedded in our application, we were using version 14 and we could draw arrow and double click in the middle of it and add text to the arrow and successfully save the sketch. However after upgrading to v15 , we can no longer save the sketch if there is an arrow with its text is in our sketch.
Could you please let us know what is changed about the arrow in version 15 and how could we fix this problem?
Are you going to fix this bug soon?
Thanks,
Samira
Repository: godot
Issue: Make anchoring presets an enum instead of being assigned based on ints. 
Labels: enhancement,discussion,topic:dotnet,topic:gui

### Godot version

4.2 Dev 5

### System information

Fedora Linux 38 (Workstation Edition)

### Issue description

Having the anchor preset be an ordered  int list  is incredibly obnoxious when trying to set up any UI stuff from code . To make matters worse the corresponding ints don't seem to be in the documentation. And don't even seem to align with the order of the anchor presets in the editor 

![Screenshot from 2023-09-26 22-26-55](https://github.com/godotengine/godot/assets/74463310/4125b63f-1fcd-46fb-a47e-9fc576d60d17)

I appreciate that changing this could be considered a breaking change most likely but it makes the development experience considerably unpleasant. The enum for this seems to exist so i'm inclined to think this was an oversight.
![Screenshot from 2023-09-26 22-35-50](https://github.com/godotengine/godot/assets/74463310/cc39404d-c032-4e5a-8df0-9dc015354aed)



### Steps to reproduce

just make a control node in a script and try and give it a preset

### Minimal reproduction project

N / A
Repository: vscode
Issue: Icon picker: Pass left and right arrow events through when at the textbox boundaries
Labels: feature-request,icons-widget

Testing #194038

I think this would feel nice if left and right did work when you have a filter, but only if they would not move the cursor:

![Image](https://github.com/microsoft/vscode/assets/2193314/28061f4c-2fc3-43ff-80de-34ff68423085)
Repository: godot
Issue: Crash (SIGABRT) on reimported .glb inherited scene save/update
Labels: bug,needs testing,topic:import,crash

### Godot version

4.1.1, 4.1.1-mono, 4.2-mono-rc5

### System information

MacOS 12.3

### Issue description

Every time I update certain .glb files I get a crash when inherited scenes save or update.

Because builds trigger saves, this means that I get ~50+ crashes a day.

The only fix is to run `Project->Reload Current Project` every time I update a .glb file.

### Steps to reproduce

1. Modify the `gas_station.blend` file in some way
2. Export it as a `.glb` - export settings should be saved, just export
3. Switch to Godot, try saving, try switching from `main.tscn` to `gas_station.tscn`
4. Repeat until crash

### Minimal reproduction project
Repro project [here](https://github.com/wjagodfrey/godot-4-glb-import-issues), and [here](https://www.youtube.com/watch?v=cRfQp_Jc824) is a video of the crash in this repo on my system. Crash happens near the one minute mark.

The repro project attached is not crashing as consistently as my main project, which crashes without fail every time certain meshes are reimported. It may take a few attempts, and you may have a little difficulty replicating. 

Because I don't know what's causing it it's quite hard to make the crash more reproducible, but I hope this will enable someone to narrow it down. Repeatedly reimporting a modified mesh for anywhere from 1-20 minutes seems to eventually trigger the crash.

[Original crash log here](https://gist.github.com/wjagodfrey/caa2eba4cb8be5aeec209ba0e828af46)
Repository: TypeScript
Issue: Misleading error message for `super.instanceProperty`
Labels: Bug,Domain: Error Messages,Rescheduled

Take the following code:

```ts
export abstract class YaddaBase {
    protected roots = "hi";
}

export class DerivedYadda extends YaddaBase {
    public get rootTests() {
        return super.roots;
    }
}
```

TypeScript nightly (5.3.0-dev.20230926) reports:

> Class field 'roots' defined by the parent class is not accessible in the child class via super.

The error message here is confusing - one might believe that this has to do with accessing a member with a protected modifier, but it is really about accessing an instance field with `super`. A better error message would be:

> 'roots' is defined as an instance property and must be accessed through 'this', not 'super'.

We can also provide a quick fix for this error message.
Repository: terminal
Issue: [1.19] Random lags on focus and unfocus
Labels: Area-Rendering,Issue-Bug,Product-Terminal,Priority-1

### Windows Terminal version

1.19.2682.0

### Windows build number

_No response_

### Other Software

_No response_

### Steps to reproduce

* Run `rainbowbench -ng`
* Focus and unfocus the application

### Expected Behavior

`rainbowbench` should show something along the lines of
```
22486 fps | 83132 kcg/s
```
or about half that on a slower CPU.

Focusing/Unfocusing doesn't randomly lag the renderer.

### Actual Behavior

```
7436 fps | 26605 kcg/s
```

and it randomly lags.
Repository: vscode
Issue: Pick a forever theme color for the quick fix highlight and allow styling both background and borders
Labels: feature-request,editor-code-actions

Testing #194072

We cover bg and border for the majority of highlights, for example:

```
		"editor.lineHighlightBorder": "#263040",
		"editor.rangeHighlightBackground": "#ffffff0d",
		"editor.selectionBackground": "#399ef440",
		"editor.selectionHighlightBackground": "#399ef420",
		"editor.wordHighlightBackground": "#00000000",
		"editor.wordHighlightBorder": "#399ef4",
		"editor.wordHighlightStrongBackground": "#00000000",
		"editor.wordHighlightStrongBorder": "#399ef4",
```

We should look into whether one of those is suitable and use that, or make our own and choose a good base to derive from. Provided there's no conflicts, I'll likely make my theme use the bright accent border I use for word highlight:

![Image](https://github.com/microsoft/vscode/assets/2193314/35031ff8-8c85-4f90-98de-4e90f42a131d)

We want to make sure that it behaves correctly when there is for example find in files, find in the current file, etc. already active.
Repository: godot
Issue: Physic glitch when using a trimesh
Labels: bug,topic:physics,topic:3d

### Godot version

v4.1.1.stable.mono.official [bd6af8e0e]

### System information

Godot v4.1.1.stable.mono - Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 6GB (NVIDIA; 31.0.15.3623) - AMD Ryzen 5 5600X 6-Core Processor (12 Threads)

### Issue description

When rolling on a trimesh collision shape using apply_central_force, the physic simulation creates a weird and intense force that pushes the ball in an incorrect direction.

https://github.com/godotengine/godot/assets/1688550/b083cd64-f45e-4a2b-a5ef-e5f2a7c1617a



### Steps to reproduce

This bug seems specific to the trimesh generated from the shape. Use the reproduction project in order to reproduce it, simply by clicking on the ramp to move the ball down. When the ball crosses the edge at the upper start of the ramp, the bug happens.

### Minimal reproduction project

[phhysicsbug.zip](https://github.com/godotengine/godot/files/12731875/phhysicsbug.zip)
Repository: vscode
Issue: Icon picker: Show icon id
Labels: feature-request,icons-widget

Testing #194038

I liked the feature, without it it's hard to know what the word is that's being searched. This will be more useful when it's used in other places/more frequently. I couldn't see a closed issue or PR talking about this decision.
Repository: go
Issue: proposal: cmd/go: allow go run to pass custom environment variables 
Labels: Proposal,GoCommand

This is a proposal to extend the syntax of the command line of `go run` to allow to pass environment variables to the program that is executed after its compilation.

The current syntax:
```
go run [build flags] [-exec xprog] package [arguments...]
```
The proposed syntax:
```
go run [build flags] [-exec xprog] [name=value ...] package [arguments...]
```

That extended syntax will be incompatible with `=` being used in the *package* (package name, `.go` file) specification. However the language reference already [mentions](https://go.dev/ref/spec#ImportPath) that a compiler implementation may exclude `=` from import paths.

# Why?

1. It is useful to be able to pass to the compiled program some environment variables with values different from the values passed to `go run` which might be needed for building the program (example: #37846)
2. `go run` is often used in `//go:generate` commands. It is often needed to pass environment variables to the program, but there is no built-in portable way for calling a command with environment variables (`env(1)` is available on Unixes, but not on Windows. Workaround: [github.com/dolmen-go/env](https://github.com/dolmen-go/env))
Repository: godot
Issue: It's possible to add theme items to empty type in Theme Editor
Labels: bug,topic:editor,topic:gui

### Godot version

4.2 251fb83

### System information

Windows 10.0.19045 - Vulkan (Forward+) - dedicated NVIDIA GeForce GTX 1060 (NVIDIA; 30.0.15.1403) - Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz (8 Threads)

### Issue description

When you create a fresh Theme, it doesn't have any type. But you can still add new items. They will exist in limbo
![image](https://github.com/godotengine/godot/assets/2223172/e3c67889-9ed7-4e7a-bb4e-99fd2ce4d359)
In theme it's stored as `/styles/test = null`.

It's not a bug per se, but once you add some type, you will lose access to the hidden empty type. You will see the elements only in the inspector. Also the hierarchy gets awkward.
![image](https://github.com/godotengine/godot/assets/2223172/1cdea9bd-7a52-4eb2-85e4-38bc497be7f6)


### Steps to reproduce

1. Add Theme to Control
2. Open Theme editor
3. Without adding any type, add some item

### Minimal reproduction project

N/A
Repository: pytorch
Issue: Skip cuda kernel launch with torch.sum when dimension length is 0
Labels: module: performance,module: cuda,triaged

### 🚀 The feature, motivation and pitch

If there is a torch tensor, e.g. `a = torch.ones([1, 1000])` and I call `a.sum(dim=0)`, torch will launch a cuda kernel for this when it's really just a view. Torch should special case this or include it inside the compiler in `torch.compile` as it is leads to significant wins in certain settings.

### Alternatives

_No response_

### Additional context

_No response_

cc @ptrblck
Repository: neovim
Issue: UI flush/redraw can happen before UI attach / UIEnter
Labels: bug,compatibility,ui,has:plan,ui-extensibility,startup,events

### Problem

I'm looking for a way to improve the startup experience of Neovide, to create the window with the correct size from the start and fix some other startup related sizing issue.

But the problem is that there does not seem to any way to ensure that all the GUI options (for example the font), all our options related to the window, (for example padding), the `lines`, `columns`, and the `colorscheme` are set. This is required in order to be able to correctly resize the window. 

If the options are set directly in `init.vim/lua` then we receive several draw batches where each one sets a single option. So, this is not good.

Setting all those options inside the `UIEnter` autocommand is a little bit better as long as none of the options are set elsewhere.

But this is totally out of the user control when using a plugin like `lazy.nvim`, which can potentially do a lot of stuff before `UIEnter`, making it basically useless for about anything. This happens for example when new plugins are installed at startup.

The workaround is to load a `ginit.vim/lua` file or similar before calling `nvim_ui_attach`. But the problem is that anyhing setup there is overwritten by what's passed to `nvim_ui_attach`. So, the only workaround I see is to get the option values manually, and then pass them on to `nvim_ui_attach`. 

I consider this a bug, and IMO `UIEnter` should always be called before anything is requested to be drawn on the screen. NOTE: the workaround of waiting for `UIEnter` before showing anything does not work, since then nothing is displayed when `lazy.nvim` installs the plugins.

### Steps to reproduce

Launch a lazy.nvim configuration with some plugins not installed.
Observe that multiple UI draw batches are received until UIEnter is called.

### Expected behavior

`UIEnter` should be called before anything is drawn.

### Neovim version (nvim -v)

0.9.2

### Vim (not Nvim) behaves the same?

N/A

### Operating system/version

Windows 11 / Arch Linux WSL

### Terminal name/version

Neovide 11.2

### $TERM environment variable

N/A

### Installation

pacman
Repository: vscode
Issue: Synonyms dialog/prompt need some love
Labels: bug,settings-editor,confirmation-pending,settings-search

Testing #194026

Searching: do you trust dialog
Results: 0

Searching: do you trust prompt
Results: 4
Repository: vscode
Issue: Command center is hard to find without name
Labels: bug,settings-editor,confirmed,settings-search

Testing #194026

Search: "search box in title bar"



![Image](https://github.com/microsoft/vscode/assets/6561887/aa70b535-fbaf-4b19-8cf2-5e2f42203a29)