| Age | Commit message (Collapse) | Author |
|
(backport from branch v8.3)
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14055 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
behind it.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14053 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14052 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14051 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14050 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
The force_reset_initial starts by killing coqtop, then it tries
to acquire the lock on coq_computing. If it works, no jobs are
pending, we do the real reset_initial (launch of a new coqtop +
removal of buffer coloring) ourself.
Otherwise, the function do_if_not_computing is running, the death
of coqtop will raise a RestartCoqtop exception there, triggering
a reset_initial.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14049 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14048 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Now that coqide is a console-free win32 app, writing to
nonexistent stdout/stderr lead to Sys_error. To avoid that:
- We reroute coqide's stdout/stderr to either a pipe that will stay
unread (by default), or to a temp log file (in debug mode).
- When doing create_process, avoid referring to Unix.stderr:
anything printed by coqtop to its stderr will be merged in the
regular channel.
- On the coqtop side, remove the awkward fix consisting in a \r printed
on stderr apparently to fix coqide.byte. This fix is probably obsolete
since the separation of coqide and coqtop as distinct processes.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14047 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14046 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14045 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
This is implemented as a C external launching the TerminateProcess
of the Win32 API. This should be considered as quite experimental
(cf. the way we handle pid in the comment of ide_win32_stubs.c).
I don't know how to emulate an interrupt (Ctrl-C), for now the two
button "Restart" and "Interrupt" have the same semantics on win32
(kill the subprocess and start at top).
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14044 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
In Win32, these messages may trigger some Sys_error if we try to
turn coqide into a true windows app (no console). To be continued...
The best way would be probably to re-route the whole stdout and stderr
to something else via dup2, but to what ? A log file ?
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14043 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14042 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
This is an adaptation of commit r13750 of branch 8.3
- coqlib is currently computed relatively of Sys.executable_name,
hence no need to set it manually
- in Win32, better detection of user home dir : in System.ml,
if HOME isn't set, we look now for HOMEDRIVE\HOMEPATH, and then
for USERPROFILE
- concerning PATH, in Win32 we now add coqbin (or the location of
coqide) to PATH during the initialization.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14041 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
used
This is an adaptation of commit r13751 of branch 8.3
Even if coqide.exe keeps its console by default for the moment,
we try to allow turning it off (for instance via the mkwinapp tool) :
for that we need to be cautious about the use of functions
like prerr_endline. Since stderr doesn't exists in this settings,
such functions trigger a Sys_error "bad file descriptor".
This patch protects many access to std** by a (try ... with _ ->()).
Nota: with camlp5 < 6.02.1, Print Grammar was also generating
such a Sys_error.
TODO: we should try to figure a way of displaying messages (both
debug and early/late error message). A log file ? A popup ?
diplay in the response buffer ?
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14040 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
This is an adaptation of commit 13748 in 8.3 branch
Making coqide console-free can be done via a link flag given to mingw.
In case of problem with this setting, I also include a script mkwinapp.ml
borrowed from project OCaml-Win32 (and slightly modified to allow
restoring the console as well as removing it).
Use:
"mkwinapp coqide.exe" to make it console-free.
"mkwinapp -unset coqide.exe" to go back to usual console app.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14039 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
This is an adaptation of commit 13747 for 8.3 branch
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14038 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14037 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
We use "&&" instead of ";" which is
- compatible with unix and win32
- more adequate anyway than ";" : no need to run the command if the
cd has failed...
Concerning coqdoc, since previous commit it should not be mandatory to
provide the "--coqlib-path" option. We remove them...
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14036 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14035 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
contrib).
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14032 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
refining dependent instances
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14031 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14030 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
The declarative mode should now work almost like in v8.3
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14029 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Bug-Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=622882
Signed-off-by: Konstantinos Margaritis <markos@genesi-usa.com>
Signed-off-by: Stephane Glondu <steph@glondu.net>
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14027 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
checking types.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14023 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
backward compatibility.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14022 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
unification.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14020 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14018 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Patch suggested by Benjamin Monate
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14016 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
I thought this situation wasn't possible, hence the Option.get.
But it's apparently legal to use Declare Module anywhere, even
outside a Module Type. No idea on how to handle that at extraction
for the moment, hence a proper "unsupported" error message.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14013 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
We simply factorize code that was already existing for Ocaml.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14011 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14008 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
Signed-off-by: Tom Prince <tom.prince@ualberta.net>
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14002 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
This is to allow users to install plugins when coq is installed system-wide.
Signed-off-by: Tom Prince <tom.prince@ualberta.net>
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14001 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
This allows the construction of an extended library that shadows the standard
library.
Signed-off-by: Tom Prince <tom.prince@ualberta.net>
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14000 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
In signatures, opaque terms are always seen as parameters.
In implementations, a flag Set/Unset Extraction AccessOpaque
allows to customize things:
- Set : opacity is ignored (this is the old behavior)
- Unset : opaque terms are extracted as axioms (default now)
Some warnings are anyway emitted when extraction encounters
informative opaque terms.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13999 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
This reverts commit 33434695615806a85cec88452c93ea69ffc0e719.
Conflicts:
kernel/term_typing.ml
test-suite/success/polymorphism.v
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13998 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
change resolution time quite a bit
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13997 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
- Fix pretyping to consider remaining unif problems with the
right transparency information.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13996 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
- Be careful with consider_remaining_unif_problems: it might instantiate an evar, including the current goal!
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13995 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13994 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
reducing matches).
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13993 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
They are actually simpler, sometimes using the [rewrite at] variant.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13992 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
unification (potentially harmful)
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13991 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
before... Use sort constraint checking as in evarconv as well
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13990 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
- Add Set Typeclasses Debug/Depth n options for typeclasses eauto.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13989 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13988 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
After discussion with Bruno and Hugo, coqtop now accepts that an opaque
constant in a module type could be implemented by anything of
the right type, even if bodies differ. Said otherwise, with respect
to subtyping, an opaque constant behaves just as a parameter.
This was already the case in coqchk, and a footnote in documentation
is advertising for quite some time that:
"Opaque definitions are processed as assumptions."
Truly, it might seem awkward that "Definition x:=3" can implement
"Lemma x:nat. Proof 2. Qed." but the opacity ensures that nothing
can go wrong afterwards, since Coq is forced to ignore that the x
in signature has body "2".
Similarly, "T with Definition x := c" is now legal when T contains
an opaque x, even when this x isn't convertible with c.
By avoiding accesses to opaque bodies, we also achieve some speedup
(less delayed load of .vo final sections containing opaque terms).
Nota: the extraction will have to be adapted, since for the moment it
might access the body of opaque constants: the warning emitted when
doing that should become an error.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13987 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@13986 85f007b7-540e-0410-9357-904b9bb8a0f7
|