This commit is an implementation of [RFC 1288][rfc] which adds two new unstable
types to the `std::time` module. The `Instant` type is used to represent
measurements of a monotonically increasing clock suitable for measuring time
withing a process for operations such as benchmarks or just the elapsed time to
do something. An `Instant` favors panicking when bugs are found as the bugs are
programmer errors rather than typical errors that can be encountered.
[rfc]: https://github.com/rust-lang/rfcs/pull/1288
The `SystemTime` type is used to represent a system timestamp and is not
monotonic. Very few guarantees are provided about this measurement of the system
clock, but a fixed point in time (`UNIX_EPOCH`) is provided to learn about the
relative distance from this point for any particular time stamp.
This PR takes the same implementation strategy as the `time` crate on crates.io,
namely:
| Platform | Instant | SystemTime |
|------------|--------------------------|--------------------------|
| Windows | QueryPerformanceCounter | GetSystemTimeAsFileTime |
| OSX | mach_absolute_time | gettimeofday |
| Unix | CLOCK_MONOTONIC | CLOCK_REALTIME |
These implementations can perhaps be refined over time, but they currently
satisfy the requirements of the `Instant` and `SystemTime` types while also
being portable across implementations and revisions of each platform.
cc #29866
Leading equals symbols are treated as part of the variable name, if
there is no other equality symbol or none at all, the environment string
is ignored.
This commit is an implementation of [RFC 1288][rfc] which adds two new unstable
types to the `std::time` module. The `Instant` type is used to represent
measurements of a monotonically increasing clock suitable for measuring time
withing a process for operations such as benchmarks or just the elapsed time to
do something. An `Instant` favors panicking when bugs are found as the bugs are
programmer errors rather than typical errors that can be encountered.
[rfc]: https://github.com/rust-lang/rfcs/pull/1288
The `SystemTime` type is used to represent a system timestamp and is not
monotonic. Very few guarantees are provided about this measurement of the system
clock, but a fixed point in time (`UNIX_EPOCH`) is provided to learn about the
relative distance from this point for any particular time stamp.
This PR takes the same implementation strategy as the `time` crate on crates.io,
namely:
| Platform | Instant | SystemTime |
|------------|--------------------------|--------------------------|
| Windows | QueryPerformanceCounter | GetSystemTimeAsFileTime |
| OSX | mach_absolute_time | gettimeofday |
| Unix | CLOCK_MONOTONIC | CLOCK_REALTIME |
These implementations can perhaps be refined over time, but they currently
satisfy the requirements of the `Instant` and `SystemTime` types while also
being portable across implementations and revisions of each platform.
The book was located under 'src/doc/trpl' because originally, it was
going to be hosted under that URL. Late in the game, before 1.0, we
decided that /book was a better one, so we changed the output, but
not the input. This causes confusion for no good reason. So we'll change
the source directory to look like the output directory, like for every
other thing in src/doc.
r? @brson
The book was located under 'src/doc/trpl' because originally, it was
going to be hosted under that URL. Late in the game, before 1.0, we
decided that /book was a better one, so we changed the output, but
not the input. This causes confusion for no good reason. So we'll change
the source directory to look like the output directory, like for every
other thing in src/doc.
A race condition in Javascript was causing unpredictable ordering
of the sidebar boxes when loading documentation generated by
rustdoc, due to the script that adds the Crates box being executed
asynchronously. Disabling the asynchronous execution and deferring
this script should ensure that the Crates box always appears last
in the sidebox (this seemed to be the more common ordering prior
to this change).
Fixes#29698
This PR moves items into a separate map stored in the krate, rather than storing them inline in the HIR. The HIR visitor is also modified to skip visiting nested items by default. The goal here is to ensure that if you get access to the HIR for one item, you don't automatically get access to a bunch of other items, for better dependency tracking.
r? @nrc
cc @eddyb
encounter each module. This is somewhat different than how it used to
work; it should ensure a more equitable distribution of work than
before. The reason is that, before, when we rotated, we would rotate
before we had seen the full contents of the current module. So e.g. if
we have `mod a { mod b { .. } .. }`, then we rotate when we encounter
`b`, but we haven't processed the remainder of `a` yet. Unclear if this
makes any difference in practice, but it seemed suboptimal. Also, this
structure (with an outer walk over modules) is closer to what we will
want for an incremental setting.
noteworthy because trans got mildly simpler, since it doesn't have to
ensure that we walk the contents of all things just to find all the
hidden items.
rather being stored inline. Refactor (and rename) the visitor so that
(by default) it only visits the interior content of an item not nested
items.
This is a [breaking-change] for anyone who uses the HIR visitor. Besides
changing `visit::` to `intravisit::`, you need to refactor your visitor
in one of two ways, depending on what it requires:
1. If you just want to visit all items (most common), you should call
`krate.visit_all_items(&mut visitor)`.
2. If you need to visit nested items in the middle of the parent items,
you should override `visit_nested_item` with something like:
`self.visit_item(self.tcx.map.expect_item(item.id))`, presuming you
have access to a tcx (or at least a HIR map).
Rather than modifying the installer to disable directory rewriting,
this patch modifies the directory structure passed to the installer so
that the rewriting gives the correct results. This means that if a
non-standard --libdir is passed to configure then the same --libdir
option (relative to the --prefix) must be passed to the install
script. In the `make install` case this is handled automatically.
Binary distributions are generally generated using the default
--libdir and then have paths optionally rewritten by the installer,
which should continue to work.
This has the advantage of not complicating the installer interface
intended for end-user use.
Fixes#29561
A race condition in Javascript was causing unpredictable ordering
of the sidebar boxes when loading documentation generated by
rustdoc, due to the script that adds the Crates box being executed
asynchronously. Disabling the asynchronous execution and deferring
this script should ensure that the Crates box always appears last
in the sidebox (this seemed to be the more common ordering prior
to this change).
Fixes#29698
What this patch does:
- Stability annotations are now based on "exported items" supplied by rustc_privacy and not "public items". Exported items are as accessible for external crates as directly public items and should be annotated with stability attributes.
- Trait impls require annotations now.
- Reexports require annotations now.
- Crates themselves didn't require annotations, now they do.
- Exported macros are annotated now, but these annotations are not used yet.
- Some useless annotations are detected and result in errors
- Finally, some small bugs are fixed - deprecation propagates from stable deprecated parents, items in blocks are traversed correctly (fixes https://github.com/rust-lang/rust/issues/29034) + some code cleanup.
This change adds a `MirPass` erasing all early-bound regions from MIR, right before storing it in the MIR map. I've added some assertions at neuralgic points in `trans::mir` doing cheap checks whether region have actually been erased.
Here are some assumptions that I worked under:
- AdtDef references stay untouched. It's the `Substs` accompanying them that need to be handled (e.g. in `AggregateKind::Adt`).
- We can't really get rid of late-bound regions at this point because there is no version `BareFnTy` (for example) that comes without one. These still have to be handled on demand in trans.
Are this assumptions right?
r? @nikomatsakis
