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
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
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.
This resolves#26845.
I'm not entirely satisfied with the placement of the rounding discussion in the docs for the `Div` and `Rem` traits, but I couldn't come up with anywhere better to put it. Suggestions are welcome.
I didn't add any discussion of rounding to the `checked_div` (or rem) or `wrapping_div` documentation because those seem to make it pretty clear that they do the same thing as `Div`.
Inspired by the now-mysteriously-closed https://github.com/rust-lang/rust/pull/26782.
This PR introduces better error messages when unicode escapes have invalid format (e.g. `\uFFFF`). It also makes rustc always tell the user that escape may not be used in byte-strings and bytes and fixes some spans to not include unecessary characters and include escape backslash in some others.
TLS tests have been deadlocking on the OSX bots for quite some time now and this
commit is the result of the investigation into what's going on. It turns out
that a value in TLS which is being destroyed (e.g. the destructor is run) can be
reset back to the initial state **while the destructor is running** if TLS is
re-accessed.
To fix this we stop calling drop_in_place on OSX and instead move the data to a
temporary location on the stack.
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
}
TLS tests have been deadlocking on the OSX bots for quite some time now and this
commit is the result of the investigation into what's going on. It turns out
that a value in TLS which is being destroyed (e.g. the destructor is run) can be
reset back to the initial state **while the destructor is running** if TLS is
re-accessed.
To fix this we stop calling drop_in_place on OSX and instead move the data to a
temporary location on the stack.
This PR modernizes some names in the type checker. The only remaining snake_case name in ty.rs is `ctxt` which should be resolved by @eddyb's pending refactor. We can bike shed over the names, it would just be nice to bring the type checker inline with modern Rust.
r? @eddyb
cc @nikomatsakis
Use escaped byte string representation for CString Debug
Faithfully represent the contents of the CString and CStr in their Debug
impl, by treating them as byte strings with our default escaping to
ascii representation.
Add impl Debug for CStr.
Fixes#26964.
