Before this commit, the LLVM IR of exported items was simply zip-compressed and stored as an object file inside rlib archives. This commit adds a header to this "object" containing a file identifier and a format version number so the compiler can deal with changes in the way bytecode objects are stored within rlibs.
While updating the format of bytecode objects, this commit also worksaround a problem in LLDB which could not handle odd-sized objects within archives before mid-2014.
This PR introduces a couple of minor changes to the rustdoc html templates:
1. The `<meta name="generator" content="rustdoc">` tag now appears in API documentation as well.
2. Adds a `rustdoc` class to the top-level `<body>` tag on all HTML pages.
The second point is a nice-to-have for those who would like to apply a user stylesheet to Rust documentation regardless of where it is hosted. Easier use of user stylesheets may alleviate much of the bikeshedding of personal taste on the rustdoc styles.
The reference manual said that code is interpreted as UTF-8 text and a
implementation will normalize it to NFKC. However, rustc doesn't do
any normalization now.
We may want to do any normalization for symbols, but normalizing whole
text seems harmful because doing so loses some sort of information even
if we choose a non-K variant of normalization.
I'd suggest removing "normalized to Unicode normalization form NFKC"
phrase for the present so that the manual represents the current state
properly. When we address the problem (with a RFC?), then the manual
should be updated.
Closes#12388.
Reference: https://github.com/rust-lang/rust/issues/2253
Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
When I originally wrote the read_u32v_be() and write_u32_be() functions, I didn't consider memory alignment requirements of various architectures. Unfortunately, the current implementations may result in unaligned reads and writes. This doesn't impact x86 / x86_64, but it can cause a compiler crash on ARM. This pull requests rewrites those functions to make sure that all memory access is always correctly aligned.
This fix is a little bit academic - due to the way that LLVM aligns the structures that are passed as arguments to these functions, I believe that the end result is that all memory access happens to be aligned anyway. However, there is nothing in that code that actually enforces that, at least not explicitly. The new implementations are definitely slower than the existing ones. However, I don't believe that these functions are all that significant when looking at the overall performance of the compiler. I think getting rid of some unsafe code and removing a potential portability landmine justifies a very slight decrease in raw performance.
<strike>Adds a simple/detailed toggle to api doc pages.
Detailed mode is the current behaviour, simple mode hides all doccomment details leaving only signatures for quick browsing.
</strike>
Adds [expand all] and [collapse all] "links" to all api doc pages. All doccomments are collapsed, leaving only signatures for quick browsing.
In addition, clicking on a <strike>function name</strike> function's [toggle details] link now toggles the visibility of the associated doccomment.
--------
# [Live Build Here](http://cg.scs.carleton.ca/~abeinges/doc/std/vec/struct.Vec.html)
This is something that's been bothering me, and I've seen some people mention in IRC before. The docs are *great* if you want a full in-depth look at an API, but *awful* if you want to scan them. This provides the ability to toggle complexity freely. Interacts perfectly well with noscript, since the static page is effectively unchanged. Collapsing is just hiding divs with css.
I'm not much of a designer, so design input welcome on the actual UX for toggling.
The actual javascript is *a bit* brittle to layout changes, but it always will be without adding lots of extra junk to the actual markup, which didn't seem worth it.
All doccomments are now collapsable via a nearby [-] button
Adds [collapse all] and [expand all] buttons to the top of all api pages
Tweaks some layout to accomadate this
This is the next section of the guide, and it's on pointers. It's not done yet, as I need to write the section on ownership and borrowing, but I figured I'd share the rest now, to get feedback on the rest of it while I take some time to get that right.
The current spsc implementation doesn't enforce single-producer
single-consumer usage and also allows unsafe memory use through
peek & pop.
For safer usage, `new` now returns a pair of owned objects which
only allow consumer or producer behaviors through an `Arc`.
Through restricting the mutability of the receiver to `mut` the
peek and pop behavior becomes safe again, with the compiler
complaining about usage which could lead to problems.
To fix code broken from this, update:
Queue::new(x) -> unsafe { Queue::unchecked_new(x) }
[breaking-change]
For an example of broken behavior, check the added test which uses the unchecked constructor.
