| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Part of #87059
Partially reverts #84703
Heavily modified for beta backport needs.
|
|
|
|
|
|
|
|
pnkfelix:beta-targetted-revert-81473-warn-write-only-fields, r=Mark-Simulacrum
Beta targetted revert 81473 warn write only fields
beta backport of PR #86212
|
|
|
|
|
|
Revert "Add missing brace"
This reverts commit 85ad773049536d7fed9a94ae0ac74f97135c8655.
Revert "Simplify base_expr"
This reverts commit 899aae465eb4ef295dc1eeb2603f744568e0768c.
Revert "Warn write-only fields"
This reverts commit d3c69a4c0dd98af2611b7553d1a65afef6a6ccb0.
|
|
(cherry picked from commit 5f0c54db4e595a6a77048f2b0605138ffa49a326)
|
|
(cherry picked from commit 8ce761d75ed5132c90bfe28e983d83007b8ce7c3)
|
|
This will let us produce a beta and investigate a proper fix on a longer
timescale.
|
|
|
|
(update: placated tidy)
(update: rebased post PR #84707 )
merge me
|
|
This reverts commit 448d07683a6defd567996114793a09c9a8aef5df.
|
|
Run full const-generics test for issue-72293
Closes #72293
r? ```@oli-obk```
|
|
Detect incorrect vtable alignment during const eval
This PR fixes #86132 by detecting invalid alignment values for trait objects in the interpreter, and emitting an error about this conversion failure, to avoid the ICE.
I've noticed that the error emitted at https://github.com/rust-lang/rust/blob/a50d72158e08e02cfc051b863017bdbd2c45b637/compiler/rustc_mir/src/interpret/traits.rs#L163-L166 doesn't seem to be present in the const-ub tests, so I've tried adding a test that triggers both of these cases: one for the invalid size, and another for the invalid alignment that #86132 tracks (I have found different magic values triggering different `Align::from_bytes` errors than the "power of 2" one, if need be).
However, when doing that, I *cannot* for the life of me figure out the correct incantation to make these 2 errors trigger with the "it is undefined behavior to use this value" message rather than the "any use of this value will cause an error" lint.
I've tried Oli's suggestions of different values, tuples and arrays, using the transparent wrapper trick from the other tests and I was only able to trigger the regular const-ub errors about the size of the vtable, or that the drop pointer was invalid. Maybe these "type validation failed" errors happen before this part of the interpreter is reached and there just needs some magic incorrect values to bypass them, I don't know.
Since this fixes an ICE, and if the constants are indeed used, these 2 tests will turn into a hard error, I thought I'd open the PR anyways. And if ```@RalfJung``` you know of a way I could manage that (if you think that these tests are worth checking that the `throw_ub_format!` does indeed create const-ub errors as we expect) I'd be grateful.
For that reason, r? ```@RalfJung``` and cc ```@oli-obk.```
|
|
Print dummy spans as `no-location`
Fixes #58808.
|
|
Do not suggest ampmut if rhs is already mutable
Removes invalid suggestion in #85765, although it should highlight the user type instead of the local variable.
Looking at the comments of this line:
https://github.com/rust-lang/rust/blob/84b1005bfd22e2cb2a4c13b0b81958fe72628354/compiler/rustc_mir_build/src/build/matches/mod.rs#L2107
It was intentionally set to `None`, causing it to highlight the local variable instead. I am not sure if I will be able to fix it.
Fixes #85765
|
|
Fix some diagnostic issues with const_generics_defaults feature gate
This PR makes a few changes:
- print out const param defaults in "lifetime ordering" errors rather than discarding them
- update `is_simple_text` to account for const params when checking if a type has no generics, this was causing a note to be failed to add to an error message
- fixes some diagnostic wording that incorrectly said there was ordering restrictions between type/const params despite the `const_generics_defaults` feature gate is active
|
|
Suggest a trailing comma if a 1-tuple is expected and a parenthesized expression is found
This pull request fixes #86100. The following code:
```rust
fn main() {
let t: (i32,) = (1);
}
```
currently produces:
```
warning: unnecessary parentheses around assigned value
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ^^^ help: remove these parentheses
|
= note: `#[warn(unused_parens)]` on by default
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
error: aborting due to previous error; 1 warning emitted
```
With my changes, I get the same warning and the following error:
```
error[E0308]: mismatched types
--> test.rs:2:21
|
2 | let t: (i32,) = (1);
| ------ ^^^ expected tuple, found integer
| |
| expected due to this
|
= note: expected tuple `(i32,)`
found type `{integer}`
help: use a trailing comma to create a tuple with one element
|
2 | let t: (i32,) = (1,);
| ^^^^
```
i.e. I have added a suggestion to add a trailing comma to create a 1-tuple. This suggestion is only issued if a 1-tuple is expected and the expression (`(1)` in the example above) is surrounded by parentheses and does not already have a tuple type. In this situation, I'd say that it is pretty likely that the user meant to create a tuple.
|
|
Disallow non-monomorphic calls to `needs_drop` in interpreter
otherwise evaluation could change after further substitutions.
|
|
std: Stabilize wasm simd intrinsics
This commit performs two changes to stabilize Rust support for
WebAssembly simd intrinsics:
* The stdarch submodule is updated to pull in rust-lang/stdarch#1179.
* The `wasm_target_feature` feature gate requirement for the `simd128`
feature has been removed, stabilizing the name `simd128`.
This should conclude the FCP started on #74372 and...
Closes #74372
|
|
This commit performs two changes to stabilize Rust support for
WebAssembly simd intrinsics:
* The stdarch submodule is updated to pull in rust-lang/stdarch#1179.
* The `wasm_target_feature` feature gate requirement for the `simd128`
feature has been removed, stabilizing the name `simd128`.
This should conclude the FCP started on #74372 and...
Closes #74372
|
|
MVP for using rust-lld as part of cc
Will fix #71519. I need to figure out how to write a test showing that lld is used instead of whatever linker cc normally uses. When I manually run rustc using `echo 'fn main() {}' | RUSTC_LOG=rustc_codegen_ssa::back::link=debug ./rustc -Clinker-flavor=gcc-lld --crate-type bin -Clink-arg=-Wl,-v` (thanks to bjorn3 on Zulip), I can see that lld is used, but I'm not sure how to inspect that output in a test.
|
|
|
|
Allow qualified paths in struct construction (both expressions and patterns)
Fixes #79658
|
|
Add the x86_64-gnu-stable builder
During the 1.52 release process we had to deal with some commits that passed the test suite on the nightly branch but failed on the beta or stable branch. In that case it was due to some UI tests including the channel name in the output, but other changes might also be dependent on the channel.
This commit adds a new CI job that runs the Linux x86_64 test suite with the stable branch, ensuring nightly changes also work as stable. To ensure the new job works the following other changes are present:
* The `ui-fulldeps/session-derive-errors.rs` test has been disabled on beta and stable, which required adding support for `// ignore-{channel}` and `// only-{channel}`.
* The `rustdoc/intra-doc/field.rs` has been fixed.
r? `@Mark-Simulacrum`
fixes https://github.com/rust-lang/release-team/issues/11
|
|
Don't pass -Z unstable-options by default for UI tests
Unconditionally passing -Z unstable-options makes it impossible to test whether an option requires unstable-options or not.
This uncovered quite a lot of bugs, I'll open issues for each. These don't strictly need to be fixed before this is merged, it just makes the diff much larger because of the changes to diagnostics.
- https://github.com/rust-lang/rust/issues/82636
- https://github.com/rust-lang/rust/issues/82637
- https://github.com/rust-lang/rust/issues/82638
|
|
position.
|
|
ignore test if rust-lld not found
create ld -> rust-lld symlink at build time instead of run time
for testing in ci
copy instead of symlinking
remove linux check
test for linker, suggestions from bjorn3
fix overly restrictive lld matcher
use -Zgcc-ld flag instead of -Clinker-flavor
refactor code adding lld to gcc path
revert ci changes
suggestions from petrochenkov
rename gcc_ld to gcc-ld in dirs
|
|
also add tests for these 2 kinds of errors for size and alignment,
as the existing size check wasn't apparently tested
|
|
Make copy/copy_nonoverlapping fn's again
Make copy/copy_nonoverlapping fn's again, rather than intrinsics.
This a short-term change to address issue #84297.
It effectively reverts PRs #81167 #81238 (and part of #82967), #83091, and parts of #79684.
|
|
Create different inference variables for different defining uses of TAITs
Fixes #73481
r? `@nikomatsakis`
cc `@oli-obk`
|
|
Peephole optimize `x == false` and `x != true`
This adds peephole optimizations to make `x == false`, `false == x`, `x != true`, and `true != x` get optimized to `!x` in the `instcombine` MIR pass. That pass currently handles `x == true` -> `x` already.
|
|
Include macro name in 'local ambiguity' error
Currently, we only point at the span of the macro argument. When the
macro call is itself generated by another macro, this can make it
difficult or impossible to determine which macro is responsible for
producing the error.
|
|
Enable rustdoc to document safe wasm intrinsics
This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
|
|
Display defaults on const params- rustdoc
previously rustdoc would render this struct declaration:
`pub struct Foo<const N: usize = 10>;`
as:
`pub struct Foo<const N: usize>;`
this PR changes it to render correctly
|
|
|
|
Comment out unused error codes and add description for E0316
I have added an extended description of `E0316` and commented out a bunch of unused error codes to make clear the fact that they are no longer in use. You can check for yourself with
```shell
for ec in \
E0314 E0315 E0473 E0474 E0475 E0479 E0480 E0481 \
E0483 E0484 E0485 E0486 E0487 E0488 E0489
do
if [ ! -z "`grep -r $ec compiler/* --exclude-dir=rustc_error_codes`" ]
then
echo $ec
false
fi
done
```
i.e. these error codes appear nowhere in the compiler code and thus cannot be emitted.
r? ```@GuillaumeGomez```
|
|
Search description codeblock
The codeblocks are not displayed correctly:
This PR interprets the HTML correctly (and still prevent invalid HTML because of how it inserts it):
r? ```@jsha```
|
|
Type page font weight
Fixes https://github.com/rust-lang/rust/issues/86069.
r? ```@jsha```
|
|
Default panic message should print Box<dyn Any>
Closes #86039
Prior to this patch, the panic message from running the following code would be `thread 'main' panicked at 'Box<Any>'...`
```rust
use std::panic::panic_any;
fn main() {
panic_any(42);
}
```
This patch updates the phrasing to be more consistent. It now instead shows the following panic message:
```
thread 'main' panicked at 'Box<dyn Any>', ...
```
It's a very small fix 😄
|
|
Currently, we only point at the span of the macro argument. When the
macro call is itself generated by another macro, this can make it
difficult or impossible to determine which macro is responsible for
producing the error.
|
|
This commit fixes an issue not found during #84988 where rustdoc is used
to document cross-platform intrinsics but it was requiring that
functions which use `#[target_feature]` are `unsafe` erroneously, even
if they're WebAssembly specific. Rustdoc today, for example, already has
a special case where it enables annotations like
`#[target_feature(enable = "simd128")]` on platforms other than
WebAssembly. The purpose of this commit is to relax the "require all
`#[target_feature]` functions are `unsafe`" requirement for all targets
whenever rustdoc is running, enabling all targets to fully document
other targets, such as WebAssembly, where intrinsics functions aren't
always `unsafe`.
|
|
|
|
generic parameters
|
|
|
|
|
|
|
