If `v` were a type with some kind of indirection, so that `v += 1` would
have an effect even if `v` were not used anymore, the unused_assignments lint
would mark a false positive.
This exempts overloaded (non-primitive) assign ops from being treated as
assignments (they are method calls).
The previous compile-fail tests that ensure x += 1 can trigger for
primitive types continue to pass. Added a representative test for the
"view" indirection.
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.
Similarly to #31629 where an i586-unknown-linux-gnu target was added, there is
sometimes a desire to compile for x86 Windows as well where SSE2 is disabled.
This commit mirrors the i586-unknown-linux-gnu target and simply adds a variant
for Windows as well.
This is motivated by a recent [Gecko bug][ff] where crashes were seen on 32-bit
Windows due to users having CPUs that don't support SSE2 instructions. It was
requested that we could have non-SSE2 builds of the standard library available
so they could continue to use vanilla releases and nightlies.
[ff]: https://bugzilla.mozilla.org/show_bug.cgi?id=1253202
- 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`
