sharjeelyunus/github-issues-dataset huggingface dataset:
Repository: flutter
Issue: flutter_markdown blockquoteDecoration does not respect dark theme
Labels: package,team-ecosystem,P3,p: flutter_markdown,triaged-ecosystem

Hello

blockquote background does not respect dark theme. It has hardcoded color:  `Colors.blue.shade100`
see https://github.com/flutter/packages/blob/master/packages/flutter_markdown/lib/src/style_sheet.dart
lines 118-121:

```
      blockquoteDecoration: BoxDecoration(
        color: Colors.blue.shade100,
        borderRadius: BorderRadius.circular(2.0),
      ),
```

I guess code to reproduce the issue and further comments are not needed because everything is obvious from the code.
Even my flutter doctor doesn't matter because the code block above is from current master branch.
Repository: godot
Issue: Shader does not accept uniform expressions
Labels: enhancement,discussion,topic:shaders

<!-- Please search existing issues for potential duplicates before filing yours:
https://github.com/godotengine/godot/issues?q=is%3Aissue
-->

**Godot version:**
3.3


**OS/device including version:**
Arch Linux


**Issue description:**

Shader does not accept uniform expressions.

```
// ok
const float c = 1.0 / sqrt(2.0);

// Expected constant expression after '='
uniform float u = 1.0 / sqrt(2.0);
```
Repository: storybook
Issue: Core: Filtered story mode
Labels: feature request,performance issue,core

Storybooks can be quite large. We should make it easy to:
- [ ] Dev/build storybooks with limited stories => faster builds, smaller bundles
- [ ] Load already-built storybooks with limited stories => faster loads of existing builds, e.g. for embeds

## Strawman

**Filtered dev/build**

```sh
yarn storybook --story-filter="some-component--*"
```

**Filtered load**

```sh
open https://path-to-storybook/?path=/some/path&storyFilter=some-component--*
```
Repository: electron
Issue: [Feature Request]: Option to use Sparkle for Electron Updating
Labels: enhancement :sparkles:

### Preflight Checklist

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

### Problem Description

