| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update cargo
10 commits in a4c1cd0eb6b18082a7e693f5a665548fe1534be4..39ad1039d9e3e1746177bf5d134af4c164f95528
2022-05-20 00:55:25 +0000 to 2022-05-25 00:50:02 +0000
* doc: discuss build script instruction order (rust-lang/cargo#10600)
* Require http-registry URLs to end with a '/' (rust-lang/cargo#10698)
* No printing executable names when running tests and benchmarks with json message format (rust-lang/cargo#10691)
* Restore proper error for crate not in local reg (rust-lang/cargo#10683)
* Update libcurl (rust-lang/cargo#10696)
* Fixed small typos (rust-lang/cargo#10693)
* fix bugs with `workspace` key and `update_toml` (rust-lang/cargo#10685)
* Bump to 0.64.0, update changelog (rust-lang/cargo#10687)
* List C compiler as a build dependency in README (rust-lang/cargo#10678)
* Add unstable `rustc-check-cfg` build script output (rust-lang/cargo#10539)
r? `@ehuss`
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #97302 (Do writeback of Closure params before visiting the parent expression)
- #97328 (rustc: Fix ICE in native library error reporting)
- #97351 (Output correct type responsible for structural match violation)
- #97398 (Add regression test for #82830)
- #97400 (Fix a typo on Struct `Substructure`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Add regression test for #82830
Closes #82830
r? `@compiler-errors`
|
|
b-naber:adt-const-params-structural-match-violation, r=michaelwoerister
Output correct type responsible for structural match violation
Previously we included the outermost type that caused a structural match violation in the error message and stated that that type must be annotated with `#[derive(Eq, PartialEq)]` even if it already had that annotation. This PR outputs the correct type in the error message.
Fixes https://github.com/rust-lang/rust/issues/97278
|
|
rustc: Fix ICE in native library error reporting
Fixes https://github.com/rust-lang/rust/issues/97299
|
|
Do writeback of Closure params before visiting the parent expression
This means that given the expression:
```
let x = |a: Vec<_>| {};
```
We will visit the HIR node for `a` before `x`, and report the ambiguity on the former instead of the latter. This also moves writeback for struct field ids and const blocks before, but the ordering of this and walking the expr doesn't seem to matter.
|
|
Extend ptr::null and null_mut to all thin (including extern) types
Fixes https://github.com/rust-lang/rust/issues/93959
This change was accepted in https://rust-lang.github.io/rfcs/2580-ptr-meta.html
Note that this changes the signature of **stable** functions. The change should be backward-compatible, but it is **insta-stable** since it cannot (easily, at all?) be made available only through a `#![feature(…)]` opt-in.
The RFC also proposed the same change for `NonNull::dangling`, which makes sense it terms of its signature but not in terms of its implementation. `dangling` uses `align_of()` as an address. But what `align_of()` should be for extern types or whether it should be allowed at all remains an open question.
This commit depends on https://github.com/rust-lang/rust/pull/93977, which is not yet part of the bootstrap compiler. So `#[cfg]` is used to only apply the change in stage 1+. As far a I know bounds cannot be made conditional with `#[cfg]`, so the entire functions are duplicated. This is unfortunate but temporary.
Since this duplication makes it less obvious in the diff, the new definitions differ in:
* More permissive bounds (`Thin` instead of implied `Sized`)
* Different implementation
* Having `rustc_allow_const_fn_unstable(const_fn_trait_bound)`
* Having `rustc_allow_const_fn_unstable(ptr_metadata)`
|
|
|
|
Minor improvement on else-no-if diagnostic
Don't suggest wrapping in block since it's highly likely to be a missing `if` after `else`. Also rework message a bit (open to further suggestions).
cc: https://github.com/rust-lang/rust/pull/97298#discussion_r880933431
r? `@estebank`
|
|
RFC3239: Implement `cfg(target)` - Part 2
This pull-request implements the compact `cfg(target(..))` part of [RFC 3239](https://github.com/rust-lang/rust/issues/96901).
I recommend reviewing this PR on a per commit basics, because of some moving parts.
cc `@GuillaumeGomez`
r? `@petrochenkov`
|
|
Modify MIR building to drop repeat expressions with length zero
Closes #74836 .
Previously, when a user wrote `[foo; 0]` we used to simply leak `foo`. The goal is to fix that. This PR changes MIR building to make `[foo; 0]` equivalent to `{ drop(foo); [] }` in all cases. Of course, this is a breaking change (see below). A crater run did not indicate any regressions though, and given that the previous behavior was almost definitely not what any user wanted, it seems unlikely that anyone was relying on this.
Note that const generics are in general unaffected by this. Inserting the extra `drop` is only meaningful/necessary when `foo` is of a non-`Copy` type, and array repeat expressions with const generic repetition count must always be `Copy`.
Besides the obvious change to behavior associated with the additional drop, there are three categories of examples where this also changes observable behavior. In all of these cases, the new behavior is consistent with what you would get by replacing `[foo; 0]` with `{ drop(foo); [] }`. As such, none of these give the user new powers to express more things.
**No longer allowed in const (breaking)**:
```rust
const _: [String; 0] = [String::new(); 0];
```
This compiles on stable today. Because we now introduce the drop of `String`, this no longer compiles as `String` may not be dropped in a const context.
**Reduced dataflow (non-breaking)**:
```rust
let mut x: i32 = 0;
let r = &x;
let a = [r; 0];
x = 5;
let _b = a;
```
Borrowck rejects this code on stable because it believes there is dataflow between `a` and `r`, and so the lifetime of `r` has to extend to the last statement. This change removes the dataflow and the above code is allowed to compile.
**More const promotion (non-breaking)**:
```rust
let _v: &'static [String; 0] = &[String::new(); 0];
```
This does not compile today because `String` having drop glue keeps it from being const promoted (despite that drop glue never being executed). After this change, this is allowed to compile.
### Alternatives
A previous attempt at this tried to reduce breakage by various tricks. This is still a possibility, but given that crater showed no regressions it seems unclear why we would want to introduce this complexity.
Disallowing `[foo; 0]` completely is also an option, but obviously this is more of a breaking change. I do not know how often this is actually used though.
r? `@oli-obk`
|
|
Introduce stricter checks for might_permit_raw_init under a debug flag
This is intended to be a version of the strict checks tried out in #79296, but also checking number validity (under the assumption that `let _ = std::mem::uninitialized::<u32>()` is UB, which seems to be what https://github.com/rust-lang/unsafe-code-guidelines/issues/71 is leaning towards.)
|
|
Add tests for lint on type dependent on consts
r? `@lcnr`
|
|
Make llvm-libunwind a per-target option
Fuchsia doesn't ship libunwind in its SDK, so we must provide it statically.
|
|
rustdoc: fix few clippy lints
Fix few clippy lints: second commit - perf ones, first - other ones.
|
|
|
|
|
|
Update minifier-rs version to 0.1.0
It fixes a bug with regex parsing.
r? `@notriddle`
|
|
Remove unused brush image
r? `@notriddle`
|
|
Make weird name lints trigger behind cfg_attr
The weird name lints (`unknown_lints`, `renamed_and_removed_lints`), the lints that lint the linting, were previously not firing for lint level declarations behind `cfg_attr`, as they were only running before expansion.
Now, this will give a `unknown_lints` warning:
```Rust
#[cfg_attr(all(), allow(this_lint_does_not_exist))]
fn foo() {}
```
Lint level declarations behind a `cfg_attr` whose condition is not applying are still ignored. So this still won't give a warning:
```Rust
#[cfg_attr(any(), allow(this_lint_does_not_exist))]
fn foo() {}
```
Furthermore, this PR also makes the weird name lints respect level delcarations for *them* that were hidden by `cfg_attr`, making them consistent to other lints. So this will now not issue a warning:
```Rust
#[cfg_attr(all(), allow(unknown_lints))]
mod foo {
#[allow(does_not_exist)]
fn foo() {
}
}
```
Fixes #97094
|
|
|
|
update Miri
Fixes https://github.com/rust-lang/rust/issues/97348
r? `@ghost` Cc `@rust-lang/miri`
|
|
|
|
|
|
|
|
Previously, we were emitting weird name lints (for renamed or unknown lints)
before expansion, most importantly before cfg expansion.
This meant that the weird name lints would not fire
for lint attributes hidden inside cfg_attr. The same applied
for lint level specifications of those lints.
By moving the lints for the lint names to the post-expansion
phase, these issues are resolved.
|
|
|
|
Parse expression after `else` as a condition if followed by `{`
Fixes #49361.
Two things:
1. This wording needs help. I can never find a natural/intuitive phrasing when I write diagnostics :sweat_smile:
2. Do we even want to show the "wrap in braces" case? I would assume most of the time the "add an `if`" case is the right one.
|
|
Lifetime variance fixes for rustdoc
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be unified by shortening both to some common lifetime.
This is doable, since everything is already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the rustdoc team can review independently.
|
|
|
|
|
|
|
|
|
|
Refactor call terminator to always include destination place
In #71117 people seemed to agree that call terminators should always have a destination place, even if the call was guaranteed to diverge. This implements that. Unsurprisingly, the diff touches a lot of code, but thankfully I had to do almost nothing interesting. The only interesting thing came up in const prop, where the stack frame having no return place was also used to indicate that the layout could not be computed (or similar). I replaced this with a ZST allocation, which should continue to do the right things.
cc `@RalfJung` `@eddyb` who were involved in the original conversation
r? rust-lang/mir-opt
|
|
Rollup of 5 pull requests
Successful merges:
- #97240 (Typo suggestion for a variable with a name similar to struct fields)
- #97289 (Lifetime variance fixes for clippy)
- #97290 (Turn on `fast_submodules` unconditionally)
- #97336 (typo)
- #97337 (Fix stabilization version of `Ipv6Addr::to_ipv4_mapped`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
Turn on `fast_submodules` unconditionally
I don't know why anyone would turn this off; doing so makes builds much slower (nearly a 60x slowdown according to #49057).
Remove the option to do so, which makes bootstrap a little easier to maintain.
Bootstrap continues to allow you to manage submodules manually by setting `submodules = false`.
|
|
Lifetime variance fixes for clippy
#97287 migrates rustc to a `Ty` type that is invariant over its lifetime `'tcx`, so I need to fix a bunch of places that assume that `Ty<'a>` and `Ty<'b>` can be shortened to some common lifetime.
This is doable, since everything is already `'tcx`, so all this PR does is be a bit more explicit that elided lifetimes are actually `'tcx`.
Split out from #97287 so the clippy team can review independently.
|
|
r=compiler-errors
Typo suggestion for a variable with a name similar to struct fields
closes #97133
|
|
I don't know why anyone would turn this off; doing so makes builds much slower (nearly a 60x slowdown according to #49057).
Remove the option to do so, which makes bootstrap a little easier to maintain.
Bootstrap continues to allow you to manage submodules manually by setting `submodules = false`.
|
|
Disallow compare-mode=nll test differences
This ensures that new tests don't get added not as revisions if they have nll output. This will make stabilization PR easier.
r? `@Mark-Simulacrum`
|
|
|
|
Update `rustc` PGO benchmark list
I noticed that the `rustc` PGO crates do not contain any crate that would stress the trait system. I tried adding and removing various crates to the PGO benchmark list here. Here's what I found:
- Removing [`externs` and `match-stress`](https://perf.rust-lang.org/compare.html?start=c0672870491e84362f76ddecd50fa229f9b06dff&end=b056963e0324fa76c721d79f12658a64cfa4cb5e&stat=instructions:u) regresses these two benchmarks by up to 15 % and removing them doesn't improve anything else, so we should keep them.
- Adding [`keccak`](https://perf.rust-lang.org/compare.html?start=52cc7795245347500ddf6dc959cf58a7abe2d935&end=6fd27b23fd7860c79752479173b4a1b877cba490) regresses `diesel`, otherwise it doesn't do much.
- Adding [`tt-muncher`](https://perf.rust-lang.org/compare.html?start=c0672870491e84362f76ddecd50fa229f9b06dff&end=2ab5994d9cdfb098344895f7d8d5aee3cf3d6eff&stat=instructions:u) improves it very slightly, not worth it to include it IMO.
- Adding just [`diesel`](https://perf.rust-lang.org/compare.html?start=00755e4ca68f12ed200e921276788ab19975e85f&end=cd37706ad459ee8ddfda4631be71120cb7eda19d) improves it by up to 1.5 % and others crate slightly, but regresses `bitmaps`.
- Adding [`bitmaps`](https://perf.rust-lang.org/compare.html?start=67a9bcb31b85e87cc8bb327022632e48a0ca64a8&end=0cd80ba74425e6614cd52c4ea2bf6b0191c6dbc4&stat=instructions:u) improves both it and diesel, no other regressions.
- Adding [both](https://perf.rust-lang.org/compare.html?start=77972d2d0134fb597249b3b64dcf9510a790c34e&end=f968d7af511d750db96cfdc04f844fb017c079ce) `bitmaps` and `diesel` produces quite nice improvements and almost no regressions.
- Adding [ucd](https://perf.rust-lang.org/compare.html?start=b5caa5a8421f84cb7664f999b7635801bcf3f96a&end=327cc09917311f65cf427e6c0bf5f7424af9fd05&stat=instructions:u) did not have a large effect on primary benchmarks.
r? `@lqd`
|
|
rustdoc: Remove fields_stripped fields (and equivalents)
Fixes #90588.
r? `@camelid`
|
|
|
|
|
|
|
|
Add some regression tests for #90400
This adds two regression tests taken from https://github.com/rust-lang/rust/issues/90400#issuecomment-954927836.
Note that we cannot close the issue right now as the [original code](https://github.com/rust-lang/rust/issues/90400#issue-1039577786) still triggers an ICE.
r? `@compiler-errors`
|
|
Add new eslint rule to prevent whitespace before function call paren
It prevents `foo ()` basically. :)
r? `@notriddle`
|
