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` & `or_else`
This is a
[breaking-change]
Due to some code needing additional type annotations.
Change MarkerTrait to be invariant. This is a (small) loss of expressiveness, but is necessary for now to work around #22806. Fixes#22655.
r? @pnkfelix
r? @steveklabnik
Closes#22698
I wasn't sure that this was appropriate for the book, but I've added this to the reference. I also noticed that one of the U+ symbols in the character literals section was missing the graves.
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.