It seems the current state of [Electron updaters for private use](https://www.electronjs.org/docs/tutorial/updates#deploying-an-update-server) (other than `update.electronjs.org`) are extremely out of date, even after the Electron team [migrated away from Sparkle to Squirrel](https://github.com/electron/electron/issues/160) and called it ["abandoned"](https://github.com/electron/electron/issues/160#issuecomment-32703634)

Nuts – Has not been supported or actively maintained since 2017 being the last commit even though it looks like the easiest option.

Hazel – Uses the old ZEIT Now service (Now Vercel) and doesn't support Apple Silicon builds, it all seems broken and out of date.

electron-release-server – Is far too complex and complicated for hosting an update server and does not use GitHub releases and requires a database.

Nucleus – The same thing as electron-release-server and not as simple to use as Hazel, plus looks very specific to Atlasssian's needs.

Most of these updaters either are too complex, out of date, are not maintained and is just too broken to use as the server hangs waiting for the file to download as I reported in Hazel.

### Proposed Solution

For both Mac and Windows another option is to use [Sparkle](https://sparkle-project.org/) & [WinSparkle](https://winsparkle.org/) which has been the standard updater for Mac and even supports Windows. 

I would like this to be an option, to use either Squirrel or Sparkle as the updater for my electron app, such that I don't need a dedicated server like Hazel, Nuts, Nucleus etc. 

With Sparkle I only need an S3 bucket and an RSS feed.


### Alternatives Considered

Writing YAEU (Yet Another Electron Updater) Or Manual Zip File.

### Additional Information

Since the Electron Team called Sparkle ["abandoned"](https://github.com/electron/electron/issues/160#issuecomment-32703634) it has now been maintained by the Sparkle Team, clearly **not abandoned** and in use with many apps.

It is worth considering using Sparkle again for Electron apps to make updating electron app easier than the now outdated solutions like Hazel, Nuts, Nucleus etc.
Repository: transformers
Issue: Felix
Labels: New model

# 🌟 New model addition

## Model description

New model released by [google](https://github.com/google-research/google-research/tree/master/felix)

## Open source status

* [x] the model implementation is available: https://github.com/google-research/google-research/tree/master/felix
* [x] the model weights are available: https://github.com/google-research/google-research/tree/master/felix (pretrained `bert-base-cased` can be used)
* [x] who are the authors: @Jmallins
Repository: go
Issue: x/tools/go/analysis/analysistest: analysistest.Run failing with modules
Labels: NeedsInvestigation,modules,Tools

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
go version go1.15.7 darwin/amd64
analysistest v0.1.0

</pre>

### Does this issue reproduce with the latest release?
yes


### What operating system and processor architecture are you using (`go env`)?

<details><summary><code>go env</code> Output</summary><br><pre>
$ go env

</pre></details>

### What did you do?
I have built a clean architecture go/analysis linter which works pretty well. However, when I was trying to run analysistest on complex test cases with lots of imports it was failing.

analysistest.Run(t, analysistest.TestData(), cleanarch.Analyzer, c.Pattern)

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->


### What did you expect to see?
analysistest working does not fail with modules used in test data files


### What did you see instead?
valid-simple/pkg/questions/adapter/http_adapter.go:4:2: cannot find package "github.com/$ORGNAME/$REPO/cleanarch/testdata/valid-simple/pkg/questions" in any of:
	/usr/local/Cellar/go/1.15.7_1/libexec/src/github.com/$ORGNAME/$REPO/cleanarch/testdata/valid-simple/pkg/questions (from $GOROOT)
	/Users/$USER/IdeaProjects/$PRJ/cleanarch/testdata/src/github.com/$ORGNAME/$REPO/cleanarch/testdata/valid-simple/pkg/questions (from $GOPATH)

I determine the root cause is: ["GO111MODULE=off", "GOPROXY=off"](https://github.com/golang/tools/blob/fe37c9e135b934191089b245ac29325091462508/go/analysis/analysistest/analysistest.go#L321) introduced in change: https://github.com/golang/tools/commit/211dcd1cef82d4dbfb19179d0694fa0dc9207ef1 

What puzzled me is that analysis itself worked perfectly, however, I determined modules are not disabled in the main path: https://github.com/golang/tools/blob/fe37c9e135b934191089b245ac29325091462508/go/analysis/internal/checker/checker.go#L152 

When I reverted change locally it worked like a charm for me. Let me know if I can just make a PR to resolve this issue once and for all.
Repository: next.js
Issue: Fastify: next.js attempts (and fails) to consume a request body that's already been consumed by Fastify
Labels: good first issue,examples

**NOTE: this description was updated on Dec 14th, 2022 to reflect modern repro details**

### What version of Next.js are you using?

13.0.6

### What version of Node.js are you using?

16.16.0

### What browser are you using?

Chrome

### What operating system are you using?

macOS

### How are you deploying your application?

custom server (fastify 4.10.2)

### Describe the Bug

When using Fastify as a custom web server, performing a `POST` to a Next.js `/api` route results in a `400 Invalid body` response.

### Expected Behavior

The API handler is allowed to process the request.

### To Reproduce

1. Clone this repo: https://github.com/chrskrchr/next-js-api-body-bug
2. Run `npm install` (Node v16)
3. Run `npm run dev`
4. Run this command:
    - `curl -v -POST -H "Content-Type: application/json" -d '{"ping":true}' http://localhost:3000/api/test`

You should see a `400 Invalid Body` response like the following:

```
*   Trying 127.0.0.1:3000...
* Connected to localhost (127.0.0.1) port 3000 (#0)
> POST /api/test HTTP/1.1
> Host: localhost:3000
> User-Agent: curl/7.84.0
> Accept: */*
> Content-Type: application/json
> Content-Length: 13
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Invalid body
< Date: Wed, 14 Dec 2022 13:19:46 GMT
< Connection: keep-alive
< Keep-Alive: timeout=72
< Transfer-Encoding: chunked
<
* Connection #0 to host localhost left intact
Invalid body%  
```

Uncomment the no-op content parser in `server.ts` to work around the issue.
Repository: opencv
Issue: cv::dnn ABI changes between minor versions (i.e. 4.5.0 -> 4.5.1 -> 4.5.2) without soname changes
Labels: feature,category: build/install

The ABI of the DNN module apparently changed between 4.5.0 and 4.5.1 due to

https://github.com/opencv/opencv/commit/23baf1a75e1fd70e300769654afec0024047fe7b

There was another ABI version bump between 4.5.1 and 4.5.2:

https://github.com/opencv/opencv/pull/19657/commits/a823b06fa5afd0a1c42f032f00a5169bf8ddef1e#diff-635059e6e33138c5734e926dfbb7355b08ce112d9ec542313f0377761bf00da6

Both ABI changes where not mentioned in the [Changelog](https://github.com/opencv/opencv/wiki/ChangeLog#version452)

Is the DNN ABI expected to break between minor versions?

Iff the ABI expected to break, probably something like the following should be used:

`set_target_properties(${dnn_module}
    SOVERSION "${OPENCV_SOVERSION}_${DNN_ABIVERSION}"
`

##### System information (version)
- OpenCV => 4.5.1
- Operating System / Platform => Linux
- Compiler => GCC 11

##### Detailed description

##### Issue submission checklist

 - [x] I report the issue, it's not a question
 - [x] I checked the problem with documentation, FAQ, open issues,
       forum.opencv.org, Stack Overflow, etc and have not found solution
 - [ ] I updated to latest OpenCV version and the issue is still there
 - [ ] There is reproducer code and related data files: videos, images, onnx, etc
Repository: vscode
Issue: Cursors are not merged in this case
Labels: bug,editor-multicursor

* configure `"editor.multiCursorMergeOverlapping": false` 
* click inside a word
* press cmd+d

![image](https://user-images.githubusercontent.com/5047891/117477395-40918f80-af5e-11eb-9313-8f772d41ec50.png)
Repository: create-react-app
Issue: Support for module using exports instead of main
Labels: stale,needs triage

Hi !

I use the[ ky ](https://github.com/sindresorhus/ky) library and since their latest release i have trouble to use it with CRA. I already fill an issue inside the repository https://github.com/sindresorhus/ky/issues/340 and they ask if it couldn't come from  CRA itself ?

Does CRA support package using `exports` instead of `main` ? If CRA does support this feature, is there any limitations ?because the problem seems to come because they use subdirectories inside export 

Sorry if i didn't use the good "Issue" mode i'm not really sure which categorie it belongs.
Repository: go
Issue: testing: Ambiguous error message for wrong `-benchtime` value
Labels: NeedsFix,GoCommand

<!--
Please answer these questions before submitting your issue. Thanks!
For questions please use one of our forums: https://github.com/golang/go/wiki/Questions
-->

### What version of Go are you using (`go version`)?

<pre>
$ go version
go version go1.16.4 linux/amd64
</pre>

I also checked go1.14 and go1.15 by docker image.
### Does this issue reproduce with the latest release?
I guess. I tested with go 1.16.4 docker image(which was built 15 hours ago) and the ambiguous error message was reproduced.


### What operating system and processor architecture are you using (`go env`)?

I think `go env` doesn't matter so I skip this question.

### What did you do?

<!--
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
-->
I tried to repeat benchmark for specific times. I saw there is a flag to set the number of repetition ago but didn't remember how to use it exactly so I just tried `-benchtime 1` to execute the benchmark only once.

```go
# main_test.go
package main

import "testing"

func BenchmarkDummy(b *testing.B) {
    for i := 0; i < b.N; i++ {    }
}
```
```shell
$ go test -bench=. -benchtime 1
go test -bench=. -benchtime 1
invalid value "1" for flag -test.benchtime: invalid duration
Usage of /tmp/go-build191827203/b001/me.test:
  -test.bench regexp
        run only benchmarks matching regexp
  -test.benchmem
        print memory allocations for benchmarks
  -test.benchtime d
        run each benchmark for duration d (default 1s)
  -test.blockprofile file
        write a goroutine blocking profile to file
  -test.blockprofilerate rate
        set blocking profile rate (see runtime.SetBlockProfileRate) (default 1)
  -test.count n
        run tests and benchmarks n times (default 1)
 ... // I left out other logs.
exit status 2
FAIL    me      0.001s
```
### What did you expect to see?
I think the error message should let users know the `iteration count` feature of `benchtime` flag.
```
invalid value "1" for flag -test.benchtime or -benchtime: invalid duration or iteration count.
benchtime should be the duration (e.g. ms, s) or the iteration count(e.g. 1x, 100x).
Usage of /tmp/go-build191827203/b001/me.test:
...
  -test.benchtime d
        d can be duration or iteration count(default 1s).
        if d is duration, run each benchmark for duration d.
        else if d is iteration count, run each benchmark iterating for d.
...
```
### What did you see instead?
I pasted the log above.
### My additional explanation

The error log said "invalid value "1" for flag -test.benchtime: invalid duration". But `benchtime` flag can be either duration or iteration count. This ambiguity of `benchtime` flag has also been introduced in #32051 and robpike hadn't been aware of the feature of `benchtime` flag as iteration count.

The iteration count feature of `benchtime` flag was introduced in 1.12 but I think the error message didn't reflect on the update.
Repository: rust
Issue: `doc_cfg` does not have a correct effect on `use` items referencing other public items
Labels: T-rustdoc,B-unstable,C-bug,F-doc_cfg

Consider the following code:

```rust
#[doc(cfg(feature="include_file"))]
pub mod include_file {
    pub fn generated() {}
}

pub use include_file::*;
pub use include_file::generated;
pub use include_file::generated as renamed;
```

The produced documentation looks like this:

![An image of rustdoc output for the crate root, showing 3 reexports, `use include_file::*` which has a doc_cfg badge, and `use include_file::generated` as well as `use include_file::generated as renamed` which don't](https://user-images.githubusercontent.com/679122/117484130-323f7580-af56-11eb-8a0a-cf4b0a60eeb1.png)

I think we should be showing the doc_cfg badge consistently here: either on all of the re-exports or none of them. I would probably lean towards "none" in this particular case, in part because it would be easier to implement properly situations where re-exports don't share the features of the modules that are being re-exported. For instance:

```rust
#[doc(cfg(feature="include_file"))]
pub mod include_file {
    pub fn generated() {}
}
#[doc(cfg(feature="reexport_glob"))]
pub use include_file::*;
#[doc(cfg(feature="reexport_generated"))]
pub use include_file::generated;
#[doc(cfg(feature="reexport_renamed"))]
pub use include_file::generated as renamed;
```

which generates exactly the same documentation page as shown above. I believe in this case we should show exactly the specified `cfg` badges, rather than attempting to infer from what items are being re-exported.

(related https://github.com/rust-lang/rust/issues/83428, https://github.com/rust-lang/rust/issues/43781)
Repository: TypeScript
Issue: Improve code formatting for inferred type signatures on hover in VSC
Labels: Suggestion,In Discussion

# Suggestion

<!--
  Please fill in each section completely. Thank you!
-->

## 🔍 Search Terms

VSC, code formatting, prettier, type signature, hover, inferred types

## ✅ Viability Checklist

My suggestion meets these guidelines:

* [x] This wouldn't be a breaking change in existing TypeScript/JavaScript code
* [x] This wouldn't change the runtime behavior of existing JavaScript code
* [x] This could be implemented without emitting different JS based on the types of the expressions
* [x] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, new syntax sugar for JS, etc.)
* [x] This feature would agree with the rest of [TypeScript's Design Goals](https://github.com/Microsoft/TypeScript/wiki/TypeScript-Design-Goals).


## ⭐ Suggestion

In VSC when hovering over a code element (e.g. a function call) it displays the definition of the code element (e.g. the function signature) combined with the inferred types. 

### Problem

For simple code elements (e.g. variables) the displayed result is usually easy to read but for more complex code elements (e.g. complex function definitions) the displayed definition gets hard to read.

e.g. here's what I see when hovering over `T.catchAllCause` (see source)

<img width="841" alt="image" src="https://user-images.githubusercontent.com/1567498/117485803-214c2f80-af69-11eb-9083-03568089fecc.png">

For reference this is [the corresponding source code](https://github.com/Effect-TS/core/blob/5cee96bd86965cd50fff5026390bd9a26f3aaf17/packages/system/src/Effect/catchAllCause.ts#L23) (when I jump to definition) which is properly formatted:

```ts
/**
 * Recovers from all errors with provided cause.
 *
 * @dataFirst catchAllCause_
 */
export declare function catchAllCause<R2, E2, A2, R, E, A>(
  f: (_: Cause<E2>) => Effect<R, E, A>,
  __trace?: string
): (effect: Effect<R2, E2, A2>) => Effect<R2 & R, E, A2 | A>
```

### Solution suggestion

It would be great if the rendered code definition were formatted/pretty printed to make it easier to read (or apply the original code formatting of the definition).

Here's an annotated version of my suggestion based on what I'm seeing when holding down the <kbd>CMD</kbd> key.

![CleanShot 2021-05-07 at 19 30 27@2x](https://user-images.githubusercontent.com/1567498/117487382-5063a080-af6b-11eb-8460-2e1c24c32637.png)
Repository: rust
Issue: `#[link_section]` does not work in libraries on release
Labels: A-linkage,A-codegen,T-compiler,C-feature-request

<!--
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 while compiling for release:
bin.rs
```rust
use elfredo::extended_data;


fn main() {
    print!("{}", do_stuff_with_extended_data());
}

```
lib.rs
```rust
#[link_section = ".extended"]
#[used]
#[no_mangle]
pub static extended_data: u8 = 3;

fn do_stuff_with_extended_data() -> &str{
// Uses extended_data
}
```

I expected to see this happen (compiled with debug):
```bash
asaffisher@ubuntu:/mnt/hgfs/elfredo/target/debug$ readelf -S test_echo_patch_elf | grep extend
  [18] .extended         PROGBITS         000000000003cec8  0003cec8
```

Instead, this happened(compiled in release):
```bash
asaffisher@ubuntu:/mnt/hgfs/elfredo/target/release$ readelf -S test_echo_patch_elf | grep extend
asaffisher@ubuntu:/mnt/hgfs/elfredo/target/release$
```

### Meta

`rustc --version --verbose`:
```
rustc 1.53.0-nightly (42816d61e 2021-04-24)
binary: rustc
commit-hash: 42816d61ead7e46d462df997958ccfd514f8c21c
commit-date: 2021-04-24
host: x86_64-unknown-linux-gnu
release: 1.53.0-nightly
LLVM version: 12.0.0
```
Repository: angular
Issue: Auto bind attributes and events like Vue (Transparent Wrapper Components)
Labels: feature,area: core,core: binding & interpolation,core: inputs / outputs,feature: under consideration,feature: votes required

One of the brilliant features in `Vue.js` is the ability to assign new attributes to a specific element in the template. known as [Transparent Wrapper Components](https://zendev.com/2018/05/31/transparent-wrapper-components-in-vue.html)

![image](https://user-images.githubusercontent.com/8418700/117489627-156d6700-af83-11eb-9b2b-a167f77148ba.png)

In this sample, I can send all existing HTML attributes to a specific element. (in here with v-bind="$attrs" for input) 

I would be great if we are able to **bind all attrs and events** like Vue in Angular too.
Repository: rust
Issue: Provide example when suggesting to import private trait directly
Labels: A-diagnostics,T-compiler

<!--
Thank you for filing a bug report! 🐛 Please provide a short summary of the bug,
along with any information you feel relevant to replicating the bug.

If you cannot produce a minimal reproduction case (something that would work in
isolation), please provide the steps or even link to a repository that causes
the problematic output to occur. 
-->

Given the following code: https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=8abe48a64675f6641c251a8f8d31e654
```rust
pub trait Data {}
pub enum Message<A>
where
    A: data::Data,
{
    Data(A),
}

mod data {
    use super::*;

    enum Server {

    }

    enum Ui {

    }

    impl Data for Server {}
    impl Data for Ui {}
}


fn main() {
    println!("Oi, mate!");
}

```

The current output is:

```
error[E0603]: trait import `Data` is private
  --> src\main.rs:4:14
   |
4  |     A: data::Data,
   |              ^^^^ private trait import
   |
note: the trait import `Data` is defined here...
  --> src\main.rs:10:9
   |
10 |     use super::*;
   |         ^^^^^^^^
note: ...and refers to the trait `Data` which is defined here
  --> src\main.rs:1:1
   |
1  | pub trait Data {}
   | ^^^^^^^^^^^^^^ consider importing it directly

error: aborting due to previous error

For more information about this error, try `rustc --explain E0603`.
```

<!-- The following is not always necessary. -->

I don't have a concrete suggestion for what an improvement would look like, but I will try to explain the issue: Because the error says "consider importing it directly" and points out that the trait import is defined in line 10 as `use super::*;`, I thought that my problem was with this line. Since the suggestion is to "import it directly", I tried changing it to `use super::Data;`, but that didn't work. Then I tried `pub use super::*;` instead. With this change, I stopped getting errors and therefore thought that the issue was fixed. 

Only shortly before creating this issue, however, did I realize that my actual problem was line 4: `A: data::Data,` should actually be `A: Data,`. With that, I can keep the original version of line 10, and everthing works. It would be nice if this issue could be pointed out a bit more directly, perhaps with a "consider changing `A: data::Data,` to `A: Data,`. 

<!--
If the problem is not self-explanatory, please provide a rationale for the
change.
-->

<!--
If dramatically different output is caused by small changes, consider also
adding them here.

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. The output might also be
different depending on the Edition.
-->

The behavior is the same for rustc 1.54.0-nightly (676ee1472 2021-05-06).