| Age | Commit message (Collapse) | Author |
|---|
|
|
|
I am the maintainer of projectile for debian. (Aymeric Agon-Rambosson)
As part of the building process of our packages, we run the tests
provided by the upstream maintainers in a clean and empty
environment (no writable $HOME, no internet access, etc...). For
this reason, we sometimes uncover bugs that would remain masked on
the machines of the upstream maintainers, and of the users.
The test "projectile-parse-dirconfig-file" can break in a very
specific setting :
Since version 28.1, emacs has been shipped with
native-compilation, that is the possibility to compile elisp to
native instructions using libgccjit. Since elisp allows the
advising of functions implemented in C ("primitives"), it is
necessary to compile trampolines to replace those functions if we
want to advise them, in order to allow an arbitrary user-defined
function to be run instead.
The test library you use, buttercup, and more specifically its
function spy-on, advises functions routinely.
In the test we're interested in, buttercup (spy-on) changes the
definition of a few primitives in the offending test
(projectile-parse-dirconfig-file), namely file-exists-p,
file-truename and insert-file-contents.
The first one is advised so as to always return t, regardless of
whether the file is really present or not.
The first two are advised without error. The last one, however,
can fail because, being a primitive, a trampoline needs to be
compiled. We have the following backtrace in our build environment
:
comp-subr-trampoline-install(insert-file-contents)
comp-trampoline-search(insert-file-contents)
native-elisp-load("/tmp/buttercupKuLmvD/28.2-4001e2a9/subr--trampoline-696...
error: (native-lisp-load-failed "file does not exists"
"/tmp/buttercupKuLmvD/28.2-4001e2a9/subr--trampoline-696e736572742d66696c652d636f6e74656e7473_insert_file_contents_0.eln")
What happens here is the following : if we are in a situation
where the trampoline corresponding to the function
insert-file-contents is not already present in some eln-cache
directory on the machine, then the function comp-trampoline-search
should return nil, which would trigger the compilation of said
trampoline.
However, since comp-trampoline-search relies on file-exists-p, and
this last one has been advised so as to always answer yes,
comp-trampoline-search tries to load a file that does not exists,
hence our error.
You or your users probably never reach that state, probably
because you can always count on the trampoline being present
beforehand. But if it is not there, you should be able to
reproduce. We always reach that state because we run the tests in
a clean environment, where the trampoline is never present.
This error can be expected whenever a primitive is advised (in our
case insert-file-contents) while file-exists-p is already advised
so as to always return t, and the trampoline corresponding to the
primitive does not already exists on the file system.
There are two possible solutions : the first one is to try and
ensure the trampoline is present by the time of the advice, for
instance by compiling it unconditionally before the test. This is
not entirely reliable, as some environments could inhibit the
saving of this trampoline to the file system (this is what we do,
for instance).
The second one is to exclude the function insert-file-contents
(and indeed, any primitive you would want to advise while
file-exists-p is advised as to always return t) from trampoline
optimisation completely. The variable
native-comp-never-optimize-functions can be used to do just that.
This patch tweaks it accordingly.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Introduces a variable, `projectile-dirconfig-file` specifying the name of the
file used by Projectile to explicitly mark project roots. The default is
“.projectile”.
One use case for this is if you group project-local configs in an XDG-style
location. E.g., setting it to “.config/projectile”.
|
|
Prioritizes .projectile above other bottom-up root files.
Related to #1810.
|
|
|
|
Previously, the directory it found would depend on the order of
`projectile-project-root-files-bottom-up` (or the provided list).
given a directory structure
foo
├── .a
└── bar
└── .a
└── baz
└── .b
`(projectile-root-bottom-up ".../foo/bar/baz/" '(".a" ".b"))` would return
`".../foo/bar/"`, because the current definition looks for any `".a"` before it
looks for ".b".
With this change, it traverses the directory structure once, looking for any
element of the list before moving up a level. So now the same call returns
`".../foo/bar/baz/"`, which matches the documented behavior of returning the
bottommost matched directory.
Fixes #1796
|
|
They should return the bottommost directory that contains a matching file, not
the bottommost directory for the first file matched.
Incidentally, reordered the files created for the test, so it’s easier to follow
the hierarchy. This also necessitated changing `projectile-test-with-files` so
that attempting to create a file before creating the directory that contains it
didn’t fail.
|
|
|
|
|
|
|
|
|
|
This address potential issues with project root discovery - e.g. before this change projectile-project-type could return the wrong project type when called with a dir argument, as this was not propagated properly.
|
|
|
|
|
|
|
|
Functions `projectile-add-dir-local-variable` and `projectile-delete-dir-local-variable`
wraps their built-in counterparts. They always use `.dir-locals.el` from root of projectile project.
|
|
|
|
I had flipped the order of concat's arguments by accident.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit f5a2a3ab268b905c796de255e04790e6e69a61ab.
This out we already had this functionality under the name
`projectile-globally-ignored-buffers`.
|
|
|
|
|
|
|
|
|
|
|
|
are closed
|
|
|
|
|
|
|
|
I totally forgot to do this at release time. :(
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Task is a task runner.
go-task/task support multile file name (Taskfile.yml, Taskfile.yaml, Taskfile.dist.yml, Taskfile.dist.yaml),
but this patch just support Taskfile.yml for now.
Reference: https://taskfile.dev/
|
|
The behaviour of projectile-ripgrep was inconsistent depending on
which package was being used. If the rg package was being used, hidden
files were included in the search, while if the ripgrep package was
being used, hidden files were excluded. This commit ensures that
hidden files are now consistently included, which is consistent with
the behaviour of other searches (like grep).
|
