Repo:

Go to https://codemirror.net/6/ Select some text (either with Control+A) or mouse drag Press up arrow key

The selection ends up in a weird spot - this behavior is at least different than in CodeMirror 5.

🐛 Bug Report

const {produce} = require("immer");

const bar = {};
const foo = {bar};

console.log(
  produce(foo, (draft) => {
    // comment next line out and it works as expected
    draft.bar;
    draft.bar = bar;
  }) === foo
);

Accessing draft.bar (without modifying it) in this example breaks immutability. This appears to be a regression starting from version 7.0.0 onwards. Works as expected in 6.

Link to repro

https://codesandbox.io/s/immer-sandbox-forked-ldhg9?file=/src/index.ts

Environment

We only accept bug reports against the latest Immer version.

• Immer version: 7.0.0 onwards

@benwilson512 I have schemas User and and UserProfile and querying for user, I preload UserProfile.

So in my resolver:

  def add_source(loader, session) do
    loader
    |> Dataloader.add_source(
      Accounts,
      Dataloader.Ecto.new(
        Repo,
        query: fn _query, params ->
          {_params_session, args} = Map.split(params, [:session])
          Accounts.query(args, session)
        end,
        default_params: %{session: session}
      )
    )
  end

  def user_profile(%User{id: user_id}, _args, %{context: %{loader: loader}}, fun \\ nil) do
    loader
    |> Dataloader.load(Accounts, {User, load: :profile}, user_id)
    |> on_load(fn loader ->
      loader
      |> Dataloader.get(Accounts, {User, load: :profile}, user_id)
      |> case do
        %User{} = user -> {:ok, user.profile}
        nil -> {:error, :not_found}
      end
      |> default_fun(fun)
    end)
  end

So dataloader calls Accounts.query(...) with [load: :profile] and that constructs a standard Ecto query of this form:

    from user in query,
      join: profile in assoc(user, :profile),
      preload: [profile: profile]

Also just noticed there's more error output - did something change with the way dataloader constructs ecto queries in 1.0.8?

11:11:29.346 [error] Task #PID<0.3055.0> started from #PID<0.3058.0> terminating
** (Ecto.SubQueryError) the following exception happened when compiling a subquery.

    ** (Ecto.QueryError) cannot preload associations in subquery in query:

    from u0 in Server.Accounts.User,
      join: u1 in Server.Accounts.UserProfile,
      on: u1.user_id == u0.id,
      where: u0.id == parent_as(:input).id,
      limit: ^40,
      offset: ^0,
      preload: [profile: u1]


The subquery originated from the following query:

from u0 in subquery(from u0 in Server.Accounts.User,
  where: u0.id in ^["18dd4bf9-92ff-4448-9631-b6031355ce32"],
  distinct: true,
  select: [:id]),
  as: :input,
  join_lateral: u1 in subquery(from u0 in Server.Accounts.User,
  join: p1 in assoc(u0, :profile),
  where: u0.id == parent_as(:input).id,
  limit: ^40,
  offset: ^0,
  preload: [profile: p1]),
  on: true,
  select: u1

Upgraded to 1.0.8 of dataloader and am getting this error now:

** (Dataloader.GetError) {%Ecto.SubQueryError{exception: %Ecto.QueryError{message: "cannot preload associations in subquery in query:\n\nfrom u0 in Server.Accounts.User,\n  join: u1 in Server.Accounts.UserProfile,\n  on: u1.user_id == u0.id,\n  where: u0.id == parent_as(:input).id,\n  limit: ^40,\n  offset: ^0,\n  preload: [profile: u1]\n"}, message: "the following exception happened when compiling a subquery.\n\n    ** (Ecto.QueryError) cannot preload associations in subquery in query:\n    \n    from u0 in Server.Accounts.User,\n      join: u1 in Server.Accounts.UserProfile,\n      on: u1.user_id == u0.id,\n      where: u0.id == parent_as(:input).id,\n      limit: ^40,\n      offset: ^0,\n      preload: [profile: u1]\n    \n\nThe subquery originated from the following query:\n\nfrom u0 in subquery(from u0 in Server.Accounts.User,\n  where: u0.id in ^[\"4cb62820-1d0e-4265-852a-e62086d98264\"],\n  distinct: true,\n  select: [:id]),\n  as: :input,\n  join_lateral: u1 in subquery(from u0 in Server.Accounts.User,\n  join: p1 in assoc(u0, :profile),\n  where: u0.id == parent_as(:input).id,\n  limit: ^40,\n  offset: ^0,\n  preload: [profile: p1]),\n  on: true,\n  select: u1\n"}, [{Ecto.Repo.Queryable, :execute, 4, [file: 'lib/ecto/repo/queryable.ex', line: 176]}, {Ecto.Repo.Queryable, :all, 3, [file: 'lib/ecto/repo/queryable.ex', line: 17]}, {Dataloader.Ecto, :run_batch, 6, [file: 'lib/dataloader/ecto.ex', line: 328]}, {Dataloader.Source.Dataloader.Ecto, :run_batch, 2, [file: 'lib/dataloader/ecto.ex', line: 643]}, {Dataloader.Source.Dataloader.Ecto, :"-run_batches/1-fun-1-", 2, [file: 'lib/dataloader/ecto.ex', line: 601]}, {Task.Supervised, :invoke_mfa, 2, [file: 'lib/task/supervised.ex', line: 90]}, {Task.Supervised, :reply, 5, [file: 'lib/task/supervised.ex', line: 35]}, {:proc_lib, :init_p_do_apply, 3, [file: 'proc_lib.erl', line: 226]}]}         (dataloader 1.0.8) lib/dataloader.ex:223: Dataloader.do_get/2

