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
Move self-profile infrastructure to data structures
The single dependency on queries (QueryName) can be fairly easily
abstracted via a trait and this further decouples Session from librustc
(the primary goal).
This is intended as a precursor to moving Session out of librustc, but since that involves lots of smaller steps that move around code I'm splitting it up into separate PRs.
Move Session fields to CrateStore
`allocator_kind` and `injected_panic_runtime` are both query-like, this moves them out of Session and into CrateStore, avoiding the `Once` they previously had by clearing separating initialization and de-initialization.
The single dependency on queries (QueryName) can be fairly easily
abstracted via a trait and this further decouples Session from librustc
(the primary goal).
support issue = "none" in unstable attributes
This works towards fixing #41260.
This PR allows the use of `issue = "none"` in unstable attributes and makes changes to internally store the issue number as an `Option<NonZeroU32>`. For example:
```rust
#[unstable(feature = "unstable_test_feature", issue = "none")]
fn unstable_issue_none() {}
```
It was not made optional because feedback seen here #60860 suggested that people might forget the issue field if it was optional.
I could not remove the current uses of `issue = "0"` (of which there are a lot) because the stage 0 compiler expects the old syntax. Once this is available in the stage 0 compiler we can replace all uses of `"0"` with `"none"` and no longer allow `"0"`. This is my first time contributing, so I'm not sure what the protocol is with two-part things like this, so some guidance would be appreciated.
r? @varkor
This was essentially a "query" previously (with no key, just always run
once when resolving the crate dependencies), and remains so, just now in
a way that isn't on Session. This removes the need for the `Once` as
well.
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
Move has_panic_handler to query
Moves us off of a global Once instead re-querying the lang item each time. The conditions on when we set it to true change a little (previously we'd make sure a few more lang items were `Some`) but I think they in practice don't matter, we won't compile later on if we don't have them.
Don't hide ICEs from previous incremental compiles
I think this fixes#65401, the compiler does not fail to ICE after the first compilation, tested on the last snippet of [this comment](https://github.com/rust-lang/rust/issues/63154#issuecomment-541592381).
I am not very sure of the fix as I don't understand much of the structure of the compiler.
The value names are used when reporting issues found by address
sanitizer or memory sanitizer. Avoid discarding names when those
sanitizers are enabled, unless explicitly requested to do otherwise.
SelfProfiler API refactoring and part one of event review
This PR refactors the `SelfProfiler` a little bit so that most profiling methods are RAII-based. The codegen backend code already had something similar, this refactoring pulls this functionality up into `SelfProfiler` itself, for general use.
The second commit of this PR is a review and update of the existing events we are already recording. Names have been made more consistent. CGU names have been removed from event names. They will be added back in when function parameter recording is implemented.
There is still some work to be done for adding new events, especially around trait resolution and the incremental system.
r? @wesleywiser
Make all alt builders produce parallel-enabled compilers
We're not quite ready to ship parallel compilers by default, but the alt
builders are not used too much (in theory), so we believe that shipping
a possibly-broken compiler there is not too problematic.
r? @nikomatsakis
This changes the default parallelism for parallel compilers to one,
instead of the previous default, which was "num cpus". This is likely
not an optimal default long-term, but it is a good default for testing
whether parallel compilers are not a significant regression over a
sequential compiler.
Notably, this in theory makes a parallel-enabled compiler behave
exactly like a sequential compiler with respect to the jobserver.
rustc: Fix mixing crates with different `share_generics`
This commit addresses #64319 by removing the `dylib` crate type from the
list of crate type that exports generic symbols. The bug in #64319
arises because a `dylib` crate type was trying to export a symbol in an
uptream crate but it miscalculated the symbol name of the uptream
symbol. This isn't really necessary, though, since `dylib` crates aren't
that heavily used, so we can just conservatively say that the `dylib`
crate type never exports generic symbols, forcibly removing them from
the exported symbol lists if were to otherwise find them.
The fix here happens in two places:
* First is in the `local_crate_exports_generics` method, indicating that
it's now `false` for the `Dylib` crate type. Only rlibs actually
export generics at this point.
* Next is when we load exported symbols from upstream crate. If, for our
compilation session, the crate may be included from a dynamic library,
then its generic symbols are removed. When the crate was linked into a
dynamic library its symbols weren't exported, so we can't consider
them a candidate to link against.
Overally this should avoid situations where we incorrectly calculate the
upstream symbol names in the face of differnet `share_generics` options,
ultimately...
Closes#64319
This commit converts a field of `Session`, `dependency_formats`, into a
query of `TyCtxt`. This information then also needed to be threaded
through to other remaining portions of the linker, but it's relatively
straightforward. The only change here is that instead of
`HashMap<CrateType, T>` the data structure changed to `Vec<(CrateType,
T)>` to make it easier to deal with in queries.
When `rustc` is invoked with the `--print` argument, we don't actually
generate any code (unless it's the `native-static-libs` option). So we
don't need to error our in this case since there's no risk of generating
either LLVM assertions or corrupted binaries.
Stabilize support for Profile-guided Optimization
This PR makes profile-guided optimization available via the `-C profile-generate` / `-C profile-use` pair of commandline flags and adds end-user documentation for the feature to the [rustc book](https://doc.rust-lang.org/rustc/). The PR thus ticks the last two remaining checkboxes of the [stabilization tracking issue](https://github.com/rust-lang/rust/issues/59913).
From the tracking issue:
> Profile-guided optimization (PGO) is a common optimization technique for ahead-of-time compilers. It works by collecting data about a program's typical execution (e.g. probability of branches taken, typical runtime values of variables, etc) and then uses this information during program optimization for things like inlining decisions, machine code layout, or indirect call promotion.
If you are curious about how this can be used, there is a rendered version of the documentation this PR adds available [here](
https://github.com/michaelwoerister/rust/blob/stabilize-pgo/src/doc/rustc/src/profile-guided-optimization.md).
r? @alexcrichton
cc @rust-lang/compiler
