Skip to content

Conversation

@staticfloat
Copy link
Member

This causes the eval to be invoked in user scope, rather than in the Artifacts module itself.

X-ref: #46755 (review)

find_artifacts_toml(srcfile)
else
eval(artifacts_toml_path)
Core.eval(__module__, artifacts_toml_path)
Copy link
Member

Choose a reason for hiding this comment

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

Instead of eval use getfield? But that may just be personal taste.

Copy link
Member Author

Choose a reason for hiding this comment

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

How would you use getfield? In this case, artifacts_toml_path could be an expression, rather than a quoted string.

Copy link
Member

Choose a reason for hiding this comment

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

I would prefer not using a runtime/order dependent lookup here. eval inside a macro is for me a code-smell. Either the data is a literal and can be relied upon, or it is a runtime value and we should defer it's evaluation to inside the quote block.

@simeonschaub
Copy link
Member

Couldn't we just require this to always be a literal string? Consumers could still do @eval @artifact_str "foo" $bar if this was really needed. Calling eval in a macro just seems like a bad idea and I could see this causing issues in environments like Pluto.

@KristofferC
Copy link
Member

Couldn't we just require this to always be a literal string?

That was the original idea but Elliot added the eval in (0f309bc), likely due to some use case that I had not thought about.

@StefanKarpinski
Copy link
Member

Can we revert that? This seems quite fishy.

My assertion in the previous attempt to fix this issue was incorrect:

> We define a simpler match as one that has fewer tags overall.
> As these candidate matches have already been filtered to match the
> given platform, the only other tags that exist are ones that are in
> addition to the tags declared by the platform.  Hence, selecting the
> minimum in number of tags is equivalent to selecting the closest match.

This is demonstrably false, by my own test case:

```
platforms = Dict(
    Platform("x86_64", "linux") => "bad",
    Platform("x86_64", "linux"; sanitize="memory") => "good",
)
select_platform(platforms, Platform("x86_64", "linux"; sanitize="memory")) == "good"
```

In this case, because there exists a candidate that is _more general_
than the provided platform type, the shortest match is no longer the
best match.

This PR performs a more rigorous matching that works more reliably in
all cases.
@staticfloat staticfloat deleted the sf/fix_artifacts branch April 25, 2023 22:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants