Re-enable more debuginfo tests on Windows
These tests used to be disabled on all Windows hosts. Now they're fully enabled or just disabled on windows-gnu with an issue citation that clearly explains why.
The changes in this PR are not tested by PR CI, but I've tested it using try-jobs below.
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-mingw
try-job: x86_64-msvc
Re-enable `dump-ice-to-disk` for Windows
This test was previously flakey on `i686-mingw` (reason unknown), but since some modifications (quarantining each ICE test in separate tmp dirs, adding/removing `RUSTC_ICE` env vars as suitable to prevent any kind of environmental influence), I could no longer make it fail on `i686-mingw`.
I tried running this test (without the `ignore-windows` of course) a bunch of times via `i686-mingw` try jobs and it refused to fail (see #128958). I was also never able to reproduce the failure locally.
In any case, if this turns out to be still flakey on `i686-mingw`, we can revert the removal of `ignore-windows` but this time we'll have way more context for why the test failed.
Running the `i686-mingw` alongside some Windows jobs for basic santiy check. But the try jobs succeeding is insufficient to guarantee reproducibility.
cc #129115 for backlink.
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
Stabilize `unsafe_attributes`
# Stabilization report
## Summary
This is a tracking issue for the RFC 3325: unsafe attributes
We are stabilizing `#![feature(unsafe_attributes)]`, which makes certain attributes considered 'unsafe', meaning that they must be surrounded by an `unsafe(...)`, as in `#[unsafe(no_mangle)]`.
RFC: rust-lang/rfcs#3325
Tracking issue: #123757
## What is stabilized
### Summary of stabilization
Certain attributes will now be designated as unsafe attributes, namely, `no_mangle`, `export_name`, and `link_section` (stable only), and these attributes will need to be called by surrounding them in `unsafe(...)` syntax. On editions prior to 2024, this is simply an edition lint, but it will become a hard error in 2024. This also works in `cfg_attr`, but `unsafe` is not allowed for any other attributes, including proc-macros ones.
```rust
#[unsafe(no_mangle)]
fn a() {}
#[cfg_attr(any(), unsafe(export_name = "c"))]
fn b() {}
```
For a table showing the attributes that were considered to be included in the list to require unsafe, and subsequent reasoning about why each such attribute was or was not included, see [this comment here](https://github.com/rust-lang/rust/pull/124214#issuecomment-2124753464)
## Tests
The relevant tests are in `tests/ui/rust-2024/unsafe-attributes` and `tests/ui/attributes/unsafe`.
Use `FnSig` instead of raw `FnDecl` for `ForeignItemKind::Fn`, fix ICE for `Fn` trait error on safe foreign fn
Let's use `hir::FnSig` instead of `hir::FnDecl + hir::Safety` for `ForeignItemKind::Fn`. This consolidates some handling code between normal fns and foreign fns.
Separetly, fix an ICE where we weren't handling `Fn` trait errors for safe foreign fns.
If perf is bad for the first commit, I can rework the ICE fix to not rely on it. But if perf is good, I prefer we fix and clean up things all at once 👍
r? spastorino
Fixes#128764
Rollup of 6 pull requests
Successful merges:
- #128989 (Emit an error for invalid use of the linkage attribute)
- #129167 (mir/pretty: use `Option` instead of `Either<Once, Empty>`)
- #129168 (Return correct HirId when finding body owner in diagnostics)
- #129191 (rustdoc-json: Clean up serialization and printing.)
- #129192 (Remove useless attributes in merged doctest generated code)
- #129196 (Remove a useless ref/id/ref round-trip from `pattern_from_hir`)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove a useless ref/id/ref round-trip from `pattern_from_hir`
This re-lookup of `&hir::Pat` by its ID appears to be an artifact of earlier complexity that has since been removed from the compiler.
Merely deleting the let/match results in borrow errors, but sprinkling `'tcx` in the signature allows it to work again, so I suspect that this code's current function is simply to compensate for overly loose lifetimes in the signature. Perhaps it made more sense at a time when HIR lifetimes were not tied to `'tcx`.
I spotted this while working on some more experimental changes, which is why I've extracted it into its own PR.
Remove useless attributes in merged doctest generated code
I took another look at the generated code for merged doctests and it seems like those attributes are only useful when running `rustc --test`, which isn't the case for merged doctests. Less code generated. \o/
r? `@notriddle`
rustdoc-json: Clean up serialization and printing.
Somewhat a followup to #128963, but makes sense regardless.
- Renames `out_path` to `out_dir` because it's not the path to the JSON, but the directory
- Also adds a comment explaining `None`
- Renames `write` to `serialize_and_write` because it does both.
- Also renames the self-profile activity name to be clear this measures both IO cost and serialization CPU cost
- Expands the timer to cover flushing
- Renames `output` to `output_crate`, to emphasize it's the contents, not the `--output` flag.
r? `@GuillaumeGomez`
Return correct HirId when finding body owner in diagnostics
Fixes#129145Fixes#128810
r? ```@compiler-errors```
```rust
fn generic<const N: u32>() {}
trait Collate<const A: u32> {
type Pass;
fn collate(self) -> Self::Pass;
}
impl<const B: u32> Collate<B> for i32 {
type Pass = ();
fn collate(self) -> Self::Pass {
generic::<{ true }>()
//~^ ERROR: mismatched types
}
}
```
When type checking the `{ true }` anon const we would error with a type mismatch. This then results in diagnostics code attempting to check whether its due to a type mismatch with the return type. That logic was implemented by walking up the hir until we reached the body owner, except instead of using the `enclosing_body_owner` function it special cased various hir nodes incorrectly resulting in us walking out of the anon const and stopping at `fn collate` instead.
This then resulted in diagnostics logic inside of the anon consts `ParamEnv` attempting to do trait solving involving the `<i32 as Collate<B>>::Pass` type which ICEs because it is in the wrong environment.
I have rewritten this function to just walk up until it hits the `enclosing_body_owner` and made some other changes since I found this pretty hard to read/understand. Hopefully it's easier to understand now, it also makes it more obvious that this is not implemented in a very principled way and is definitely missing cases :)
mir/pretty: use `Option` instead of `Either<Once, Empty>`
`Either` is wasteful for a one-or-none iterator, especially since `Once`
is already an `option::IntoIter` internally. We don't really need any of
the iterator mechanisms in this case, just a single conditional insert.
Emit an error for invalid use of the linkage attribute
fixes#128486
Currently, the use of the linkage attribute for Mod, Impl,... is incorrectly permitted. This PR will correct this issue by generating errors, and I've also added some UI test cases for it.
Related: #128552.
Detect multiple crate versions on method not found
When a type comes indirectly from one crate version but the imported trait comes from a separate crate version, the called method won't be found. We now show additional context:
```
error[E0599]: no method named `foo` found for struct `dep_2_reexport::Type` in the current scope
--> multiple-dep-versions.rs:8:10
|
8 | Type.foo();
| ^^^ method not found in `Type`
|
note: there are multiple different versions of crate `dependency` in the dependency graph
--> multiple-dep-versions.rs:4:32
|
4 | use dependency::{do_something, Trait};
| ^^^^^ `dependency` imported here doesn't correspond to the right crate version
|
::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-1.rs:4:1
|
4 | pub trait Trait {
| --------------- this is the trait that was imported
|
::: ~/rust/build/x86_64-unknown-linux-gnu/test/run-make/crate-loading/rmake_out/multiple-dep-versions-2.rs:4:1
|
4 | pub trait Trait {
| --------------- this is the trait that is needed
5 | fn foo(&self);
| --- the method is available for `dep_2_reexport::Type` here
```
Fix#128569, fix#110926, fix#109161, fix#81659, fix#51458, fix#32611. Follow up to #124944.
CloneToUninit impls
As per #126799.
Also implements it for `Wtf8` and both versions of `os_str::Slice`.
Maybe it is worth to slap `#[inline]` on some of those impls.
r? `@dtolnay`
float to/from bits and classify: update for float semantics RFC
With https://github.com/rust-lang/rfcs/pull/3514 having been accepted, it is clear that hardware which e.g. flushes subnormal to zero is just non-conformant from a Rust perspective -- this is a hardware bug, or maybe an LLVM backend bug (where LLVM doesn't lower floating-point ops in a way that they have the standardized behavior). So update the comments here to make it clear that we don't have to do any of this, we're just being nice.
Also remove the subnormal/NaN checks from the (unstable) const-version of to/from-bits; they are not needed since we decided with the aforementioned RFC that it is okay to get a different result at const-time and at run-time.
r? `@workingjubilee` since I think you wrote many of the comments I am editing here.
Update cargo
8 commits in 2f738d617c6ead388f899802dd1a7fd66858a691..ba8b39413c74d08494f94a7542fe79aa636e1661
2024-08-13 10:57:52 +0000 to 2024-08-16 22:48:57 +0000
- feat(update): Report when incompatible-rust-version packages are selected (rust-lang/cargo#14401)
- test: Migrate old_cargos to snapbox (rust-lang/cargo#14410)
- Correct diagnostic for `TomlDebugInfo` (rust-lang/cargo#14413)
- Add `--lockfile-path` flag (rust-lang/cargo#14326)
- test: Migrate some json tests to snapbox (rust-lang/cargo#14402)
- Implement base paths (RFC 3529) 1/n: path dep and patch support (rust-lang/cargo#14360)
- doc: convert comments to rustdoc in workspace (rust-lang/cargo#14397)
- Fix MSRV for workspace .package and .dependencies (rust-lang/cargo#14400)
r? ghost
Implement DoubleEnded and ExactSize for Take<Repeat> and Take<RepeatWith>
Repeat iterator always returns the same element and behaves the same way
backwards and forwards. Take iterator can trivially implement backwards
iteration over Repeat inner iterator by simply doing forwards iteration.
DoubleEndedIterator is not currently implemented for Take<Repeat<T>>
because Repeat doesn’t implement ExactSizeIterator which is a required
bound on DEI implementation for Take.
Similarly, since Repeat is an infinite iterator which never stops, Take
can trivially know how many elements it’s going to return. This allows
implementing ExactSizeIterator on Take<Repeat<T>>.
While at it, observe that ExactSizeIterator can also be implemented for
Take<RepeatWhile<F>> so add that implementation too. Since in contrast
to Repeat, RepeatWhile doesn’t guarante to always return the same value,
DoubleEndedIterator isn’t implemented.
Those changes render core::iter::repeat_n somewhat redundant.
Issue: https://github.com/rust-lang/rust/issues/104434
Issue: https://github.com/rust-lang/rust/issues/104729
- [ ] ACP: https://github.com/rust-lang/libs-team/issues/120 (this is actually ACP for repeat_n but this is nearly the same functionality so hijacking it so both approaches can be discussed in one place)
`Either` is wasteful for a one-or-none iterator, especially since `Once`
is already an `option::IntoIter` internally. We don't really need any of
the iterator mechanisms in this case, just a single conditional insert.
Fix wrong source location for some incorrect macro definitions
Fixes#95463
Currently the code will consume the next token tree after `var` when trying to parse `$var:some_type` even when it's not a `:` (e.g. a `$` when input is `($foo $bar:tt) => {}`). Additionally it will return the wrong span when it's not a `:`.
This PR fixes these problems.
Migrate `validate_json.py` script to rust in `run-make/rustdoc-map-file` test
This PR fixes the FIXME I added for future-me who become present-me. :')
Since there are multiple `run-make` tests using python scripts, I suppose more of them will migrate to Rust, hence why I added the `jzon` public reexport to the `run-make-support` crate.
cc `@jieyouxu`
r? `@Kobzol`
Special-case alias ty during the delayed bug emission in `try_from_lit`
This PR tries to fix#116308.
A delayed bug in `try_from_lit` will not be emitted so that the compiler will not ICE when it sees the pair `(ast::LitKind::Int, ty::TyKind::Alias)` in `lit_to_const` (called from `try_from_lit`).
This PR is related to an unstable feature `adt_const_params` (#95174).
r? ``@BoxyUwU``
Re-enable more debuginfo tests on freebsd
These ignores are _ancient_, we don't run freebsd tests in CI, and even if we did they'd probably pass because the test suite passes with the latest gdb release on Linux.
Migrate `reproducible-build` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This will likely fail. Locally, rustc errors with `linker 'linker' not found` on line 36 while the file exists according to the dir-debug statement before it.
If this gets fixed and the test passes, further developments may include:
- [x] There may be some leftovers from each test - `test_in_tmpdir` may therefore be required.
- [ ] Try jobs on all ignored architectures.
- [x] A potential refactor with a struct and a custom function like #128410 so this isn't just a huge stream of `rfs` and `rustc`. This is a little bit harder to do in this test considering the variability present in each test case.
// try-job: x86_64-msvc // windows jobs passed in a prior run
// try-job: x86_64-mingw
// try-job: i686-msvc
// try-job: i686-mingw
try-job: aarch64-apple
try-job: aarch64-gnu
try-job: armhf-gnu
try-job: test-various
try-job: dist-various-1
detect incompatible CI rustc options more precisely
Previously, the logic here was simply checking whether the option was set in `config.toml`. This approach was not manageable in our CI runners as we set so many options in config.toml. In reality, those values are not incompatible since they are usually the same value used to generate the CI rustc. Now, the new logic compares the configuration values with the values used to generate the CI rustc, so we get more precise results and make the process more manageable.
r? Kobzol
Blocker for https://github.com/rust-lang/rust/pull/122709
Only try to modify file times of a writable file on Windows
Introduces a `set_file_times` helper which opens a given path as a file in r+w mode on Windows and then sets file times. Previously the file was open as read-only for Windows which caused permission errors locally.
This should hopefully make setting file times less error prone, since trying to set file times on read-only file on Windows also happened in #127850.
try-job: dist-loongarch64-musl
try-job: x86_64-msvc
