Magic functions for writing to stdout/stderr.
This enables I/O in no_std contexts (or, really, any Miri-specific OS-independent context). Combined with the `abort` intrinsic it should allow a reasonable test framework in no_std.
**Question for maintainers:** So, the `no_std` panic test needs work, for two reasons:
- First, its stdout includes Miri's whole message about the abort intrinsic having been used. I guess whatever panic handler you use in `std` contexts exits cleanly without triggering this message. Comparing the entire output with backtrace as golden seems fragile.
- Second, likely for the same reason, the test framework appears to expect the test to exit successfully, when in fact it exits with status 1 due to the abort. This means the test doesn't actually pass right now.
What shall I do there?
The canonical form of a usub.with.overflow check in LLVM are
separate sub + icmp instructions, rather than a usub.with.overflow
intrinsic. Using usub.with.overflow will generally result in worse
optimization potential.
The backend will attempt to form usub.with.overflow when it comes
to actual instruction selection. This is not fully reliable, but
I believe this is a better tradeoff than using the intrinsic in
IR.
Fixes#103285.
Fix the bug of next_point in source_map
There is a bug in `next_point`, the new span won't move to next position when be called in the first time.
For this reason, our current code is working like this:
1. When we really want to move to the next position, we called two times of `next_point`
2. Some code which use `next_point` actually done the same thing with `shrink_to_hi`
This fix make sure when `next_point` is called, span will move with the width at least 1, and also work correctly in the scenario of multiple bytes.
Ref: https://github.com/rust-lang/rust/pull/103140#discussion_r997710998
r? `@davidtwco`
fix: Don't catch the server activation error
We are are rethrowing and showing errors higher up in the call stack already. This just ate the error hiding the stacktrace unnecessarily.
The primary reason for this is that make can result in a substantial
under utilization of parallelism, mostly due to the submake structure
preventing good dependency tracking and scheduling.
In f758c7b2a7 (Debian 6 doesn't have ninja, so use make for the dist builds)
llvm.ninja was disabled due to lack of distro package. This is no longer the
case with the CentOS 7 base, so bring ninja back for a performance boost.
rustdoc: remove no-op CSS `nav.sub { font-size: 1rem }`
This rule originated as a `font-size: 16px`, when body had `font-size: 13px` set in 4fd061c426.
It remained even when body's font size was bumped up to 16px, 4d5f4ff5e9, making the rule a no-op, and was carried forward when it was converted to 1rem in cc18120425.
Deny hashing ty/re/ct inference variables
cc `@cjgillot` and https://github.com/rust-lang/rust/pull/102695#issuecomment-1275706528
r? `@lcnr`
best reviewed one commit at a time, mostly because the second commit that fixes `ClosureOutlivesRequirement` is mostly noise because of losing its `<'tcx>` lifetime parameter.
Do anonymous lifetimes remapping correctly for nested rpits
Closes#103141
r? `@cjgillot` `@nikomatsakis`
This fixes a stable to stable regression that in my opinion is `P-critical` so, we probably want to backport it all the way up to stable.
This enables I/O in no_std contexts (or, really, any Miri-specific
OS-independent context). Combined with the `abort` intrinsic it should
allow a reasonable test framework in no_std.
Following up on #92964, only add default trait implementations for the
`c-unwind` family of function pointers. The previous attempt in #92964
added trait implementations for many more ABIs and ran into concerns
regarding the increase in size of the libcore rlib.
An attempt to abstract away function pointer types behind a unified
trait to reduce the duplication of trait impls is being discussed in #99531
but this change looks to be blocked on a lang MCP.
Following @RalfJung's suggestion in
https://github.com/rust-lang/rust/pull/99531#issuecomment-1233440142,
this commit is another cut at #92964 but it _only_ adds the impls for
`extern "C-unwind" fn` and `unsafe extern "C-unwind" fn`.
I am interested in landing this patch to unblock the stabilization of
the `c_unwind` feature.
RFC: https://github.com/rust-lang/rfcs/pull/2945
Tracking Issue: https://github.com/rust-lang/rust/issues/74990
Implement invocation strategy config
Fixes https://github.com/rust-lang/rust-analyzer/issues/10793
This allows to change how we run build scripts (and `checkOnSave`), exposing two configs:
- `once`: run the specified command once in the project root (the working dir of the server)
- `per_workspace`: run the specified command per workspace in the corresponding workspace
This also applies to `checkOnSave` likewise, though `once_in_root` is useless there currently, due to https://github.com/rust-lang/cargo/issues/11007
