| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Rollup of 4 pull requests
Successful merges:
- #90529 (Skip reborrows in AbstractConstBuilder)
- #91437 (Pretty print empty blocks as {})
- #91450 (Don't suggest types whose inner type is erroneous)
- #91535 (Stabilize `-Z emit-future-incompat` as `--json future-incompat`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Stabilize `-Z emit-future-incompat` as `--json future-incompat`
The FCP was completed in https://github.com/rust-lang/rust/issues/71249
|
|
Don't suggest types whose inner type is erroneous
Currently, we check if the returned type equals to `tcx.ty_error()` not to emit
erroneous types, but this has a pitfall; for example,
`Option<[type error]> != tcx.ty_error()` holds.
Fixes #91371.
|
|
Pretty print empty blocks as {}
**Example:**
```rust
macro_rules! p {
($e:expr) => {
println!("{}", stringify!($e));
};
($i:item) => {
println!("{}", stringify!($i));
};
}
fn main() {
p!(if true {});
p!(struct S {});
}
```
**Before:**
```console
if true { }
struct S {
}
```
**After:**
```console
if true {}
struct S {}
```
This affects [`dbg!`](https://doc.rust-lang.org/std/macro.dbg.html), as well as ecosystem uses of stringify such as in [`anyhow::ensure!`](https://docs.rs/anyhow/1/anyhow/macro.ensure.html). Printing a `{ }` in today's heavily rustfmt'd world comes out looking jarring/sloppy.
|
|
Skip reborrows in AbstractConstBuilder
Fixes https://github.com/rust-lang/rust/issues/90455
Temporary fix to prevent confusing diagnostics that refer to implicit borrows and derefs until we allow borrows and derefs on constant expressions.
r? `@oli-obk`
|
|
Deprecate array::IntoIter::new.
|
|
|
|
|
|
rustdoc: Cleanup two things in `clean::types`
Explanations are in the individual commits.
|
|
Include `lld` in `rust-dev` package
Fixes #88941
This will allow using `download-ci-llvm` while still having LLD
available.
|
|
Add a MIR pass manager (Taylor's Version)
The final draft of #91386 and #77665.
While the compile-time constraints in #91386 are cool, I decided on a more minimal approach for now. I want to explore phase constraints and maybe relative-ordering constraints in the future, though. This should preserve existing behavior **exactly** (please let me know if it doesn't) while making the following changes to the way we organize things today:
- Each `MirPhase` now corresponds to a single MIR pass. `run_passes` is not responsible for listing the correct MIR phase.
- `run_passes` no longer silently skips passes if the declared MIR phase is greater than or equal to the body's. This has bitten me multiple times. If you want this behavior, you can always branch on `body.phase` yourself.
- If your pass is solely to emit errors, you can use the `MirLint` interface instead, which gets a shared reference to `Body` instead of a mutable one. By differentiating the two, I hope to make it clearer in the short term where lints belong in the pipeline. In the long term perhaps we could enforce this at compile-time?
- MIR is no longer dumped for passes that aren't enabled, or for lints.
I tried to check that `-Zvalidate` still works correctly, since the MIR phase is now updated as soon as the associated pass is done, instead of at the end of all the passes in `run_passes`. However, it looks like `-Zvalidate` is broken with current nightlies anyways :cry: (it spits out a bunch of errors).
cc `@oli-obk` `@wesleywiser`
r? rust-lang/wg-mir-opt
|
|
LLVM support .insn directive
Closes #90558. See also https://github.com/rust-lang/llvm-project/pull/121.
|
|
std: Stabilize the `thread_local_const_init` feature
This commit is intended to follow the stabilization disposition of the
FCP that has now finished in #84223. This stabilizes the ability to flag
thread local initializers as `const` expressions which enables the macro
to generate more efficient code for accessing it, notably removing
runtime checks for initialization.
More information can also be found in #84223 as well as the tests where
the feature usage was removed in this PR.
Closes #84223
|
|
Postpone the evaluation of constant expressions that depend on inference variables
Previously `delay_span_bug` calls were triggered once an inference variable was included in the substs of a constant that was to be evaluated. Some of these would merely have resulted in trait candidates being rejected, hence no real error was ever encountered, but the triggering of the `delay_span_bug` then caused an ICE in later stages of the compiler due to no error ever occurring.
We now postpone the evaluation of these constants, so any trait obligation fulfillment will simply stall on this constant and the existing type inference machinery of the compiler handles any type errors if present.
Fixes https://github.com/rust-lang/rust/issues/89320
Fixes https://github.com/rust-lang/rust/issues/89146
Fixes https://github.com/rust-lang/rust/issues/87964
Fixes https://github.com/rust-lang/rust/issues/87470
Fixes https://github.com/rust-lang/rust/issues/83288
Fixes https://github.com/rust-lang/rust/issues/83249
Fixes https://github.com/rust-lang/rust/issues/90654
I want to thank `@BoxyUwU` for cooperating on this and for providing some help.
r? `@lcnr` maybe?
|
|
Explain why `Self` is invalid in generic parameters
Close #89985.
r? `@estebank`
|
|
Fixes #88941
This will allow using `download-ci-llvm` while still having LLD
available.
|
|
|
|
|
|
|
|
Currently, we check if the returned type equals to `tcx.ty_error()` not to emit
erroneous types, but this has a pitfall; for example,
`Option<[type error]> != tcx.ty_error()` holds.
|
|
Keep spans for generics in `#[derive(_)]` desugaring
Keep the spans for generics coming from a `derive`d Item, so that errors
and suggestions have better detail.
Fix #84003.
|
|
Updated error message for accidental uses of derive attribute as a crate attribute
This partially fixes the original issue #89566 by adding derive to the list of invalid crate attributes and then providing an updated error message however I'm not sure how to prevent the resolution error message from emitting without causing the compiler to just abort when it finds an invalid crate attribute (which I'd prefer not to do so we can find and emit other errors).
`@petrochenkov` I have been told you may have some insight on why it's emitting the resolution error though honestly I'm not sure if we need to worry about fixing it as long as we can provide the invalid crate attribute error also (which happens first anyway)
|
|
Unwinding support for inline assembly
r? `@Amanieu`
|
|
Rationale:
* The name was confusing.
* It was only used in one place.
* That place didn't actually need all the functionality of `get_type`;
rather, removing `get_type` makes that code clearer.
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #90538 (Document how recursion is handled for `ty::Ty`)
- #90851 (Add unchecked downcast methods)
- #91209 (Implement ``@snapshot`` check for htmldocck)
- #91385 (Suggest the `pat_param` specifier before `|` on 2021 edition )
- #91478 (Remove incorrect newline from float cast suggestion)
- #91481 (Use let_else in some more places in rustc_lint)
- #91488 (Fix ICE when `yield`ing in function returning `impl Trait`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Fix ICE when `yield`ing in function returning `impl Trait`
Change an assert to a `delay_span_bug` and remove an unwrap, that should fix it.
Fixes #91477
|
|
Remove incorrect newline from float cast suggestion
|
|
Suggest the `pat_param` specifier before `|` on 2021 edition
Ran into this today after writing some Rust for the first time in a while.
r? `@estebank`
|
|
Implement `@snapshot` check for htmldocck
This form of check allows performing snapshot tests (à la `src/test/ui`)
on rustdoc HTML output, making it easier to create and update tests.
See [this Zulip thread][1] for more information about the motivation for
this change.
[1]: https://zulip-archive.rust-lang.org/stream/266220-rustdoc/topic/HTML.20snapshot.20tests.html#262651142
r? `@GuillaumeGomez`
|
|
rustdoc: Remove Clean impls for tuples
This PR removes all nine Clean impls on tuples, converting them to
functions instead.
The fact that these are impls causes several problems:
1. They are nameless, so it's unclear what they do.
2. It's hard to find where they're used apart from removing them and
seeing what errors occur (this applies to all Clean impls, not just
the tuple ones).
3. Rustc doesn't currently warn when impls are unused, so dead code
can accumulate easily (all Clean impls).
4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
to refer to their "arguments", which makes reading the code more
difficult.
As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.
Converting the impls to functions solves all four of these problems.
r? `@GuillaumeGomez`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This was the last one!
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This commit removes the first of nine Clean impls on tuples, converting
it to a function instead.
The fact that these are impls causes several problems:
1. They are nameless, so it's unclear what they do.
2. It's hard to find where they're used apart from removing them and
seeing what errors occur (this applies to all Clean impls, not just
the tuple ones).
3. Rustc doesn't currently warn when impls are unused, so dead code
can accumulate easily (all Clean impls).
4. Their bodies often use tuple field indexing syntax (e.g., `self.1`)
to refer to their "arguments", which makes reading the code more
difficult.
As I noted, some of these problems apply to all Clean impls, but even
those problems are exacerbated by the tuple impls since they make
general understanding of the code harder.
Converting the impls to functions solves all four of these problems.
|
