8000 assorted: update nickel dep, set initial-env instead of writing files to disk by twitchyliquid64 · Pull Request #218 · gominimal/minimal · GitHub
[go: up one dir, main page]
Skip to content

assorted: update nickel dep, set initial-env instead of writing files to disk #218

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
twitchyliquid64 merged 1 commit into from
May 22, 2026
Merged

assorted: update nickel dep, set initial-env instead of writing files to disk #218

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
7 changes: 4 additions & 3 deletions Cargo.lock
View file
Open in desktop

Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.

2 changes: 1 addition & 1 deletion Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -57,7 +57,7 @@ jaq-all = "0.1.0"
lzma-rs = "0.3"

# Revert back to crates.io dep once 0.18 is released.
nickel-lang-core = { git = "https://github.com/nickel-lang/nickel.git", rev = "3a399233dcb5b5e8610a1245eeb171c29787a903", default-features = false, features = ["format"] }
nickel-lang-core = { git = "https://github.com/nickel-lang/nickel.git", rev = "5bf193c843bdd5fe87aac288d1b1e32a945c2f29", default-features = false, features = ["format"] }

nix = { version = "0.31", features = ["fs"] }
object = { version = "0.39", default-features = false, features = ["archive", "elf", "read_core", "std"] }
Expand Down
1 change: 1 addition & 0 deletions crates/args/Cargo.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -8,6 +8,7 @@ publish.workspace = true

[dependencies]
clap.workspace = true
nickel-lang-core.workspace = true
serde.workspace = true
shlex.workspace = true
toml.workspace = true
Expand Down
53 changes: 18 additions & 35 deletions crates/args/src/lib.rs
View file
Open in desktop
8BD0
Original file line number Diff line number Diff line change
Expand Up @@ -156,16 +156,16 @@ impl Hash for ScalarArg {
}

impl ScalarArg {
/// Append the nickel literal representation of this value to `buf`.
pub fn write_nickel(&self, buf: &mut String) {
/// Returns this value as a Nickel value, suitable for use in an
/// initial-env binding.
pub fn to_nickel(&self) -> nickel_lang_core::eval::value::NickelValue {
use nickel_lang_core::eval::value::NickelValue;
match self {
ScalarArg::String(s) => {
buf.push('"');
buf.push_str(s);
buf.push('"');
ScalarArg::String(s) => NickelValue::string_posless(s.as_str()),
ScalarArg::Number(f) => {
NickelValue::number_posless(nickel_lang_core::term::Number::try_from(*f).unwrap())
}
Comment on lines +165 to 167
@coderabbitai coderabbitai Bot May 22, 2026
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🌐 Web query:

Does nickel-lang-core Number::try_from fail for NaN and Infinity f64 values?

💡 Result:

No definitive evidence found in the searched sources that directly answers whether nickel-lang-core’s Number::try_from fails (returns Err) specifically for f64 NaN and ±Infinity. What I can say from the evidence gathered: 1) The available nickel-lang-core documentation pages in the search results don’t expose the implementation or behavior of Number::try_from for f64 NaN/Infinity (the rustdoc snippets shown are general crate docs, not the conversion implementation). 2) The search turned up Nickel issues/PRs about YAML/serialization panics and large numbers, but nothing in those results discusses NaN/Infinity handling for Number::try_from. 3) The only authoritative “NaN/Infinity” behavior I found in the evidence is about Rust f64 itself (NaN/Infinity are representable) and about Malachite float conversions, neither of which is directly tied to nickel-lang-core’s Number::try_from. If you want, I can do one more targeted search by opening the exact source file that defines nickel-lang-core::term::Number::try_from (or searching within t 8000 he nickel-lang-core crate sources for “try_from” and “Number::try_from”), then verify the NaN/Infinity branches precisely.

Citations:

🏁 Script executed:

# Find Cargo.toml to understand dependencies
fd -t f "Cargo.toml" | head -20

Repository: gominimal/minimal

Length of output: 556

🏁 Script executed:

# Look at the structure of the crates directory
ls -la crates/

Repository: gominimal/minimal

Length of output: 1245

🏁 Script executed:

# Check the specific crate's Cargo.toml
cat crates/args/Cargo.toml

Repository: gominimal/minimal

Length of output: 388

🏁 Script executed:

# Check the root Cargo.toml for workspace definition
cat Cargo.toml | head -80

Repository: gominimal/minimal

Length of output: 2456

🏁 Script executed:

# Search for nickel-lang-core definition
rg "nickel-lang-core" --type toml | head -20

Repository: gominimal/minimal

Length of output: 1312

🏁 Script executed:

# View the file at the exact location mentioned in the review
cat -n crates/args/src/lib.rs | sed -n '150,180p'

Repository: gominimal/minimal

Length of output: 1210

🏁 Script executed:

# Get more context around the function
cat -n crates/args/src/lib.rs | sed -n '140,195p'

Repository: gominimal/minimal

Length of output: 2194

🏁 Script executed:

# Search for the parsing logic and PrimitiveSpec
rg "PrimitiveSpec" crates/args/src/lib.rs -A 10 -B 2

Repository: gominimal/minimal

Length of output: 6864

🏁 Script executed:

# Search for where ScalarArg::Number is created
rg "ScalarArg::Number" crates/args/src/lib.rs -B 5 -A 2

Repository: gominimal/minimal

Length of output: 3000

🏁 Script executed:

# Search for any tests in this file that might use NaN or Infinity
rg "NaN|Infinity" crates/args/src/lib.rs

Repository: gominimal/minimal

Length of output: 43

🏁 Script executed:

# Check if there are any error handling tests for number conversion
rg "to_nickel" crates/args/src/lib.rs -A 3 -B 3

Repository: gominimal/minimal

Length of output: 982

🌐 Web query:

nickel-lang Number::try_from implementation f64 NaN Infinity

💡 Result:

I couldn’t find (in the sources surfaced by the searches) Nickel’s specific Number::try_from implementation that handles f64 inputs like NaN, +Infinity, or -Infinity. What I can support from authoritative Nickel sources is: 1) Nickel’s user-facing number type is arbitrary-precision rationals internally, but during deserialization it goes through 64-bit floating point numbers (“Numbers are deserialized as 64-bit floating point numbers, in line with common JSON implementations”) [1]. 2) Nickel’s stdlib documentation explicitly notes that when operating with pow, if exponent/result fallbacks to float are used, the docs exclude NaN and infinity from that float conversion path [2]. So, the likely behavior of Number::try_from(f64) with NaN/Infinity is somewhere in Nickel’s Rust core conversions (probably involving Malachite’s float/Float conversions), but the exact match arm / error-or-success behavior for NaN and Infinity is not present in the results I retrieved. If you want, paste a link to the Rust file/line where Number::try_from (or the TryFrom<f64> for Number impl) lives in your Nickel version, and I can precisely extract and summarize how it treats NaN and ±Infinity with line-level citations.

Citations:

🏁 Script executed:

# Search for test cases that might exercise to_nickel or provide insight
rg "test" crates/args/src/lib.rs -i | head -30

Repository: gominimal/minimal

Length of output: 291

🏁 Script executed:

# Look at the test section of the file
cat -n crates/args/src/lib.rs | tail -200 | head -100

Repository: gominimal/minimal

Length of output: 3957

🏁 Script executed:

# Check if there are any clues in Cargo.lock about the exact version/commit of nickel-lang-core
grep -A 10 "name = \"nickel-lang-core\"" Cargo.lock | head -15

Repository: gominimal/minimal

Length of output: 371

🏁 Script executed:

# Look for any edge case testing or NaN/Infinity handling in tests
rg "parse.*[Nn]a[Nn]|parse.*[Ii]nf" crates/args/src/lib.rs

Repository: gominimal/minimal

Length of output: 43

🏁 Script executed:

# Check what happens when parsing edge case strings
cat -n crates/args/src/lib.rs | sed -n '940,1000p'

Repository: gominimal/minimal

Length of output: 2345

🏁 Script executed:

# Test what Rust's f64 parser does with NaN/Infinity strings
python3 << 'EOF'
# Simulate what Rust's f64 parser does
test_strings = ["NaN", "Infinity", "-Infinity", "inf", "-inf", "nan", "1.5", "abc"]
for s in test_strings:
    try:
        f = float(s)
        print(f"{s:20} -> {f:20} (finite: {str(float('nan')).lower() not in str(f).lower() and str(float('inf')).lower() not in str(f).lower()})")
    except ValueError as e:
        print(f"{s:20} -> ERROR: {e}")
EOF

Repository: gominimal/minimal

Length of output: 559

🌐 Web query:

Rust f64 parsing "NaN" "Infinity" parse method

💡 Result:

In Rust, the f64::from_str method—which is invoked when calling str::parse::—fully supports parsing special floating-point values, including "NaN", "Infinity", and their signed variants [1][2]. When parsing a string to f64, the input is treated in a case-insensitive manner [1]. The parser accepts the following variations [1]: - "inf", "infinity", "+inf", "+infinity", "-inf", "-infinity" (all map to the corresponding infinity value) [1][2] - "nan", "+nan", "-nan" (all map to NaN) [1] The parsing logic follows a specific EBNF grammar [1]. If a string does not match the valid floating-point format, the method returns an Err(ParseFloatError) [1][3]. Note that these special values are only supported by the standard from_str implementation for f32 and f64; they are not supported by from_str_radix, which strictly parses numeric characters [2].

Citations:

🌐 Web query:

site:github.com/nickel-lang/nickel Number try_from f64 implementation

💡 Result:

There is no standard library Number type in Rust that implements TryFrom. The TryFrom trait in Rust's standard library is designed for safe, fallible conversions between types. While specific crates or third-party libraries may define their own Number types and implement TryFrom for them, it is not a feature of the Rust standard library itself. In the context of the Nickel configuration language (which is implemented in Rust), developers may work with arbitrary-precision numbers or other custom number representations [1][2], but these are specific to that project and not a general Rust language standard [3]. If you are encountering this in code, it is likely a custom implementation within the specific codebase you are examining [1][3].

Citations:

🌐 Web query:

nickel-lang-core Number type finite nan infinity constraints

💡 Result:

In Nickel, the Number type is implemented as an arbitrary-precision rational number [1][2]. Because it uses this representation, it inherently does not support IEEE 754 concepts such as NaN (Not-a-Number), positive infinity, or negative infinity [1][2]. Key characteristics of the Nickel Number type include: - Exact Arithmetic: Basic arithmetic operations (addition, subtraction, multiplication, and division) are performed on rationals and do not incur rounding errors [2]. - Conversion Behavior: While Nickel defaults to arbitrary-precision rationals, certain operations—specifically non-integral exponentiation via std.number.pow—may convert operands to 64-bit floating-point numbers to perform the calculation [1][2]. In these specific cases, if the resulting value exceeds the range of a 64-bit float, or if the operation involves values that would typically produce NaN or infinity, the behavior is governed by floating-point arithmetic; however, these resulting values are converted back to rationals, and the language is designed to avoid IEEE 754 artifacts like NaN and infinity in its primary representation [1]. - Constraints: Since Nickel does not natively represent NaN or infinity as Number values, standard programs do not encounter them. If you need to enforce constraints such as finite range, you must define custom contracts [3][4]. For example, you can use a contract to restrict a number to a specific range (e.g., value >= 0 && value <= 65535) [3]. In summary, Nickel's core design prioritizes precision through rationals over IEEE 754 floating-point behavior, effectively eliminating NaN and infinity from the Number type's standard domain [1][2].

Citations:

🏁 Script executed:

# Check if there are any existing tests for NaN/Infinity in the parsing
rg "NaN|Infinity|to_nickel" crates/ --type rust

Repository: gominimal/minimal

Length of output: 811

unwrap() on Number::try_from will panic for non-finite floats.

Nickel's Number type represents arbitrary-precision rationals and does not support NaN, positive infinity, or negative infinity. The parsing code accepts these values—Rust's f64::parse() successfully parses "NaN", "Infinity", and "-Infinity"—so a user can provide such input, which will then panic when Number::try_from(*f).unwrap() is called. Validate inputs in PrimitiveSpec::parse to reject non-finite numbers:

