When there're more than one suggestions in the same diagnostic, they are
displayed in their own block, instead of inline. In order to reduce
confusion, those blocks now display the line number.
rustc: Implement stack probes for x86
This commit implements stack probes on x86/x86_64 using the freshly landed
support upstream in LLVM. The purpose of stack probes here are to guarantee a
segfault on stack overflow rather than having a chance of running over the guard
page already present on all threads by accident.
At this time there's no support for any other architecture because LLVM itself
does not have support for other architectures.
This commit implements stack probes on x86/x86_64 using the freshly landed
support upstream in LLVM. The purpose of stack probes here are to guarantee a
segfault on stack overflow rather than having a chance of running over the guard
page already present on all threads by accident.
At this time there's no support for any other architecture because LLVM itself
does not have support for other architectures.
Suggest rustup toolchain link
The contributing instructions only explain how to build the compiler, but not how to try it out.
I found `rustup toolchain link` to be super useful for this, so I think it's good to suggest it.
use field init shorthand in src/librustc/
Commentary on #37340 [suggested](https://github.com/rust-lang/rust/issues/37340#issuecomment-255513390) using the new field init syntax in the compiler. Do we care about this? If so, here's a pull request for the librustc/ directory. While [`rustfmt` might do this in the future](https://github.com/rust-lang/rust/issues/37340#issuecomment-255513712), in the meantime, some simple Python will do:
```python
#!/usr/bin/env python3
import os, re, sys
OPPORTUNITY = re.compile(r" (\w+): \1,?\n")
def field_init_shorthand_substitution(filename):
with open(filename) as f:
text = f.read()
revised = OPPORTUNITY.sub(r" \1,\n", text)
with open(filename, 'w') as f:
f.write(revised)
def substitute_in_directory(path):
for dirname, _subdirs, basenames in os.walk(path):
for basename in basenames:
field_init_shorthand_substitution(os.path.join(dirname, basename))
if __name__ == "__main__":
substitute_in_directory(sys.argv[1])
```
**Update 3 July**: edited the search (respectively replace) regex to ` (\w+): \1,?\n` (` \1,\n`) from ` (\w+): \1,` (` \1,`)
Switch to rust-lang-nursery/compiler-builtins
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
rustc: Implement the #[global_allocator] attribute
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/1974
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
Add support to `rustc_on_unimplemented` to reference the full path of
the annotated trait. For the following code:
```rust
pub mod Bar {
#[rustc_on_unimplemented = "test error `{Self}` with `{Bar}` `{Baz}` `{Quux}` in `{Foo}`"]
pub trait Foo<Bar, Baz, Quux> {}
}
```
the error message will be:
```
test error `std::string::String` with `u8` `_` `u32` in `Bar::Foo`
```
This PR is an implementation of [RFC 1974] which specifies a new method of
defining a global allocator for a program. This obsoletes the old
`#![allocator]` attribute and also removes support for it.
[RFC 1974]: https://github.com/rust-lang/rfcs/pull/197
The new `#[global_allocator]` attribute solves many issues encountered with the
`#![allocator]` attribute such as composition and restrictions on the crate
graph itself. The compiler now has much more control over the ABI of the
allocator and how it's implemented, allowing much more freedom in terms of how
this feature is implemented.
cc #27389
This commit migrates the in-tree `libcompiler_builtins` to the upstream version
at https://github.com/rust-lang-nursery/compiler-builtins. The upstream version
has a number of intrinsics written in Rust and serves as an in-progress rewrite
of compiler-rt into Rust. Additionally it also contains all the existing
intrinsics defined in `libcompiler_builtins` for 128-bit integers.
It's been the intention since the beginning to make this transition but
previously it just lacked the manpower to get done. As this PR likely shows it
wasn't a trivial integration! Some highlight changes are:
* The PR rust-lang-nursery/compiler-builtins#166 contains a number of fixes
across platforms and also some refactorings to make the intrinsics easier to
read. The additional testing added there also fixed a number of integration
issues when pulling the repository into this tree.
* LTO with the compiler-builtins crate was fixed to link in the entire crate
after the LTO process as these intrinsics are excluded from LTO.
* Treatment of hidden symbols was updated as previously the
`#![compiler_builtins]` crate would mark all symbol *imports* as hidden
whereas it was only intended to mark *exports* as hidden.
Add pager support for `rustc --explain EXXXX`
Hello!
Fixes#32665.
Thanks!
**EDIT:** _I've limited access to a Windows machine so this is taking longer than I've anticipated_. 🐢
cc @alexcrichton @nikomatsakis @Mark-Simulacrum @retep998 @ollie27 @afiune
README: note how to enable debugging for rustc
I got stuck on this for a bit, looking for a debug option in `./x.py build --help`.
Diff without newline changes:
Before:
> Various other options are also supported, and are documented in the config file.
After:
> Various other options, such as enabling debug information, are also supported, and are documented in the config file.
Various minor cleanups to rustbuild
This is work I did before the migration to the new rustbuild. I'd prefer to land this first, before my other PR, to make the diff a little clearer.
r? @alexcrichton
Document unintuitive argument order for Vec::dedup_by relation
When trying to use `dedup_by` to merge some auxiliary information from removed elements into kept elements, I was surprised to observe that `vec.dedup_by(same_bucket)` calls `same_bucket(a, b)` where `b` appears before `a` in the vector, and discards `a` when true is returned. This argument order is probably a bug, but since it has already been stabilized, I guess we should document it as a feature and move on.
(`Vec::dedup` also uses `==` with this unexpected argument order, but I figure that’s not important since `==` is expected to be symmetric with no side effects.)
Update docs for Debug* structs. #29355
This adds docs for the Debug* structs as well as examples from the
Formatter::debug_* methods, so that a user knows how to construct them.
I added these examples as the builders module is not public and hence
the debug_*_new() functions are not available to a user.
r? @steveklabnik
