| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Only use it when the type alias contains an opaque type.
Also does wf-checking on such type aliases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Remove comments from mir-opt MIR dumps
See https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Line.20numbers.20in.20mir-opt.20tests/near/363849874
In https://github.com/rust-lang/rust/pull/99780 there is mention that "there has been a zulip conversation about disabling line numbers with mixed opinions" which to me means that some people opposed this. I can't find the referenced conversation so... here we go.
The current situation is quite chaotic. It's not hard to find MIR diffs which contain
* Absolute line numbers
* Relative line numbers
* Substituted line numbers (LL)
For example: https://github.com/rust-lang/rust/blob/408bbd040613f6776e0a7d05d582c81f4ddc189a/tests/mir-opt/inline/inline_shims.drop.Inline.diff#L10-L17
And sometimes adding a comment at the top of a mir-opt test generates a diff in the test because a line number changed: https://github.com/rust-lang/rust/pull/98112/files#diff-b8cf4bcce95078e6a3faf075e9abf6864872fb28a64d95c04f04513b9e3bbd81
And irrelevant changes to the standard library can generate diffs in mir-opt tests: https://github.com/rust-lang/rust/pull/110694/files#diff-bf96b0e7c67b8b272814536888fd9428c314991e155beae1f0a2a67f0ac47b2c
https://github.com/rust-lang/rust/commit/769886cc35ce08b76839f4cf72b8af1161c432e1
I think we should, specifically in mir-opt tests, completely remove the comments, or insert placeholders for all line and column numbers.
|
|
Rollup of 8 pull requests
Successful merges:
- #112403 (Prevent `.eh_frame` from being emitted for `-C panic=abort`)
- #112517 (`suspicious_double_ref_op`: don't lint on `.borrow()`)
- #112529 (Extend `unused_must_use` to cover block exprs)
- #112614 (tweak suggestion for argument-position `impl ?Sized`)
- #112654 (normalize closure output in equate_inputs_and_outputs)
- #112660 (Migrate GUI colors test to original CSS color format)
- #112664 (Add support for test tmpdir to fuchsia test runner)
- #112669 (Fix comment for ptr alignment checks in codegen)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Extend `unused_must_use` to cover block exprs
Given code like
```rust
#[must_use]
fn foo() -> i32 {
42
}
fn warns() {
{
foo();
}
}
fn does_not_warn() {
{
foo()
};
}
fn main() {
warns();
does_not_warn();
}
```
### Before This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: 1 warning emitted
```
### After This PR
```
warning: unused return value of `foo` that must be used
--> test.rs:8:9
|
8 | foo();
| ^^^^^
|
= note: `#[warn(unused_must_use)]` on by default
help: use `let _ = ...` to ignore the resulting value
|
8 | let _ = foo();
| +++++++
warning: unused return value of `foo` that must be used
--> test.rs:14:9
|
14 | foo()
| ^^^^^
|
help: use `let _ = ...` to ignore the resulting value
|
14 | let _ = foo();
| +++++++ +
warning: 2 warnings emitted
```
Fixes #104253.
|
|
|
|
Sync rustc_codegen_cranelift
The main highlights this time are a cranelift update, some x86 vendor intrinsic implementations and preparations for testing cg_clif in CI here.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
|
|
|
|
|
|
rustdoc-gui: allow running on Windows
This adds few fixes to allow running `python x.py test rustdoc-gui` on Windows.
* path to npm required to be `npm.cmd` on Windows (otherwise don't work for me)
* properly parse node module version on Windows
* properly provide path to browser-ui-test runner (fixed in #112613)
r? `@GuillaumeGomez`
|
|
Dereference pointers in shims as correct types
Currently, shims will dereference pointers as the type written by the user. This can cause false positives, incorrect behavior such as #2136, and even ICEs if a field is not present.
This PR fixes this by having shims dereference pointers with types from `std` or `libc` that we can rely on the layout and field names of instead of with whatever the user passed in.
Fixes #1123
|
|
|
|
|
|
|
|
Update cargo
11 commits in 49b6d9e179a91cf7645142541c9563443f64bf2b..0c14026aa84ee2ec4c67460c0a18abc8519ca6b2
2023-06-09 17:21:19 +0000 to 2023-06-14 18:43:05 +0000
- fix(embedded): Don't append hash to bin names (rust-lang/cargo#12269)
- Fix version requirement example in Dependency Resolution, SemVer compatibility section (rust-lang/cargo#12267)
- Update triagebot links. (rust-lang/cargo#12265)
- Show a better error when container tests fail. (rust-lang/cargo#12264)
- chore: update dependencies (rust-lang/cargo#12261)
- refactor(embedded) (rust-lang/cargo#12262)
- docs: clarify the use of `default` branch instead of `main` by default (rust-lang/cargo#12251)
- docs: update changelog for 1.71 backport and 1.72 (rust-lang/cargo#12256)
- feat: Initial support for single-file packages (rust-lang/cargo#12245)
- test(z-flags): Verify `-Z` flags list is sorted (rust-lang/cargo#12224)
- refactor: registry data kinds cleanup (rust-lang/cargo#12248)
---
This commit also update LICENSE exceptions, as Cargo introduced a newer version of `dunce` and `blake3` as dependencies.
r? `@ghost`
|
|
Don't drain-on-drop in DrainFilter impls of various collections.
This removes drain-on-drop behavior from various unstable DrainFilter impls (not yet for HashSet/Map) because that behavior [is problematic](https://github.com/rust-lang/rust/issues/43244#issuecomment-641638196) (because it can lead to panic-in-drop when user closures panic) and may become forbidden if [this draft RFC passes](https://github.com/rust-lang/rfcs/pull/3288).
closes #101122
[ACP](https://github.com/rust-lang/libs-team/issues/136)
affected tracking issues
* #43244
* #70530
* #59618
Related hashbrown update: https://github.com/rust-lang/hashbrown/pull/374
|
|
Rollup of 7 pull requests
Successful merges:
- #112584 (loongarch64-none*: Remove environment component from llvm target)
- #112600 (Introduce a `Stable` trait to translate MIR to SMIR)
- #112605 (Improve docs/clean up negative overlap functions)
- #112611 (Error on unconstrained lifetime in RPITIT)
- #112612 (Fix explicit-outlives-requirements lint span)
- #112613 (Fix rustdoc-gui tests on Windows)
- #112620 (Fix small typo)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Fix rustdoc-gui tests on Windows
The browser-ui-test update contains fixes needed for backslash handling (they were not correctly escaped).
Since we have a mix of slash and backslash in some tests, I replaced `DOC_FOLDER` variable backslashes with slashes.
And finally it seemed like the unicode escaped wasn't much appreciated on Windows for some reason so I used the character directly.
cc `@klensy`
r? `@notriddle`
|
|
Add support for targets without unwinding in `mir-opt`, and improve `--bless` for it
The main goal of this PR is to add support for targets without unwinding support in the `mir-opt` test suite, by adding the `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment. Similarly to 32bit vs 64bit, when that comment is present, blessed output files will have the `.panic-unwind` or `.panic-abort` suffix, and the right one will be chosen depending on the target's panic strategy.
The `EMIT_MIR_FOR_EACH_PANIC_STRATEGY` comment replaced all the `ignore-wasm32` comments in the `mir-opt` test suite, as those comments were added due to `wasm32` being a target without unwinding support. The comment was also added on other tests that were only executed on x86 but were still panic strategy dependent.
The `mir-opt` suite was then blessed, which caused a ton of churn as most of the existing output files had to be renamed and (mostly) duplicated with the abort strategy.
---
After [asking on Zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/mir-opt.20tests.20and.20panic.3Dabort), the main concern about this change is it'd make blessing the `mir-opt` suite even harder, as you'd need to both bless it with an unwinding target and an aborting target. This exacerbated the current situation, where you'd need to bless it with a 32bit and a 64bit target already.
Because of that, this PR also makes significant enhancements to `--bless` for the `mir-opt` suite, where it will automatically bless the suite four times with different targets, while requiring minimal cross-compilation.
To handle the 32bit vs 64bit blessing, there is now an hardcoded list of target mapping between 32bit and 64bit. The goal of the list is to find a related target that will *probably* work without requiring additional cross-compilation toolchains on the system. If a mapping is found, bootstrap will bless the suite with both targets, otherwise just with the current target.
To handle the panic strategy blessing (abort vs unwind), I had to resort to what I call "synthetic targets". For each of the target we're blessing (so either the current one, or a 32bit and a 64bit depending on the previous paragraph), bootstrap will extract the JSON spec of the target and change it to include `"panic-strategy": "abort"`. It will then build the standard library with this synthetic target, and bless the `mir-opt` suite with it.
As a result of these changes, blessing the `mir-opt` suite will actually bless it two or four times with different targets, ensuring all possible variants are actually blessed.
---
This PR is best reviewed commit-by-commit.
r? `@jyn514`
cc `@saethlin` `@oli-obk`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rustup
|
|
|
|
|
|
|
|
Uplift `clippy::cmp_nan` lint
This PR aims at uplifting the `clippy::cmp_nan` lint into rustc.
## `invalid_nan_comparisons`
~~(deny-by-default)~~ (warn-by-default)
The `invalid_nan_comparisons` lint checks comparison with `f32::NAN` or `f64::NAN` as one of the operand.
### Example
```rust,compile_fail
let a = 2.3f32;
if a == f32::NAN {}
```
### Explanation
NaN does not compare meaningfully to anything – not even itself – so those comparisons are always false.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
|
|
Update cargo
12 commits in b0fa79679e717cd077b7fc0fa4166f47107f1ba9..49b6d9e179a91cf7645142541c9563443f64bf2b
2023-06-03 14:19:48 +0000 to 2023-06-09 17:21:19 +0000
- docs: doc comments for all registry kinds (rust-lang/cargo#12247)
- chore: Migrate print-ban from test to clippy (rust-lang/cargo#12246)
- fix: fetch nested git submodules (rust-lang/cargo#12244)
- refactor: registry source cleanup (rust-lang/cargo#12240)
- test: loose overly matches for git cli output (rust-lang/cargo#12241)
- fix: disable multiplexing on macOS for some versions of curl (rust-lang/cargo#12234)
- docs: doc comments for registry source and index (rust-lang/cargo#12239)
- doc: point to nightly cargo doc (rust-lang/cargo#12237)
- Upgrade to `gix` v0.45 for multi-round pack negotiations. (rust-lang/cargo#12236)
- refactor: git source cleanup (rust-lang/cargo#12197)
- Add message on reusing previous temporary path on failed cargo installs (rust-lang/cargo#12231)
- doc: the first line should be a simple sentence instead of a heading (rust-lang/cargo#12228)
r? `@ghost`
|
|
Change format of rustdoc-js tests by putting query and correction directly alongside the expected values
As I was working on fixing merge conflicts in #108537, I faced quite a big issue when trying to update the `rustdoc-js*` tests. To make it much simpler, this PR moves the `query` and `correction` directly alongside the expected data so now we know what is the query that is being run without needing to add comments or going back to the top of the file.
r? ```@notriddle```
|
|
|
|
|
|
directly alongside the expected values
|
|
Uplift `clippy::undropped_manually_drops` lint
This PR aims at uplifting the `clippy::undropped_manually_drops` lint.
## `undropped_manually_drops`
(warn-by-default)
The `undropped_manually_drops` lint check for calls to `std::mem::drop` with a value of `std::mem::ManuallyDrop` which doesn't drop.
### Example
```rust
struct S;
drop(std::mem::ManuallyDrop::new(S));
```
### Explanation
`ManuallyDrop` does not drop it's inner value so calling `std::mem::drop` will not drop the inner value of the `ManuallyDrop` either.
-----
Mostly followed the instructions for uplifting an clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
-----
For Clippy:
changelog: Moves: Uplifted `clippy::undropped_manually_drops` into rustc
|
|
|
|
|
|
|
|
Removed use of iteration through a HashMap/HashSet in rustc_incremental and replaced with IndexMap/IndexSet
This allows for the `#[allow(rustc::potential_query_instability)]` in rustc_incremental to be removed, moving towards fixing #84447 (although a LOT more modules have to be changed to fully resolve it). Only HashMaps/HashSets that are being iterated through have been modified (although many structs and traits outside of rustc_incremental had to be modified as well, as they had fields/methods that involved a HashMap/HashSet that would be iterated through)
I'm making a PR for just 1 module changed to test for performance regressions and such, for future changes I'll either edit this PR to reflect additional modules being converted, or batch multiple modules of changes together and make a PR for each group of modules.
|
