A program created with `rustc --test` prints at least one line per test.
This can be very verbose, especially with [data-driven tests](
https://internals.rust-lang.org/t/test-and-external-test-harnesses/3145)
when hundreds or thousands of tests is not rare.
This adds a `-q` or `--quiet` option that changes the output
to one character instead of one line per test
(except metrics and benchmarks results which have additional data to
show):
```
Running target/debug/wpt-75c594dc1e6e6187
running 314 tests
..............................................................................
..............................................................................
..............................................................................
..............................................................................
..
test result: ok. 314 passed; 0 failed; 0 ignored; 0 measured
```
This is a breaking change since the `test::TestOpts` struct
now has one more field.
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`
This is mostly cleanup of individual code bits and code reuse for `clean::Attribute` handling.
The only change in behaviour should be that emitted sources are now being recorded and queried when trying to create src-links to local source-files.
r? @alexcrichton
This PR implements [RFC 1192](https://github.com/rust-lang/rfcs/blob/master/text/1192-inclusive-ranges.md), which is triple-dot syntax for inclusive range expressions. The new stuff is behind two feature gates (one for the syntax and one for the std::ops types). This replaces the deprecated functionality in std::iter. Along the way I simplified the desugaring for all ranges.
This is my first contribution to rust which changes more than one character outside of a test or comment, so please review carefully! Some of the individual commit messages have more of my notes. Also thanks for putting up with my dumb questions in #rust-internals.
- For implementing `std::ops::RangeInclusive`, I took @Stebalien's suggestion from https://github.com/rust-lang/rfcs/pull/1192#issuecomment-137864421. It seemed to me to make the implementation easier and increase type safety. If that stands, the RFC should be amended to avoid confusion.
- I also kind of like @glaebhoerl's [idea](https://github.com/rust-lang/rfcs/pull/1254#issuecomment-147815299), which is unified inclusive/exclusive range syntax something like `x>..=y`. We can experiment with this while everything is behind a feature gate.
- There are a couple of FIXMEs left (see the last commit). I didn't know what to do about `RangeArgument` and I haven't added `Index` impls yet. Those should be discussed/finished before merging.
cc @Gankro since you [complained](https://www.reddit.com/r/rust/comments/3xkfro/what_happened_to_inclusive_ranges/cy5j0yq)
cc #27777#30877rust-lang/rust#1192rust-lang/rfcs#1254
relevant to #28237 (tracking issue)
This PR allows using methods from traits that are visible but are defined in an inaccessible module (fixes#18241). For example,
```rust
mod foo {
pub use foo::bar::Tr;
mod bar { // This module is inaccessible from `g`
pub trait Tr { fn f(&self) {} }
}
}
fn g<T: foo::Tr>(t: T) {
t.f(); // Currently, this is a privacy error even though `foo::Tr` is visible
}
```
After this PR, it will continue to be a privacy error to use a method from a trait that is not visible. This can happen when a public trait inherits from a private trait (in violation of the `public_in_private` lint) -- see @petrochenkov's example in #28504.
r? @nikomatsakis
Now that 767d85061a is upstream, the relevant deadlocking issue which prompted our downgrade has been resolved. As a result, there's no known issue to *not* upgrade! This also re-enables jemalloc for the pc-windows-gnu target as known issues with that have also been fixed.
Closes#31030
This PR improves the import resolution algorithm.
First, it records that an import succeeded or failed for one namespace (by calling `decrement_outstanding_references_for` and `try_define_child` if successful) even if it is still indeterminate in the other namespace, fixing #31444.
Second, it starts importing bindings from globs as soon as the glob path is determined.
It maintains links from imported modules to their importers so that when a resolution becomes successful in an imported module, a corresponding binding will be added to the importer module.
It also maintains links from importer modules to imported modules so that we can determine if an undefined name is indeterminate or failing by recursively checking this in the imported modules.
This allows, for example:
```rust
mod foo {
pub mod baz {}
pub use bar::baz::*;
}
mod bar {
pub use foo::*;
}
```
It also allows cycles of pub glob imports, although by to the current shadowing rules, the only way for such a cycle to compile is if each participating module defines no names. Incidentally, this PR lays the groundwork for more permissive feature-gated shadowing rules.
Finally, this PR encapsulates almost all implementation details of import resolution in `resolve_imports` (some of which used to be in `lib.rs`) and refactors reexport recording, shadowed trait collecting, some duplicate checking, and the `private_in_public` lint out of the core import resolution algorithm and into a post-processing pass in `resolve_imports`.
r? @nrc
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`