Proposed fix 
PrimitiveSpec::Number => {
    let f: f64 = s
        .parse()
        .map_err(|_| format!("expected a number, got `{s}`"))?;
+   if !f.is_finite() {
+       return Err(format!("expected a finite number, got `{s}`"));
+   }
    Ok(ScalarArg::Number(f))
}
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/args/src/lib.rs` around lines 165 - 167, The code is calling
Number::try_from(...).unwrap() in the ScalarArg::Number arm which will panic for
non-finite f64 (NaN/inf); update PrimitiveSpec::parse to validate floats are
finite before attempting conversion and reject non-finite inputs (return an Err
or parse failure) and remove the unwrap in the ScalarArg::Number handling so
conversion errors are propagated instead of panicking—specifically check
f.is_finite() in PrimitiveSpec::parse, return a clear parse error for non-finite
values, and replace unwrap() in the ScalarArg::Number ->
NickelValue::number_posless(Number::try_from(...)) path with proper error
handling that forwards Number::try_from failures.

ScalarArg::Number(f) => buf.push_str(&f.to_string()),
ScalarArg::Boolean(b) => buf.push_str(if *b { "true" } else { "false" }),
ScalarArg::Boolean(b) => NickelValue::bool_value_posless(*b),
}
}
}
Expand All @@ -179,36 +179,19 @@ pub enum Arg {
}

impl Arg {
/// Append the nickel literal representation of this value to `buf`.
pub fn write_nickel(&self, buf: &mut String) {
/// Returns this value as a Nickel value, suitable for use in an
/// initial-env binding.
pub fn to_nickel(&self) -> nickel_lang_core::eval::value::NickelValue {
use nickel_lang_core::eval::value::{Array, NickelValue};
match self {
Arg::Scalar(s) => s.write_nickel(buf),
Arg::Enum(s) => {
buf.push('"');
buf.push_str(s);
buf.push('"');
}
Arg::Array(v) => {
buf.push('[');
for (i, s) in v.iter().enumerate() {
if i > 0 {
buf.push_str(", ");
}
s.write_nickel(buf);
}
buf.push(']');
}
Arg::Scalar(s) => s.to_nickel(),
Arg::Enum(s) => NickelValue::string_posless(s.as_str()),
Arg::Array(items) => NickelValue::array_posless(
Array::from_iter(items.iter().map(ScalarArg::to_nickel)),
Vec::new(),
),
}
}

/// Write a `let <ident> = <value> in\n` binding into `buf`.
pub fn write_nickel_binding(&self, ident: &str, buf: &mut String) {
buf.push_str("let ");
buf.push_str(ident);
buf.push_str(" = ");
self.write_nickel(buf);
buf.push_str(" in\n");
}
}

/// The leaf scalar types an argument can have.
Expand Down
61 changes: 42 additions & 19 deletions crates/check/src/lib.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -665,37 +665,61 @@ impl FileBasedChecker for ParseCheck {
}

use nickel_lang_core::error::report::report_as_str;
use nickel_lang_core::eval::value::{NickelValue, RecordData};
use nickel_lang_core::identifier::{Ident, LocIdent};
use nickel_lang_core::program::{BuilderError, ProgramBuilder};
use nickel_lang_core::{error::NullReporter, eval::cache::CacheImpl, program::Program};

let program_res = Program::new_from_source(
std::io::Cursor::new(format!(
"import \"{}\"",
pkg_dir.join("build.ncl").as_os_str().to_str().unwrap()
)),
"toplevel",
std::io::stderr(),
NullReporter {},
);
let target_val = NickelValue::record_posless(RecordData::with_field_values([
(
LocIdent::new("os"),
NickelValue::enum_tag_posless(LocIdent::new("Linux")),
),
(
LocIdent::new("arch"),
NickelValue::enum_tag_posless(LocIdent::new("Amd64")),
),
]));
let injected = NickelValue::record_posless(RecordData::with_field_values([
(LocIdent::new("target"), target_val),
(
LocIdent::new("args"),
NickelValue::record_posless(RecordData::default()),
),
]));

let program_res: Result<Program<CacheImpl>, _> = ProgramBuilder::new()
.add_source(
std::io::Cursor::new(format!(
"import \"{}\"",
pkg_dir.join("build.ncl").as_os_str().to_str().unwrap()
)),
"toplevel",
)
.add_import_paths([ctx.stdlib_dir.as_path()].iter())
.extend_initial_env(vec![(Ident::new("__minimal_injected_config"), injected)])
.with_reporter(NullReporter {})
.with_trace(std::io::stderr())
.build();

let mut program: Program<CacheImpl> = match program_res {
Ok(p) => p,
Err(e) => {
let msg = match e {
BuilderError::NoInputs => unreachable!(),
BuilderError::Io { path, error } => match path {
Some(p) => format!("{}: {}", p.display(), error),
None => format!("{}", error),
},
};
return Ok(CheckResult {
check: "parse".into(),
verdict: CheckVerdict::Fail,
err: vec![format!("{}", e)],
err: vec![msg],
});
}
};

let generated_lib_dir = tempfile::TempDir::new().unwrap();
std::fs::write(
generated_lib_dir.path().join("__injected_config__.ncl"),
b"{target = {arch = 'Amd64, os = 'Linux}}",
)
.unwrap();
program.add_import_paths([ctx.stdlib_dir.as_path(), generated_lib_dir.path()].iter());

if let Err(e) = program.typecheck(nickel_lang_core::typecheck::TypecheckMode::Walk) {
return Ok(CheckResult {
check: "parse".into(),
Expand All @@ -719,7 +743,6 @@ impl FileBasedChecker for ParseCheck {
});
}

drop(generated_lib_dir);
Ok(CheckResult {
check: "parse".into(),
verdict: CheckVerdict::Pass,
Expand Down
42 changes: 26 additions & 16 deletions crates/check/src/profile.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -20,33 +20,43 @@ pub(crate) async fn check_profile(
let mut out = Vec::new();

use nickel_lang_core::error::report::report_as_str;
use nickel_lang_core::program::{BuilderError, ProgramBuilder};
use nickel_lang_core::{error::NullReporter, eval::cache::CacheImpl, program::Program};

let program_res = Program::new_from_source(
std::io::Cursor::new(format!(
"import \"{}\"",
profiles_dir
.join(&profile)
.join("profile.ncl")
.as_os_str()
.to_str()
.unwrap()
)),
"toplevel",
std::io::stderr(),
NullReporter {},
);
let program_res: Result<Program<CacheImpl>, _> = ProgramBuilder::new()
.add_source(
std::io::Cursor::new(format!(
"import \"{}\"",
profiles_dir
.join(&profile)
.join("profile.ncl")
.as_os_str()
.to_str()
.unwrap()
)),
"toplevel",
)
.add_import_paths([ctx.stdlib_dir.clone()].iter())
.with_reporter(NullReporter {})
.with_trace(std::io::stderr())
.build();

let mut program: Program<CacheImpl> = match program_res {
Ok(p) => p,
Err(e) => {
let msg = match e {
BuilderError::NoInputs => unreachable!(),
BuilderError::Io { path, error } => match path {
Some(p) => format!("{}: {}", p.display(), error),
None => format!("{}", error),
},
};
return Ok(vec![CheckResult::parse_failure(format!(
"loading failed: {}",
e
msg
))]);
}
};
program.add_import_paths([ctx.stdlib_dir.clone()].iter());

if let Err(e) = program.typecheck(nickel_lang_core::typecheck::TypecheckMode::Walk) {
return Ok(vec![CheckResult::parse_failure(report_as_str(
Expand Down
48 changes: 21 additions & 27 deletions crates/check/src/stack.rs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -19,51 +19,45 @@ pub(crate) async fn check_stack(
let mut out = Vec::new();

use nickel_lang_core::error::report::report_as_str;
use nickel_lang_core::program::{BuilderError, ProgramBuilder};
use nickel_lang_core::{error::NullReporter, eval::cache::CacheImpl, program::Program};

// TODO: Transitioning from 'harness' => 'stack', remove after May 2026
let program_res = if stacks_dir.join(&stack).join("harness.ncl").exists() {
Program::new_from_source(
std::io::Cursor::new(format!(
"import \"{}\"",
stacks_dir
.join(&stack)
.join("harness.ncl")
.as_os_str()
.to_str()
.unwrap()
)),
"toplevel",
std::io::stderr(),
NullReporter {},
)
let entry_file = if stacks_dir.join(&stack).join("harness.ncl").exists() {
stacks_dir.join(&stack).join("harness.ncl")
} else {
Program::new_from_source(
stacks_dir.join(&stack).join("stack.ncl")
};
Comment on lines +26 to +30
@coderabbitai coderabbitai Bot May 22, 2026
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Keep stack-name diagnostics aligned with the selected entry file.

Line 26-Line 30 can choose harness.ncl, but the failure message later is still hardcoded to stack.ncl. This can mislead users during triage.

Suggested fix 
 pub(crate) async fn check_stack(
@@
-    let entry_file = if stacks_dir.join(&stack).join("harness.ncl").exists() {
-        stacks_dir.join(&stack).join("harness.ncl")
+    let (entry_file, entry_filename) = if stacks_dir.join(&stack).join("harness.ncl").exists() {
+        (stacks_dir.join(&stack).join("harness.ncl"), "harness.ncl")
     } else {
-        stacks_dir.join(&stack).join("stack.ncl")
+        (stacks_dir.join(&stack).join("stack.ncl"), "stack.ncl")
     };
@@
-    out.push(check_stack_name(stack.clone(), ctx, &mut program)?);
+    out.push(check_stack_name(stack.clone(), entry_filename, ctx, &mut program)?);
-fn check_stack_name(
+fn check_stack_name(
     stack: String,
+    entry_filename: &str,
     ctx: &CheckCtx,
     program: &mut Program<CacheImpl>,
 ) -> Result<CheckResult, Error> {
@@
             return Ok(CheckResult::stack_name_fail(format!(
-                "stack defined in {}/stack.ncl has name {}",
+                "stack defined in {}/{} has name {}",
                 stack,
+                entry_filename,
                 s.as_str()
             )));
📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change
let entry_file = if stacks_dir.join(&stack).join("harness.ncl").exists() {
stacks_dir.join(&stack).join("harness.ncl")
} else {
Program::new_from_source(
stacks_dir.join(&stack).join("stack.ncl")
};
let (entry_file, entry_filename) = if stacks_dir.join(&stack).join("harness.ncl").exists() {
(stacks_dir.join(&stack).join("harness.ncl"), "harness.ncl")
} else {
(stacks_dir.join(&stack).join("stack.ncl"), "stack.ncl")
};
🤖 Prompt for AI Agents 
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@crates/check/src/stack.rs` around lines 26 - 30, The code selects an entry
file into the variable entry_file by checking for "harness.ncl" and falling back
to "stack.ncl", but later diagnostics still mention "stack.ncl"; update the
failure/diagnostic message to reference the actually selected entry file instead
of hardcoding "stack.ncl". Concretely, compute the chosen file name from
entry_file (e.g., entry_file.file_name() or a small string like chosen = if
harness exists { "harness.ncl" } else { "stack.ncl" }) and use that chosen name
in the diagnostic/emission site (the code that reports the missing/invalid
stack) so messages align with the selected entry file; adjust any surrounding
test strings or formatters that currently hardcode "stack.ncl".


