This diff will look better once bors takes care of https://github.com/rust-lang/rust/pull/15183
@brson and I talked about it, and, if I commit this skeleton, I can submit PRs for each portion, without doing this silly "builds on previous PRs" stuff, and it shouldn't cause conflicts.
This lays out what I think the guide should cover, and in what order. I haven't picked a cohesive project yet that shows all this off, but I think this progression of concepts is appropriate.
We use re-exported pathes (e.g. std::io::Command) and original ones
(e.g. std::io::process::Command) together in examples now. Using
re-exported ones consistently avoids confusion.
Since procs do not have lifetime bounds, we must do this to maintain
safety.
This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.
Closes#14036.
[breaking-change]
r? @alexcrichton
Since procs do not have lifetime bounds, we must do this to maintain
safety.
This can break code that incorrectly captured references in procedure
types. Change such code to not do this, perhaps with a trait object
instead.
A better solution would be to add higher-rank lifetime support to procs.
However, this would be a lot of work for a feature we want to remove in
favor of unboxed closures. The corresponding "real fix" is #15067.
Closes#14036.
[breaking-change]
We use re-exported pathes (e.g. std::io::Command) and original ones
(e.g. std::io::process::Command) together in examples now. Using
re-exported ones consistently avoids confusion.
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.
Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.
Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.
Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.
Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
What's funny about this one is that spellcheck caught it, but for
some reason didn't give me the right suggestion, so I assumed that it
wasn't in my dictionary. Oh well.
Thanks @P1start! ❤️
The JSON spec requires that these special values be serialized as "null"; the current serialization breaks any conformant JSON parser. So encoding needs to output "null", `to_json` on floating-point types can return `Null` as well as `Number` values, and reading a `Null` value when specifically expecting a number should be interpreted as NaN. There's no way to round-trip Infinity through JSON.
This is my first attempt at both writing Rust and opening pull requests, so please dial your derp detector up to eleven when reviewing. A `rustc --test lib.rs` in `libserialize` passes all tests; a `make check` of the whole tree fails with the error below, but it doesn't look obviously related and the docs say that `make check` is known to be flaky on Windows.
---- [compile-fail] compile-fail/svh-change-significant-cfg.rs stdout ----
task '[compile-fail] compile-fail/svh-change-significant-cfg.rs' failed at 'called `Result::
unwrap()` on an `Err` value: couldn't create file (end of file (unknown error); path=i686-pc-mingw32
\test\compile-fail\svh-a-base.err; mode=truncate; access=write)', C:\msys\home\Mike\rust\src\libcore
\result.rs:545
Incidentally, it may just be my lack of familiarity with the language and its idioms, but the duplication between `Encoder`/`PrettyEncoder` had a distinct code smell to it. The size of the file (~3500 lines) also made it a bit hard to navigate. Has there been any discussion of refactoring and/or breaking it up? I couldn't find anything in Issues except the ancient #9028.
This is built on top of https://github.com/rust-lang/rust/pull/15162 . cccae83d92 is the only new commit, you may want to look at that rather than the whole diff.
Writing our first Rust program together. This is the most crucial step, so I go to a fairly deep level of detail. Future sections will move more quickly.
This has my voice *very strongly*. I'm not sure if it's too much. I'd find it okay if I had to tone it back, and I don't want it to be _too strong_, but clinical docs are boring.
It turns out that bindings introduced by 'for' loops were not treated hygienically. The fix for this is to make the 'for' expansion more like a macro; rather than expanding sub-pieces and then assembling them, we need to rewrite the for and then call expand again on the whole thing.
This PR includes a test and the fix.
It also contains a number of other things:
- unit tests for other forms of hygiene (currently ignored)
- a fix for the isaac.rs macro that (it turned out) was relying on capturing
- other miscellaneous cleanup and comments
The JSON spec requires that these special values be serialized as null; the current serialization breaks any conformant JSON parser. So encoding needs to output "null", to_json on floating-point types can return Null as well as Number, and reading null when specifically expecting a number should be interpreted as NaN. There's no way to round-trip Infinity.
