This pass was supposed to check use of gated features before
`#[cfg]`-stripping but this was not the case since it in fact happens
after. Checks that are actually important and must be done before macro
expansion are now made where the features are actually used. Close#32648.
Also ensure that attributes on macro-generated macro invocations are
checked as well. Close#32782 and #32655.
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.
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.
Replace consider_unification_despite_ambiguity with new obligation variant
Is work towards #32730. Addresses part one of #32286. Addresses #24210 and #26046 to some degree.
r? @nikomatsakis
Do not rely on file extensions after path canonicalization.
Rustc does not recognize libraries which are symlinked to files having extension other than .rlib. The problem is that find_library_crate calls fs::canonicalize on found library paths, but then the resulting path is passed to get_metadata_section, which assumes it will end in ".rlib" if it's an rlib (from https://internals.rust-lang.org/t/is-library-path-canonicalization-worth-it/3206).
cc #29433
resolve: Improve duplicate glob detection
This fixes a bug introduced in #31726 in which we erroneously allow multiple imports of the same item under some circumstances.
More specifically, we erroneously allow a module that is in a cycle of glob re-exports to have other re-exports (besides the glob from the cycle).
For example,
```rust
pub fn f() {}
mod foo {
pub use f; // (1) This defines `foo::f`.
pub use bar::*; // (3) This also defines `foo::f`, which should be a duplicate error but is currently allowed.
}
mod bar {
pub use foo::*; // (2) This defines `bar::f`.
}
```
A module in a glob re-export cycle can still have `pub` items after this PR. For example,
```rust
mod foo {
pub fn f() {}; // (1) This defines `foo::f`.
pub use bar::*; // (3) This is not a duplicate error since items shadow glob-imported re-exports (cf #31337).
}
mod bar {
pub use foo::*; // (2) This defines `bar::f`.
}
```
r? @nikomatsakis
