Fixes#21370.
`unused-macro-with-follow-violation.rs` was already handled correctly. That test is just for good measure. :)
I have a more involved plan to clean this up, but it ran into difficulties such as #22814.
Ensure we do not zero when \"moving\" types that are Copy.
Uses more precise `type_needs_drop` for deciding about emitting cleanup code. Added notes about the weaknesses regarding `ty::type_contents` here.
Fix#22536
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.
Details in the commit messages.
Implements `Debug` for `RwLock` and `arc::Weak` in the same way it is implemented for `rc::Weak` (basically copy & paste).
The lack of this implementation prevents the automatic implementation of `Debug` for structs containing members of these types.
rustdoc impl item did not include default methods for local crates, but did include them for external crates. This resulted in duplicate methods. Fix so that impl item does not include default methods for external crates.
Fix#22595.
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.
