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
}
If we match a whole struct or tuple, the "field" for the reassignment
checker will be "None" which means that mutating any field should count
as a reassignment.
Fixes#26996.
If we match a whole struct or tuple, the "field" for the reassignment
checker will be "None" which means that mutating any field should count
as a reassignment.
Fixes#26996.
