typeck: Do high-level structural/signature checks before function body checks.
This avoids various ICEs, e.g. premature calls to cat_expr that yield the dreaded "cat_expr Errd" ICE.
However, it also means that some early error feedback is now not provided. This may be for the best, because the error feedback were were providing in some of those cases were false positives -- it was spurious feedback and a distraction from the real problem.
So it is not 100% clear whether we actually want to put this change in or not. I think its a net win, but others might disagree.
(Kudos to @arielb1 for suggesting this modification.)
(The cast from the 64-bit value to isize was using the lower 32-bits,
which led to it being treated as a large positive value rather than a
smallish negative one. The fix was to use the same bits for the upper-
and lower- 32 bits.)
A few final improvements to rustdoc for 1.0:
* Improve how rustdoc handles stability
* Fix cross-crate macro source links
* Improve experience of types inheriting methods through `Deref`
Some more details can be found in the commits.
[Preview](http://people.mozilla.org/~acrichton/doc/std/)
Whenever a type implements Deref, rustdoc will now add a section to the "methods
available" sections for "Methods from Deref<Target=Foo>", listing all the
inherent methods of the type `Foo`.
Closes#19190
This commit is an overhaul to how rustdoc deals with stability of the standard
library. The handling has all been revisited with respect to Rust's current
approach to stability in terms of implementation as well as the state of the
standard library today. The high level changes made were:
* Stable items now have no marker by default
* Color-based small stability markers have been removed
* Module listings now fade out unstable/deprecated items slightly
* Trait methods have a separate background color based on stability and also
list the reason that they are unstable.
* `impl` blocks with stability no longer render at all. This may be re-added
once the compiler recognizes stability on `impl` blocks.
* `impl` blocks no longer have stability of the methods implemente indicated
* The stability summary has been removed
Closes#15468Closes#21674Closes#24201
I doubt this PR is ready to merge as-is, for a couple reasons:
* There are no tests for this change. I'm not sure how to add tests for this change, as it modifies the C ABI for a cross-compilation target. Anecdotally, I have an iOS library I've been working on, and before this change, it crashes running on an arm64 device due to bad calling conventions (a simplified example is in #24154), and after this change, it runs correctly.
* This is my first foray into LLVM. I did my best to reimplement what Clang does for AArch64 codegen (https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/TargetInfo.cpp), particularly in `ABIInfo::isHomogeneousAggregate`, `AArch64ABIInfo::isHomogeneousAggregateBaseType`, and `AArch64ABIInfo::isHomogeneousAggregateSmallEnough`, but I'm not confident I got a complete translation, particularly because Clang includes a lot of checks that I don't believe are necessary for rustc.
Fixes#24154.
One of the parameters to the magical "register a thread-local destructor"
function is called `__dso_handle` and largely just passed along (this seems to
be what other implementations do). Currently we pass the *value* of this symbol,
but apparently the correct piece of information to pass is the *address* of the
symbol.
In a PIE binary the symbol actually contains an address to itself which is why
we've gotten away with what we're doing as long as we have. In a non-PIE binary
the symbol contains the address `NULL`, causing a segfault in the runtime
library if it keeps going.
Closes#24445
closes#24434
This PR changes executes `syntax::config::strip_unconfigured_items` before `syntax::feature_gate::check_crate_macros(sess.codemap()`. As far as I know, `strip_unconfigured_items` should be independent of `check_crate_macros`.
This is a little bit tricky, since with include_str!, we know that we
are including utf-8 content, so it's safe to store the source as a
String in a FileMap. We don't know that for include_bytes!, but I don't
think we actually need to track the contents anyways, so I'm passing "".
new_filemap does check for the zero length content, and it should be
reasonable, howeven I'm not sure if it would be better to pass None
instead of Some(Rc::new("")) as the src component of a FileMap.
Fixes bug #24348
I found that the current description of `enumerate()` doesn't actually tell you what, specifically, the method does, and you have to look at the example to figure it out. Here's a description that I think is better.
The link works on the `std/ptr/index.html` docs page, but not the `std/primitive.pointer.html` page. Instead of leaving it half-broken, it is removed.
I tried fixing this in #24432, but @alexcrichton mentioned that this doc string was used in two places (with different base paths unfortunately).
r? @alexcrichton
