Replace `TypeNsDef` and `ValueNsDef` with a more general type `NsDef`.
Define a newtype `NameBinding` for `Rc<RefCell<Option<NsDef>>>` and refactor `NameBindings` to be a `NameBinding` for each namespace.
Replace uses of `NameBindings` with `NameBinding` where only one binding is being used (in `NamespaceResult`, `Target,` etc).
Refactor away `resolve_definition_of_name_in_module` and `NameDefinition`, fixing issue #4952.
I'd like to have the message print out the index and length values like it does elsewhere, but I'm not sure how to do that without affecting perf here. Will `assert!(cond, "index out of bounds got {} but len is ", idx, len)` make things slower? It calls `panic_fmt` which is marked as cold but also calls `format_args!`, and I don't know if that allocates or does any heavy lifting.
cc @alexcrichton @Gankro
Hey hey,
This is the result of running rustfmt over the libterm module. The first commit reflects the unaltered changes from rustfmt, and the commit message contains some notes on areas where I thought rustfmt had behaved strangely. The second commit attempts to fix the strange areas from the first commit.
Clarification edit: there are still some areas where I think rustfmt has made changes which may merit discussion (one is noted in the comments below). My second commit only undoes the changes that I figured would not warrant discussion (based on my opinion of the style, which is of course subjective).
r? @nrc
Since fat pointers do not qualify as structural types, they got copied
using load_ty and store_ty, which means that we load an FCA and use
extractvalue to get the components of the fat pointer. This breaks
certain optimizations in LLVM.
Found via apasel422/ref_count#13
This commit fixes a bug where a crate could fail to compile depending on the
order of `extern crate` directives at the top of the crate. Specifically, if the
same crate is found at two locations, then if it's loaded first via `--extern`
it will not emit a duplicate warning, but if it's first loaded transitively
via a dep and *then* via `--extern` an error will be emitted.
The loader was tweaked to catch this scenario and coalesce the loading of these
two crates to prevent errors from being emitted.
Since fat pointers do not qualify as structural types, they got copied
using load_ty and store_ty, which means that we load an FCA and use
extractvalue to get the components of the fat pointer. This breaks
certain optimizations in LLVM.
Found via apasel422/ref_count#13
r? @alexcrichton
This prevents outputting csv files with the same name and thus overwriting each other when indexing Cargo projects with a bin crate (and some other cases).
This commit fixes a bug where a crate could fail to compile depending on the
order of `extern crate` directives at the top of the crate. Specifically, if the
same crate is found at two locations, then if it's loaded first via `--extern`
it will not emit a duplicate warning, but if it's first loaded transitively
via a dep and *then* via `--extern` an error will be emitted.
The loader was tweaked to catch this scenario and coalesce the loading of these
two crates to prevent errors from being emitted.
This patch implements the plan described in https://internals.rust-lang.org/t/privacy-and-its-interaction-with-docs-lints-and-stability/2880 with one deviation.
It turns out, that rustdoc needs the "directly public" set for its docs inlining logic, so the privacy pass have to produce three sets and not two. Three is arguably too many, so I merged them in one map:
`public_items/exported_items/reachable_items: NodeSet => access_levels: NodeMap<AccessLevel>`
r? @alexcrichton
Trait references are always invariant, so all uses of subtyping between
them are equivalent to using equality.
Moreover, the overlap check was previously performed twice per impl
pair, once in each direction. It is now performed only once, and
internally uses the equality check.
On glium, a crate that spends some time in coherence, this change sped
up coherence checking by a few percent (not very significant).
Debian wants to build all binaries with particular hardening flags.
The Rust makefiles are inconsistent in which architectures they
correctly include CFLAGS/etc from the enivoronment (see mk/cfg/*).
This patch adds LDFLAGS, and then unconditionally prepends
CFLAGS/LDFLAGS/etc to the build commands.
This tiny PR renames the result variable in HashSet's `intersection` example from `diff` to `intersection` and the same for `union`, which seem more appropriate.
Corresponds directly to llvm's inline-threshold.
I want this so I can experiment out-of-tree with tweaking optimization settings, and this is the most important value that isn't exposed. I can't get it to work either via `-C llvm-args`.
cc @rust-lang/compiler
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
