You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running make check, it failed during the doc-std target with 244 failures and 0 successes. All of them produced an error of the form "'couldn't run the test: permission denied', [snip]/rust/src/librustdoc/test.rs:131".
Investigating this further, it turns out to be because rustdoc's test.rs attempts to create a file in a temporary directory and then execute it. By default on my platform, this happens in /tmp. My /tmp, however, is mounted with the "noexec" option that prevents executing files from it.
Arguably this is just user error on my part for configuring things this way, but I don't think it's an uncommon setup. It was also quite a mysterious way for things to fail. Perhaps the test runner could check for this and fail more usefully?
In the meantime, a workaround is to run the tests with the environment variable TMPDIR set to something else.
The text was updated successfully, but these errors were encountered:
[`let_and_return`]: avoid linting when code between last stmt and return expr is cfg'd out
Fixesrust-lang#9150
This moves `span_contains_cfg` to utils and starts using it in `let_and_return` as well.
changelog: [`let_and_return`]: avoid linting when code between the last statement and the final return expression is `#[cfg]`ed out
When running
make check
, it failed during thedoc-std
target with 244 failures and 0 successes. All of them produced an error of the form "'couldn't run the test: permission denied', [snip]/rust/src/librustdoc/test.rs:131".Investigating this further, it turns out to be because rustdoc's
test.rs
attempts to create a file in a temporary directory and then execute it. By default on my platform, this happens in/tmp
. My/tmp
, however, is mounted with the "noexec" option that prevents executing files from it.Arguably this is just user error on my part for configuring things this way, but I don't think it's an uncommon setup. It was also quite a mysterious way for things to fail. Perhaps the test runner could check for this and fail more usefully?
In the meantime, a workaround is to run the tests with the environment variable
TMPDIR
set to something else.The text was updated successfully, but these errors were encountered: