rustdoc: Fix the strip-hidden `ImplStripper`
Instead of stripping impls which reference *stripped* items, we keep impls which reference *retained* items. We do this because when we strip an item we immediately return, and do not recurse into it - leaving the contained items non-stripped from the point of view of the `ImplStripper`.
fixes#33069
r? @alexcrichton
This uncovered a lot of bugs in compiletest and also some shortcomings
of our existing JSON output. We had to add information to the JSON
output, such as suggested text and macro backtraces. We also had to fix
various bugs in the existing tests.
Joint work with jntrnr.
Compute `target_feature` from LLVM
This is a work-in-progress fix for #31662.
The logic that computes the target features from the command line has been replaced with queries to the `TargetMachine`.
Compute LLVM-agnostic type layouts in rustc.
Layout for monomorphic types, and some polymorphic ones (e.g. `&T` where `T: Sized`),
can now be computed by rustc without involving LLVM in the actual process.
This gives rustc the ability to evaluate `size_of` or `align_of`, as well as obtain field offsets.
MIR-based CTFE will eventually make use of these layouts, as will MIR trans, shortly.
Layout computation also comes with a `[breaking-change]`, or two:
* `"data-layout"` is now mandatory in custom target specifications, reverting the decision from #27076.
This string is needed because it describes endianness, pointer size and alignments for various types.
We have the first two and we could allow tweaking alignments in target specifications.
Or we could also extract the data layout from LLVM and feed it back into rustc.
However, that can vary with the LLVM version, which is fragile and undermines stability.
For built-in targets, I've added a check that the hardcoded data-layout matches LLVM defaults.
* `transmute` calls are checked in a stricter fashion, which fixes#32377
To expand on `transmute`, there are only 2 allowed patterns: between types with statically known sizes and between pointers with the same potentially-unsized "tail" (which determines the type of unsized metadata they use, if any).
If you're affected, my suggestions are:
* try to use casts (and raw pointer deref) instead of transmutes
* *really* try to avoid `transmute` where possible
* if you have a structure, try working on individual fields and unpack/repack the structure instead of transmuting it whole, e.g. `transmute::<RefCell<Box<T>>, RefCell<*mut T>>(x)` doesn't work, but `RefCell::new(Box::into_raw(x.into_inner()))` does (and `Box::into_raw` is just a `transmute`)
This test checks that all of the x86 architectures (both `x86` and
`x86_64`) have the `sse2` feature. This is currently true for all of
the targets whose target CPU is `pentium4` (or better), but it might
fail on other targets (for example on `i586`).
rustdoc: refine cross-crate impl inlining
This changes the current rule that impls within `doc(hidden)` modules aren't inlined, to only inlining impls where the implemented trait and type are reachable in documentation.
fixes#14586fixes#31948
.. and also applies the reachability checking to cross-crate links.
fixes#28480
r? @alexcrichton
rustbuild: Add support for compiletest test suites
This commit adds support in rustbuild for running all of the compiletest test
suites as part of `make check`. The `compiletest` program was moved to
`src/tools` (like `rustbook` and others) and is now just compiled like any other
old tool. Each test suite has a pretty standard set of dependencies and just
tweaks various parameters to the final compiletest executable.
Note that full support is lacking in terms of:
* Once a test suite has passed, that's not remembered. When a test suite is
requested to be run, it's always run.
* The arguments to compiletest probably don't work for every possible
combination of platforms and testing environments just yet. There will likely
need to be future updates to tweak various pieces here and there.
* Cross compiled test suites probably don't work just yet, support for that will
come in a follow-up patch.
This commit adds support in rustbuild for running all of the compiletest test
suites as part of `make check`. The `compiletest` program was moved to
`src/tools` (like `rustbook` and others) and is now just compiled like any other
old tool. Each test suite has a pretty standard set of dependencies and just
tweaks various parameters to the final compiletest executable.
Note that full support is lacking in terms of:
* Once a test suite has passed, that's not remembered. When a test suite is
requested to be run, it's always run.
* The arguments to compiletest probably don't work for every possible
combination of platforms and testing environments just yet. There will likely
need to be future updates to tweak various pieces here and there.
* Cross compiled test suites probably don't work just yet, support for that will
come in a follow-up patch.
Instead of stripping impls which reference *stripped* items, we keep impls
which reference *retained* items. We do this because when we strip an
item we immediately return, and do not recurse into it - leaving the
contained items non-stripped from the point of view of the `ImplStripper`.
This changes the current rule that impls within `doc(hidden)` modules
aren't inlined, to only inlining impls where the implemented
trait and type are reachable in documentation.
Get all (but one) of debuginfo tests to pass with MIR codegen.
I didn't get much feedback in #31005 so I went ahead and implemented something simple.
Closes#31005, as MIR debuginfo should work now for most usecases.
The `no-debug-attribute` test no longer assumes variables are in scope of `return`.
We might also want to revisit that in #32949, but the test is more reliable now either way.
In order to get one last function in the `associated-type` test pass, this PR also fixes#32790.
Implement `pub(restricted)` privacy (RFC 1422)
This implements `pub(restricted)` privacy from RFC 1422 (cc #32409) behind a feature gate.
`pub(restricted)` paths currently cannot use re-exported modules both for simplicity of implementation and for future compatibility with RFC 1560 (cf #31783).
r? @nikomatsakis
Add initial version of codegen unit partitioning for incremental compilation.
The task of the partitioning module is to take the complete set of translation items of a crate and produce a set of codegen units from it, where a codegen unit is a named set of (translation-item, linkage) pairs. That is, this module decides which translation item appears in which codegen units with which linkage.
This version only handles the case of partitioning for incremental compilation, not the regular N-codegen units case. In the future the regular case should be handled too, maybe even doing a bit more analysis to intelligently figure out a good partitioning.
One thing that could be improved is the syntax of the codegen unit tests. Right now they still use the compile-fail error specification infrastructure, so everything has to be on one line. Would be nice to be able to format things in a more readable way.
Restore trait impl docs
Currently, documentation on methods in trait implementations doesn't get rendered. This changes that; trait implementations have all documentation associated with impl items displayed (documentation from the trait definition is ignored).
Fixes#24838Fixes#26871
Fix macro hygiene bug
This fixes#32922 (EDIT: and fixes#31856), macro hygiene bugs.
It is a [breaking-change]. For example, the following would break:
```rust
fn main() {
let x = true;
macro_rules! foo { () => {
let x = 0;
macro_rules! bar { () => {x} }
let _: bool = bar!();
//^ `bar!()` used to resolve the first `x` (a bool),
//| but will now resolve to the second x (an i32).
}}
foo! {};
}
```
r? @nrc
We don't want to render default item docs but previously
`doctraititem` naively delegated to the trait definition in those
cases.
Updated tests to also check that this doesn't strip default item
docs from the trait definition.
In `test/rustdoc/manual_impl.rs` there are now three structs:
* S1 implements and documents required method `a_method`.
* S2 implements and documents `a_method` as well as provided
method `b_method`.
* S3 implements `a_method` and `b_method`, but only documents
`b_method`.
For a struct, we want the rendered trait impls to include documentation
if and only if it appears on the trait implementation itself
(since users can just go to the trait definition for anything not
covered in the impl docs). This means we expect:
* S1, S2, and S3 to all include top-level trait impl docs.
* S1, S2, and S3 to exclude all trait definition docs.
* S1 to show impl docs for `a_method`.
* S2 to show impl docs for `a_method` and `b_method`.
* S3 to show impl docs for `b_method`.
These tests cover those cases.
Deduplicate libraries on hash instead of filename.
Removes the need for canonicalization to prevent #12459.
(Now with passing tests!)
Canonicalization breaks certain environments where the libraries are symlinks to files that don't end in .rlib (e.g. /remote/cas/$HASH).
don't report errors in constants at every use site
partially fixes#32842
r? @arielb1
cc @retep998
I chose this way of implementing it, because the alternative (checking if the error span is inside the constant's expressions's span) would get confusing when combined with expression generating macros.
A next step would be to re-enable the re-reporting of errors if the original erroneous constant is in another crate.
