| Age | Commit message (Collapse) | Author | Lines |
|---|
|
include 1.80.1 release notes on master
Forgot this during the release process.
|
|
r=compiler-errors
rustc_driver_impl: remove some old dead logic
This got added in https://github.com/rust-lang/rust/commit/5013952e4a1b15198c3569fdcb9890af70f06ab9, before `cfg(target_feature)` was stable. It should not be needed any more ever since `cfg(target_feature)` is stable.
|
|
Move `SanityCheck` and `MirPass`
They are currently in `rustc_middle`. This PR moves them to `rustc_mir_transform`, which makes more sense.
r? ``@cjgillot``
|
|
do not attempt to prove unknowable goals
In case a goal is unknowable, we previously still checked all other possible ways to prove this goal, even though its final result is already guaranteed to be ambiguous. By ignoring all other candidates in that case we can avoid a lot of unnecessary work, fixing the performance regression in typenum found in #121848.
This is already the behavior in the old solver. This could in theory cause future-compatability issues as considering fewer goals unknowable may end up causing performance regressions/hangs. I am quite confident that this will not be an issue.
r? ``@compiler-errors``
|
|
update comment regarding TargetOptions.features
The claim that `-Ctarget-features` cannot disable these features set in the target spec is definitely wrong -- I tried it for `x86_64-pc-windows-gnu`, which enables SSE3 that way. Building with `-Ctarget-feature=-sse3` works fine, and `cfg!(target_feature = "sse3")` is `false` in that build.
There are also some indications that these are actually intended to be overwritten:
https://github.com/rust-lang/rust/blob/3b14526cead4105f82c398d8d4c7954efa3bab6b/compiler/rustc_target/src/spec/targets/i686_unknown_uefi.rs#L22-L23
https://github.com/rust-lang/rust/blob/84ac80f1921afc243d71fd0caaa4f2838c294102/compiler/rustc_target/src/spec/targets/x86_64h_apple_darwin.rs#L18-L23
So... let's update the comment to match reality, I guess?
The claim that they overwrite `-Ctarget-cpu` is based on
- for `native`, the comment in the apple target spec quoted above
- for other CPU strings, the assumption that `LLVMRustCreateTargetMachine` will apply these features after doing whatever the base CPU model does. I am not sure how to check that, I hope some LLVM backend people can chime in. :)
|
|
r=workingjubilee
Document the broken C ABI of `wasm32-unknown-unknown`
Inspired by discussion on
https://github.com/rust-lang/rust/issues/129486 this is intended to at least document the current state of the world in a more public location than throughout a series of issues.
|
|
Non-exhaustive structs may be empty
This is a follow-up to a discrepancy noticed in https://github.com/rust-lang/rust/pull/122792: today, the following struct is considered inhabited (non-empty) outside its defining crate:
```rust
#[non_exhaustive]
pub struct UninhabitedStruct {
pub never: !,
// other fields
}
```
`#[non_exhaustive]` on a struct should mean that adding fields to it isn't a breaking change. There is no way that adding fields to this struct could make it non-empty since the `never` field must stay and is inconstructible. I suspect this was implemented this way due to confusion with `#[non_exhaustive]` enums, which indeed should be considered non-empty outside their defining crate.
I propose that we consider such a struct uninhabited (empty), just like it would be without the `#[non_exhaustive]` annotation.
Code that doesn't pass today and will pass after this:
```rust
// In a different crate
fn empty_match_on_empty_struct<T>(x: UninhabitedStruct) -> T {
match x {}
}
```
This is not a breaking change.
r? ``@compiler-errors``
|
|
Don't Suggest Labeling `const` and `unsafe` Blocks
Fixes #128604
Previously, both anonymous constant blocks (E.g. The labeled block
inside `['_'; 'block: { break 'block 1 + 2; }]`) and inline const
blocks (E.g. `const { ... }`) were considered to be the same
kind of blocks. This caused the compiler to incorrectly suggest
labeling both the blocks when only anonymous constant blocks can be
labeled.
This PR adds an other enum variant to `Context` so that both the
blocks can be handled appropriately.
Also, adds some doc comments and removes unnecessary `&mut` in a
couple of places.
|
|
Suggest `impl Trait` for References to Bare Trait in Function Header
Fixes #125139
This PR suggests `impl Trait` when `&Trait` is found as a function parameter type or return type. This makes use of existing diagnostics by adding `peel_refs()` when checking for type equality.
Additionaly, it makes a few other improvements:
1. Checks if functions inside impl blocks have bare trait in their headers.
2. Introduces a trait `NextLifetimeParamName` similar to the existing `NextTypeParamName` for suggesting a lifetime name. Also, abstracts out the common logic between the two trait impls.
### Related Issues
I ran into a bunch of related diagnostic issues but couldn't fix them within the scope of this PR. So, I have created the following issues:
1. [Misleading Suggestion when Returning a Reference to a Bare Trait from a Function](https://github.com/rust-lang/rust/issues/127689)
2. [Verbose Error When a Function Takes a Bare Trait as Parameter](https://github.com/rust-lang/rust/issues/127690)
3. [Incorrect Suggestion when Returning a Bare Trait from a Function](https://github.com/rust-lang/rust/issues/127691)
r? ```@estebank``` since you implemented #119148
|
|
|
|
Forgot this during the release process
|
|
|
|
|
|
|
|
|
|
They're now all just used within this crate.
|
|
Because that's now the only crate that uses it.
Moving stuff out of `rustc_middle` is always welcome.
I chose to use `impl crate::MirPass`/`impl crate::MirLint` (with
explicit `crate::`) everywhere because that's the only mention of
`MirPass`/`MirLint` used in all of these files. (Prior to this change,
`MirPass` was mostly imported via `use rustc_middle::mir::*` items.)
|
|
Rollup of 8 pull requests
Successful merges:
- #129152 (custom/external clippy support for bootstrapping)
- #129311 (don't copy `.rustc-dev-contents` from CI rustc)
- #129800 (Move the Windows remove_dir_all impl into a module and make it more race resistant)
- #129860 (update `object` dependency to remove duplicate `wasmparser`)
- #129885 (chore: remove repetitive words)
- #129913 (Add missing read_buf stub for x86_64-unknown-l4re-uclibc)
- #129916 (process.rs: remove "Basic usage" text where not useful)
- #129917 (Fix parsing of beta version in dry-run mode)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
The actual implementation remains in `rustc_mir_dataflow`, but this
commit moves the `MirPass` impl to `rustc_mir_transform` and changes it
to a `MirLint` (fixing a `FIXME` comment).
(I originally tried moving the full implementation from
`rustc_mir_dataflow` but I had some trait problems with `HasMoveData`
and `RustcPeekAt` and `MaybeLiveLocals`. This commit was much smaller
and simpler, but still will allow some follow-up cleanups.)
|
|
Fix parsing of beta version in dry-run mode
This was blocking beta release.
r? `@BoxyUwU`
|
|
process.rs: remove "Basic usage" text where not useful
Is not useful because just a single example is given.
|
|
Add missing read_buf stub for x86_64-unknown-l4re-uclibc
Before this PR, `x check library/std --target x86_64-unknown-l4re-uclibc` will fail with
```
error[E0599]: no method named `read_buf` found for struct `Socket` in the current scope
--> std/src/os/unix/net/stream.rs:598:16
|
598 | self.0.read_buf(buf)
| ^^^^^^^^
|
::: std/src/sys/pal/unix/l4re.rs:23:5
|
23 | pub struct Socket(FileDesc);
| ----------------- method `read_buf` not found for this struct
|
= help: items from traits can only be used if the trait is implemented and in scope
```
This target doesn't have a maintainer to cc.
|
|
chore: remove repetitive words
|
|
update `object` dependency to remove duplicate `wasmparser`
``@alexcrichton`` in #129762 you bumped a few wasm-related dependencies and tried to avoid duplicates.
If I understand correctly, `object` 0.36.4 wasn't yet released at the time, and therefore #129762 ended up duplicating `wasmparser`. Now that the release happened, we can remove the duplicate.
r? ``@alexcrichton``
|
|
Move the Windows remove_dir_all impl into a module and make it more race resistant
This attempts to make the Windows implementation of `remove_dir_all` easier to understand and work with by separating out different concerns into their own functions. The code is mostly the same as before just moved around. There are some changes to make it more robust against races (e.g. two calls to `remove_dir_all` running concurrently). The module level comment explains the issue.
try-job: x86_64-msvc
try-job: i686-msvc
|
|
don't copy `.rustc-dev-contents` from CI rustc
Since https://github.com/rust-lang/rust/pull/127188, copying files from `.rustc-dev-contents` regressed https://github.com/rust-lang/rust/issues/108767 again. Since `rustc-src` is already included in the CI rustc sysroot, we don't need to copy these files to have `rustc-src` component.
Blocker for #122709
|
|
custom/external clippy support for bootstrapping
Similar to cargo, rustc, and rustfmt, this adds the support of using custom clippy on bootstrap. It’s designed for those who want to test their own clippy builds or avoid downloading the stage0 clippy.
Closes #121518
|
|
Add `unreachable_pub`, round 4
A follow-up to #129732.
r? `@Urgau`
|
|
Rollup of 12 pull requests
Successful merges:
- #129748 (Box validity: update for new zero-sized rules)
- #129829 (Make decoding non-optional `LazyArray` panic if not set)
- #129856 (compiler_fence documentation: emphasize synchronization, not reordering)
- #129868 (Remove kobzol vacation status)
- #129875 (chore: Fix typos in 'compiler' (batch 1))
- #129877 (chore: Fix typos in 'compiler' (batch 2))
- #129878 (chore: Fix typos in 'compiler' (batch 3))
- #129890 (Remove stray word in a comment)
- #129892 (Clarify language around ptrs in slice::raw)
- #129905 (mailmap: add new email for davidtwco)
- #129906 (mailmapper?)
- #129907 (Fix compile error in solid's remove_dir_all)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Is not useful because just a single example is given.
|
|
Fix compile error in solid's remove_dir_all
Before this PR, `x check library/std --target=aarch64-kmc-solid_asp3` will fail with:
```
error[E0382]: use of partially moved value: `result`
--> std/src/sys/pal/solid/fs.rs:544:20
|
541 | if let Err(err) = result
| --- value partially moved here
...
544 | return result;
| ^^^^^^ value used here after partial move
|
= note: partial move occurs because value has type `io::error::Error`, which does not implement the `Copy` trait
help: borrow this binding in the pattern to avoid moving the value
|
541 | if let Err(ref err) = result
| +++
```
cc `@kawadakk` I think this will clear up https://solid-rs.github.io/toolstate/ :)
|
|
mailmapper?
I think I have done this right? lol
|
|
mailmap: add new email for davidtwco
|
|
Clarify language around ptrs in slice::raw
More specifically we explicitly mention that the pointer should be non-null as a top level requirement. Nullptrs are always valid for zero sized operations, so just validity (and alignment) does not guarantee non-nullness as implied in the existing docs.
We also explicitly call out ZSTs as an additional example where perhaps unintuitively alignment and non-nullness still have to hold.
Finally we change `data` in the range functions to `start`, which seems like a typo to me.
Touches docs for #89792
r? RalfJung
|
|
Remove stray word in a comment
|
|
chore: Fix typos in 'compiler' (batch 3)
Batch 3/3: Fixes typos in `compiler`
(See [issue](https://github.com/rust-lang/rust/issues/129874) tracking all PRs with typos fixes)
|
