Rename `ConstValue::Infer(InferConst::Canonical(..))` to `ConstValue::Bound(..)`
It already has the right form, so this is just a renaming. Fixes https://github.com/rust-lang/rust/issues/65655.
r? @eddyb
make is_power_of_two a const function
This makes `is_power_of_two` a const function by using `&` instead of short-circuiting `&&`; Rust supports bitwise `&` for `bool` and short-circuiting is not required in the existing expression.
I don't think this needs a const-hack label as I don't find the changed code less readable, if anything I prefer that it is clearer that short circuiting is not used.
@oli-obk
Change untagged_unions to not allow union fields with drop
This is a rebase of #56440, massaged to solve merge conflicts and make the test suite pass.
Change untagged_unions to not allow union fields with drop
Union fields may now never have a type with attached destructor. This for example allows unions to use arbitrary field types only by wrapping them in `ManuallyDrop` (or similar).
The stable rule remains, that union fields must be `Copy`. We use the new rule for the `untagged_union` feature.
Tracking issue: https://github.com/rust-lang/rust/issues/55149
Fix `canonicalize_const_var` leaking inference variables
Fixes#61338Fixes#61516Fixes#62536Fixes#64087Fixes#64863Fixes#65623
I added regression tests for all these issues apart from #64863, which is very similar to #61338.
r? @varkor
The `ConstProp` can cause many locals to be initialized to a constant
value and then never read from. `ConstProp` can also evaluate ZSTs into
constant values. Previously, many of these would be removed by other
parts of the MIR optimization pipeline. However, evaluating ZSTs
(especially `()`) into constant values defeated those parts of the
optimizer and so in a2e3ed5c05, I added a
hack to `ConstProp` that skips evaluating ZSTs to avoid that regression.
This commit changes `SimplifyLocals` so that it doesn't consider writes
of const values to a local to be a use of that local. In doing so,
`SimplifyLocals` is able to remove otherwise unused locals left behind
by other optimization passes (`ConstProp` in particular).
Remove `borrowck_graphviz_postflow` from test
Resolves#65071 (again).
Sorry. I've added a commit hook to prevent this from happening in the future.
r? @petrochenkov
rustdoc: forward -Z options to rustc
Currently rustdoc does not forward `-Z` options to rustc when building
test executables. This makes impossible to use rustdoc to run test
samples when crate under test is instrumented with one of sanitizers
`-Zsanitizer=...`, since the final linking step will not include
sanitizer runtime library.
Forward `-Z` options to rustc to solve the issue.
Helps with #43031.
add test for calling non-const fn
The good news is that there is an error. But I expected to see [this error](9578272d68/src/librustc_mir/const_eval.rs (L346)) surface. @oli-obk any idea why that message is not shown anywhere?
r? @oli-obk
Avoid injecting sanitizer runtimes into staticlibs (#64629).
This fixes the remaining issue in `creader.rs` and also fixes the expected test failure. I have explicitly turned the `$(CC)` call into a negative check with the `!` to ensure that this command is really failing (if it is not, then either the runtime is attached to the lib or the lib has not been instrumented and both would be an error).
I've also borrowed `program.rs` and the additional `rustc` invocation from @tmiasko 's PR since he pointed out that using `-fsanitize=address` with `$(CC)` for linking could fail if the sanitizer runtimes on the system are incompatible.
With this toolchain I was able to compile Firefox locally without any linker errors. I am still seeing races with Rust in TSan but I assume that is because I did not build with `-Z build-std`.
Use structured suggestion for restricting bounds
When a trait bound is not met and restricting a type parameter would
make the restriction hold, use a structured suggestion pointing at an
appropriate place (type param in param list or `where` clause).
Account for opaque parameters where instead of suggesting extending
the `where` clause, we suggest appending the new restriction:
`fn foo(impl Trait + UnmetTrait)`. Fix#64565, fix#41817, fix#24354,
cc #26026, cc #37808, cc #24159, fix#37138, fix#24354, cc #20671.
More symbol cleanups
Some minor improvements, mostly aimed at reducing unimportant differences between `Symbol` and `InternedString`. Helps a little with #60869.
r? @petrochenkov
Suppress ICE when validators disagree on `LiveDrop`s in presence of `&mut`
Resolves#65394.
This hack disables the validator mismatch ICE in cases where a `MutBorrow` error has been emitted by both validators, but they don't agree on the number of `LiveDrop` errors.
The new validator is more conservative about whether a value is moved from in the presence of mutable borrows. For example, the new validator will emit a `LiveDrop` error on the following code.
```rust
const _: Vec<i32> = {
let mut x = Vec::new();
let px = &mut x as *mut _;
let y = x;
unsafe { ptr::write(px, Vec::new()); }
y
};
```
This code is not UB AFAIK (it passes MIRI at least). The current validator does not emit a `LiveDrop` error for `x` upon exit from the initializer. `x` is not actually dropped, so I think this is correct? A proper fix for this would require a new `MaybeInitializedLocals` dataflow analysis or maybe a relaxation of the existing `IndirectlyMutableLocals` one.
r? @RalfJung
expand: Simplify expansion of derives
And make it more uniform with other macros.
This is done by merging placeholders for future derives' outputs into the derive container's output fragment early (addressing FIXMEs from https://github.com/rust-lang/rust/pull/63667).
Also, macros with names starting with `_` are no longer reported as unused, in accordance with the usual behavior of `unused` lints.
r? @matthewjasper or @mark-i-m
save-analysis: Nest tables when processing impl block definitions
Similar to #65353 (which this PR should've been a part of), however in this case we didn't previously nest the tables when processing trait paths in impl block declarations.
Closes#65411
Plugins deprecation: don’t suggest simply removing the attribute
Building Servo with a recent Nightly produces:
```rust
warning: use of deprecated attribute `plugin`: compiler plugins are deprecated. See https://github.com/rust-lang/rust/issues/29597
--> components/script/lib.rs:14:1
|
14 | #![plugin(script_plugins)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove this attribute
|
= note: `#[warn(deprecated)]` on by default
```
First, linking to https://github.com/rust-lang/rust/issues/29597 is not ideal since there is pretty much no discussion there of the deprecation and what can be used instead. This PR changes the link to the deprecation PR which does have more discussion.
Second, the “remove this attribute” suggestion is rather unhelpful. Just because a feature is deprecated doesn’t mean that simply removing its use without a replacement is acceptable.
In the case of custom lint, there is no replacement available. Prefixing a message with “help:” when telling users that they’re screwed honestly feels disrespectful.
This PR also changes the message to be more factual.
Currently, `Symbol::Debug` and `Symbol::Display` produce the same
output; neither wraps the symbol in double quotes.
This commit changes `Symbol::Debug` so it wraps the symbol in quotes.
This change brings `Symbol`'s behaviour in line with `String` and
`InternedString`. The change requires a couple of trivial test output
adjustments.
Building Servo with a recent Nightly produces:
```rust
warning: use of deprecated attribute `plugin`: compiler plugins are deprecated. See https://github.com/rust-lang/rust/issues/29597
--> components/script/lib.rs:14:1
|
14 | #![plugin(script_plugins)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ help: remove this attribute
|
= note: `#[warn(deprecated)]` on by default
```
First, linking to https://github.com/rust-lang/rust/issues/29597 is not ideal
since there is pretty much no discussion there of the deprecation
and what can be used instead.
This PR changes the link to the deprecation PR which does have more discussion.
Second, the “remove this attribute” suggestion is rather unhelpful.
Just because a feature is deprecated doesn’t mean that simply removing its use
without a replacement is acceptable.
In the case of custom lint, there is no replacement available.
Prefixing a message with “help:” when telling users that they’re screwed
honestly feels disrespectful.
This PR also changes the message to be more factual.
