Add a proc-macro to derive HashStable in librustc dependencies
A second proc-macro is added to derive HashStable for crates librustc depends on.
This proc-macro HashStable_Generic (to bikeshed) allows to decouple code and some librustc's boilerplate.
Not everything is migrated, because `Span` and `TokenKind` require to be placed inside librustc.
Types using them stay there too.
Split out of #66279
r? @Zoxc
This optimization depends on inlining for the identity
conversions introduced by the lowering of the `?`.
To take advantage of `SimplifyArmIdentity`, `-Z mir-opt-level=2`
is required because that triggers the inlining MIR optimization.
rustc_plugin: Remove the compatibility shim
The compatibility crate was introduced in https://github.com/rust-lang/rust/pull/62727 to migrate Cargo and some other tools, but now it's no longer necessary.
Derive TypeFoldable using a proc-macro
A new proc macro is added in librustc_macros.
It is used to derive TypeFoldable inside librustc and librustc_traits.
For now, the macro uses the `'tcx` lifetime implicitly, and does not allow for a more robust selection of the adequate lifetime.
The Clone-based TypeFoldable implementations are not migrated.
Closes#65674
Update Cargo, books
## cargo
12 commits in 5da4b4d47963868d9878480197581ccbbdaece74..8280633db680dec5bfe1de25156d1a1d53e6d190
2019-10-28 21:53:41 +0000 to 2019-11-11 23:17:05 +0000
- Don't panic when parsing `/proc/stat` (rust-lang/cargo#7580)
- Fix unused configuration key warning for a few keys under `build`. (rust-lang/cargo#7575)
- Add back support for `BROWSER` envvar in `cargo doc --open`. (rust-lang/cargo#7576)
- Only include "already existing ..." comment in gitignore on conflict (rust-lang/cargo#7570)
- Add VS Code user dir to .gitignore (rust-lang/cargo#7578)
- Added aliases to subcommand typo suggestions. (rust-lang/cargo#7486)
- Use multiple requirement syntax consistently (rust-lang/cargo#7573)
- Update verison to 0.42 (rust-lang/cargo#7568)
- Expand documentation on build scripts. (rust-lang/cargo#7565)
- Update crossbeam-utils requirement from 0.6 to 0.7 (rust-lang/cargo#7566)
- don't download std-docs on CI (rust-lang/cargo#7513)
- Change my-buddy to github-handle (rust-lang/cargo#7553)
## nomicon
2 commits in 5004ad30d69f93553ceef74439fea2159d1f769e..58e36e0e08dec5a379ac568827c058e25990d6cd
2019-10-12 19:52:40 +0200 to 2019-10-30 08:14:24 -0500
- remove references to the nursery
- Add github action to replace Travis.yml (rust-lang-nursery/nomicon#172)
## reference
7 commits in 4b21b646669e0af49fae7cae301898dc4bfaa1f0..45558c464fb458affbcdcb34323946da45c8a117
2019-10-27 22:33:11 +0100 to 2019-11-08 14:47:35 +0100
- Audit code blocks. (rust-lang-nursery/reference#715)
- Update coherence and orphan rules documentation to match RFC 2451 (rust-lang-nursery/reference#703)
- Update organization name (rust-lang-nursery/reference#713)
- State that no_implicit_prelude also applies to nested modules (rust-lang-nursery/reference#707)
- expand Copy docs (rust-lang-nursery/reference#711)
- github action doesn't use the nursery (rust-lang-nursery/reference#706)
- Migrate to GitHub Actions. (rust-lang-nursery/reference#705)
## book
1 commits in 28fa3d15b0bc67ea5e79eeff2198e4277fc61baf..e79dd62aa63396714278d484d91d48826737f47f
2019-10-29 07:16:09 -0500 to 2019-10-30 07:33:12 -0500
- No need for an iterator here to fetch values (rust-lang/book#1957)
## rust-by-example
1 commits in f3197ddf2abab9abdbc029def8164f4a748b0d91..dcee312c66267eb5a2f6f1561354003950e29105
2019-10-29 10:17:40 -0300 to 2019-10-31 11:26:53 -0300
- refactor: simplify extracting Result from Option (rust-lang/rust-by-example#1283)
## edition-guide
2 commits in e58bc4ca104e890ac56af846877c874c432a64b5..f553fb26c60c4623ea88a1cfe731eafe0643ce34
2019-07-31 20:14:12 +0200 to 2019-10-30 08:27:42 -0500
- remove old references to the nursery
- Port from Travis to GitHub Actions (rust-lang-nursery/edition-guide#192)
Move `DIAGNOSTICS` usage to `rustc_driver`
Remove `rustc_interface`'s dependency on `rustc_error_codes` and centralize all usages of `DIAGNOSTICS` in `rustc_driver`. Once we remove all references to `rustc_error_codes` in all other crates but `rustc_driver`, this should allow for incremental recompilation of the compiler to be smoother when tweaking error codes. This works towards https://github.com/rust-lang/rust/issues/66210#issuecomment-551862528.
(May include traces of minor drive-by cleanup.)
r? @Mark-Simulacrum
Update cc, git2, num_cpus.
This updates the `cc` crate, bringing in better parallel building support. Also updates `git2` which enables the parallel feature. (Note: I don't expect it will have a significant impact on build time, but seems good to update anyways.)
The main thorn is that `cc` gained knowledge about RISC-V architectures (https://github.com/alexcrichton/cc-rs/pull/428, https://github.com/alexcrichton/cc-rs/pull/429, https://github.com/alexcrichton/cc-rs/pull/430), but the builders on CI do not have the riscv C compiler installed. This means that bootstraps' cc detection was finding a C compiler that isn't installed, and fails.
The solution here is to override the cc detection to `false`. The C compiler isn't actually used on riscv platforms. AFAIK, the only location would be compiler_builtins, and it currently forces C support off (a533ae9c5a/build.rs (L49-L55)).
Other possible solutions:
- Add the override in cc_detect for riscv (or any "no-C" platform like wasm32 and nvptx)
- Install and use the appropriate c compiler. I tried this the `g++-riscv64-linux-gnu` package, but it failed missing some header file.
Closes#66232
Move the JSON error emitter to librustc_errors
This is done both as a cleanup (it makes little sense for this emitter to be in libsyntax), but also as part of broader work to decouple Session from librustc itself.
Along the way, this also moves SourceMap to syntax_pos, which is also nice for the above reasons, as well as allowing dropping the SourceMapper trait from code. This had the unfortunate side-effect of moving `FatalError` to rustc_data_structures (it's needed in syntax_pos, due to SourceMap, but putting it there feels somehow worse).
This does not update the use sites or delete the now unnecessary
SourceMapper trait, to allow git to interpret the file move as a rename
rather than a new file.
Update mdbook.
This brings in some important updates to fix some rendering issues in the books. In particular fixing hidden lines in code blocks, and some escaping issues. More details at https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md
This also requires updating mdbook-linkcheck.
The single dependency on queries (QueryName) can be fairly easily
abstracted via a trait and this further decouples Session from librustc
(the primary goal).
Split libsyntax apart
In this PR the general idea is to separate the AST, parser, and friends by a more data / logic structure (tho not fully realized!) by separating out the parser and macro expansion code from libsyntax. Specifically have now three crates instead of one (libsyntax):
- libsyntax:
- concrete syntax tree (`syntax::ast`)
- definition of tokens and token-streams (`syntax::{token, tokenstream}`) -- used by `syntax::ast`
- visitors (`syntax::visit`, `syntax::mut_visit`)
- shared definitions between `libsyntax_expand`
- feature gating (`syntax::feature_gate`) -- we could possibly move this out to its own crater later.
- attribute and meta item utilities, including used-marking (`syntax::attr`)
- pretty printer (`syntax::print`) -- this should possibly be moved out later. For now I've reduced down the dependencies to a single essential one which could be broken via `ParseSess`. This entails that e.g. `Debug` impls for `Path` cannot reference the pretty printer.
- definition of `ParseSess` (`syntax::sess`) -- this is used by `syntax::{attr, print, feature_gate}` and is a common definition used by the parser and other things like librustc.
- the `syntax::source_map` -- this includes definitions used by `syntax::ast` and other things but could ostensibly be moved `syntax_pos` since that is more related to this module.
- a smattering of misc utilities not sufficiently important to itemize -- some of these could be moved to where they are used (often a single place) but I wanted to limit the scope of this PR.
- librustc_parse:
- parser (`rustc_parse::parser`) -- reading a file and such are defined in the crate root tho.
- lexer (`rustc_parse::lexer`)
- validation of meta grammar (post-expansion) in (`rustc_parse::validate_attr`)
- libsyntax_expand -- this defines the infra for macro expansion and conditional compilation but this is not libsyntax_ext; we might want to merge them later but currently libsyntax_expand is depended on by librustc_metadata which libsyntax_ext is not.
- conditional compilation (`syntax_expand::config`) -- moved from `syntax::config` to here
- the bulk of this crate is made up of the old `syntax::ext`
r? @estebank
We also sever syntax's dependency on rustc_target as a result.
This should slightly improve pipe-lining.
Moreover, some cleanup is done in related code.
Dual proc macro hash
This PR changes current `-Z dual-proc-macro` mechanism from resolving only by name to including the hash of the host crate inside the transistive dependency information to prevent name conflicts.
Fix partially #62558
Use rustc-workspace-hack for rustbook
As rustbook now depends transitively on openssl, it needs access to the
rustc-workspace-hack/all-static feature to pick up openssl-sys/vendored.
This fixes the rust build with `all-static = true` on systems where
openssl is not installed (e.g. when cross-compiling).
As rustbook now depends transitively on openssl, it needs access to the
rustc-workspace-hack/all-static feature to pick up openssl-sys/vendored.
This fixes the rust build with `all-static = true` on systems where
openssl is not installed (e.g. when cross-compiling).
Lint ignored `#[inline]` on function prototypes
Fixes https://github.com/rust-lang/rust/issues/51280.
- Adds a `unused_attribute` lint for `#[inline]` on function prototypes.
- As a consequence, foreign items, impl items and trait items now have their attributes checked, which could cause some code to no longer compile (it was previously erroneously ignored).
Redesign the interface to the unikernel HermitCore
We are developing the unikernel HermitCore, where the kernel is written in Rust and is already part of the Rust Standard Library. The interface between the standard library and the kernel based on a small C library. With this pull request, we remove completely the dependency to C and use lld as linker. Currently, the kernel will be linked to the application as static library, which is published at https://github.com/hermitcore/libhermit-rs.
We don’t longer support the C interface to the kernel. Consequently, we remove this part from the Rust Standard Library.
self-profiling: Update measureme to 0.4.0 and remove non-RAII methods from profiler.
This PR removes all non-RAII based profiling methods from `SelfProfilerRef` 🎉
It also delegates the `TimingGuard` implementation to `measureme`, now that that is available there.
r? @wesleywiser
Lockless LintStore
This removes mutability from the lint store after registration. Each commit stands alone, for the most part, though they don't make sense out of sequence.
The intent here is to move LintStore to a more parallel-friendly architecture, although also just a cleaner one from an implementation perspective. Specifically, this has the following changes:
* We no longer implicitly register lints when registering lint passes
* For the most part this means that registration calls now likely want to call something like:
`lint_store.register_lints(&Pass::get_lints())` as well as `register_*_pass`.
* In theory this is a simplification as it's much easier for folks to just register lints and then have passes that implement whichever lint however they want, rather than necessarily tying passes to lints.
* Lint passes still have a list of associated lints, but a followup PR could plausibly change that
* This list must be known for a given pass type, not instance, i.e., `fn get_lints()` is the signature instead of `fn get_lints(&self)` as before.
* We do not store pass objects, instead storing constructor functions. This means we always get new passes when running lints (this happens approximately once though for a given compiler session, so no behavior change is expected).
* Registration API is _much_ simpler: generally all functions are just taking `Fn() -> PassObject` rather than several different `bool`s.
Implement (HashMap) Entry::insert as per #60142
Implementation of `Entry::insert` as per @SimonSapin's comment on #60142. This requires a patch to hashbrown:
```diff
diff --git a/src/rustc_entry.rs b/src/rustc_entry.rs
index fefa5c3..7de8300 100644
--- a/src/rustc_entry.rs
+++ b/src/rustc_entry.rs
@@ -546,6 +546,32 @@ impl<'a, K, V> RustcVacantEntry<'a, K, V> {
let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
unsafe { &mut bucket.as_mut().1 }
}
+
+ /// Sets the value of the entry with the RustcVacantEntry's key,
+ /// and returns a RustcOccupiedEntry.
+ ///
+ /// # Examples
+ ///
+ /// ```
+ /// use hashbrown::HashMap;
+ /// use hashbrown::hash_map::RustcEntry;
+ ///
+ /// let mut map: HashMap<&str, u32> = HashMap::new();
+ ///
+ /// if let RustcEntry::Vacant(v) = map.rustc_entry("poneyland") {
+ /// let o = v.insert_and_return(37);
+ /// assert_eq!(o.get(), &37);
+ /// }
+ /// ```
+ #[inline]
+ pub fn insert_and_return(self, value: V) -> RustcOccupiedEntry<'a, K, V> {
+ let bucket = self.table.insert_no_grow(self.hash, (self.key, value));
+ RustcOccupiedEntry {
+ key: None,
+ elem: bucket,
+ table: self.table
+ }
+ }
}
impl<K, V> IterMut<'_, K, V> {
```
This is also only an implementation for HashMap. I tried implementing for BTreeMap, but I don't really understand BTreeMap's internals and require more guidance on implementing the equivalent `VacantEntry::insert_and_return` such that it returns an `OccupiedEntry`. Notably, following the original PR's modifications I end up needing a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::LeafOrInternal>, _>` while I only have a `Handle<NodeRef<marker::Mut<'_>, _, _, marker::Internal>, _>` and don't know how to proceed.
(To be clear, I'm not asking for guidance right now; I'd be happy getting only the HashMap implementation — the subject of this PR — reviewed and ready, and leave the BTreeMap implementation for a latter PR.)
update Miri
Fixes https://github.com/rust-lang/rust/issues/64363
r? @alexcrichton for the Cargo.toml changes: with byteorder 1.3, the `i128` feature is a NOP, so we can remove it everywhere and then get rid of this crate in the workspace-hack.
Rollup of 10 pull requests
Successful merges:
- #63955 (Make sure interned constants are immutable)
- #64028 (Stabilize `Vec::new` and `String::new` as `const fn`s)
- #64119 (ci: ensure all tool maintainers are assignable on issues)
- #64444 (fix building libstd without backtrace feature)
- #64446 (Fix build script sanitizer check.)
- #64451 (when Miri tests are not passing, do not add Miri component)
- #64467 (Hide diagnostics emitted during --cfg parsing)
- #64497 (Don't print the "total" `-Ztime-passes` output if `--prints=...` is also given)
- #64499 (Use `Symbol` in two more functions.)
- #64504 (use println!() instead of println!(""))
Failed merges:
r? @ghost
when Miri tests are not passing, do not add Miri component
This makes build-manifest query the toolstate repo at https://github.com/rust-lang-nursery/rust-toolstate to figure out if the tests of the Miri component are passing. If they are not, we remove the component from the manifest, to avoid shipping a broken Miri.
I tested this locally by running build-manifest and making sure that it correctly detects the toolstate of 02785dabad as broken.
r? @pietroalbini
Cc @kennytm @alexcrichton
Fixes https://github.com/rust-lang/rust/issues/60301
Use `panic::set_hook` to print the ICE message
This allows custom frontends and backends to override the hook with their own, for example to point people to a different issue tracker.
ICE messages are printed in a slightly different order now. Nightly prints:
```
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0277, E0658.
For more information about an error, try `rustc --explain E0277`.
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.36.0-nightly (08bfe1612 2019-05-02) running on x86_64-unknown-linux-gnu
```
After this PR, rustc prints:
```
thread 'rustc' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:347:21
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
error: internal compiler error: unexpected panic
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports
note: rustc 1.36.0-dev running on x86_64-unknown-linux-gnu
error: aborting due to 2 previous errors
Some errors have detailed explanations: E0277, E0658.
For more information about an error, try `rustc --explain E0277`.
```
Trim rustc-workspace-hack
Those dependencies seem no longer necessary.
`./x.py test` and `x86_64-gnu-tools` container passed locally so I think this won't hurt.
This ensures that the failure cases for finding the codegen backend and
for finding the rustc binary are essentially the same, and since we
almost always will load the codegen backend, this is essentially meaning
that the rustc change is not a regression.
Update version of `rustc-std-workspace-*` crates
This commit updates the version of the `rustc-std-workspace-*` crates
in-tree which are used in `[patch]`. This will guarantee that Cargo will
select these versions even if minor updates are published to crates.io
because otherwise a newer version on crates.io would be preferred which
misses the point of `[patch]`!
This commit updates the version of the `rustc-std-workspace-*` crates
in-tree which are used in `[patch]`. This will guarantee that Cargo will
select these versions even if minor updates are published to crates.io
because otherwise a newer version on crates.io would be preferred which
misses the point of `[patch]`!
Not doing this leads to building two copies of e.g. num_cpus in the
sysroot and _llvm deps, leading to conflicts between the two when
compiling librustc_codegen_llvm. It's not entirely clear why this is the
case after the changes in this PR but likely has something to do with a
subtle difference in ordering or similar.
Rollup of 11 pull requests
Successful merges:
- #62848 (Use unicode-xid crate instead of libcore)
- #63774 (Fix `window.hashchange is not a function`)
- #63930 (Account for doc comments coming from proc macros without spans)
- #64003 (place: Passing `align` = `layout.align.abi`, when also passing `layout`)
- #64030 (Fix unlock ordering in SGX synchronization primitives)
- #64041 (use TokenStream rather than &[TokenTree] for built-in macros)
- #64051 (Add x86_64-linux-kernel target)
- #64063 (Fix const_err with `-(-0.0)`)
- #64083 (Point at appropriate arm on type error on if/else/match with one non-! arm)
- #64100 (Fix const eval bug breaking run-pass tests in Miri)
- #64157 (Opaque type locations in error message for clarity.)
Failed merges:
r? @ghost
They are only used by rustc_lexer, and are not needed elsewhere.
So we move the relevant definitions into rustc_lexer (while the actual
unicode data comes from the unicode-xid crate) and make the rest of
the compiler use it.
Since its inception rustbuild has always worked in three stages: one for
libstd, one for libtest, and one for rustc. These three stages were
architected around crates.io dependencies, where rustc wants to depend
on crates.io crates but said crates don't explicitly depend on libstd,
requiring a sysroot assembly step in the middle. This same logic was
applied for libtest where libtest wants to depend on crates.io crates
(`getopts`) but `getopts` didn't say that it depended on std, so it
needed `std` built ahead of time.
Lots of time has passed since the inception of rustbuild, however,
and we've since gotten to the point where even `std` itself is depending
on crates.io crates (albeit with some wonky configuration). This
commit applies the same logic to the two dependencies that the `test`
crate pulls in from crates.io, `getopts` and `unicode-width`. Over the
many years since rustbuild's inception `unicode-width` was the only
dependency picked up by the `test` crate, so the extra configuration
necessary to get crates building in this crate graph is unlikely to be
too much of a burden on developers.
After this patch it means that there are now only two build phasese of
rustbuild, one for libstd and one for rustc. The libtest/libproc_macro
build phase is all lumped into one now with `std`.
This was originally motivated by rust-lang/cargo#7216 where Cargo was
having to deal with synthesizing dependency edges but this commit makes
them explicit in this repository.
