WhereIsAI/github-issue-similarity huggingface dataset:
Issue 1:
I have searched the issues of this repository and believe that this is not a duplicate.

Notice how promise.then() is called without a .catch().

https://github.com/zeit/next.js/blob/e093441bad588e98765a05df90f76f75283eda07/lib/dynamic.js#L56-L74

In my code I have this line:

const Foo = dynamic(import('./test'), {ssr: false})

Which transpiles to this via the handle-import babel plugin:

var Foo = (0,
_dynamic.default)(new (__webpack_require__("../../../../../../../../../dev-live/next.js/dist/lib/dynamic.js").SameLoopPromise)(function(resolve, reject) {
var weakId = /*require.resolve*/
("./pages/test.js");

try {
var weakModule = __webpack_require__(weakId);

return resolve(weakModule);
} catch (err) {}

__webpack_require__.e /* require.ensure */
(5).then((function(require) {
try {
var m = __webpack_require__("./pages/test.js");

m.__webpackChunkName = 'app_pages_test_57cb2b7894b1a841c4b5aa44c2077b83';
resolve(m);
} catch (error) {
reject(error);
}
}
).bind(null, __webpack_require__)).catch(__webpack_require__.oe);
}
), {
ssr: false
});

Which cleaned up looks like this:

dynamicComponent(new SameLoopPromise(cb), {ssr: false})

// NB: Not sure what 5 corresponds to...
cb = function(resolve, reject) {
require.ensure(5).then(require => {
try {
require('./pages/test.js')
resolve(m)
} catch (error) {
reject(error)
}
}).catch(__webpack_require__.oe)
}

Now, if our require throws an error (e.g. ReferenceError):

reject is called, but in dynamicComponent#loadComponent() as seen above, there is nothing to catch it.

Also, the .catch(__webpack_require__.oe) after require.ensure is never called either because our require is wrapped in its own try catch.

Solution

Add }).catch(e => console.error(e)) at the end of dynamicComponent#loadComponent().

Your Environment

Tech
Version

next
6.0.0

node
8.1.2

OS
macOS

browser
Chrome

etc

Issue 2:
None of my JavaScript gets loaded on the custom _error page in a production bundle, works fine in development though.

There's also things on the _error page that are reused elsewhere in the application like a common header that has some JavaScript for letting a user log in/sign out.

In the console I can see some errors saying the scripts can't be found.

Is this normal behaviour that you simply can't run any JavaScript on the _error page? Is there any way to hack around this?

asdf:1 GET https://<BASE_URL>/_next/56777ac5-5382-4caf-9a49-e437db6e03a1/page/asdf.js net::ERR_ABORTED

I have searched the issues of this repository and believe that this is not a duplicate.

Steps to Reproduce (for bugs)

Create a custom _error.js page in the pages folder that's part of next's api

Go to a route that doesn't exist

Context

I was asked to implement a newsletter subscription form on the custom error page in order to give the user the ability to be notified as soon as a certain page exists because we have links that don't lead anywhere yet for a second stage of the project.

Your Environment

Tech
Version

next
4.2.3

node
9.5.0

OS
Mac OS X

Chrome
65.0.3325.181
Issue 1:
I can't believe this isn't available in Symfony2?

I want to give my API the ability to just update one attribute instead of having all the attributes and relations when updating a resource.

I know there's this workaround https://gist.github.com/makasim/3720535

but I'm not sure where to implement that Listener.

Issue 2:
binding partial parameters effectively clears all existing values from the model and only persists the new parameters that are passed in. See example:

// Author.php
class Author
{
public $name;
public $email = 'bar';
}

// AuthorType
...
$builder->add('name', 'text')->author('text');
...

Passing $form->bind(array('name' => 'foo')) wipes out the existing email value.
Issue 1:
ISSUE TYPE

Feature Idea

COMPONENT NAME

core

ANSIBLE VERSION

2.2

CONFIGURATION

OS / ENVIRONMENT

SUMMARY

