Commit graph

16 commits

Author SHA1 Message Date
Mario Carneiro
e41cd310e9
fix: String.splitOn bug (#3832)
Fixes #3829. As reported on Zulip (both
[recently](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/current.20definition.20of.20.60String.2EsplitOn.60.20is.20incorrect/near/430930535)
and [a year
ago](https://leanprover.zulipchat.com/#narrow/stream/270676-lean4/topic/should.20we.20redefine.20.60String.2EsplitOnAux.60.3F/near/365899332)),
`String.splitOn` has a bug when dealing with separators of more than one
character (which are luckily rare). The code change here is very small,
replacing a `i` with `i - j`, but it makes termination more complex so
that's where the rest of the line count goes.
2024-04-04 09:30:53 +00:00
Leonardo de Moura
3862e7867b refactor: make String.Pos opaque
TODO: this refactoring exposed bugs in `FuzzyMatching` and `Lake`

closes #410
2022-03-20 10:47:13 -07:00
Leonardo de Moura
92f0afa424 chore: fix tests 2020-12-18 11:21:30 -08:00
Sebastian Ullrich
f22c17e94b chore(library/init/data/string/basic): remove broken lineColumn obsoleted by FileMap 2019-09-19 18:12:51 +02:00
Sebastian Ullrich
8cb387e599 chore(tests/lean/extract): reactivate some #eval tests 2019-09-19 18:12:51 +02:00
Leonardo de Moura
2cbdb287c3 chore(tests): fix/disable some tests 2019-03-21 15:11:05 -07:00
Leonardo de Moura
cd10ca74f7 chore(tests/lean/string_imp): fix test 2018-04-30 16:15:51 -07:00
Leonardo de Moura
62d425073e feat(library/init/data/string/basic): add string.iterator.offset 2018-04-30 15:43:51 -07:00
Leonardo de Moura
9e9a0d103f feat(library/vm/vm_string): add fast string.iterator.remaining 2018-04-26 18:03:41 -07:00
Leonardo de Moura
77993c967d chore(tests/lean): restore string tests 2018-04-26 17:36:41 -07:00
Leonardo de Moura
6234c60aae chore(*): disable test suite 2018-04-10 12:56:55 -07:00
Leonardo de Moura
9399ce8346 feat(library/vm/vm_string): provide native implementation of type string in the VM
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.
2017-10-23 10:55:26 -07:00
Leonardo de Moura
c6a10b127f chore(tests/lean): fix tests
Remarks:
- Some tests do not produce error messages anymore because they can be
  processed using the new equation compiler preprocessor.

- Some error messages got worse because of the preprocessing step.
  We use metavariables in the preprocessing step. This information
  may "leak" to users. Another problem is that some variable names
  are lost. Example: in the following definition

  def to_nat : ∀ {n}, fi n → nat
  | (succ n) f0     := 0
  | (succ n) (fs i) := succ (to_nat i)

  The preprocessing step uses metavariables for pattern variables.
  Thus, we have

  def to_nat : ∀ {n}, fi n → nat
  | (succ ?n) (@f0 ?x)    := 0
  | (succ ?n) (@fs ?x ?i) := succ (to_nat i)

  when solving the constraint `succ ?n =?= succ ?x`, Lean assigns
        ?n := ?x
  after solving these constraints, the preprocessor converts
  metavariables into pattern variables again, and we have

  def to_nat : ∀ {n}, fi n → nat
  | (succ x) (@f0 x)   := 0
  | (succ x) (@fs x i) := succ (to_nat i)

  So, we get the following equation lemmas:

  to_nat.equations._eqn_1 : ∀ (x : ℕ), @to_nat (succ x) (@f0 x) = 0
  to_nat.equations._eqn_2 : ∀ (x : ℕ) (i : fi x), @to_nat (succ x) (@fs x i) = succ (@to_nat x i)

  instead of

  to_nat.equations._eqn_1 : ∀ (n : ℕ), @to_nat (succ n) (@f0 n) = 0
  to_nat.equations._eqn_2 : ∀ (n : ℕ) (i : fi n), @to_nat (succ n) (@fs n i) = succ (@to_nat n i)
2017-08-18 17:32:13 -07:00
Sebastian Ullrich
7e619487f0 fix(frontends/lean/elaborator): suppress error messages containing synthetic sorrys 2017-07-21 01:46:31 -07:00
Sebastian Ullrich
f8cfc4ea1b feat(kernel/error_msgs,frontends/lean/elaborator): add more context to 'type/function expected' errors 2017-07-21 01:46:31 -07:00
Leonardo de Moura
0b04376676 refactor(library/init/data/string/basic): mark string implementation as private
See issue #1175

BTW, we may have to revise this decision in the future when we decide to
populate the string library with lemmas.
It is inconvenient to prove the lemmas at string/basic.lean since the
tactic framework has not been defined yet.
Anyway, I think it is worth to keep the private for now, and make sure
nobody relies on its implementation.
2017-06-07 18:00:24 -07:00