Fixes#20978 for supported platforms (i.e. non-Android POSIX).
This uses `backtrace_pcinfo` to inspect the DWARF debug info
and list the file and line pairs for given stack frame.
Such pair is not unique due to the presence of inlined functions
and the updated routine correctly handles this case.
The code is modelled after libbacktrace's `backtrace_full` routine.
There is one known issue with this approach. Macros, when invoked,
take over the current frame and shadows the file and line pair
which has invoked a macro. In particular, this makes many panicking
macros a bit harder to inspect. This really is a debuginfo problem,
and the backtrace routine should print them correctly with
a correct debuginfo.
The stability check checks the `PublicItems` map when giving errors if
there is a #[stable] item with a public contents that doesn't not have
its own stability. Without recording this, struct fields and enum
variants will not get errors for e.g. stable modules with unmarked
functions internally.
This is just improving the compiler's precision to give the standard
library developers more information earlier.
E.g.
#![staged_api]
#![feature(staged_api)]
#![crate_type = "lib"]
#[stable(feature = "rust1", since = "1.0.0")]
pub struct Foo {
pub x: i32
}
#[stable(feature = "rust1", since = "1.0.0")]
pub mod bar {
pub fn baz() {}
}
Without the patch it gives:
test.rs:12:5: 12:20 error: This node does not have a stability attribute
test.rs:12 pub fn baz() {}
^~~~~~~~~~~~~~~
error: aborting due to previous error
With the patch it gives:
test.rs:7:9: 7:15 error: This node does not have a stability attribute
test.rs:7 pub x: i32
^~~~~~
test.rs:12:5: 12:20 error: This node does not have a stability attribute
test.rs:12 pub fn baz() {}
^~~~~~~~~~~~~~~
error: aborting due to 2 previous errors
We were recording stability attributes applied to fields in the
compiler, and even annotating it in the libs, but the compiler didn't
actually do the checks to give errors/warnings in user crates.
Avoid `cat_expr Erred` notes when already in error state.
Also, to ensure we do not let the dropck get skipped, ICE if `cat_expr` errors when *not* in error state.
This is not known to be a breaking change (i.e. I do not know of a current case that causes the new ICE to be exercised).
Fix#22265
Changes .or() so that it can return a Result with a different E type
than the one it is called on.
Essentially:
fn or(self, res: Result<T, E>) -> Result<T, E>
becomes
fn or<F>(self, res: Result<T, F>) -> Result<T, F>
This brings `or` in line with the existing `and` and `or_else` member
types.
This is a
[breaking-change]
Due to some code needing additional type annotations.
If the filename for a path is `None` then we know that the creation of the
parent directory created the whole path so there's no need to retry the call to
`create_dir`.
Closes#22737
Specifically, the following actions were takend:
* The `copy_memory` and `copy_nonoverlapping_memory` functions
to drop the `_memory` suffix (as it's implied by the functionality). Both
functions are now marked as `#[stable]`.
* The `set_memory` function was renamed to `write_bytes` and is now stable.
* The `zero_memory` function is now deprecated in favor of `write_bytes`
directly.
* The `Unique` pointer type is now behind its own feature gate called `unique`
to facilitate future stabilization.
[breaking-change]
This commit moves `std::env` away from the `std::old_io` error type as well as
the `std::old_path` module. Methods returning an error now return `io::Error`
and methods consuming or returning paths use `std::path` instead of
`std::old_path`. This commit does not yet mark these APIs as `#[stable]`.
This commit also migrates `std::old_io::TempDir` to `std::fs::TempDir` with
essentially the exact same API. This type was added to interoperate with the new
path API and has its own `tempdir` feature.
Finally, this commit reverts the deprecation of `std::os` APIs returning the old
path API types. This deprecation can come back once the entire `std::old_path`
module is deprecated.
[breaking-change]
This commit removes many unnecessary `unsafe impl` blocks as well as pushing the
needed implementations to the lowest level possible. I noticed that the bounds
for `RwLock` are a little off when reviewing #22574 and wanted to ensure that we
had our story straight on these implementations.
