sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: Creating test implementation of `AssetBundle` is tricky and will likely result in errors that are difficult to understand
Labels: tool,a: assets,P3,c: tech-debt,team-tool,triaged-tool

See https://github.com/flutter/flutter/issues/126612.

If unfamiliar with the concept of assets in Flutter, see [Adding assets and images](https://docs.flutter.dev/ui/assets-and-images).

TL;DR: There are multiple users that use fake/mock/stub implements of [`AssetBundle`](https://api.flutter.dev/flutter/services/AssetBundle-class.html) in tests. `AssetBundle` is used for loading assets in flutter apps. Nearly all assets in a bundle are ones that user chooses to include, but the framework also bundles its own asset, the asset manifest. This means that users need to handle the call to load the asset manifest in their [`load`](https://api.flutter.dev/flutter/services/AssetBundle/load.html) override, but it's unlikely that they will be aware of this (or even what the asset manifest is).

While there is perhaps a greater discussion to be had around whether or not flutter bundling files (namely the asset manifest) with an app should have the ability to break these tests, we can perhaps start with something smaller to help these users. Here are some suggestions, none of which are mutually exclusive:

* In the call to load the asset manifest, we can catch the vague `FormatException` and augment the message with a more useful note.
* Improve the documentations of `DefaultAssetBundle`, which is (probably) commonly used to provide/inject test implementations of `AssetBundle`. We could make an explicit note about how to override this for custom tests, and/or we could could consider changing the example code to look more like one of the examples on [this comment on #126612](https://github.com/flutter/flutter/issues/126612#issuecomment-1545070520) (thanks @eerive).
Repository: next.js
Issue: middleware rewrite and tailwind.css
Labels: bug,Runtime

### Verify canary release

- [X] I verified that the issue exists in the latest Next.js canary release

### Provide environment information

```bash
latest of all
```


### Which area(s) of Next.js are affected? (leave empty if unsure)

Middleware / Edge (API routes, runtime)

### Link to the code that reproduces this issue

none

### To Reproduce

create an middleware.ts and make an rewrite if a specific cookie is not there.

`let hasCookie = request.cookies.get('access-cookie')?.value

    if (hasCookie) {
        console.log('access granted')
    } else {
      rewrite to /login
    }
}`

### Describe the Bug

The rewrite works, but no css is loading.

### Expected Behavior

load tailwind css.

### Which browser are you using? (if relevant)

_No response_

### How are you deploying your application? (if relevant)

_No response_
Repository: flutter
Issue: Make internationalization files easier to update
Labels: c: new feature,framework,a: internationalization,P2,team-framework,triaged-framework

By reading the documentation of Internationalization I have to create manually all the `intl_*lang*.arb` files. But once it's done and I need to update my translation (example I removed and/or added screens), how can I update the localisations ? What's the procedure in that case ? 

Because having to manually search for the new messages into `intl_messages.arb` and after add them into each `intl_*lang*.arb` is not really an option... 

Having the Intl package that merge all the translation and add/remove/update for all langage.
On angular the i18n tool is doing it and I find it really cool to work with.
Repository: rust
Issue: Allow numeric tokens containing 'e' that aren't exponents be passed to proc macros
Labels: A-grammar,T-lang,T-compiler,C-feature-request,A-proc-macros,I-lang-nominated,I-lang-easy-decision

I tried this code:

```rust
// This could also be a complex proc macro
macro_rules! print_token {
    ($x:tt) => { println!("{}", stringify!($x)) }
}

fn main() {
    print_token!(123aefg123);  // ok, unknown suffix
    print_token!(123e123); // ok: float literal
    
    print_token!(123ef3); // error:  expected at least one digit in exponent
}
```

I expected to see this happen:  It should compile in print the token verbatim. If unkown/invalid suffix are OK, so should invalid float, because the macro DSL my use it for something else


Instead, this happened: Compilation error :
```
error: expected at least one digit in exponent
  --> src/main.rs:11:18
   |
11 |     print_token!(123ef3); // error:  expected at least one digit in exponent
   |                  ^^^^^^
```

(tested with Rust 1.69 as well as current nightly,  this always has been a problem)


### Context

This was discussed with @nnethercote and others last week and I wanted to make sure there is a track of this.

The usecase is so that Slint's color literal work in the `slint!` maco DSL.
Currently one can do `color: #0e9` but not `color:#0ea` in the slint! macro.  And Makepad DSL has to workaround the same issue.
Repository: flutter
Issue: Avoid objective-C RTTI (Run-Time Type information) code in engine
Labels: platform-ios,engine,platform-mac,P3,team-ios,triaged-ios

We shy away from RTTI-ish things in the engine. We should try to do the same for Objective-Code, such as `isKindOfClass` type checks.
Reasoning: https://google.github.io/styleguide/cppguide.html#Run-Time_Type_Information__RTTI_ 

An example: https://github.com/flutter/engine/blob/main/shell/platform/darwin/ios/framework/Source/FlutterViewController.mm#L1626
Repository: flutter
Issue: Add ability to easily get semantic label of the currently-focused widget in tests
Labels: a: tests,c: new feature,framework,c: proposal,f: focus,P2,team-framework,triaged-framework

### Is there an existing issue for this?

- [X] I have searched the [existing issues](https://github.com/flutter/flutter/issues)
- [X] I have read the [guide to filing a bug](https://flutter.dev/docs/resources/bug-reports)

### Use case

In some tests, I'd like to be able to confirm that the focus ends up on the right widget. One way I've been doing is:

```dart
final expectFocusedButton = find.bySemanticsLabel(expectFocused);
expect(expectFocusedButton, findsOneWidget);
// Expect the given button to receive focus.
expect(Focus.of(tester.element(expectFocusedButton)).hasFocus, true);
```

But the error is not great when the focus is not where I expect or the semantic label changes:

```
Expected: exactly one matching node in the widget tree
  Actual: _DescendantFinder:<zero widgets with element matching predicate (Closure: (Element) => bool from: element => {
    let t$3641;
    if (!framework.RenderObjectElement.is(element)) {
      return false;
    }
    let semanticsLabel = (t$3641 = element.renderObject.debugSemantics, t$3641 == null ? null : t$3641.label);
    if (semanticsLabel == null) {
      return false;
    }
    return core.RegExp.is(label) ? label.hasMatch(semanticsLabel) : label[S.$_equals](semanticsLabel);
  }) that has ancestor(s) with type "OnScreenKeyboardButtonPopup" (ignoring offstage widgets)>
  Which: means none were found but one was expected
```

Through some trial and error and [looking at `find.bySemanticsLabel`][1], I figured out this alternative:

[1]: https://github.com/flutter/flutter/blob/41abe998ee37fb70fb3c86c5c2bbc3dcf2f1302c/packages/flutter_test/lib/src/finders.dart#L450

```dart
final focusedButton = tester.element(find
    .byElementPredicate((element) =>
        element.renderObject?.debugSemantics?.label != null &&
        (Focus.maybeOf(element)?.hasFocus ?? false))
    .first)
expect(focusedButton.renderObject?.debugSemantics?.label, expectFocused);
```

This gives much better errors on failure since it points out the semantic label of the element actually focused. (That being said, I'm not sure how efficient calling `Focus.maybeOf(element)` is on a bunch of nodes.)

### Proposal

Could we have something more official to address this need? At first, I thought that we could add the

```dart
.byElementPredicate((element) =>
    element.renderObject?.debugSemantics?.label != null &&
    (Focus.maybeOf(element)?.hasFocus ?? false))
```

part as a method to `Finder`, but (1) it returned 2 elements for my perticular use-case (hence to `.first` above), and (2) it still requires the user to then assert against `focusedButton.renderObject?.debugSemantics?.label`, which is not obvious (very discoverable) at all.

Alternatively, the framework could add `tester.semanticLabelForFocusedElement()` which does the find and returns the `focusedButton.renderObject?.debugSemantics?.label`, but such an API seems very specific, so I'm not sure.
Repository: flutter
Issue: Provide guidance for customers about error recovery in release mode
Labels: framework,engine,d: api docs,P2,customer: chalk (g3),team-engine,triaged-engine

Internal: b/374884064

Flutter avoids crashing in development mode so that hot reload/restart workflows are usable.

An application may prefer crashing when in end-user facing builds, and some application developers have provided feedback to me that mobile development on other platforms do in fact crash more eagerly when reaching an unknown state. In particular, it may be difficult or impossible to enumerate all unknown states and deciding which ones are recoverable or not. We do tend to provide error handling callbacks to things like `Image.foo` where an application does want to recover from e.g. a corrupted image served over the network.

We should provide documentation and guidance about how to do this in a safe/sane way. In particular, the engine team has seen that calling `exit` can cause unexpected additional exceptions if the engine has not been cleanly shut down. The current implementation of a Google-internal plugin calls `exit` explicitly to intentionally crash the application.

/cc @zanderso @chinmaygarde @jason-simmons for engine
/cc @goderbauer for framework
Repository: react-native
Issue:  FlatList with sticky ListHeaderComponent, stickyHeaderIndices, onViewableItemsChanged gives incorrect viewableItems #31109 
Labels: Issue: Author Provided Repro,Component: FlatList,Needs: Triage :mag:,Newer Patch Available

### Description

exactly this issue: https://github.com/facebook/react-native/issues/31109. this is still a problem.

---

using FlatList with stickyHeaderIndices, viewabilityConfigCallbackPairs, and ListHeaderComponent, when scrolling the list onViewableItemsChanged is called. the viewableItems includes items that are behind (not viewable) the sticky list header.

```jsx
const viewabilityConfig = {
  minimumViewTime: 1000,
  waitForInteraction: true,
  itemVisiblePercentThreshold: 100,
}

const onViewableItemsChanged = React.useCallback(
  ({ viewableItems, changed }) => {
    console.log('viewableItems', viewableItems)
    console.log('changed', changed)
  },
  []
)

const viewabilityConfigCallbackPairs = React.useRef([
  { viewabilityConfig, onViewableItemsChanged },
])

<FlatList
  stickyHeaderIndices={[0]}
  viewabilityConfigCallbackPairs={viewabilityConfigCallbackPairs.current}
  ListHeaderComponent={() => <MyListHeader/>}
/>
```

### React Native Version

0.71.7

### Output of `npx react-native info`

System:
    OS: macOS 12.6
    CPU: (10) arm64 Apple M1 Pro
    Memory: 509.05 MB / 32.00 GB
    Shell: 5.8.1 - /bin/zsh
  Binaries:
    Node: 16.18.1 - ~/.asdf/installs/nodejs/16.18.1/bin/node
    Yarn: 1.22.19 - ~/.asdf/installs/nodejs/16.18.1/bin/yarn
    npm: 8.19.2 - ~/.asdf/plugins/nodejs/shims/npm
    Watchman: Not Found
  Managers:
    CocoaPods: 1.11.3 - /Users/ty/.asdf/shims/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 21.4, iOS 16.0, macOS 12.3, tvOS 16.0, watchOS 9.0
    Android SDK: Not Found
  IDEs:
    Android Studio: 2021.3 AI-213.7172.25.2113.9123335
    Xcode: 14.0.1/14A400 - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.17 - /usr/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0 
    react-native: 0.71.7 => 0.71.7 
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

### Steps to reproduce

1. drag the list so that the 2nd item is the first in the list
1. observe the viewableItems

### Snack, code example, screenshot, or link to a repository

https://snack.expo.io/@tantommy/intelligent-churros
Repository: pytorch
Issue: Enhance FSDP debugability
Labels: oncall: distributed,triaged,module: fsdp

### 🚀 The feature, motivation and pitch

Some items we can add under torch_distributed_debug mode to improve debugability of FSDP:

- Shared parameter detection
- Logging when backward hooks are fired (per parameter or per individually wrapped FSDP unit), to debug convergence / parity with DDP issues
- These should also work with the composable API.

### Alternatives

_No response_

### Additional context

_No response_

cc @mrshenli @pritamdamania87 @zhaojuanmao @satgera @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu
Repository: vscode
Issue: Empty environment variables passed to vscode are unset
Labels: bug,upstream,electron,workbench-cli

This is a continuation of #174330 which is now locked and doesn't accept comments.
The original report was filed by our Go extension users who observed empty env vars were
not reflected when they run/debug tests using the extension's feature.
The issue was closed with #175682, which fixed env handling in the term env.

However, the Go extension features (run/debug tests) actually use extension host's `process.env` directly. So, the term environment fix doesn't help the original issue users are facing. (https://github.com/golang/vscode-go/issues/2745)

I prepared a repro in https://github.com/microsoft/vscode-extension-samples/compare/main...hyangah:vscode-extension-samples:main#diff-665767c0f91ad3e1e028cc5dd145783e8ecaef232aefdb222ba9590b6bd52ba1

Either use the launch config in the commit, or 

1) cd getting-started-sample
2) vsce package
3) code-insiders --install-extension=getting-started-sample-0.0.1.vsix
4) EMPTY_VAR="" NONEMPTY_VAR="nonempty" code-insiders 
5) Select "Getting Started Sample: Say Hello" from command palette. Check the console log, using "Developer: Toggle Developer Tools". 

code-insiders (Version: 1.79.0-insider (Universal) Commit: 9084e081d4e89ed8ab67fce340d573c4e1378939) gives me 
<img width="642" alt="Screenshot 2023-05-15 at 5 16 48 PM" src="https://github.com/microsoft/vscode/assets/4999471/ace6fb32-a632-42db-a3db-d0d3540fb403">

You can see that EMPTY_VAR is undefined. 

Is there a recommended way for extensions to get the process environment other than `process.env`?
Does the node debugger avoid this issue in https://github.com/microsoft/vscode/issues/174330#issuecomment-1431541396 because the debugger/debugee is launched from a terminal?
Repository: storybook
Issue: [Feature Request]: A way to pass docgen options for JS projects
Labels: feature request,good first issue,help wanted,sev:S3

### Is your feature request related to a problem? Please describe

In mono repo where package paths do not live always under node_modules, docgen is running and breaking imported packages by modifying underlying object in undesirable ways.

### Describe the solution you'd like

Ability to pass an options object to docgen for configuration so that one can include, or exclude paths.

Looking at this code it looks like the plugin could easily take some configuration and pass it to reactDocgen, rather than using a string. 
https://github.com/storybookjs/storybook/blob/9655d80efa4681cbac18671f30ecf09de95688d7/code/frameworks/react-vite/src/preset.ts#L48-L57

### Describe alternatives you've considered

I tried using node module resolvers to resolve packages to a node_modules folder but that created other problems.

Update: I ended up resolving this issue by adding this to my main js:
```js
  async viteFinal(config) {
    // Override the default docgen handler for mono repo, so we can exclude more paths than just node_modules
    config.plugins[0] = reactDocgen({
      include: /\.(mjs|jsx?)$/,
      exclude: [/node_modules\/.*/, /packages\/.*/]
    })
    return config;
  },
```
Had to copy the docgen plugins from your repo, and convert the so they are not type script. Another solution would be to export the reactDocgen plugin, so that people do not have to copy it into their code bases to pass a parameter to it. 

### Are you able to assist to bring the feature to reality?

no

### Additional context

_No response_
Repository: react-native
Issue: react-native inspector not Showing component file name and it's line number
Labels: Needs: Triage :mag:,Newer Patch Available

### Description

After updating to latest react native 0.71.7, not able to see component file name and with it's code line number.

 

### React Native Version

0.71.7

### Output of `npx react-native info`

System:
    OS: macOS 13.3.1
    CPU: (10) x64 Apple M1 Pro
    Memory: 13.20 MB / 16.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 18.13.0 - ~/.nvm/versions/node/v18.13.0/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 8.19.3 - ~/.nvm/versions/node/v18.13.0/bin/npm
    Watchman: Not Found
  Managers:
    CocoaPods: 1.12.1 - /usr/local/bin/pod
  SDKs:
    iOS SDK:
      Platforms: DriverKit 22.4, iOS 16.4, macOS 13.3, tvOS 16.4, watchOS 9.4
    Android SDK: Not Found
  IDEs:
    Android Studio: 2022.2 AI-222.4459.24.2221.9862592
    Xcode: 14.3/14E222b - /usr/bin/xcodebuild
  Languages:
    Java: 11.0.18 - /Library/Java/JavaVirtualMachines/openlogic-openjdk-11.jdk/Contents/Home/bin/javac
  npmPackages:
    @react-native-community/cli: Not Found
    react: 18.2.0 => 18.2.0
    react-native: 0.71.7 => 0.71.7
    react-native-macos: Not Found
  npmGlobalPackages:
    *react-native*: Not Found

### Steps to reproduce

Step to reproduce : 
go to app press D , will see a inspector option.
then inspect any element, observe only react native component are showing. we are not able to comment file name and code line number.

please help here.

### Snack, code example, screenshot, or link to a repository

![Untitled](https://github.com/facebook/react-native/assets/25655346/0906a584-e233-4c4b-adbd-151500e8fc65)
no file name and code line is there.i have scroll to it's edge also no file name with line was present.
please help here
Repository: terminal
Issue: AtlasEngine: Text rendering differences between Direct2D and Direct3D
Labels: Area-Rendering,Issue-Bug,Product-Terminal,Area-AtlasEngine

The Direct3D based text renderer is the default, but the Direct2D based on is used when the device has a GPU without support for shader model 4 (usually GPUs below feature level 10.1), or no GPU at all (for instance when connecting to headless, GPU-less servers over RDP).

In that case the following differences occur, because the Direct2D text renderer is less feature-complete:
* [ ] The margins around the viewport ("gutters") are drawn in the same background color as the nearest cell and not in the overall background color of the terminal. This is because Direct2D lacks support for `D3D11_TEXTURE_ADDRESS_BORDER` which we'd need when drawing the background bitmap.
* [ ] Text on top of the cursor is not always visible / readable. Intersecting glyphs with the cursor rectangle was deemed too difficult and CPU intensive to implement for now. Direct2D doesn't expose the boundaries of each individual glyph in a glyph run after all.
* [ ] Ligatures spanning cells with different foreground colors are drawn in the color of the first cell. Same as for the previous point, intersecting and splitting up glyphs is non-trivial with Direct2D and might hurt performance.
* [ ] Box drawing glyphs are not clipped to their cells, and so they might overlap to produce unsightly results like this: ![comparison](https://github.com/microsoft/terminal/assets/2256941/58c5e8ae-ee56-4e59-ac26-ee2be2e5e007)
      This has the same problem as cursors/ligatures.
* [ ] Soft font support. This would be easy to add in a future version if need be.
Repository: TypeScript
Issue: Experiment with Parallelized Parsing
Labels: Suggestion,Domain: Performance,Experimentation Needed,Rescheduled

Before TypeScript can respond to any semantic query (accurately), the entire program has to be loaded into memory, parsed, and bound. Parsing today ends up taking a surprising amount of time, and even if we don't have to do any path resolution. One of the things we could exploit is that parsing any two files should (ideally) be independent operations - and so one could imagine spinning up multiple processes or workers to divide and conquer the problem. 

Unfortunately, program construction is not an [embarrassingly parallelizable](https://en.wikipedia.org/wiki/Embarrassingly_parallel) step because we don't always know the full list of files in a program ahead of time; however, one could imagine some work-stealing scheme with single orchestrator.

A glaring problem for TypeScript is that it is currently synchronous from end-to-end, and most worker capabilities are built with an expectation of asynchronous communication (and often depend on the surrounding environment - Node.js main thread, UI thread in the browser, non-UI worker threads, etc.). Another problem is that while we might be able to divide and conquer, the overhead of moving data between workers might be more than we'd have anticipated. And one last concern I'll mention is that while running multiple workers gets more work done faster, it's not a free lunch - it has UX tradeoffs because multiple threads can degrade the responsiveness of the overall machine.

So in the coming months, we'll be investigating here, finding out what works, and seeing if we can bring it into TypeScript itself.
Repository: pytorch
Issue: Regression in NCCL error handling
Labels: oncall: distributed

### 🐛 Describe the bug

There is a regression in NCCL error handling after https://github.com/pytorch/pytorch/pull/97066 on PyTorch master. If one rank of a training job is killed/dies, some ranks of a training job get stuck with this traceback of the workCleanupLoop:

```
Thread 9 (Thread 0x1554539fc700 (LWP 153338)):
#0  0x0000155520c47cdc in ?? () from lib/libcudart.so.11.0
#1  0x0000155520c14bde in ?? () from lib/libcudart.so.11.0
#2  0x0000155520c4a915 in cudaGetLastError () from lib/libcudart.so.11.0
#3  0x00001555097933b5 in c10d::ProcessGroupNCCL::WorkNCCL::finishedGPUExecutionInternal() const () from lib/python3.8/site-packages/torch/lib/libtorch_cuda.so
#4  0x0000155509794008 in c10d::ProcessGroupNCCL::WorkNCCL::isCompleted() () from lib/python3.8/site-packages/torch/lib/libtorch_cuda.so
#5  0x0000155509793a25 in c10d::ProcessGroupNCCL::workCleanupLoop() () from lib/python3.8/site-packages/torch/lib/libtorch_cuda.so
#6  0x000015552081aa93 in std::execute_native_thread_routine (__p=<optimized out>) at ../../../../../libstdc++-v3/src/c++11/thread.cc:82
#7  0x00001555554f5609 in start_thread (arg=<optimized out>) at pthread_create.c:477
#8  0x00001555552b4133 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```

Basically the `workCleanupLoop` is stuck on `cudaGetLastError` which is blocked since NCCL kernels are locking up the GPU. As a result, `workCleanupLoop` never gets a chance to `abort` the communicators and recover. This is essentially the potential issue reported in https://github.com/pytorch/pytorch/pull/97066#discussion_r1164692531. I was able to reliably reproduce the issue on a job with 24 ranks and manually killing one rank. After this 9 ranks did not exit and were stuck with the traceback above.

As mentioned in https://github.com/pytorch/pytorch/pull/97066#discussion_r1164692531, we should probably add a separate lightweight thread whose sole responsibility is to abort NCCL kernels that run into errors. 

### Versions

PyTorch: master
CUDA: 12.0
NCCL: 2.17.1

cc @mrshenli @zhaojuanmao @satgera @rohan-varma @gqchen @aazzolini @osalpekar @jiayisuse @H-Huang @kwen2501 @awgu