| Age | Commit message (Collapse) | Author |
|---|
|
This was already the case for constant, but not for constructors and
inductive types.
For instance, in message "The constructor @cons (in type list) is
expected to ..." we don't want a @ to be printed.
|
|
|
|
cf "If this is implemented, long names might cause a printing
problem:" in #11852
|
|
|
|
This fixes the fix 1522b989 to #7192.
The remaining Not_found after 1522b989 should have rung a bell that
something was still strange.
|
|
We fix it by looking manually for the implementation at each level of
nesting rather than using the signature for the n first levels and
looking for the implementation only in the n+1-th level.
|
|
|
|
"Fetching opaque proofs" notices are not printed by default anymore.
|
|
|
|
|
|
|
|
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@16760 85f007b7-540e-0410-9357-904b9bb8a0f7
|
|
#2168)
We replace Global.lookup_constant by our own code that looks for a module
and enters its implementation. This is still preliminary work, I would prefer
to understand more completely the part about module substitutions when
entering an applied functor. But this code already appears to work quite well.
Anyway, since we only search for constants, we don't need to reconstitute a
100% accurate environment, as long as the same objects are in it.
Note:
- Digging inside module structures is slower than just using
Global.lookup_constant. Hence we try to avoid it as long as we could.
Only in front of axioms (or in front of constant unknown to Global)
do we check whether we have an inner-module implementation for this
constant. There is some memoization of the search for internal
structure_body out of a module_path.
- In case of inner-module axioms, we might not be able to print
its type, but only its long name.
git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/coq/trunk@14600 85f007b7-540e-0410-9357-904b9bb8a0f7
|
