Enable svh tests on msvc
These tests were ignored for msvc in #30778 because of additional notes that were being added for some reason. I'm fairly confident this has been fixed in the intervening years so lets try re-enabling these tests.
Fixes#31306
Issue 90702 fix: Stop treating some crate loading failures as fatal errors
Surface mulitple `extern crate` resolution errors at a time.
This is achieved by creating a dummy crate, instead of aborting directly after the resolution error. The `ExternCrateError` has been added to allow propagating the resolution error from `rustc_metadata` crate to the `rustc_resolve` with a minimal public surface. The `import_extern_crate` function is a block that was factored out from `build_reduced_graph_for_item` for better organization. The only added functionality made to it where the added error handling in the `process_extern_crate` call. The remaining bits in this function are the same as before.
Resolves#90702
r? `@petrochenkov`
Disallow non-c-like but "fieldless" ADTs from being casted to integer if they use arbitrary enum discriminant
Code like
```rust
#[repr(u8)]
enum Enum {
Foo /* = 0 */,
Bar(),
Baz{}
}
let x = Enum::Bar() as u8;
```
seems to be unintentionally allowed so we couldn't disallow them now ~~, but we could disallow them if arbitrary enum discriminant is used before 1.56 hits stable~~ (stabilization was reverted).
Related: #88621
`@rustbot` label +T-lang
Cleanup: Eliminate ConstnessAnd
This is almost a behaviour-free change and purely a refactoring. "almost" because we appear to be using the wrong ParamEnv somewhere already, and this is now exposed by failing a test using the unstable `~const` feature.
We most definitely need to review all `without_const` and at some point should probably get rid of many of them by using `TraitPredicate` instead of `TraitRef`.
This is a continuation of https://github.com/rust-lang/rust/pull/90274.
r? `@oli-obk`
cc `@spastorino` `@ecstatic-morse`
... if they use arbitrary enum discriminant. Code like
```rust
enum Enum {
Foo = 1,
Bar(),
Baz{}
}
```
seems to be unintentionally allowed so we couldn't disallow them now,
but we could disallow them if arbitrary enum discriminant is used before
1.56 hits stable.
Add tests for `normalize-docs` overflow errors
`@b-naber` do you understand why using `try_normalize_erasing_regions` doesn't silence these cycle errors? Rustdoc isn't emitting them, rustc is aborting before returning an error, even though the function has `try_` in the name.
cc https://github.com/rust-lang/rust/issues/82692, https://github.com/rust-lang/rust/pull/91255
expand: Turn `ast::Crate` into a first class expansion target
And stop creating a fake `mod` item for the crate root when expanding a crate, thus addressing FIXMEs left in https://github.com/rust-lang/rust/pull/82238, and making a step towards a proper support for crate-level macro attributes (cc #54726).
I haven't added token collection support for the whole crate in this PR, maybe later.
r? `@Aaron1011`
Deny warnings in rustdoc non-UI tests
These warnings were silently ignored since they did not appear in a
`.stderr` file and did not fail the test. With this change, warnings in
tests are denied, causing the tests to fail if they have warnings.
This change has already led me to find a bug in rustdoc (#91274) and a
useless test (`src/test/rustdoc/primitive/primitive-generic-impl.rs`,
though its uselessness is unrelated to its warnings).
r? `@jyn514`
Add support for LLVM coverage mapping format versions 5 and 6
This PR cherry-pick's Swatinem's initial commit in unsubmitted PR #90047.
My additional commit augments Swatinem's great starting point, but adds full support for LLVM
Coverage Mapping Format version 6, conditionally, if compiling with LLVM 13.
Version 6 requires adding the compilation directory when file paths are
relative, and since Rustc coverage maps use relative paths, we should
add the expected compilation directory entry.
Note, however, that with the compilation directory, coverage reports
from `llvm-cov show` can now report file names (when the report includes
more than one file) with the full absolute path to the file.
This would be a problem for test results, but the workaround (for the
rust coverage tests) is to include an additional `llvm-cov show`
parameter: `--compilation-dir=.`
Remove all migrate.nll.stderr files
There are a few ui tests that setup the revisions like:
```rust
// revisions: migrate nll`
// [nll]compile-flags: -Zborrowck=mir
```
However most of them fail to disable the nll compare mode like this:
```rust
// ignore-compare-mode-nll
```
This ends up generating confusing files ending in `.migrate.nll.stderr` because the nll compare mode is run on top of the migrate revision.
This PR fixes this by adding `ignore-compare-mode-nll` to these tests.
I would have just made these tests use compare modes instead but I assume the reason these tests are messing around with revisions instead of just letting the nll compare mode do its thing is to enforce error annotations for both migrate and nll.
Relying on just compare modes would only have the error annotations for migrate.
When recovering from a `:` in a pattern, use adequate AST pattern
If the suggestion to use `::` instead of `:` in the pattern isn't correct, a second resolution error will be emitted.
This commit augments Swatinem's initial commit in uncommitted PR #90047,
which was a great starting point, but did not fully support LLVM
Coverage Mapping Format version 6.
Version 6 requires adding the compilation directory when file paths are
relative, and since Rustc coverage maps use relative paths, we should
add the expected compilation directory entry.
Note, however, that with the compilation directory, coverage reports
from `llvm-cov show` can now report file names (when the report includes
more than one file) with the full absolute path to the file.
This would be a problem for test results, but the workaround (for the
rust coverage tests) is to include an additional `llvm-cov show`
parameter: `--compilation-dir=.`
CTFE: support assert_zero_valid and assert_uninit_valid
This ensures the implementation of all three type-based assert_ intrinsics remains consistent in Miri.
`assert_inhabited` recently got stabilized in https://github.com/rust-lang/rust/pull/90896 (meaning stable `const fn` can call it), so do the same with these other intrinsics.
Cc ```@rust-lang/wg-const-eval```
tests: Ignore `test/debuginfo/rc_arc.rs` on windows-gnu
The tests checks some pretty-printer output, but pretty-printers are not embedded on windows-gnu.
Regressed in https://github.com/rust-lang/rust/pull/85448.
Take a LocalDefId in expect_*item.
Items and item-likes are always HIR owners.
When trying to find such nodes, there is no ambiguity, the `LocalDefId` and the `HirId::owner` always match.
In such cases, `local_def_id_to_hir_id` does not carry any meaningful information, so we can just skip calling it altogether.
Accumulate all values of `-C remark` option
When `-C remark=...` option is specified multiple times,
accumulate all values instead of using only the last one.
r? `@nikic`
Add demonstration test for #91161
Since cross-crate things are hard to demonstrate in playground, here's a test showing that something currently works that shouldn't.
cc https://github.com/rust-lang/rust/issues/91161 that tracks fixing the problem (and updating this test)
Emit LLVM optimization remarks when enabled with `-Cremark`
The default diagnostic handler considers all remarks to be disabled by
default unless configured otherwise through LLVM internal flags:
`-pass-remarks`, `-pass-remarks-missed`, and `-pass-remarks-analysis`.
This behaviour makes `-Cremark` ineffective on its own.
Fix this by configuring a custom diagnostic handler that enables
optimization remarks based on the value of `-Cremark` option. With
`-Cremark=all` enabling all remarks.
Fixes#90924.
r? `@nikic`
