When generating documentation, rustdoc has the ability to generate relative
links within the current distribution of crates to one another. To do this, it
must recognize when a crate's documentation is in the same output directory. The
current threshold for "local documentation for crate X being available" is
whether the directory "doc/X" exists.
This change modifies the build system to have new dependencies for each
directory of upstream crates for a rustdoc invocation. This will ensure that
when building documentation that all the crates in the standard distribution are
guaranteed to have relative links to one another.
This change is prompted by guaranteeing that offline docs always work with one
another. Before this change, races could mean that some docs were built before
others, and hence may have http links when relative links would suffice.
Closes#14747
**Update**
I've reimplemented this using `Cell` and `RefCell`, as suggested by @alexcrichton. By taking care with the duration of the borrows, I was able to maintain the recursive allocation feature (now covered by a test) without the use of `Unsafe`, and without breaking the non-aliasing `&mut` invariant.
**Original**
Changes both `Arena` and `TypedArena` to contain an inner struct wrapped in a `Unsafe`, and change field access to go through those instead of transmuting `&self` to `&mut self`.
Part of #13933
Previously, the type system's restrictions on borrowing were summarized as
> The previous example showed that the type system forbids any borrowing of owned boxes found in aliasable, mutable memory
This did not jive with the example, which allowed mutations so long as the borrowed reference had been returned. Also, the language has changed to no longer allow aliasable mutable locations. This changes the summary to read
> The previous example showed that the type system forbids mutations of owned boxed values while they are being borrowed. In general, the type system also forbids borrowing a value as mutable if it is already being borrowed - either as a mutable reference or an immutable one.
This adds more general information for the experienced reader as well, to offer a more complete understanding.
The guide previously stated:
> The compiler will automatically convert a box box point to a reference like &point.
This fixes the doubled word `box`, so the statement reads
> The compiler will automatically convert a box point to a reference like &point.
The code it is referring to is `compute_distance(&on_the_stack, on_the_heap);`, so a single `box` is appropriate.
This uncovered some dead code, most notably in middle/liveness.rs, which I think suggests there must be something fishy with that part of the code.
The #[allow(dead_code)] annotations on some of the fields I am not super happy about but as I understand, marker type may disappear at some point.
Previously, constants used unsigned extension, while non-constants used
signed extension. This unifies both paths to use signed extension.
If this breaks your code, take a deep breath, go for a walk, and
consider why you're relying on the sign extension semantics of
enum-to-float casts.
Closes#8230.
[breaking-change]
Both of these items are surfaced as a DefTy, so some extra logic was needed in
the decoder module to figure out whether one is actually an enum or whether it's
a typedef.
Closes#14757
This refers to green, which (AFAICT) has everything implemented. In
particular, this will help guide people to get working signal handling
via libgreen.
These functions are all much better expressed via RAII using the to_utf16()
method on strings. This refactoring also takes this opportunity to properly
handle when filenames aren't valid unicode when passed through to the windows
I/O layer by properly returning I/O errors.
All previous users of the `as_utf16_p` or `as_utf16_mut_p` functions will need
to convert their code to using `foo.to_utf16().append_one(0)` to get a
null-terminated utf16 string.
[breaking-change]
This implements the design in rust-lang/rfcs#86. It shouldn't be merged until that RFC is accepted, but it would be great if somebody has time to review the code before then.
When generating documentation, rustdoc has the ability to generate relative
links within the current distribution of crates to one another. To do this, it
must recognize when a crate's documentation is in the same output directory. The
current threshold for "local documentation for crate X being available" is
whether the directory "doc/X" exists.
This change modifies the build system to have new dependencies for each
directory of upstream crates for a rustdoc invocation. This will ensure that
when building documentation that all the crates in the standard distribution are
guaranteed to have relative links to one another.
This change is prompted by guaranteeing that offline docs always work with one
another. Before this change, races could mean that some docs were built before
others, and hence may have http links when relative links would suffice.
Closes#14747
