Right now there's just a smattering of `// ignore-foo` platforms which is ever
expanding as new ones are added. Instead switch to only running these tests on
Linux/OSX and then use a guaranteed-to-work but not-as-well-tested alternative
on other platforms.
- Empty `.sidebar .location` caused "grey line" on top of the documentation page (under 700px) fixed.
- `.sidebar .location` appearance improvement in responsive mode.
This PR changes the search paths for macro-expanded non-inline modules so that they match ordinary non-inline modules (fixes#31624). This is a [breaking-change].
Right now, the search paths for a macro-expanded non-inline module are computed as if the module were declared in the top level of the file in which the macro was defined.
For example, consider `./foo/mod.rs`:
```rust
mod inconsequential { // moving the macro outside this module wouldn't change anything
macro_rules! mod_decl {
($i:ident) => { mod $i; }
}
}
```
and `./lib.rs`:
```rust
mod foo;
mod bar {
mod_decl!(baz);
//^ Now, rustc expects `./foo/baz.rs` (or `./foo/baz/mod.rs`)
//| After this PR, rustc will expect `./bar/baz.rs` (or `./bar/baz/mod.rs`)
}
```
r? @alexcrichton
Show `cfg` as possible argument to `--print` and make it so that `--print cfg` also outputs the `target_feature`s.
Should I also extend `src/test/run-make/print-cfg/Makefile` to check that `target_feature`s are actually printed?
This PR extends compiletest to support **test revisions** and with a preliminary **incremental testing harness**. run-pass, compile-fail, and run-fail tests may be tagged with
```
// revisions: a b c d
```
This will cause the test to be re-run four times with `--cfg {a,b,c,d}` in turn. This means you can write very closely related things using `cfg`. You can also configure the headers/expected-errors by writing `//[foo] header: value` or `//[foo]~ ERROR bar`, where `foo` is the name of your revision. See the changes to `coherence-cow.rs` as a proof of concept.
The main point of this work is to support the incremental testing harness. This PR contains an initial, unused version. The code that uses it will land later. The incremental testing harness compiles each revision in turn, and requires that the revisions have particular names (e.g., `rpass2`, `cfail3`), which tell it whether a particular revision is expected to compile or not.
Two questions:
- Is there compiletest documentation anywhere I can update?
- Should I hold off on landing the incremental testing harness until I have the code to exercise it? (That will come in a separate PR, still fixing a few details)
r? @alexcrichton
cc @rust-lang/compiler <-- new testing capabilities
These were intended to land in stable 1.8 but were just waiting for the
implementation PR, so now they're landing. Specifically this PR stabilizes:
* `AsciiExt::into_ascii_uppercase`
* `AsciiExt::into_ascii_lowercase`
* `AsciiExt for Vec<u8>`
* `AsciiExt for String`
Gated cfg attributes are not available on the stable and beta release
channels, therefore they should not be presented to users of those
channels in order to avoid confusion.
Use `drop_in_place` in Vec and VecDeque
We can use drop_in_place's DST capabilities directly in Vec::drop and similarly in VecDeque::drop. I verfied this has the same effect as the previous `needs_drop` code; `drop_in_place` it itself an intrinsic.
The VecDeque replacement should be more efficient too, even in release mode (slice iteration makes a more efficient loop than the deque iterator).
This PR privacy checks paths as they are resolved instead of in `librustc_privacy` (fixes#12334 and fixes#31779). This removes the need for the `LastPrivate` system introduced in PR #9735, the limitations of which cause #31779.
This PR also reports privacy violations in paths to intra- and inter-crate items the same way -- it always reports the first inaccessible segment of the path.
Since it fixes#31779, this is a [breaking-change]. For example, the following code would break:
```rust
mod foo {
pub use foo::bar::S;
mod bar { // `bar` should be private to `foo`
pub struct S;
}
}
impl foo::S {
fn f() {}
}
fn main() {
foo::bar::S::f(); // This is now a privacy error
}
```
r? @alexcrichton
The configuration returned by `config::build_configuration` needs to
be modified with `target_features::add_configuration` in order to also
contain the target features. This is already done for the
configuration used when compiling and when creating the documentation,
but was missing in the `cfg` printing code.