This is a follow up to #271, previously I reported that inputting a large, valid json resulted in a stack depth error. Now that specific error went away but there's still appears to be a performance regression compared to CodeMirror 5.

If I copy and paste the contents of:

test.txt

Into the CM 6 vs CM 5 (here: https://codemirror.net/mode/javascript/), 5 parses immediately and provides full syntax highlighting, whereas 6 appears to stall and if I start editing / scrolling, only half the document is syntax highlighted.

Not sure if relevant, but you mentioned in the commit for #271 that this is due to "error recovery" - but this json input should be valid JS so it shouldn't error?

@marijnh Ah thanks for correcting my misunderstanding then. Feel free to close this out. On a side note - will there be a JSON mode as part of 6's JS mode? Thanks!

Also wanted to mention - maybe this deserves a separate issue but it maybe related - that scrolling in 6 for this input is much slower. Scrolling quickly results in blank white space that then fills in, whereas in 5 it renders instantly.

This is a follow up to #271, previously I reported that inputting a large, valid json resulted in a stack depth error. Now that specific error went away but I think there's still a performance regression compared to CodeMirror 5.

If I copy and paste the contents of:

test.txt

Into the CM 6 vs CM 5 (here: https://codemirror.net/mode/javascript/), 5 parses immediately and provides full syntax highlighting, whereas 6 appears to stall and if I start editing / scrolling, only half the document is syntax highlighted.

Not sure if relevant, but you mentioned in the commit for #271 that this is due to "error recovery" - but this json input should be valid JS so it shouldn't error?

When inputing a large json value with javascript mode, I'm getting this error:

Uncaught RangeError: Maximum call stack size exceeded
    at StackBufferCursor.fork (codemirror.js:17779)
    at findBufferSize (codemirror.js:1618)
    ...

To repo, go to https://codemirror.net/6/ and paste in the contents of this attached json file.

test.txt

On larger documents, scrolling down and then back up causes the line numbers to disappear.

Repo:

Go to https://codemirror.net/6/ Copy and paste empty new lines into the editor until it's > 200 lines (not sure what threshold is exactly) Scroll back to the top

Screenshot:

Using Chrome 84 on OSX.

On larger documents, scrolling down and then back up causes the line numbers to disappear.

Repo:

Go to https://codemirror.net/6/ Copy and paste empty new lines into the editor until it's > 100 lines Scroll back to the top

Screenshot:

Using Chrome 84 on OSX.

Looks like this is a regression starting from 7.0.0 - works as expected in codesandbox.io when I switch to version 6.0.9

🐛 Bug Report

const { produce } = require("immer");
const foo = { bar: undefined };

console.log(produce(foo, draft => { draft.bar = undefined; }) === foo);
> false

This code evaluates to false when I would expect it to evaluate to true.

Link to repro

https://codesandbox.io/s/immer-sandbox-su9pe?file=/src/index.ts

To Reproduce

Try code above in node.js or chrome with latest immer 7.0.5

Observed behavior

When setting an object whose property is undefined to undefined, a different object is returned

Expected behavior

When setting an object whose property is undefined to undefined, the same object is returned

Environment

• Node.js and Chrome
• Immer 7.0.5

🐛 Bug Report

const { produce } = require("immer");
const foo = { bar: undefined };

produce(foo, draft => { draft.bar = undefined; }) === foo;

This code evaluates to false when I would expect it to evaluate to true.