Analysis:
st_select_lex_unit::prepare() computes can_skip_order_by as TRUE.
As a result join->prepare() gets called with order == NULL, and
doesn't do name resolution for the inner ORDER clause. Due to this
the prepare phase doesn't detect that the query references non-exiting
function and field.
  
Later join->optimize() calls update_used_tables() for a non-resolved
Item_field, which understandably has no Field object. This call results
in a crash.

Solution:
Resolve unnecessary ORDER BY clauses to detect if they reference non-exising
objects. Then remove such clauses from the JOIN object.

MDEV-5143: update of a joined table with a nested subquery with a syntax error crashes mysqld with signal 11

Added check of SELECT_LEX::handle_derived() result.

MDEV-5034:Wrong result on LEFT JOIN with a SELECT SQ or a merge view, UNION in IN subquery

Make reset null_row same as it was set in evaluate_null_complemented_join_record().

The problem was that view firlds detect null_row by not-yet-reset table.

The patch for bug mdev-5105 incorrectly counted conditions in nested joins.

Objects of the classes Item_func_isnull and Item_func_isnotnull
must have the flag sargable set to TRUE.
Set the value of the flag sargable only in constructors of the 
classes inherited from Item_int_func.

The bug caused a memory overwrite in the function update_ref_and_keys()
It happened due to a wrong value of SELECT_LEX::cond_count. This value
historically was calculated by the fix_fields method. Now the logic of
calling this method became too complicated and, as a result, this value
is calculated not always correctly.
The patch changes the way how and when  the values of SELECT_LEX::cond_count
and of SELECT_LEX::between_count are calculated. The new code does it just at
the beginning of update_ref_and_keys().
 

For aggregated fields from views/derived tables the possible adjustment
of thd->lex->in_sum_func->max_arg_level in the function Item_field::fix_fields
must be done before we leave the function.

Apparently in a general case a short-cut for the distinct optimization
is invalid if join buffers are used to join tables after the tables whose
values are to selected.

Other fix of maybe_null problem and revert of revno: 3608 "MDEV-3873 & MDEV-3876 & MDEV-3912 : Wrong result (extra rows) with ALL subquery from a MERGE view."

mtr can crash occasionally.
This happens when mtr sends to a child mtr process (or vice-versa) a packet,
that gets truncated or, perhaps, split in two.
Then the other side cannot deserialize it and fails as above.

Adding tests only.

The problem was earlier fixed by 
MDEV-4724 Some temporal functions do not preserve microseconds 

Adding test cases from the bug report only.

The problem was earlier fixed by:
MDEV-4863 COALESCE(time_or_datetime) returns wrong results in numeric context

modified:
  mysql-test/r/func_time.result
  mysql-test/t/func_time.test

Adding a test case only.

The problem was fixed by:

  MDEV-4724 Some temporal functions do not preserve microseconds

modified:
  mysql-test/r/func_time.result
  mysql-test/t/func_time.test

The patch for mdev-4355 had a defect: the cached values for bitmaps of
used tables were not updated when processing degenerate OR formulas.

Removed unneeded set of TABLE_LIST::skip_temporary flag.

- Provide a special execution path for cleanup of degenerate 
  non-merged semi-join children of degenerate selects.

The fix for bug mdev-4971 not always correctly set the pointers to
inherited multiple equalities in objects of the Item_equal class. 

The function propagate_new_equalities() did not updated properly
the references to inherited multiple equalities.

When a non-nullable datetime field is used under an IS NULL predicate
of the WHERE condition in a query with outer joins the remove_eq_conds
function should check whether this field belongs to an inner table
of any outer join that can be, in a general case, a nested outer join.

When in function remove_eq_conds() a sub-formula of the processed condition
is replaced for another formula we should ensure that in the resulting
formula AND/OR levels must alternate.

The patch to fix mdev-4418 turned out to be incorrect.
At the substitution of single row tables in make_join_statistics()
the used multiple equalities may change and references to the new multiple
equalities must be updated. The function remove_eq_conds() takes care of it and
it should be called right after the substitution of single row tables.
Calling it after the call of make_join_statistics was a mistake.

Made sure that degenerate conjunctions/disjunctions are obtained from
AND/OR conditions.

MDEV-4908: Assertion `((Item_cond *) cond)->functype() == ((Item_cond *) new_item)->functype()' fails on a query with IN and equal conditions, AND/OR, materialization+semijoin

A new AND Item should be prepared (fix_field() call) before using.

had been merged into 5.5.

Corrected the result of the output from the test case for mdev 4895.

Fix bug MDEV-4895 Valgrind warnings (Conditional jump or move depends on uninitialised value) in Field_datetime::get_date on GREATEST(..) IS NULL

Analysis:
The cause of the valgrind warning was an attempt to evaluate a Field that was not yet read.
The reason was that on one hand Item_func_isnotnull was marked as constant by
Item_func_isnotnull::update_used_tables, and this allowed eval_const_cond() to be called.
On the other hand Item_func_isnotnull::val_int() evaluated its argument as if it was not
constant.

Solution:
The fix make sure that Item_func_isnotnull::val_int() doesn't evaluate its argument when
it is constant and cannot be NULL, because the result is known in this case. 

had been discovered when merging the patch from 5.3 into 5.5.

After single row substitutions there might appear new equalities.
They should be properly propagated to all AND/OR levels the WHERE
condition. It's done now with an additional call of remove_eq_conds().