The idea would be to add notes to very specific tasks that are presented to the operator during a playbook run in a specific color.

In operational environments it would be useful to notify the operator that a specific task may do something unexpected (e.g. a change is reported, but this is related to a migration or ongoing development). Usually operations is fully aware of what changes a specific release entails, and so the output matches exactly with their expectations.

But from time to time changes may be induced that are unexpected or unrelated to the release. This could be related to changes (moving things around, module development, ongoing work, etc.) and in these cases it would be useful to make the operator aware.

Output could be as simple as:

note: Ignore below changes caused by reorganizing codebase, see change request 1234

or:

note: FIXME - below errors are suppressed, see ticket 1234, Network team is investigating real culprit

The real benefit of such a mechanism is that it can use specific colors (e.g. purple) for notes during run so that they are easy to interpret and ensures the operator is aware. We currently use the name-property for this, however this is often missed and makes it harder during maintenance windows to validate.

STEPS TO REPRODUCE

EXPECTED RESULTS

ACTUAL RESULTS

Issue 2:
ISSUE TYPE

Feature Idea

COMPONENT NAME

task keywords

ANSIBLE VERSION

N/A

SUMMARY

Even tho one can have comment blocks in yaml by commenting, I think it would be nice

to more tightly integrate comments, so suggesting the following:

setting: display_comments: true

task:

- name: install foo
apt: pkg=foo
comment: |-
install foo early to allow foo to run checks before
installing the rest of our dependencies

I would suggest that comment could also be run as a task itself:

- comment: |-
notify restart handler because
of some issue or whatever
changed_when: true
notify: restart
Issue 1:
At the moment, the summary for the IntoIterator trait definition reads:

pub trait IntoIterator where Self::IntoIter::Item == Self::Item {
type Item;
type IntoIter: Iterator;
fn into_iter(self) -> Self::IntoIter;
}

The 'where' clause on the first line isn't valid Rust, which is confusing. It should instead be rendered the way it appears in the code:

pub trait IntoIterator {
type Item;
type IntoIter: Iterator<Item=Self::Item>;
fn into_iter(self) -> Self::IntoIter;
}

(On #rust @alexcrichton said, "that's probably all located in https://github.com/rust-lang/rust/blob/master/src/librustdoc/clean/simplify.rs")

Issue 2:
The documentation for IntoIterator is inconsistent in how it shows the Item constraints.

The actual trait declaration looks like this:

pub trait IntoIterator {
type Item;
type IntoIter: Iterator<Item = Self::Item>;
fn into_iter(self) -> Self::IntoIter;
}

The nightly core documentation matches this declaration as of 1.49.0-nightly (3525087 2020-10-08). This is good.

However, the nightly std documentation shows no Item constraints at all:

pub trait IntoIterator {
type Item;
type IntoIter: Iterator;
fn into_iter(self) -> Self::IntoIter;
}

The std documentation for 1.48.0-beta.2 is even weirder, using an equality constraint that's not supported (#20041), and this goes all the way back to 1.0.0.

pub trait IntoIterator
where
<Self::IntoIter as Iterator>::Item == Self::Item,
{
type Item;
type IntoIter: Iterator;
fn into_iter(self) -> Self::IntoIter;
}
Issue 1:
Electron Version: 2.0.0

Operating System (Platform and Version): Lubuntu/Ubuntu 17.10

Last known working Electron version: 1.8.x

Expected Behavior

Electron should open and be functional when run from the terminal

Actual behavior

Electron either doesn't open, opens to a black screen, or freezes shortly after opening. The command doesn't exit, it just hangs there.

To Reproduce

$ git clone https://github.com/electron/electron-quick-start
$ npm install
$ npm start

Additional Information

If you run npm start > /dev/null, npm start 2> /dev/null, or npm start &> /dev/null, the issue cannot be reproduced. This makes me suspect that there's some bug with streaming to a terminal emulator (perhaps the terminal emulator gives backpressure that electron can't handle?)

