| Age | Commit message (Collapse) | Author | Lines |
|---|
|
enable const-float-classify test, and test_next_up/down on 32bit x86
The test_next_up/down tests have been disabled on all 32bit x86 targets, which goes too far -- they should definitely work on our (tier 1) i686 target, it is only without SSE that we might run into trouble due to https://github.com/rust-lang/rust/issues/114479. However, I cannot reproduce that trouble any more -- maybe that got fixed by https://github.com/rust-lang/rust/pull/123351?
The const-float-classify test relied on const traits "because we can", and got disabled when const traits got removed. That's an unfortunate reduction in test coverage of our float functionality, so let's restore the test in a way that does not rely on const traits.
The const-float tests are actually testing runtime behavior as well, and I don't think that runtime behavior is covered anywhere else. Probably they shouldn't be called "const-float", but we don't have a `tests/ui/float` folder... should I create one and move them there? Are there any other ui tests that should be moved there?
I also removed some FIXME referring to not use x87 for Rust-to-Rust-calls -- that has happened in #123351 so this got fixed indeed. Does that mean we can simplify all that float code again? I am not sure how to test it. Is running the test suite with an i586 target enough?
Cc ```@tgross35``` ```@workingjubilee```
|
|
r=compiler-errors
Don't warn empty branches unreachable for now
The [stabilization](https://github.com/rust-lang/rust/pull/122792) of `min_exhaustive_patterns` updated the `unreachable_pattern` lint to trigger on empty arms too. This has caused some amount of churn, and imposes an unjoyful `#[allow(unreachable_patterns)]` onto library authors who want to stay backwards-compatible.
While I think the lint should eventually cover these cases, for transition's sake I'd prefer to revert linting to what it was prior to stabilization, at least for now.
Fixes https://github.com/rust-lang/rust/issues/129031.
r? ``@compiler-errors``
|
|
Fix false positive with `missing_docs` and `#[test]`
Since #130025, the compiler don't ignore missing_docs when compiling the tests. But there is now a false positive warning for every `#[test]`
For example, this code
```rust
//! Crate docs
fn just_a_test() {}
```
Would emit this warning when running `cargo test`
```
warning: missing documentation for a constant
--> src/lib.rs:5:1
|
4 | #[test]
| ------- in this procedural macro expansion
5 | fn just_a_test() {}
| ^^^^^^^^^^^^^^^^^^^
```
|
|
Report the `note` when specified in `diagnostic::on_unimplemented`
Before this PR the `note` field was completely ignored for some reason, now it is shown (I think) correctly during the hir typechecking phase.
1. Report the `note` when specified in `diagnostic::on_unimplemented`
2. Added a test for unimplemented trait diagnostic
3. Added a test for custom unimplemented trait diagnostic
Close #130084
P.S. This is my first PR to rustc.
|
|
r=compiler-errors
Suggest the correct pattern syntax on usage of unit variant pattern for a struct variant
Closes #126243
I add a suggestion on usage of unit variant pattern for a struct variant.
|
|
Don't suggest adding return type for closures with default return type
Follow up of #129223
r? ``@compiler-errors``
|
|
|
|
disallow `naked_asm!` outside of `#[naked]` functions
tracking issue: https://github.com/rust-lang/rust/issues/90957
parent PR: https://github.com/rust-lang/rust/pull/128651
I split this out from the parent PR because it's self-contained and because the analysis has to search through all functions and there might be performance regressions.
r? `@Amanieu`
|
|
So that it doesn't fail with `forbid(missing_docs)`
Fixes #130218
|
|
generated for `#[test]`
|
|
Since #130025, the compiler don't ignore missing_docs when compiling the tests.
But there is now a false positive warning for every `#[test]`
For example, this code
```rust
//! Crate docs
fn just_a_test() {}
```
Would emit this warning when running `cargo test`
```
warning: missing documentation for a constant
--> src/lib.rs:5:1
|
4 | #[test]
| ------- in this procedural macro expansion
5 | fn just_a_test() {}
| ^^^^^^^^^^^^^^^^^^^
```
|
|
generalize: track relevant info in cache key
This was previously theoretically incomplete as we could incorrectly generalize as if the type was in an invariant context even though we're in a covariant one. Similar with the `in_alias` flag.
r? `@compiler-errors`
|
|
Enumerate lint expectations using AttrId
This PR implements the idea I outlined in https://github.com/rust-lang/rust/issues/127884#issuecomment-2240338547
We can uniquely identify a lint expectation `#[expect(lint0, lint1...)]` using the `AttrId` and the index of the lint inside the attribute. This PR uses this property in `check_expectations`.
In addition, this PR stops stashing expected diagnostics to wait for the unstable -> stable `LintExpectationId` mapping: if the lint is emitted with an unstable attribute, it must have been emitted by an `eval_always` query (like inside the resolver), so won't be loaded from cache. Decoding an `AttrId` from the on-disk cache ICEs, so we have no risk of accidentally checking an expectation.
Fixes https://github.com/rust-lang/rust/issues/127884
cc `@xFrednet`
|
|
- remove an outdated FIXME
- add reference to floating-point semantics issue
Co-authored-by: Jubilee <workingjubilee@gmail.com>
|
|
|
|
|
|
Ban non-array SIMD
Nearing the end of https://github.com/rust-lang/compiler-team/issues/621 !
Currently blocked on ~~https://github.com/rust-lang/compiler-builtins/pull/673~~ ~~https://github.com/rust-lang/compiler-builtins/pull/674~~ ~~https://github.com/rust-lang/rust/pull/129400~~ ~~https://github.com/rust-lang/rust/pull/129481~~ for windows.
|
|
Signed-off-by: FedericoBruzzone <federico.bruzzone.i@gmail.com>
|
|
Rollup of 5 pull requests
Successful merges:
- #130143 (miri-test-libstd: add missing BOOTSTRAP_ARGS)
- #130173 (rustdoc: add two regression tests)
- #130175 (`rustc_mir_transform` cleanups 3)
- #130184 (coverage: Clean up terminology in counter creation)
- #130185 (abi/compatibility test: remove tests inside repr(C) wrappers)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
abi/compatibility test: remove tests inside repr(C) wrappers
When I wrote the test I assumed we'd guarantee ABI compatibility to be "structural" wrt `repr(C)` types, i.e. if two `repr(C)` types have all their fields be pairwise ABI-compatible then the types are ABI-compatible. That got removed from the ABI compatibility docs before they landed, though, so let's also remove it from this test.
|
|
rustdoc: add two regression tests
They were basically copy/pasted from `tests/ui/` to `tests/rustdoc-ui/`.
Not sure if it's worth adding these, I can just close these issues as is if you want.
This brings the number of https://github.com/rust-lang/rust/labels/T-rustdoc + https://github.com/rust-lang/rust/labels/E-needs-test from 3 down to 1.
The remaining one – #103004 — is a nasty one to retroactively find a proper(!) test for.
Fixes #98250.
Fixes #107872.
r? rustdoc
|
|
Also emit `missing_docs` lint with `--test` to fulfil expectations
This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant".
I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive.
Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky.
Fixes https://github.com/rust-lang/rust/issues/130021
try-job: x86_64-gnu-aux
|
|
|
|
|
|
|
|
rustdoc rfc#3662 changes under unstable flags
* All new functionality is under unstable options
* Adds `--merge=shared|none|finalize` flags
* Adds `--parts-out-dir=<crate specific directory>` for `--merge=none`
to write cross-crate info file for a single crate
* Adds `--include-parts-dir=<previously specified directory>` for
`--merge=finalize` to write cross-crate info files
* `tests/rustdoc/` tests for the new flags
|
|
|
|
adapt a test for llvm 20
No functional changes intended.
``@rustbot`` label: +llvm-main
r? ``@nikic``
|
|
bootstrap `naked_asm!` for `compiler-builtins`
tracking issue: https://github.com/rust-lang/rust/issues/90957
parent PR: https://github.com/rust-lang/rust/pull/128651
in this PR, `naked_asm!` is added as an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later.
The `naked_asm!` macro must be introduced first so that we can upgrade `compiler-builtins` to use it, and can then change the implementation of `naked_asm!` in https://github.com/rust-lang/rust/pull/128651
I've added some usages for `naked_asm!` in the tests, so we can be confident that it works, but I've left upgrading the whole test suite to the parent PR.
r? ``@Amanieu``
|
|
Inform the solver if evaluation is concurrent
Parallel compilation of a program can cause unexpected event sequencing. Inform the solver when this is true so it can skip invalid asserts.
|
|
Add test to build crates used by r-a on stable
r? ````````@Kobzol````````
I've opened other PRs for this one to work and they've landed already. I cherry-picked your commit, and added the last remaining pieces we needed I think.
|
|
|
|
Parallel compilation of a program can cause unexpected event sequencing.
Inform the solver when this is true so it can skip invalid asserts, then
assert replaced solutions are equal if Some
|
|
Fix ICE caused by missing span in a region error
Fixes #130012
The ICE occurs on line 634 in this error handling code: https://github.com/rust-lang/rust/blob/085744b7ad8b227239bcee0a44cd78dcd0310ab9/compiler/rustc_trait_selection/src/error_reporting/infer/region.rs#L617-L637 It is caused by the span being a dummy span and `!span.is_dummy()` on line 628 evaluating to `false`.
A dummy span, however, is expected here thanks to the `Self: Trait` predicate from `predicates_of` (see line 61): https://github.com/rust-lang/rust/blob/085744b7ad8b227239bcee0a44cd78dcd0310ab9/compiler/rustc_hir_analysis/src/collect/predicates_of.rs#L61-L69
This PR changes the error handling code to omit the note which needed the span instead of ICE'ing in the presence of a dummy span.
|
|
fix ICE in CMSE type validation
fixes #129983
tracking issue: https://github.com/rust-lang/rust/issues/81391
r? ``@compiler-errors``
|
|
No functional changes intended.
|
|
|
|
|
|
in this commit, `naked_asm!` is an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later.
|
|
const: make ptr.is_null() stop execution on ambiguity
This seems better than saying `false` -- saying `false` is in fact actively unsound if `NonNull` then uses this to permit putting this pointer inside of it, but at runtime it turns out to be null.
Part of https://github.com/rust-lang/rust/issues/74939
Cc ```@rust-lang/wg-const-eval```
|
|
Test codegen when setting deployment target
Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in https://github.com/rust-lang/rust/pull/129342, https://github.com/rust-lang/rust/pull/129367 and https://github.com/rust-lang/rust/pull/129369. See https://github.com/rust-lang/rust/issues/129432 for the bigger picture.
Tested locally using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
```
The only Apple targets that aren't tested by the above command are:
- `arm64e-apple-darwin`, failed to build, see https://github.com/rust-lang/cc-rs/issues/1205.
- `armv7k-apple-watchos`, failed to link, see https://github.com/rust-lang/rust/issues/130071.
- `arm64e-apple-ios`, failed to link, see https://github.com/rust-lang/rust/issues/130085.
- `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html).
- `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by https://github.com/rust-lang/cc-rs/issues/1030.
But all of this is as it was before this PR.
Fixes https://github.com/rust-lang/rust/issues/47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`.
Split out from https://github.com/rust-lang/rust/pull/129342, see that for a little bit of the review that this has gone through already.
r? petrochenkov
```@rustbot``` label O-apple
|
|
r=aDotInTheVoid
rustdoc: normalise type/field names
Updates #100961
- `Import` -> `Use`, to better reflect the terminology of Rust & its syntax
- `TypeBinding` -> `AssocItemConstraint`, to sync up with `clean`
- `FnDecl` -> `FunctionSignature`, because that's what it is
- `Header` -> `FunctionHeader`, because `Header` is a very word that's very heavily loaded with different meanings
- `ItemEnum::AssocType`: `default` -> `type`, because those items appear in `impl` blocks as well, where they're _not_ the "default"
- `ItemEnum::AssocConst`: `default` -> `value`, see the previous point
- `ForeignType` -> `ExternType`, because "foreign" is not the right word there
- boolean fields' names made to consistently be a phrase that can be a yes/no answer, e.g. `async` -> `is_async`
The docs of `ItemEnum::AssocType::type_` & of `ItemEnum::AssocConst::value` are also updated to be up to date with the clarification of the name of the fields
|
|
added support for GNU/Hurd on x86_64
|
|
r=jieyouxu,petrochenkov
Update mingw-w64 + GNU toolchain
The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0
Fixes: https://github.com/rust-lang/rust/issues/112368
|
|
|
|
|
|
|
|
r=petrochenkov
Fix double handling in `collect_tokens`
Double handling of AST nodes can occur in `collect_tokens`. This is when an inner call to `collect_tokens` produces an AST node, and then an outer call to `collect_tokens` produces the same AST node. This can happen in a few places, e.g. expression statements where the statement delegates `HasTokens` and `HasAttrs` to the expression. It will also happen more after #124141.
This PR fixes some double handling cases that cause problems, including #129166.
r? `@petrochenkov`
|
|
Supress niches in coroutines to avoid aliasing violations
As mentioned [here](https://github.com/rust-lang/rust/issues/63818#issuecomment-2264915918), using niches in fields of coroutines that are referenced by other fields is unsound: the discriminant accesses violate the aliasing requirements of the reference pointing to the relevant field. This issue causes [Miri errors in practice](https://github.com/rust-lang/miri/issues/3780).
The "obvious" fix for this is to suppress niches in coroutines. That's what this PR does. However, we have several tests explicitly ensuring that we *do* use niches in coroutines. So I see two options:
- We guard this behavior behind a `-Z` flag (that Miri will set by default). There is no known case of these aliasing violations causing miscompilations. But absence of evidence is not evidence of absence...
- (What this PR does right now.) We temporarily adjust the coroutine layout logic and the associated tests until the proper fix lands. The "proper fix" here is to wrap fields that other fields can point to in [`UnsafePinned`](https://github.com/rust-lang/rust/issues/125735) and make `UnsafePinned` suppress niches; that would then still permit using niches of *other* fields (those that never get borrowed). However, I know that coroutine sizes are already a problem, so I am not sure if this temporary size regression is acceptable.
`@compiler-errors` any opinion? Also who else should be Cc'd here?
|
|
* Adds tests for the behavior from rfc#3662 in `tests/rustdoc/`
|
