Notify @topecongiro when the state of rustfmt has changed
I would like to get notified when the state of rustfmt has changed.
Context: I am currently a leader of the rustfmt working group.
cc @nrc do you still want to get notified?
rustc: Implement incremental "fat" LTO
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
cc #57968
cc rust-lang/cargo#6643
Check user type annotations for range patterns.
Fixes#58299.
This PR builds on the fix from #58161 (which fixed miscompilation
caused by the introduction of `AscribeUserType` patterns for associated
constants) to start checking these patterns are well-formed for ranges
(previous fix just ignored them so that miscompilation wouldn't occur).
r? @arielb1
Closure bounds fixes
* Ensures that "nice region errors" are buffered so that they are sorted and migrated correctly.
* Propagates fewer constraints for closures (cc #58178)
* Propagate constraints from closures more precisely (#58127)
Closes#58127
r? @nikomatsakis
Add more profiler events
- Adds Start\Stop events for time spent loading incremental query results from disk.
- Adds Start\Stop events for time spent blocked waiting for queries to complete (when parallel queries are enabled).
r? @michaelwoerister
Hidden suggestion support
Add way to hide suggestion snippet window from cli output to avoid cluttered spans that don't enhance understanding.
r? @pietroalbini CC @zackmdavis
Tweak "incompatible match arms" error
- Point at the body expression of the match arm with the type error.
- Point at the prior match arms explicitly stating the evaluated type.
- Point at the entire match expr in a secondary span, instead of primary.
- For type errors in the first match arm, the cause is outside of the
match, treat as implicit block error to give a more appropriate error.
Fix#46776, fix#57206.
CC #24157, #38234.
Update the future/task API
This change updates the future and task API as discussed in the stabilization RFC at https://github.com/rust-lang/rfcs/pull/2592.
Changes:
- Replacing UnsafeWake with RawWaker and RawWakerVtable
- Removal of LocalWaker
- Removal of Arc-based Wake trait
Since `compiler_builtins` is being injected automatically, its docs
aren't masked. This commit masks the crate's docs if it's brought in as
an extern crate.
This is a non-POSIX extension implemented in Solaris and in glibc 2.29.
With this we can still use `posix_spawn()` when `Command::current_dir()`
has been set, otherwise we fallback to `fork(); chdir(); exec()`.
The reverse conversion unfortunately causes unexpected errors like:
```
error[E0277]: the trait bound `!: std::convert::From<()>` is not satisfied
--> src/librustc_metadata/encoder.rs:105:9
|
105 | self.emit_usize(seq.len)?;
| ^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `std::convert::From<()>` is not implemented for `!`
|
= help: the following implementations were found:
<! as std::convert::From<std::convert::Infallible>>
= note: the trait is implemented for `()`. Possibly this error has been caused by changes to Rust's type-inference algorithm (see: https://github.com/rust-lang/rust/issues/48950 for more info). Consider whether you meant to use the type `()` here instead.
= note: required by `std::convert::From::from`
```
I don’t understand why this error happens.
If I’m reading the code correctly the return types of `emit_usize`
and of the method that contains line 105 are both `Result<(), !>`,
so the expansion of the `?` operator should involve `!: From<!>`,
not `From<()>`.
Is this a type inference bug?
target/uefi: clarify documentation
This clarifies why FP-units are disabled on UEFI targets, as well as
why we must opt into the NXCOMPAT feature.
I did find some time to investigate why GRUB and friends disable FP on
UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it
turns out it does not mandate enabling the instruction sets explicitly.
Hence, any use of these instructions will trigger CPU exceptions,
unless an application explicitly enables them (which is not an option,
as these are global flags that better be controlled by the
kernel/firmware).
Furthermore, UEFI systems are allowed to mark any non-code page as
non-executable. Hence, we must make sure to never place code on the
stack or heap. So we better pass /NXCOMPAT to the linker for it to
complain if it ever places code in non-code pages.
Lastly, this fixes some typos in related comments.
r? @alexcrichton
Only suggest imports if not imported.
Fixes#42944 and fixes#53430.
This commit modifies name resolution error reporting so that if a name
is in scope and has been imported then we do not suggest importing it.
This can occur when we add a label about constructors not being visible
due to private fields. In these cases, we know that the struct/variant
has been imported and we should silence any suggestions to import the
struct/variant.
r? @estebank
Fix ICE and invalid filenames in MIR printing code
* Don't panic when printing MIR for associated constants
* Don't use `<` and `>` in filenames, since they aren't allowed on Windows.
r? @eddyb
cc @RalfJung
Improve the error messages for missing stability attributes
This makes the capitalisation consistent and provides more context (especially for missing top-level attributes).
Ignore future deprecations in #[deprecated]
The future deprecation warnings should only apply to `#[rustc_deprecated]` as they take into account rustc's version. Fixes#57952.
I've also slightly modified rustdoc's display of future deprecation notices to make it more consistent, so I'm assigning a rustdoc team member for review to make sure this is okay.
r? @GuillaumeGomez
