Previously the file was not regenrated upon modification of `src/rustllvm` or others.
Now it will be rebuilt if `src/llvm` or `src/rustllvm` is touched.
Also added *.rs rule to 'clean' rule so that it is removed upon 'make
clean'.
Fixes#28614.
The `log` crate on crates.io already knows `TRACE`, but the internal liblog doesn't, which causes it to spew errors when a `TRACE` level is defined. I made `TRACE` behave like `DEBUG`.
It seems that OS X El Capitan does not pass DYLD_* environment variables to child processes anymore. See this link: https://forums.developer.apple.com/thread/9233
The causes a test in `src/libstd/process.rs' to fail when those environment variables are not found in the child process. This PR skips those variables similar to how the Windows envars that start with `=` are skipped.
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
