compiletest: suppress Windows Error Reporting (WER) for `run-make` tests
WER by default will show a *bunch* of error dialogues for missing DLLs on Windows for `run-make` tests. We address that by:
1. Guarding `run-make` test process spawning with `disable_error_reporting`.
2. Fixing `disable_error_reporting` to also add the [`SEM_FAILCRITICALERRORS` flag to `SetErrorMode`][SetErrorMode]. Just `SEM_NOGPFAULTERRORBOX` was not sufficient to suppress error dialogues for e.g. missing DLLs.
Fixes#132092. In particular, refer to that issue for the necessary conditions to observe these dialogues from popping up in the first place.
I was only able to manually test this locally in my "native" Windows msvc environment and it prevents the WER dialogues from popping up, I don't think it's possible to really test this automatically.
[SetErrorMode]: https://learn.microsoft.com/en-us/windows/win32/api/errhandlingapi/nf-errhandlingapi-seterrormode?redirectedfrom=MSDN#parameters
Don't allow test revisions that conflict with built in cfgs
Fixes#128964
Sorry `@heysujal` I started working on this about 1 minute before your comment by complete coincidence 😅
Add wasm32v1-none target (compiler-team/#791)
This is a preliminary implementation of the MCP discussed in [compiler-team#791](https://github.com/rust-lang/compiler-team/issues/791). It's not especially "major" but you know, process! Anyway it adds a new wasm32v1-none target which just pins down a set of wasm features. I think this is close to the consensus that emerged when discussing it on Zulip so I figured I'd sketch to see how hard it is. Turns out not very.
Compiletest: Custom differ
This adds support for a custom differ for compiletests. It’s purely visual and helps produce cleaner output when UI tests fail.
I’m using an environment variable for now since it’s experimental and I don’t want to drill the cli arguments all the way down. Also did a bit of general cleanup while I was at it.
This is how it looks [with debug info silenced](https://github.com/rust-lang/rust/pull/131182) (#131182)
`COMPILETEST_DIFF_TOOL="/usr/bin/env difft --color always --background light --display side-by-side" ./x test tests/ui/parser`
Rollup of 8 pull requests
Successful merges:
- #125205 (Fixup Windows verbatim paths when used with the `include!` macro)
- #131049 (Validate args are correct for `UnevaluatedConst`, `ExistentialTraitRef`/`ExistentialProjection`)
- #131549 (Add a note for `?` on a `impl Future<Output = Result<..>>` in sync function)
- #131731 (add `TestFloatParse` to `tools.rs` for bootstrap)
- #131732 (Add doc(plugins), doc(passes), etc. to INVALID_DOC_ATTRIBUTES)
- #132006 (don't stage-off to previous compiler when CI rustc is available)
- #132022 (Move `cmp_in_dominator_order` out of graph dominator computation)
- #132033 (compiletest: Make `line_directive` return a `DirectiveLine`)
r? `@ghost`
`@rustbot` modify labels: rollup
compiletest: Make `line_directive` return a `DirectiveLine`
This reduces the need to juggle raw tuples, and opens up the possibility of moving more parts of directive parsing into `line_directive`.
In order to make the main change possible, this PR also (partly) separates the debugger-command parsing from the main directive parser. That cleanup removes support for `[rev]` in debugger commands, which is not used by any tests.
terminology: #[feature] *enables* a feature (instead of "declaring" or "activating" it)
Mostly, we currently call a feature that has a corresponding `#[feature(name)]` attribute in the current crate a "declared" feature. I think that is confusing as it does not align with what "declaring" usually means. Furthermore, we *also* refer to `#[stable]`/`#[unstable]` as *declaring* a feature (e.g. in [these diagnostics](f25e5abea2/compiler/rustc_passes/messages.ftl (L297-L301))), which aligns better with what "declaring" usually means. To make things worse, the functions `tcx.features().active(...)` and `tcx.features().declared(...)` both exist and they are doing almost the same thing (testing whether a corresponding `#[feature(name)]` exists) except that `active` would ICE if the feature is not an unstable lang feature. On top of this, the callback when a feature is activated/declared is called `set_enabled`, and many comments also talk about "enabling" a feature.
So really, our terminology is just a mess.
I would suggest we use "declaring a feature" for saying that something is/was guarded by a feature (e.g. `#[stable]`/`#[unstable]`), and "enabling a feature" for `#[feature(name)]`. This PR implements that.
Move const trait tests from `ui/rfcs/rfc-2632-const-trait-impl` to `ui/traits/const-traits`
I found the old test directory to be somewhat long to name, and I don't think it's necessary to put an experimental implementation's tests under an rfc which is closed.
r? fee1-dead
Breaking this out of #131985 so that PR doesn't touch 300 files.
make unsupported_calling_conventions a hard error
This has been a future-compat lint (not shown in dependencies) since Rust 1.55, released 3 years ago. Hopefully that was enough time so this can be made a hard error now. Given that long timeframe, I think it's justified to skip the "show in dependencies" stage. There were [not many crates hitting this](https://github.com/rust-lang/rust/pull/86231#issuecomment-866300943) even when the lint was originally added.
This should get cratered, and I assume then it needs a t-compiler FCP. (t-compiler because this looks entirely like an implementation oversight -- for the vast majority of ABIs, we already have a hard error, but some were initially missed, and we are finally fixing that.)
Fixes https://github.com/rust-lang/rust/pull/87678
feat: better completions for extern blcoks
This PR refactors `add_keywords` (making it much clearer!) and enhances completion for `extern` blocks.
It is recommended to reviewing the changes in order of the commits:
- The first commit (f3c4dde0a4917a2bac98605cc045eecfb4d69872) doesn’t change any logic but refactors parts of the `add_keywords` function and adds detailed comments.
- The second commit (5dcc1ab649bf8a49cadf006d620871b12f093a2f) improves completion for `extern` kw and extern blocks.
linkchecker: add a reminder on broken links to add new/renamed pages to `SUMMARY.md` for mdBooks
I spent an embarrassingly long amount of time trying to figure out why CI was failing for a PR adding new platform support docs. In turns out it's because the PR author didn't register the new page in `SUMMARY.md`. I completely forgot about it too, and was reading linkchecker source because I thought it was a bug in linkchecker.
So this PR adds a note to modify `SUMMARY.md` when adding new pages in a mdBook.
E.g.
```
# Adding a new `meow` target but forgor to register the page in `SUMMARY.md`
rustc\platform-support.html:183: broken link - `rustc\platform-support\meow.html`
rustc\print.html:9730: broken link - `rustc\platform-support\meow.html`
checked links in: 19.1s
number of HTML files scanned: 43588
number of HTML redirects found: 13735
number of links checked: 3145951
number of links ignored due to external: 156244
number of links ignored due to exceptions: 9
number of intra doc links ignored: 8
errors found: 2
NOTE: if you are adding or renaming a markdown file in a mdBook, don't forget to register the page in SUMMARY.md
found some broken links
```
stabilize Strict Provenance and Exposed Provenance APIs
Given that [RFC 3559](https://rust-lang.github.io/rfcs/3559-rust-has-provenance.html) has been accepted, t-lang has approved the concept of provenance to exist in the language. So I think it's time that we stabilize the strict provenance and exposed provenance APIs, and discuss provenance explicitly in the docs:
```rust
// core::ptr
pub const fn without_provenance<T>(addr: usize) -> *const T;
pub const fn dangling<T>() -> *const T;
pub const fn without_provenance_mut<T>(addr: usize) -> *mut T;
pub const fn dangling_mut<T>() -> *mut T;
pub fn with_exposed_provenance<T>(addr: usize) -> *const T;
pub fn with_exposed_provenance_mut<T>(addr: usize) -> *mut T;
impl<T: ?Sized> *const T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> *mut T {
pub fn addr(self) -> usize;
pub fn expose_provenance(self) -> usize;
pub fn with_addr(self, addr: usize) -> Self;
pub fn map_addr(self, f: impl FnOnce(usize) -> usize) -> Self;
}
impl<T: ?Sized> NonNull<T> {
pub fn addr(self) -> NonZero<usize>;
pub fn with_addr(self, addr: NonZero<usize>) -> Self;
pub fn map_addr(self, f: impl FnOnce(NonZero<usize>) -> NonZero<usize>) -> Self;
}
```
I also did a pass over the docs to adjust them, because this is no longer an "experiment". The `ptr` docs now discuss the concept of provenance in general, and then they go into the two families of APIs for dealing with provenance: Strict Provenance and Exposed Provenance. I removed the discussion of how pointers also have an associated "address space" -- that is not actually tracked in the pointer value, it is tracked in the type, so IMO it just distracts from the core point of provenance. I also adjusted the docs for `with_exposed_provenance` to make it clear that we cannot guarantee much about this function, it's all best-effort.
There are two unstable lints associated with the strict_provenance feature gate; I moved them to a new [strict_provenance_lints](https://github.com/rust-lang/rust/issues/130351) feature since I didn't want this PR to have an even bigger FCP. ;)
`@rust-lang/opsem` Would be great to get some feedback on the docs here. :)
Nominating for `@rust-lang/libs-api.`
Part of https://github.com/rust-lang/rust/issues/95228.
[FCP comment](https://github.com/rust-lang/rust/pull/130350#issuecomment-2395114536)
Add wrap/unwrap return type in Option
I pretty much just copied over the code and tests for wrapping/unwrapping return types in `Result` and then did a bunch of find and replace changes.
I handled unwrapping statements returning `None` by just replacing `None` with the unit type, but I'm open to suggestions for more intuitive behavior here.
Rollup of 4 pull requests
Successful merges:
- #126588 (Added more scenarios where comma to be removed in the function arg)
- #131728 (bootstrap: extract builder cargo to its own module)
- #131968 (Rip out old effects var handling code from traits)
- #131981 (Remove the `BoundConstness::NotConst` variant)
r? `@ghost`
`@rustbot` modify labels: rollup
Rip out old effects var handling code from traits
Traits no longer have an effect parameter, so this removes logic associated with it. It also removes logic surrounding confirming `~const Destruct` bounds, which I added a looooong time ago, and which I don't feel like we need anymore -- if it needs to be added back, it should be rewritten :D
cc `@fee1-dead`
