Merge `TraitItem` & `ImplItem into `AssocItem`
In this PR we:
- Merge `{Trait,Impl}Item{Kind?}` into `AssocItem{Kind?}` as discussed in https://github.com/rust-lang/rust/issues/65041#issuecomment-538105286.
- This is done by using the cover grammar of both forms.
- In particular, it requires that we syntactically allow (under `#[cfg(FALSE)]`):
- `default`ness on `trait` items,
- `impl` items without a body / definition (`const`, `type`, and `fn`),
- and associated `type`s in `impl`s with bounds, e.g., `type Foo: Ord;`.
- The syntactic restrictions are replaced by semantic ones in `ast_validation`.
- Move syntactic restrictions around C-variadic parameters from the parser into `ast_validation`:
- `fn`s in all contexts now syntactically allow `...`,
- `...` can occur anywhere in the list syntactically (`fn foo(..., x: usize) {}`),
- and `...` can be the sole parameter (`fn foo(...) {}`.
r? @petrochenkov
This commit builds on #65501 continue to simplify the build system and
compiler now that we no longer have multiple LLVM backends to ship by
default. Here this switches the compiler back to what it once was long
long ago, which is linking LLVM directly to the compiler rather than
dynamically loading it at runtime. The `codegen-backends` directory of
the sysroot no longer exists and all relevant support in the build
system is removed. Note that `rustc` still supports a dynamically loaded
codegen backend as it did previously, it just no longer supports
dynamically loaded codegen backends in its own sysroot.
Additionally as part of this the `librustc_codegen_llvm` crate now once
again explicitly depends on all of its crates instead of implicitly
loading them through the sysroot. This involved filling out its
`Cargo.toml` and deleting all the now-unnecessary `extern crate`
annotations in the header of the crate. (this in turn required adding a
number of imports for names of macros too).
The end results of this change are:
* Rustbuild's build process for the compiler as all the "oh don't forget
the codegen backend" checks can be easily removed.
* Building `rustc_codegen_llvm` is much simpler since it's simply
another compiler crate.
* Managing the dependencies of `rustc_codegen_llvm` is much simpler since
it's "just another `Cargo.toml` to edit"
* The build process should be a smidge faster because there's more
parallelism in the main rustc build step rather than splitting
`librustc_codegen_llvm` out to its own step.
* The compiler is expected to be slightly faster by default because the
codegen backend does not need to be dynamically loaded.
* Disabling LLVM as part of rustbuild is still supported, supporting
multiple codegen backends is still supported, and dynamic loading of a
codegen backend is still supported.
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
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.
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.
When one tries to create a thread with a requested stack size larger
than 16 MB, the call will fail and the compiler will bail out. Therefore
we should limit the size of the thread stack to 16 MB on Haiku.
