Expands E0201 to be used for any duplicate associated items, not just duplicate
methods/functions. It also correctly detects when two different kinds of items
(like a constant and a method) have the same name.
Fixes#23969.
Tidy is still run first for failing fast on the easy stuff.
To accomplish this we have travis actually persist ccache across builds. This
has LLVM built within 6 minutes, and all of stage1 built within 18.
Caching should work on fresh PRs (cache acquired from the master branch).
Because all we persist is ccache, there is minimal danger of persisting corrupt
build state.
I had to mangle `configure` a bit to make --enable-ccache work when custom
compilers are provide via CC and CXX.
Grammatical update (and passive -> active, but I'm not sure if "Rust" is often used as a subject in the book; feel free to revert that part for style, but keep the subject-verb agreement)
r? @steveklabnik
The current nonzero side padding of `code` tags is good for legibility in paragraphs and lists; however, it introduces an awkward indentation to `pre` tags. Specifically, when a `pre` tag contains preformatted text with multiple lines, the fist line gets pushed slightly to the right, running the vertical alignment. An example can be seen [here](http://doc.rust-lang.org/std/fmt/#syntax). I propose setting the padding to zero for `code`s contained in `pre`s.
Regards,
Ivan
Yet another attempt to make the prose on the std crate page
clearer and more informative.
This does a lot of things: tightens up the opening, adds useful links
(including a link to the search bar), offers guidance on how to use
the docs, and expands the prelude docs as a useful newbie entrypoint.
Since Apple LLVM no longer reports which version of LLVM it's based off (starting with 7.0.0), I believe it's time to start checking Apple LLVM versions directly.
The changes in this pull request update the `configure` script to check "Apple LLVM" versions independently if no "based off" version can be found. If a "based off" version is included, however, it will be preferred.
(This is a less hacky version of #26653)
This PR will enable RUSTC to generate PDB debuginfo files when targeting the MSVC toolchain. Mind that these are not full featured PDB files -- they just contain line tables, so you can get proper backtraces and step through your code, but variable values can't be inspected. We are just levering (LLVM's current support)[http://clang.llvm.org/docs/MSVCCompatibility.html] for creating Windows debuginfo. When LLVM's support gets better, we should benefit from that too without much effort.
I also wanted to include some kind of auto test with this PR but I could not get the `rmake` tests to work properly when targeting MSVC.
EDIT:
Closes#19533
When building for AArch64/Linux, __morestack ends up in the .note.GNU-stack section,
which causes missing references for the linker. By using the func/endfunc macros
from macros.S we get __morestack right to .text (and a bit more on the side).
Currently errorck yields bogus `duplicate error code` messages when an error code occurs inside of a long diagnostic message (see https://github.com/rust-lang/rust/pull/26982), because errorck just goes line by line checking for error codes and recording them all.
A simplistic approach to fixing this is just to detect the beginning of a long diagnostic raw string literal (`r##"`) and skip lines until the end of the raw string literal is encountered. I'm not completely confident in this approach, but I think a more robust approach would be more complicated and I wanted to get feedback before pursuing that.
Grammatical update (and passive -> active, but I'm not sure if "Rust" is often used as a subject in the book; feel free to revert that part for style, but keep the subject-verb agreement)
... matching the existing Index impls.
There is no reason not to if String implement DerefMut.
The code removed in `src/librustc/middle/effect.rs` was added in #9750
to prevent things like `s[0] = 0x80` where `s: String`,
but I belive became unnecessary when the Index(Mut) traits were introduced.
This commit expands the follow set of the `ty` and `path` macro fragments to
include the semicolon token as well. A semicolon is already allowed after these
tokens, so it's currently a little too restrictive to not have a semicolon
allowed. For example:
extern {
fn foo() -> i32; // semicolon after type
}
fn main() {
struct Foo;
Foo; // semicolon after path
}
