I have tested the result with w3m and I believe this is better than the current template. In detail:
- `section.sidebar` -> `nav.sidebar`, also added an unordered list.
- `div#help` -> `aside#help`, also added a hidden heading.
- The current crate is now emphasized in the sidebar.
Fixes#16310.
Conventionally in C `*mut T` is a transfer of ownership where `*const T` is a
loan, so `*mut T` is likely the more appropriate return type for these
functions. Additionally, this more closely mirrors the APIs on `Box` for this
sort of functionality.
cc #27769
This updates the jemalloc and LLVM submodules to the recently released 4.0.0 and 3.7 versions. There's no breakage on the LLVM side of things because we had already been tracking the 3.7 release branch for awhile and no breakage was introduced, and jemalloc apparently is stable enough that nothing broke!
- section.sidebar -> nav.sidebar, also added an unordered list.
- div#help -> aside#help, also added a hidden heading.
- the current crate is now emphasized in the sidebar.
Fixes#16310.
It's a large number of small improvements to the code, mostly readability-related, but removing closures and replacing `str::to_string()` with `.to_owned()` should also positively affect performance.
r? @Manishearth (once it compiles, of course 😄)
This can be shown with the example code
```rust
fn main() {
let () = include_bytes!("/etc/hosts");
}
Which will have the error:
expected `&[u8; 195]`,
found `()`
Generally, including everything that makes an unsafe block safe in the
block is good style. Since the assert! is what makes this safe, it
should go inside the block. I also added a few bits of whitespace.
This is of course, a little style thing, so no worries if we don't want this patch.
Generally, including everything that makes an unsafe block safe in the
block is good style. Since the assert! is what makes this safe, it
should go inside the block. I also added a few bits of whitespace.
This PR contains a new crate, `rustc_mir`, which implements the MIR as specified in the RFC (more or less). There are no targeted unit tests at the moment, as I didn't decide what kind of infrastructure would be best and didn't take the time to implement it.
~~NB: In packaging up this PR, I realized that MIR construction code is not triggering for methods right now, I think it's only for fixed fns. I'll push a fix for this soon. Hopefully it doesn't stop any crates from building. :)~~ Fixed. Everything still seems to work.
However, the MIR construction code (`librustc_mir/build`) is intentionally quite distinct from the code which munges the compiler's data structures (`librustc_mir/tcx`). The interface between the two is the `HIR` trait (`librustc_mir/hir`). To avoid confusion with @nrc's work, perhaps a better name for this trait is warranted, although ultimately this trait *will* be connected to the HIR, I imagine, so in a way the name is perfect. Anyway, I'm open to suggestions. The initial motivation for this split was to allow for the MIR construction code to be unit-tested. But while I didn't end up writing unit tests (yet), I did find the split made the code immensely easier to think about, since the messiness of our existing system, with its myriad hashtables, punning, and so forth, is confined to one part, which simply transforms to a more fully explicit AST-like form. I tried to separate out the commits somewhat, but since this mostly new code, it mostly winds up coming in one fell swoop in the MIR commit.
Quick guide to the MIR crate:
- `repr.rs` defines the MIR itself; each MIR instance is parameterized by some HIR `H`
- `build/` is the MIR construction code, parameterized by a particular HIR
- `hir/` is the definition of the HIR interface
- `tcx/` is the impl of the HIR interface for the tcx
- `dump.rs` is the minimal compiler pass that invokes the HIR
One open question:
- In the HIR trait, I used exclusively struct-like variants. I found I like this more, since things have names. Should I convert the repr code?