Issue 2:
Electron version: Anything over 1.7.8, until the latest 1.8.2-beta.1

Node: 8.8.0

Operating system: high sierra

Going over 1.7.8 seems to break Electron for one of our projects. It's hard to track down what's going on but here's the output:

❯ yarn run electron
yarn run v1.2.1
$ electron .dev/electron.js
/Users/drcmda/dev/stepdoctor/node_modules/electron/dist/Electron.app/Contents/MacOS/Electron[41928]: ../../vendor/node/src/async-wrap.cc:399:void node::SetupHooks(const FunctionCallbackInfo<v8::Value> &): Assertion `env->async_hooks_init_function().IsEmpty()' failed.
1: node::Abort() [/Users/drcmda/dev/stepdoctor/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib]
2: node::Assert(char const* const (*) [4]) [/Users/drcmda/dev/stepdoctor/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib]
3: node::AsyncWrap::Initialize(v8::Local<v8::Object>, v8::Local<v8::Value>, v8::Local<v8::Context>) [/Users/drcmda/dev/stepdoctor/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib]
4: v8::internal::StrDup(char const*) [/Users/drcmda/dev/stepdoctor/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib]
5: v8::internal::compiler::BranchElimination::ControlPathConditions::operator==(v8::internal::compiler::BranchElimination::ControlPathConditions const&) const [/Users/drcmda/dev/stepdoctor/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib]
6: v8::internal::compiler::BranchElimination::ControlPathConditions::operator==(v8::internal::compiler::BranchElimination::ControlPathConditions const&) const [/Users/drcmda/dev/stepdoctor/node_modules/electron/dist/Electron.app/Contents/Frameworks/Electron Framework.framework/Versions/A/Libraries/libnode.dylib]
7: 0x3eadf51843fd
8: 0x3eadf527777c
9: 0x3eadf523be1c
✨ Done in 0.40s.

It happens when we require a file that has async/await calls in it, but nothing's yet executed. But the moment we go back to 1.7.8 it starts working again.
Issue 1:
Version

2.6.11

Reproduction link

https://jsfiddle.net/rdjjpc7a/2080/

The Link to minimal reproduction was forged by me, please take some time to read my description.

Steps to reproduce

The premise is that you have an iPhone with the system version IOS9.

The Steps to reproduce seem to be a nested amount of custom components.

The problem happened in 2.6.x. I had discovered this problem a year ago. Since I couldn't provide a minimal reproduction at the time (and it is now), I have been rolling back to 2.5.x until now.

But I now find the source of the problem in the source code.

https://github.com/vuejs/vue/blob/v2.6.11/src/platforms/web/runtime/modules/events.js#L69.

In IOS9, Condition "e.timeStamp >= attachedTimestamp" is never holds.

console.log(e.timeStamp, attachedTimestamp); // In IOS9, eg: 1585822331076 1585824221635

You can compare 2.5.x to solve this problem.

What is expected?

touch event trigger

What is actually happening?

events of the touch series are not triggered

Only happened in 2.6.x, only events of the touch series

Issue 2:
Version

2.6.11

Reproduction link

https://github.com/chenjiahan/vue-event-bubble-issue

Steps to reproduce

This is a browser quirk on iOS <= 11.3

Find an old iOS device. (I reproduced the issue on an iOS 8.4 device)

Binding click events on parent and child elements

Click child element

Event listener for parent element is not firing

What is expected?

Correct event bubbling behavior

What is actually happening?

Mobile safari has buggy event.timeStamp implementations, the value of event.timestamp is abnormal when the page is first loaded. But event.timestamp will return to normal value after refreshing the page.

We receive a lot of feedback from vant users, it is currently observed that the problem may occur on iOS 8.4、10.2、10.3、11.3 (mobile safari and wechat browser)

Screenshot:
Issue 1:
The following fails to typecheck, complaining that type 'number' is not assignable to type '() => void'.

function nop(): void { return void 0; }
function foo(xs: (number | (()=>void))[]): (() => void) {
return xs.reduce(((acc, x) => nop), nop);
}

But the code never actually looks at the contents, so it should work (and it does, if I change the argument type to something other than a function).

Issue 2:
Referencing #3645:

I agree with @Eisenspalter: Multiple tsconfig files are indispensable for large enterprise apps.

@mhegazy : As you wrote you don't want to support tsconfig.json file inheritance, I'd like to propose the following:

My proposal

TSC should come with a new command line parameter, enabling the following behaviour:

The TSC process will browse the project directory for tsconfig.json files.

If no tsconfig.json files will be found, TSC proceeds with its normal behaviour: Compiling all .ts files found in the projects sub directories, using the default configuration.

If, instead, any tsconfig.json file will be found, the TSC process refrains from compiling. Instead it spawns a new TSC child process for the tsconfig.json file and continues browsing the project's sub directories for tsconfig.json files. It does this for each tsconfig.json file it reaches.

With each new TSC process it creates it sets the -project parameter and current working directory of that child process to the tsconfig.json file's.

Any TSC process will stop evaluating a sub directory (= any directory different from -project) if it finds a tsconfig.json file in there.

The new command line parameter (e.g. -browseConfig) should require a directory information, similar to the -project command line parameter. This will allow the user to provide a dedicated sub directory as root for scanning.

#### Example

The following example depicts the original TSC process to start at -browseConfig "." ("Project root"):

TSC -browseConfig "."

Browsing the project directory tree it finds three tsconfig.json files. For each of the tsconfig.json files it spawns a new TSC process:

CD "scripts"
TSC

CD "scripts/sub directory n"
TSC

CD "scripts/sub directory n/sub directory n"
TSC

So there will be four TSC processes running in parallel (good for multi-core systems 😉), each evaluating its sub tree of the project. The first process won't perform any transpilation. It only browses the directory tree.

The following images depict the main TSC process and the three sub processes, highlighting the files they transpile:

To speed up browsing for tsconfig.json files, the first/main/original TSC process could/should better be started using: TSC -browseConfig "./scripts/"
Issue 1:
Found this while refactoring my library after the Vector -> Slice rename

STR:

use std::{mem, raw};

fn main() {
let a = &[1, 2, 3i];
let raw::Slice { data: ptr, len: len }: raw::Slice<int> = unsafe { mem::transmute(a) };
let b = unsafe { mem::transmute(Slice { data: ptr, len: len }) };
// ICE ^~~ forgot the `raw::` qualifier
}

Backtrace:

task 'rustc' failed at 'explicit failure', /var/tmp/paludis/build/dev-lang-rust-scm/work/rust-scm/src/librbml/lib.rs:246

stack backtrace:
1: 0x7fadbcf65980 - rt::backtrace::imp::write::h500c7cd49c94d6cbo1q
2: 0x7fadbcf68a20 - <unknown>
3: 0x7fadc14ddc40 - unwind::begin_unwind_inner::h78b0bc3908c6581cM8d
4: 0x7fadc03d5310 - <unknown>
5: 0x7fadc03d4340 - reader::get_doc::h659c9cb63ec6b27dQRa
6: 0x7fadc23b9d40 - metadata::decoder::get_type::h8aa840f508fceb99Bis
7: 0x7fadc1df73b0 - middle::ty::lookup_item_type::h0762f54f39bdc9b9J5G
8: 0x7fadc2154ec0 - <unknown>
9: 0x7fadc2152820 - <unknown>
10: 0x7fadc2154ec0 - <unknown>
11: 0x7fadc211dba0 - <unknown>
12: 0x7fadc2154ec0 - <unknown>
13: 0x7fadc21b39c0 - middle::typeck::check::check_decl_local::h2a1925bfb9a5b157XEW
14: 0x7fadc21b3be0 - middle::typeck::check::check_stmt::he6d6f56b73c868b94GW
15: 0x7fadc211dba0 - <unknown>
16: 0x7fadc2119930 - <unknown>
17: 0x7fadc2119650 - <unknown>
18: 0x7fadc2112510 - middle::typeck::check::check_item::h9d5462bdf5870d8fxhS
19: 0x7fadc2119450 - middle::typeck::check::check_item_types::h60cfbf824eb42ae21HR
20: 0x7fadc1b2a150 - <unknown>
21: 0x7fadc23275c0 - middle::typeck::check_crate::h322ddeef25afc167p2i
22: 0x7fadc23f6af0 - driver::driver::phase_3_run_analysis_passes::h01e8a18355fa9e80Vsx
23: 0x7fadc23f1c30 - driver::driver::compile_input::h7879a63579b438beafx
24: 0x7fadc249d400 - <unknown>
25: 0x7fadc249d310 - <unknown>
26: 0x7fadc24afc60 - <unknown>
27: 0x7fadc24afa60 - <unknown>
28: 0x7fadc1838b30 - <unknown>
29: 0x7fadc152d970 - <unknown>
30: 0x7fadc152d960 - rust_try
31: 0x7fadc14db2a0 - unwind::try::h36697dac480a0e50hXd
32: 0x7fadc14db040 - task::Task::run::h0fb2de2c85c53b00T4c
33: 0x7fadc18388f0 - <unknown>
34: 0x7fadc14dce80 - <unknown>
35: 0x7fadbc2e0000 - start_thread
36: 0x7fadc11ac269 - clone
37: 0x0 - <unknown>

Version:

rustc 0.12.0-pre (a8c8e3f80 2014-08-14 19:11:18 +0000)

Issue 2:
failed to find block with tag 7
error: internal compiler error: unexpected failure
note: the compiler hit an unexpected failure path. this is a bug.
note: we would appreciate a bug report: http://static.rust-lang.org/doc/master/complement-bugreport.html
note: run with `RUST_LOG=std::rt::backtrace` for a backtrace
task 'rustc' failed at 'explicit failure', /usr/local/git/rust/src/libserialize/ebml.rs:209

The following simple code triggers this:

fn main() {
println!("{}", ::std::num::Float::to_radians(200));
}
Issue 1:
For tests that must (for some reason) leak an operation or resource deno test allows us to opt out of Op and Resource sanitizing for a single test. Unfortunately, the resources purposefully leaked by a "leaky" test end up associated with other tests, causing hard to diagnose errors.

I've created a minimal reproduction of the issue in this repository.

Thanks for all the hard work you guys are doing!

Issue 2:
It would be nice to be able to see the async objects that are leaking and their allocation stack. I think this would be useful as a command line switch to enable it while debugging. For my complex application, one part of the system seems to be affecting a different part. Their individual unit tests execute just fine. When running the entire test on the system, I'm getting random failures.

Right now I'm hunting for the leaking ops and adding more test coverage, but it would be nice to have some insight here.
Issue 1:
Output of a session of mine:

fn factorial(x: int) -> int {
if x <= 0 { 1 } else { x * factorial(x - 1) }
}

fn main() {
let x = 4;
println!("{}", factorial(x));
}

$ rustc -g inspect.rs
$ lldb ./inspect
Current executable set to './inspect' (x86_64).
(lldb) b main
Breakpoint 1: 2 locations.
(lldb) r
Process 45203 launched: './inspect' (x86_64)
Process 45203 stopped
* thread #1: tid = 0x370ce1, 0x0000000100001780 inspect`main, queue = 'com.apple.main-thread', stop reason = breakpoint 1.2
frame #0: 0x0000000100001780 inspect`main
inspect`main:
-> 0x100001780: cmpq %gs:0x330, %rsp
0x100001789: ja 0x1000017a5 ; main + 37
0x10000178b: movabsq $0x18, %r10
0x100001795: movabsq $0x0, %r11
(lldb) c
Process 45203 resuming
Process 45203 stopped
* thread #2: tid = 0x370cf7, 0x00000001000016b4 inspect`inspect::main + 52 at inspect.rs:6, stop reason = breakpoint 1.1
frame #0: 0x00000001000016b4 inspect`inspect::main + 52 at inspect.rs:6
3 }
4
5 fn main() {
-> 6 let x = 4;
7 println!("{}", factorial(x));
8 }
(lldb) print factorial(5)
Error [IRForTarget]: Size of result type 'long (long)' couldn't be determined
error: warning: function 'factorial' has internal linkage but is not defined
note: used here
error: The expression could not be prepared to run in the target
(lldb)