let program_res: Result<Program<CacheImpl>, _> = ProgramBuilder::new()
.add_source(
std::io::Cursor::new(format!(
"import \"{}\"",
stacks_dir
.join(&stack)
.join("stack.ncl")
.as_os_str()
.to_str()
.unwrap()
entry_file.as_os_str().to_str().unwrap()
)),
"toplevel",
std::io::stderr(),
NullReporter {},
)
};
.add_import_paths([ctx.stdlib_dir.clone()].iter())
.with_reporter(NullReporter {})
.with_trace(std::io::stderr())
.build();

let mut program: Program<CacheImpl> = match program_res {
Ok(p) => p,
Err(e) => {
let msg = match e {
BuilderError::NoInputs => unreachable!(),
BuilderError::Io { path, error } => match path {
Some(p) => format!("{}: {}", p.display(), error),
None => format!("{}", error),
},
};
return Ok(vec![CheckResult::parse_failure(format!(
"loading failed: {}",
e
msg
))]);
}
};
program.add_import_paths([ctx.stdlib_dir.clone()].iter());

if let Err(e) = program.typecheck(nickel_lang_core::typecheck::TypecheckMode::Walk) {
return Ok(vec![CheckResult::parse_failure(report_as_str(
Expand Down
Loading
Loading
0