This is a fix for a nasty bug at `type_context::set_instance_fingerprint`.
This method traverses the local context `m_lctx` and invokes `is_class`
which may invoke `whnf`, and `whnf` may temporarily update the local
context. The local context is implemented using a `rb_tree`.
Note that the updates performed by `whnf` are temporary, but it
its representation in memory may be different.
On OSX, Lean was often crashing when using trace messages.
I identified a problem in the thread finalization process.
In OSX, the `silent_ios_helper` at `library/trace.cpp` was being
finalized after the `null_streambuf` at `util/null_ostream.cpp`.
There was also a memory corruption problem also related to
`null_streambuf`.
This commit fixes this problem by using the following recipe
for creating null output stream buffers in C++.
https://stackoverflow.com/questions/11826554/standard-no-op-output-stream
closes#1175
The types `string_imp` and `string.iterator_imp` were supposed to be
marked private, but we cannot do it because we need to provide
`string_imp.mk`, `string_imp.cases_on`, `string.iterator_imp.mk` and
`string.iterator_imp.cases_on` in the VM since we use a different
internal representation. Note that marking them as private does not
work since users can still access `string_imp.cases_on` using
meta-programming.
So, we need better support for private declarations.
Missing feature, char literals do not support non ASCII values.
That is, in the current implementation, we cannot write 'α'.
This will be implemented in the future.
The VM native implementation does not behave correctly for huge
strings (i.e., strings with more than 4G characters).
The problem is that the current implementation relies on
```
size_t force_to_size_t(vm_obj const & o, size_t def)
```
We may also have overflow problems in the string.iterator implementation
code. This is not a big deal right now, since I doubt we will try
to process string with more than 2^32 characters.
@Kha the `core_lib` and tests seem to be working correctly, but
we need more tests.
As suggested by David Chisnall. If I read the spec correctly, it would
be unsafe to use the release ordering for dec_ref_core: then the
following situation could happen:
```c++
// m_rc -> 2
// Thread 1:
unsigned x = atomic_fetch_sub_explicit(&m_rc, 1u, memory_order_release);
// Thread 2:
unsigned y = atomic_fetch_sub_explicit(&m_rc, 1u, memory_order_release);
// x = y = 1u, m_rc -> 2
```
That is, a release store operation is not required to be visible to
another release operation.
Herb Sutter also recommends the acq_rel ordering for reference counters.
Older gcc compilers generate a warning when the attribute is used.
I found out that GCC 7 will not produce a warning if comments
such as /* fall-thru */ or /* FALLTHRU */ are used instead of the
attribute [[fallthrough]]
