nixbot

builds

failed iets-ast-grep checks.aarch64-linux.ast-grep · build #766 · raw

1elastic-arm-3e34f16b: building 5wcnsbxndhnjl9vaimixzn8gliw1mxf2-iets-ast-grep.drv2error[no-function-level-use]: move this `use` to the top of the module3 ┌─ tests/pure.rs:210:54 │ 5209 │ ╭ fn linked() -> TempDir {6210 │ │ use std::os::unix::fs::symlink;7 │ │ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^8 · │9223 │ │ }10 │ ╰─'1112error[no-inline-absolute-paths]: use a `use` import instead of an inline crate::/super::/std:: path13 ┌─ src/builtins/store_hooks.rs:261:1614 │15261 │ let path = crate::compile::canon_path(path);16 │ ^^^^^^^^^^^^^^^^^^^^^^^^^^1718error[no-comment-essays]: comment block of 8+ lines; condense it to the WHY19 ┌─ src/builtins/store_hooks.rs:191:120 │ 21184 │ ╭ /// the path resolution ended at, and its place in the (virtual) store, `None`22185 │ │ ╭ /// for one the real file system answers. [`resolve_links`] runs under a store23 │ ╰────────────'24186 │ │ ╭ /// path this evaluation copied from a local tree, and in a pure evaluation25 │ ╰──────────'26187 │ │ ╭ /// under the project: there the kernel would follow a link out of the allow27 │ ╰────────'28188 │ │ ╭ /// list, which is judged on the text of the path. A fetched input's spool29 │ ╰──────'30189 │ │ ╭ /// resolves a member's links inside the entry itself, and elsewhere the31 │ ╰────'32190 │ │ ╭ /// kernel resolves as the accessor would, so the walk is skipped and this33 │ ╰──'34191 │ ╭ │ /// costs the one lookup the reader needed anyway.35 │ │ ╰'36192 │ │ ╭ pub fn located(37 │ ╰────────────────^38 · │ 39217 │ │ }40 │ ╰───────────────'4142Error: 3 error(s) found in code.43Help: Scan succeeded and found error level diagnostics in the codebase.44