| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix a bug where an obligation that depend on an erroring obligation would
be regarded as successful, leading to global cache pollution and random
lossage.
Fixes #33723.
Fixes #34503.
|
|
|
|
Use libc::abort, not intrinsics::abort, in rtabort!
intrinsics::abort compiles down to an illegal instruction, which on
Unix-like platforms causes the process to be killed with SIGILL. A more
appropriate way to kill the process would be SIGABRT; this indicates
better that the runtime has explicitly aborted, rather than some kind of
compiler bug or architecture mismatch that SIGILL might indicate.
For rtassert!, replace this with libc::abort. libc::abort raises
SIGABRT, but is defined to do so in such a way that it will terminate
the process even if SIGABRT is currently masked or caught by a signal
handler that returns.
On non-Unix platforms, retain the existing behavior. On Windows we
prefer to avoid depending on the C runtime, and we need a fallback for
any other platforms that may be defined. An alternative on Windows
would be to call TerminateProcess, but this seems less essential than
switching to using SIGABRT on Unix-like platforms, where it is common
for the process-killing signal to be printed out or logged.
This is a [breaking-change] for any code that depends on the exact
signal raised to abort a process via rtabort!
cc #31273
cc #31333
|
|
intrinsics::abort compiles down to an illegal instruction, which on
Unix-like platforms causes the process to be killed with SIGILL. A more
appropriate way to kill the process would be SIGABRT; this indicates
better that the runtime has explicitly aborted, rather than some kind of
compiler bug or architecture mismatch that SIGILL might indicate.
For rtassert!, replace this with libc::abort. libc::abort raises
SIGABRT, but is defined to do so in such a way that it will terminate
the process even if SIGABRT is currently masked or caught by a signal
handler that returns.
On non-Unix platforms, retain the existing behavior. On Windows we
prefer to avoid depending on the C runtime, and we need a fallback for
any other platforms that may be defined. An alternative on Windows
would be to call TerminateProcess, but this seems less essential than
switching to using SIGABRT on Unix-like platforms, where it is common
for the process-killing signal to be printed out or logged.
This is a [breaking-change] for any code that depends on the exact
signal raised to abort a process via rtabort!
cc #31273
cc #31333
|
|
|
|
test: explicitely check the number of spawned threads in tcp-stress
System limits may restrict the number of threads effectively spawned by this test (eg. systemd recently introduced a 512 tasks per unit maximum default).
Now this test explicitly asserts on the expected number of threads, making failures due to system limits easier to spot.
More details at https://bugs.debian.org/822325
|
|
mir: always allow &mut [...] in static mut regardless of the array length.
|
|
Signed-off-by: Luca Bruno <lucab@debian.org>
|
|
System limits may restrict the number of threads effectively spawned
by this test (eg. systemd recently introduced a 512 tasks per unit
maximum default).
This commit explicitly asserts on the expected number of threads,
making failures due to system limits easier to spot.
More details at https://bugs.debian.org/822325
Signed-off-by: Luca Bruno <lucab@debian.org>
|
|
Support references to outer type params for assoc consts
Fixes #28809
r? @eddyb
|
|
Don't use env::current_exe with libbacktrace
If the path we give to libbacktrace doesn't actually correspond to the
current process, libbacktrace will segfault *at best*.
cc #21889
r? @alexcrichton
cc @semarie
|
|
|
|
|
|
mir: don't attempt to promote Unpromotable constant temps.
Fixes #33537. This was a non-problem in regular functions, but we also promote in `const fn`s.
There we always qualify temps so you can't depend on `Unpromotable` temps being `NOT_CONST`.
|
|
It turns out that `ast_ty_to_ty` is supposed to be updating the `def`
after it finishes, but at some point in the past it stopped doing
so. This was never noticed because of the `ast_ty_to_ty_cache`, but that
cache was recently removed. This PR fixes the code to update the def
properly, but apparently that is not quite enough to make the operation
idempotent, so for now we reintroduce the cache too.
Fixes #33425.
|
|
If the path we give to libbacktrace doesn't actually correspond to the
current process, libbacktrace will segfault *at best*.
cc #21889
|
|
|
|
Rollup of 9 pull requests
- Successful merges: #33129, #33260, #33345, #33386, #33522, #33524, #33528, #33539, #33542
- Failed merges: #33342, #33475, #33517
|
|
middle: reset loop labels while visiting closure
This should fix #31754 and follow-up #25343. Before the latter, the closure was visited twice in the context of the enclosing fn, which made even a single closure with a loop label emit a warning.
With this change, the closure is still visited within the context of the main fn (which is intended, since it is not a separate item) but resets the found loop labels while being visited.
Fixes: #31754
Note: I amended the test file from #25343, but I don't know if the original or amended test are effective, since as far as I could see, compiletest's run-pass tests do not check for zero warnings emitted?
/cc @Manishearth
|
|
|
|
|
|
Fix several -Z orbit crater blockers.
Fixes 3 of the issues found by @nikomatsakis' crater run with `-Z orbit` forced on:
https://gist.github.com/nikomatsakis/6688c30a0e5d3fed07cc1ebd4efb1412
Two of the regressions seemed to be fixed by #33130 and the remaining two are timeouts.
|
|
rustc: Implement custom panic runtimes
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
Closes #32837
|
|
Utilize `Result::unwrap_err` in more places.
None
|
|
|
|
|
|
casting `&[u8]` to `* const u8` doesn't work in const_eval
fixes #33452
r? @eddyb
cc @Ms2ger
|
|
This commit is an implementation of [RFC 1513] which allows applications to
alter the behavior of panics at compile time. A new compiler flag, `-C panic`,
is added and accepts the values `unwind` or `panic`, with the default being
`unwind`. This model affects how code is generated for the local crate, skipping
generation of landing pads with `-C panic=abort`.
[RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md
Panic implementations are then provided by crates tagged with
`#![panic_runtime]` and lazily required by crates with
`#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic
runtime must match the final product, and if the panic strategy is not `abort`
then the entire DAG must have the same panic strategy.
With the `-C panic=abort` strategy, users can expect a stable method to disable
generation of landing pads, improving optimization in niche scenarios,
decreasing compile time, and decreasing output binary size. With the `-C
panic=unwind` strategy users can expect the existing ability to isolate failure
in Rust code from the outside world.
Organizationally, this commit dismantles the `sys_common::unwind` module in
favor of some bits moving part of it to `libpanic_unwind` and the rest into the
`panicking` module in libstd. The custom panic runtime support is pretty similar
to the custom allocator support with the only major difference being how the
panic runtime is injected (takes the `-C panic` flag into account).
|
|
|
|
trans: callee: normalize trait_ref before use
This fixes #33436 and #33461. Ran the tests and nothing else seems to be affected.
P.S. How to write the regression test for this fix? Does this qualify as run-pass or run-make, as the test only needs to be successfully compiled to be considered passed? Will add the testcase (the minimal example in #33461 seems fit) after clarifying this.
|
|
|
|
|
|
Implement constant support in MIR.
All of the intended features in `trans::consts` are now supported by `mir::constant`.
The implementation is considered a temporary measure until `miri` replaces it.
A `-Z orbit` bootstrap build will only translate LLVM IR from AST for `#[rustc_no_mir]` functions.
Furthermore, almost all checks of constant expressions have been moved to MIR.
In non-`const` functions, trees of temporaries are promoted, as per RFC 1414 (rvalue promotion).
Promotion before MIR borrowck would allow reasoning about promoted values' lifetimes.
The improved checking comes at the cost of four `[breaking-change]`s:
* repeat counts must contain a constant expression, e.g.:
`let arr = [0; { println!("foo"); 5 }];` used to be allowed (it behaved like `let arr = [0; 5];`)
* dereference of a reference to a `static` cannot be used in another `static`, e.g.:
`static X: [u8; 1] = [1]; static Y: u8 = (&X)[0];` was unintentionally allowed before
* the type of a `static` *must* be `Sync`, irrespective of the initializer, e.g.
`static FOO: *const T = &BAR;` worked as `&T` is `Sync`, but it shouldn't because `*const T` isn't
* a `static` cannot wrap `UnsafeCell` around a type that *may* need drop, e.g.
`static X: MakeSync<UnsafeCell<Option<String>>> = MakeSync(UnsafeCell::new(None));`
was previously allowed based on the fact `None` alone doesn't need drop, but in `UnsafeCell`
it can be later changed to `Some(String)` which *does* need dropping
The drop restrictions are relaxed by RFC 1440 (#33156), which is implemented, but feature-gated.
However, creating `UnsafeCell` from constants is unstable, so users can just enable the feature gate.
|
|
|
|
Fix some some duplicate words.
|
|
|
|
|
|
Fixes #33436 and #33461. Test case is from #33461.
|
|
|
|
For legacy reasons (presumably), Windows does not permit files name aux.
|
|
|
|
Instead of finding aux-build files in `auxiliary`, we now search for an
`aux` directory relative to the test. So if your test is
`compile-fail/foo.rs`, we would look in `compile-fail/aux`. Similarly,
we ignore the `aux` directory when searching for tets.
|
|
Short-cut `T: Sized` trait selection for ADTs
Basically avoids all nested obligations when checking whether an ADT is sized - this speeds up typeck by ~15%
The refactoring fixed #32963, but I also want to make `Copy` not object-safe (will commit that soon).
Fixes #33201
r? @nikomatsakis
|
|
|
|
this commit should be reverted after a release cycle
|
|
|
|
|
|
fix various const eval errors
These were found after const_evaluating arbitrary expressions and linting if the const evaluator failed
fixes #33275 (int -> float casts for negative ints)
fixes #33291 (int -> char casts (new! wasn't allowed in constants until this PR))
r? @eddyb
cc @bluss @japaric
|
|
This should fix #31754 and follow-up #25343. Before the latter, the
closure was visited twice in the context of the enclosing fn, which
made even a single closure with a loop label emit a warning.
With this change, the closure is still visited within the context
of the main fn (which is intended, since it is not a separate item)
but resets the found loop labels while being visited.
Fixes: #31754
|
