-
Notifications
You must be signed in to change notification settings - Fork 17
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.
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
Reading files from within const eval #44
Comments
It's not yet possible to share the machinery between const fn foo() -> String {
File::open("foo.txt").unwrap().read_to_string()
} you will get different results when calling this function from different crates, because each crate will resolve I don't think we need to take care to ignore the Two important thing we need to take care of:
|
That would take care of dynamically computing the filename. However, @joshtriplett also asked to be able to read parts of a file without reading the whole file, which this would not do.
Why that? Does
|
Because... we can do it? No need to start out a new feature without sandboxing if we can sandbox it from the start
That's actually fine, because if recomputing the query causes the result to differ, it will poison all queries that called this query and force them to get recomputed, too. So you don't get any behaviour where if you have a dataflow from such a file to an array length, the array length changes within the same compilation. |
On Wed, Jun 24, 2020 at 11:57:26PM -0700, Ralf Jung wrote:
> In order for const eval to be able to read from files, we need to add a query that goes from (CrateNum, PathBuf) to &'tcx [u8] by reading the entire file in one go and interning it. This means that if you have a
That would take care of dynamically computing the filename. However, @joshtriplett also asked to be able to read parts of a file without reading the whole file, which this would not do.
That would be nice, but not necessary right away. I'd like the `File`
API to just work in const eval, but it's fine for now if it just reads
the entire file into memory and doesn't try to read only a subset.
|
How could this still hold with arbitrary file access which whose content can change at any point? |
Why does |
Proc macros are like code that generates .rs files. They are executed once upfront and then produce the input for the rest of complication. Constants can be evaluated multiple times. E.g. when you have something like impl<T, U> Trait for Type<T, U> {
const C: Type = ...;
} The value of |
(Filing this at @oli-obk's request, based on discussions on Zulip.)
We should be able to read files within const eval. This is equivalent to doing
include_bytes!
(which we already support at compile time), and should use the same machinery for "rebuild if this changes".@oli-obk suggested that this could work by tagging specific portions of low-level file I/O as something akin to lang items, and then implementing that low-level file I/O by invoking the machinery that powers
include_bytes!
.The text was updated successfully, but these errors were encountered: