Implement Make `handle_alloc_error` default to panic (for no_std + liballoc)
Related: https://github.com/rust-lang/rust/issues/66741
Guarded with `#![feature(default_alloc_error_handler)]` a default
`alloc_error_handler` is called, if a custom allocator is used and no
other custom `#[alloc_error_handler]` is defined.
Improve rustdoc error for failed intra-doc link resolution
The previous error was confusing since it made it sound like you can't
link to items that are defined outside the current module.
Also suggested importing the item.
r? @jyn514
Add some regression tests
Closes#66501Closes#68951Closes#72565Closes#74244Closes#75299
The first issue is fixed in 1.43.0, other issues are fixed in the recent nightly.
Use `tracing` spans to trace the entire MIR interp stack
r? @RalfJung
While being very verbose, this allows really good tracking of what's going on. While I considered schemes like the previous indenter that we had (which we could get by using the `tracing-tree` crate), this will break down horribly with things like multithreaded rustc. Instead, we can now use `RUSTC_LOG` to restrict the things being traced. You could specify a filter in a way that only shows the logging of a specific frame.
If we lower the span's level to `debug`, then in `info` level logging we'd not see the frames, but in `debug` level we would see them. The filtering rules in `tracing` are super powerful, but I'm not sure if we can specify a filter so we do see `debug` level events, but *not* the `frame` spans. The documentation at https://docs.rs/tracing-subscriber/0.2.10/tracing_subscriber/struct.EnvFilter.html makes me think that we can only turn on things, not turn off things at a more precise level.
cc @hawkw
This matches Cargo behavior and avoids the (somewhat expensive) double checking,
as well as the unfortunate duplicate error messages (#76822,
rust-lang/cargo#5128).
Remove --cfg dox from rustdoc.rs
This was added in https://github.com/rust-lang/rust/pull/53076 because
several dependencies were using `cfg(dox)` instead of `cfg(rustdoc)` (now `cfg(doc)`).
I ran `rg 'cfg\(dox\)'` on the source tree with no matches, so I think
this is now safe to remove.
r? `@Mark-Simulacrum`
cc `@QuietMisdreavus` :)
Permit ty::Bool in const generics for v0 mangling
This should unbreak using new-symbol-mangling = true in config.toml (once it lands in beta anyway).
Fixes#76365 (well, it will, but seems fine to close as soon as we have support)
r? @eddyb (for mangling) but I'm okay with some other reviewer too :)
Bypass const_item_mutation if const's type has Drop impl
Follow-up to #75573. This PR disables the const_item_mutation lint in cases that the const has a Drop impl which observes the mutation.
```rust
struct Log { msg: &'static str }
const LOG: Log = Log { msg: "" };
impl Drop for Log {
fn drop(&mut self) { println!("{}", self.msg); }
}
LOG.msg = "wow"; // prints "wow"
```
r? @Aaron1011
Write manifest for MAJOR.MINOR channel to enable rustup convenience
This connects to https://github.com/rust-lang/rustup/issues/794.
It's hard to remember if there have been patch releases for old versions
when you'd like to install the latest in a MAJOR.MINOR series.
When we're doing a stable release, we write duplicate manifests to
`stable`. With this change, only when we're doing a stable release, also
write duplicate manifests to `MAJOR.MINOR` to eventually enable rustup
(and any other tooling that builds Rust release URLs) to request, say,
`1.45` and get `1.45.2` (assuming `1.45.2` is the latest available
`1.45` and assuming that we never publish patch releases out of order).
I tested the best I could; it's a bit hard to get everything set up right
to be able to run the build-manifest tool. But I was able to run it with
a release of "1.45.2" and in addition to the files like `channel-rust-1.45.2.toml`
and `channel-rust-stable.toml` (and other manifests) that I got before this
change, I now get `channel-rust-1.45.toml`.
I believe this change to be safe to deploy as it does not change or remove
anything about manifests, just adds more. The actions in rust-central-station
that interact with manifests appear to use wildcards in such a way that it will
pick up these files without any problems.
There will need to be changes to `rustup` before `rustup install 1.45` will work,
but we can wait for a stable release and stable patch releases to happen with this
change before making the `rustup` changes, so that we're not committing to anything
before we know it works.
The previous error was confusing since it made it sound like you can't
link to items that are defined outside the current module.
Also suggested importing the item.
Stop running macOS builds on Azure Pipelines
The Infrastructure Team agreed to migrate macOS builds to GitHub Actions, so this commit stops running those builders on Azure Pipelines. The GitHub Actions runners are already configured to upload to the production bucket.
We can't still fully remove the Azure Pipelines configuration, as we still need to have that available until no stable releases run any of their builds on Azure Pipelines anymore. I'll open an issue to track fully removing our Azure Pipelines setup once the PR is merged.
r? @Mark-Simulacrum
Fix AVR stack corruption bug
Updates the Rust LLVM fork to pull in a fix for a stack corruption bug in AVR platform interrupt code lowering.
Fixes#75504
----
It looks like this is also pulling in a register selection fix by @Amanieu and @tambry that hasn't merged yet; I don't see an open PR for that update.
resolve: prohibit anon const non-static lifetimes
Fixes#75323, fixes#74447 and fixes#73375.
This PR prohibits non-static lifetimes in anonymous constants when only the `min_const_generics` feature is enabled. ~~To do so, `to_region_vid`'s `bug!` had to be changed into a delayed bug, which unfortunately required providing it a `TyCtxt`.~~
---
~~While I am happy with how the implementation of the error turned out in `rustc_passes::check_const`, emitting an error wasn't sufficient to avoid hitting the ICE later. I also tried implementing the error in `rustc_mir::transform::check_consts::validation` and that worked, but it didn't silence the ICE either. To silence the ICE, I changed it to a delayed bug which worked but was more invasive that I would have liked, and required I return an incorrect lifetime. It's possible that this check should be implemented earlier in the compiler to make the invasive changes unnecessary, but I wasn't sure where that would be and wanted to get some feedback first.~~
The approach taken by this PR has been changed to implement the error in name resolution, which ended up being much simpler.
cc @rust-lang/wg-const-eval
r? @lcnr
-Zvalidate-mir: Assert that storage is allocated on local use
This extends the MIR validator to check that locals are only used when their backing storage is currently allocated via `StorageLive`.
The result of this is that miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs.
The PR currently fails tests because miscompilations such as https://github.com/rust-lang/rust/issues/77359 are caught and turned into ICEs.
I have confirmed that tests pass (even with `-Zvalidate-mir`) once `SimplifyArmIdentity` is turned into a no-op (except mir-opt tests, of course).
This commit modifies name resolution to emit an error when non-static
lifetimes are used in anonymous constants when the `min_const_generics`
feature is enabled.
Signed-off-by: David Wood <david@davidtw.co>
Disable the SimplifyArmIdentity mir-opt
The optimization still has some bugs that need to be worked out
such as #77359.
We can try re-enabling this again after the known issues are resolved.
r? `@oli-obk`
Related: https://github.com/rust-lang/rust/issues/66741
Guarded with `#![feature(default_alloc_error_handler)]` a default
`alloc_error_handler` is called, if a custom allocator is used and no
other custom `#[alloc_error_handler]` is defined.
The panic message does not contain the size anymore, because it would
pull in the fmt machinery, which would blow up the code size
significantly.