cc @michaelwoerister

Issue 2:
The way the runtime is currently structured every time "something happens" a callback is registered with a libuv event loop that wakes up that loop to deal with it. This could be "work available to steal" or "message sent to scheduler" for example. The problem with these is that we create massive numbers of the things when we really only need one per scheduler. If the scheduler needs to have a callback registered, register the singleton callback for that scheduler. Doing this would eliminate huge amounts of allocation and many many calls out to libuv functions.
Issue 1:
Version

2.6.10

Reproduction link

https://jsfiddle.net/hataketed/m0t2ng8b/4/

Steps to reproduce

just run and see the console errors

What is expected?

click alert

What is actually happening?

vue.js:634 [Vue warn]: Property or method "eventname" is not defined on the instance but referenced during render. Make sure that this property is reactive, either in the data option, or for class-based components, by initializing the property. See: https://vuejs.org/v2/guide/reactivity.html#Declaring-Reactive-Properties.

(found in )

warn @ vue.js:634

vue.js:634 [Vue warn]: Invalid value for dynamic directive argument (expected string or null): undefined

(found in )

warn @ vue.js:634

vue.js:634 [Vue warn]: Property or method "attributename" is not defined on the instance but referenced during render. Make sure that this property is reactive, either in the data option, or for class-based components, by initializing the property. See: https://vuejs.org/v2/guide/reactivity.html#Declaring-Reactive-Properties.

