Improve UEFI target docs
* Add a section showing exactly how to build a driver instead of an application
* Add links to the crates mentioned in the doc
CC `@dvdhrm`
Move personality implementation out of PAL
The module already follows the new convention described in #117276. This PR also includes a small fix in the tidy pal check, that was just an oversight in #117285.
store the segment name when resolution fails
Fixes#112672
The `find_cfg_stripped` does indeed get executed within `smart_resolve_report_errors`. However, this error is not reported as it is subsequently overridden by `parent_err`. (See: https://github.com/rust-lang/rust/blob/master/compiler/rustc_resolve/src/late.rs#L3760)
This PR changes `last_segment` to `segment`, which stores the name of the failed resolution, and ensures that the result of `find_cfg_stripped` is also included in `parent_err`.
r? ```@Nilstrieb```
Move platform modules into `sys::pal`
This is the initial step of #117276. `sys` just re-exports everything from the current `sys` for now, I'll move the implementations for the individual features one-by-one after this PR merges.
Taint `_` placeholder types in trait impl method signatures
We report an error right below for them, but that kind of broken type can cause subsequent ICEs.
fixes#119867
Allow `~const` on associated type bounds again
This follows from [this Zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/419616-t-compiler.2Fproject-const-traits/topic/projections.20on.20.28~.29const.20Trait.20.26.20.28~.29const.20assoc.20ty.20bounds).
Basically in my opinion, it makes sense to allow `~const` on associated type bounds again since they're quite useful even though we haven't implemented the proposed syntax `<Ty as ~const Trait>::Proj`/`<Ty as const Trait>::Proj` yet; that can happen as a follow-up.
This already allows more code to compile since `T::Assoc` where `T` is a type parameter and where the predicate `<T as ~const Trait>` is in the environment gets elaborated to (pseudo) `<T as ~const Trait>::Assoc`.
```rs
#[const_trait]
trait Trait {
type Assoc: ~const Trait;
fn func() -> i32;
}
const fn function<T: ~const Trait>() -> i32 {
T::Assoc::func()
}
```
`~const` associated type bounds also work together with `const` bounds:
```rs
struct Type<const N: i32>;
fn procedure<T: const Trait>() -> Type<{ T::Assoc::func() }> { // `Trait` comes from above
Type
}
```
NB: This PR also starts allowing `~const` bounds in the generics and the where-clause of trait associated types since it's trivial to support them. However, I don't know if those bounds are actually useful. Maybe we should continue to reject them?
For reference, it wouldn't make any sense to allow `~const Trait` in GACs (generic associated constants, `generic_const_items`) because they'd be absolutely useless (contrary to `const Trait`).
~~[``@]rustbot`` ping project-const-traits~~
r? project-const-traits
Varargs support for system ABI
This PR allows functions with the `system` ABI to be variadic (under the `extended_varargs_abi_support` feature tracked in #100189). On x86 windows, the `system` ABI is equivalent to `C` for variadic functions. On other platforms, `system` is already equivalent to `C`.
Fixes#110505
Overhaul `-Ztreat-err-as-bug`
It's current behaviour is surprising, in a bad way. This also makes the implementation more complex than it needs to be.
r? `@oli-obk`
Add explicit `none()` value variant in check-cfg
This PR adds an explicit none value variant in check-cfg values: `values(none())`.
Currently the only way to define the none variant is with an empty `values()` which means that if someone has a cfg that takes none and strings they need to use two invocations: `--check-cfg=cfg(foo) --check-cfg=cfg(foo, values("bar"))`.
Which would now be `--check-cfg=cfg(foo, values(none(),"bar"))`, this is simpler and easier to understand.
`--check-cfg=cfg(foo)`, `--check-cfg=cfg(foo, values())` and `--check-cfg=cfg(foo, values(none()))` would be equivalent.
*Another motivation for doing this is to make empty `values()` actually means no-values, but this is orthogonal to this PR and adding `none()` is sufficient in it-self.*
`@rustbot` label +F-check-cfg
r? `@petrochenkov`
Update cargo
8 commits in 3e428a38a34e820a461d2cc082e726d3bda71bcb..84976cd699f4aea56cb3a90ce3eedeed9e20d5a5
2024-01-09 20:46:36 +0000 to 2024-01-12 15:55:43 +0000
- fix(resolver): do not panic when sorting empty summaries (rust-lang/cargo#13287)
- Implementation of shallow libgit2 fetches behind an unstable flag (rust-lang/cargo#13252)
- Add documentation entry for unstable `--output-format` flag (rust-lang/cargo#13284)
- doc: add `public` info in `cargo-add` man page. (rust-lang/cargo#13272)
- More docs on prerelease compat (rust-lang/cargo#13286)
- Add unstable `--output-format` option to `cargo rustdoc` (rust-lang/cargo#12252)
- feat: Add `rustc` style errors for manifest parsing (rust-lang/cargo#13172)
- Document why `du` function uses mutex (rust-lang/cargo#13273)
r? ghost
`-Ztreat-err-as-bug` treats normal errors and delayed bugs equally,
which can lead to some really surprising results.
This commit changes `-Ztreat-err-as-bug` so it ignores delayed bugs,
unless they get promoted to proper bugs and are printed.
This feels to me much simpler and more logical. And it simplifies the
implementation:
- The `-Ztreat-err-as-bug` check is removed from in
`DiagCtxt::{delayed_bug,span_delayed_bug}`.
- `treat_err_as_bug` doesn't need to count delayed bugs.
- The `-Ztreat-err-as-bug` panic message is simpler, because it doesn't
have to mention delayed bugs.
Output of delayed bugs is now more consistent. They're always printed
the same way. Previously when they triggered `-Ztreat-err-as-bug` they
would be printed slightly differently, via `span_bug` in
`span_delayed_bug` or `delayed_bug`.
A minor behaviour change: the "no errors encountered even though
`span_delayed_bug` issued" printed before delayed bugs is now a note
rather than a bug. This is done so it doesn't get counted as an error
that might trigger `-Ztreat-err-as-bug`, which would be silly.
This means that if you use `-Ztreat-err-as-bug=1` and there are no
normal errors but there are delayed bugs, the first delayed bug will be
shown (and the panic will happen after it's printed).
Also, I have added a second note saying "those delayed bugs will now be
shown as internal compiler errors". I think this makes it clearer what
is happening, because the whole concept of delayed bugs is non-obvious.
There are some test changes.
- equality-in-canonical-query.rs: Minor output changes, and the error
count reduces by one because the "no errors encountered even though
`span_delayed_bug` issued" message is no longer counted as an error.
- rpit_tait_equality_in_canonical_query.rs: Ditto.
- storage-live.rs: The query stack disappears because these delayed bugs
are now printed at the end, rather than when they are created.
- storage-return.rs, span_delayed_bug.rs: now need
`-Zeagerly-emit-delayed-bugs` because they need the delayed bugs
emitted immediately to preserve behaviour.
Fix unused_parens issue when cast is followed LT
Fixes#117142
The original check only checks `a as (i32) < 0`, this fix extends it to handle `b + a as (i32) < 0`.
A better way is maybe we suggest `(a as i32) < 0` instead of suppressing the warning, maybe following PR could improve it.
Rollup of 6 pull requests
Successful merges:
- #119817 (Remove special-casing around `AliasKind::Opaque` when structurally resolving in new solver)
- #119819 (Check rust lints when an unknown lint is detected)
- #119872 (Give me a way to emit all the delayed bugs as errors (add `-Zeagerly-emit-delayed-bugs`))
- #119877 (Add more information to `visit_projection_elem`)
- #119884 (Rename `--env` option flag to `--env-set`)
- #119885 (Revert #113923)
r? `@ghost`
`@rustbot` modify labels: rollup
Add more information to `visit_projection_elem`
Without the starting place, it's hard to retrieve any useful information from visiting a projection.
Note: I still need to add a test.
Give me a way to emit all the delayed bugs as errors (add `-Zeagerly-emit-delayed-bugs`)
This is probably a *better* way to inspect all the delayed bugs in a program that what exists currently (and therefore makes it very easy to choose the right number `N` with `-Zemit-err-as-bug=N`, though I guess the naming is a bit ironic when you pair both of the flags together, but that feels like naming bikeshed more than anything).
This pacifies my only concern with https://github.com/rust-lang/rust/pull/119871#issuecomment-1888170259, because (afaict?) that PR doesn't allow you to intercept a delayed bug's stack trace anymore, which as someone who debugs the compiler a lot, is something that I can *promise* that I do.
r? `@nnethercote` or `@oli-obk`
Remove special-casing around `AliasKind::Opaque` when structurally resolving in new solver
This fixes a few inconsistencies around where we don't eagerly resolve opaques to their (locally-defined) hidden types in the new solver. It essentially allows this code to work:
```rust
fn main() {
type Tait = impl Sized;
struct S {
i: i32,
}
let x: Tait = S { i: 0 };
println!("{}", x.i);
}
```
Since `Tait` is defined in `main`, we are able to poke through the type of `x` with deref.
r? lcnr
Exhaustiveness: track overlapping ranges precisely
The `overlapping_range_endpoints` lint has false positives, e.g. https://github.com/rust-lang/rust/issues/117648. I expected that removing these false positives would have too much of a perf impact but never measured it. This PR is an experiment to see if the perf loss is manageable.
r? `@ghost`