(found in )

warn @ vue.js:634

vue.js:634 [Vue warn]: Invalid value for dynamic directive argument (expected string or null): undefined

(found in )

Issue 2:
What problem does this feature solve?

when we want to do something like hide / show password input we should add state called "IsVisible" in our data but actually this data is specific for this input not relate to our app so we shoud put it on a scope of the element to prevent our data's pollution

What does the proposed API look like?

<div class="field" v-data="{ isVisible : false }">
<button @click="isVisible = !isVisible">isVisible ? 'hide' : 'show'</button>
<input :type=" isVisible ? 'text' : 'password' " />
</div>
Issue 1:
Feature request

Is your feature request related to a problem? Please describe.

Next.js v9.0.0 hard codes the root API directory path to /pages/api

Making this a config option would allow for a better separation of concerns.

We consider pages just that, pages, each one relates to a page you can visit, where as the API is the API an endpoint we consume. Because we are also connecting to a graphql backend to consume our data (which allows you to request everything in a single request) and since the release of serverless pre-rendering we are creating an endpoint for each of our pages to consume, i.e. api/pages/index etc... so right now that looks like /pages/api/pages/index, which gets confusing.

Describe the solution you'd like

A config option to be able to specify the API direction path.

const path = require('path')

module.exports = {
apiDir: path.resolve(__dirname, 'api'),
}

Describe alternatives you've considered

n/a

Additional context

https://spectrum.chat/next-js/general/next-9-is-there-a-config-option-to-change-where-the-api-dir-is-located~81da11ce-cd38-4fb5-bcda-9e95ee07db14

Issue 2:
I have searched the issues of this repository and believe that this is not a duplicate.

egg.js: https://github.com/eggjs/egg

In this example: https://github.com/zeit/next.js/blob/master/examples/custom-server-koa/server.js. ctx.respond = false causes a large number of koa middleware to be invalid. egg.js is based onkoa implementation.

Expected Behavior

Current Behavior

Steps to Reproduce (for bugs)

Context

Your Environment

Tech
Version

next
v3

node
8.4

OS
mac

browser
*

etc