Auto merge of #43115 - petrochenkov:methlife2, r=eddyb
Store all generic arguments for method calls in AST/HIR
The first part of https://github.com/rust-lang/rust/pull/42492.
Landed separately to start the process of merging libsyntax changes breaking rustfmt, which is not easy these days.
Auto merge of #43117 - MJDSys:fix_rustbuild_libdir_2, r=alexcrichton
Fix stage 2 builds with a custom libdir.
When copying libstd for the stage 2 compiler, the builder ignores the
configured libdir/libdir_relative configuration parameters. This causes
the compiler to fail to find libstd, which cause any tools built with the
stage 2 compiler to fail.
To fix this, make the copy steps of rustbuild aware of the libdir_relative
parameter when the stage >= 2. Also update the dist target to be aware of
the new location of libstd.
This is quite handy in some user code, for instance to pull out type errors from an inference context when `fresh_substs_for_item` has been used before.
Auto merge of #43019 - kevinmehall:cleanup-errors, r=nikomatsakis
Remove unused code from librustc_errors
While extracting librustc_errors into a [reusable library](https://github.com/kevinmehall/codemap-diagnostic), I noticed some obsolete code that the `dead_code` warning missed because it was marked `pub` but not used elsewhere.
Auto merge of #42996 - Boreeas:merge-e0609-e0612, r=GuillaumeGomez
Fold E0612, E0613 into E0609
As discussed in #42945, with PR 1506 tuple indices are no longer considered a separate case from normal field. This PR folds E06012 ("tuple index out of bounds") and E0613 ("type is not a tuple") into E0609 ("type does not have field with that name")
Auto merge of #43104 - nbaksalyar:rustbuild-illumos-fix, r=sanxiyn
Fix Rustbuild linking on Illumos
Illumos (an OpenSolaris fork) expects to get several extra library references for some system functions used by Rust standard library. This commit adds required linker options to rustbuild, which is currently doesn't work on Illumos-based operating systems.
Auto merge of #43072 - cuviper:linux-stack-guard, r=alexcrichton
Skip the main thread's manual stack guard on Linux
Linux doesn't allocate the whole stack right away, and the kernel has its own stack-guard mechanism to fault when growing too close to an existing mapping. If we map our own guard, then the kernel starts enforcing a rather large gap above that, rendering much of the possible stack space useless.
Instead, we'll just note where we expect rlimit to start faulting, so our handler can report "stack overflow", and trust that the kernel's own stack guard will work.
Fixes #43052.
r? @alexcrichton
### Kernel compatibility:
Strictly speaking, Rust claims support for Linux kernels >= 2.6.18, and stack guards were only added to mainline in 2.6.36 for [CVE-2010-2240]. But since that vulnerability was so severe, the guards were backported to many stable branches, and Red Hat patched this all the way back to RHEL3's 2.4.21! I think it's reasonable for us to assume that any *supportable* kernel should have these stack guards.
At that time, the kernel only enforced one page of padding between the stack and other mappings, but thanks to [Stack Clash] that padding is now much larger, causing #43052. The kernel side of those fixes are in [CVE-2017-1000364], which Red Hat has backported to at least RHEL5's 2.6.18 so far.
Matthew Dawson [Sat, 8 Jul 2017 03:00:38 +0000 (23:00 -0400)]
Fix stage 2 builds with a custom libdir.
When copying libstd for the stage 2 compiler, the builder ignores the
configured libdir/libdir_relative configuration parameters. This causes
the compiler to fail to find libstd, which cause any tools built with the
stage 2 compiler to fail.
To fix this, make the copy steps of rustbuild aware of the libdir_relative
parameter when the stage >= 2. Also update the dist target to be aware of
the new location of libstd.
Auto merge of #42840 - arielb1:poison-smoke-and-mirrors, r=nikomatsakis
Replace the global fulfillment cache with the evaluation cache
This uses the new "Chalk" ParamEnv refactoring to check "global" predicates in an empty environment, which should be correct because global predicates aren't affected by a consistent environment.
Ariel Ben-Yehuda [Mon, 26 Jun 2017 15:39:52 +0000 (18:39 +0300)]
use dep-graph reads for the evaluation cache
This is just duplicating the logic from the old fulfillment cache, so
I'm not sure it is 100% correct, but it should not be more wrong than
the old logic.
Josh Stone [Wed, 5 Jul 2017 19:03:17 +0000 (12:03 -0700)]
Skip the main thread's manual stack guard on Linux
Linux doesn't allocate the whole stack right away, and the kernel has
its own stack-guard mechanism to fault when growing too close to an
existing mapping. If we map our own guard, then the kernel starts
enforcing a rather large gap above that, rendering much of the possible
stack space useless.
Instead, we'll just note where we expect rlimit to start faulting, so
our handler can report "stack overflow", and trust that the kernel's own
stack guard will work.
Auto merge of #43099 - japaric:msp430, r=alexcrichton
add a built-in MSP430 target
the MSP430 backend has been enabled for a while but no target was added to rustc
to encourage out of tree experimentation.
We believe the out of tree (custom) target has been iterated long enough and is
stable enough for inclusion in the compiler. Kudos to @pftbest and @awygle for
fixing several LLVM / codegen bugs this target had!
The target name chosen is a slight variation of the triple gcc uses, which is
simply `msp430-elf`. We picked `msp430-none-elf` to leave room for custom
targets that target some embedded OS running on MSP430 devices. (cf. the
custom `thumbv7m-tockos-eabi` target TockOS uses vs the built-in
`thumbv7m-none-eabi`).
There's one expected change in the specification of the proposed target: the
`asm_args` and `no_integrated_as` fields will change to their default values.
Once the LLVM backend gains the ability to directly produce MSP430 object files
we can stop depending on `msp430-elf-gcc` for producing object files; when that
occurs the `asm` related fields will change. This change won't break existing
user code.
Auto merge of #43091 - aidanhs:aphs-no-docker-priv, r=alexcrichton
Privileged in docker run isn't necessary
Added relatively recently in https://github.com/rust-lang/rust/pull/40199/files#diff-71609a365528e4649836825d8250c241R57, but I don't see anything in that PR that requires it. If it's not strictly necessary, we shouldn't use it.
(if this lands I'll make a PR against libc which also uses privileged)
Illumos (an OpenSolaris fork) expects to get several
extra library references for some system functions used
by Rust standard library. This commit adds required linker
options to rustbuild, which is currently doesn't work on
Illumos-based operating systems.
Auto merge of #42125 - petrochenkov:privty, r=nikomatsakis
Check types for privacy
This PR implements late post factum checking of type privacy, as opposed to early preventive "private-in-public" checking.
This will allow to turn private-in-public checks into a lint and make them more heuristic-based, and more aligned with what people may expect (e.g. reachability-based behavior).
Types are privacy-checked if they are written explicitly, and also if they are inferred as expression or pattern types.
This PR checks "semantic" types and does it unhygienically, this significantly restricts what macros 2.0 (as implemented in https://github.com/rust-lang/rust/pull/40847) can do (sorry @jseyfried) - they still can use private *names*, but can't use private *types*.
This is the most conservative solution, but hopefully it's temporary and can be relaxed in the future, probably using macro contexts of expression/pattern spans.
Traits are also checked in preparation for [trait aliases](https://github.com/rust-lang/rust/issues/41517), which will be able to leak private traits, and macros 2.0 which will be able to leak pretty much anything.
This is a [breaking-change], but the code that is not contrived and can be broken by this patch should be guarded by `private_in_public` lint. [Previous crater run](https://github.com/rust-lang/rust/issues/34537#issuecomment-262865768) discovered a few abandoned crates that weren't updated since `private_in_public` has been introduced in 2015.
cc https://github.com/rust-lang/rust/issues/34537 https://internals.rust-lang.org/t/lang-team-minutes-private-in-public-rules/4504
Fixes https://github.com/rust-lang/rust/issues/30476
Fixes https://github.com/rust-lang/rust/issues/33479
Auto merge of #42904 - estebank:number-suggestions, r=nikomatsakis
Make suggestion include the line number
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.
New output:
```
error[E0308]: mismatched types
--> ../../src/test/ui/block-result/unexpected-return-on-unit.rs:19:5
|
19 | foo()
| ^^^^^ expected (), found usize
|
= note: expected type `()`
found type `usize`
help: did you mean to add a semicolon here?
|
19 | foo();
| ^
help: possibly return type missing here?
|
18 | fn bar() -> usize {
| ^^^^^^^^
Esteban Küber [Sun, 25 Jun 2017 20:11:22 +0000 (13:11 -0700)]
Make suggestion include the line number
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.
Auto merge of #42816 - alexcrichton:probestack, r=nikomatsakis
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.
Alex Crichton [Wed, 21 Jun 2017 19:08:18 +0000 (12:08 -0700)]
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.
Auto merge of #43008 - zackmdavis:field_init_shorthand_in_librustc, r=estebank
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,`)
Auto merge of #42899 - alexcrichton:compiler-builtins, r=nikomatsakis
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.
Auto merge of #42727 - alexcrichton:allocators-new, r=eddyb
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.
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.
Alex Crichton [Sat, 3 Jun 2017 21:54:08 +0000 (14:54 -0700)]
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.
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.
Auto merge of #40939 - jseyfried:proc_macro_api, r=nrc
proc_macro: implement `TokenTree`, `TokenKind`, hygienic `quote!`, and other API
All new API is gated behind `#![feature(proc_macro)]` and may be used with `#[proc_macro]`, `#[proc_macro_attribute]`, and `#[proc_macro_derive]` procedural macros.
More specifically, this PR adds the following in `proc_macro`:
```rust
// `TokenStream` constructors:
impl TokenStream { fn empty() -> TokenStream { ... } }
impl From<TokenTree> for TokenStream { ... }
impl From<TokenKind> for TokenStream { ... }
impl<T: Into<TokenStream>> FromIterator<T> for TokenStream { ... }
macro quote($($t:tt)*) { ... } // A hygienic `TokenStream` quoter
struct Span { ... } // a region of source code along with expansion/hygiene information
impl Default for Span { ... } // a span from the current procedural macro definition
impl Span { fn call_site() -> Span { ... } } // the call site of the current expansion
fn quote_span(span: Span) -> TokenStream;
enum TokenKind {
Group(Delimiter, TokenStream), // A delimited sequence, e.g. `( ... )`
Term(Term), // a unicode identifier, lifetime ('a), or underscore
Op(char, Spacing), // a punctuation character (`+`, `,`, `$`, etc.).
Literal(Literal), // a literal character (`'a'`), string (`"hello"`), or number (`2.3`)
}
enum Delimiter {
Parenthesis, // `( ... )`
Brace, // `[ ... ]`
Bracket, // `{ ... }`
None, // an implicit delimiter, e.g. `$var`, where $var is `...`.
}
struct Term { ... } // An interned string
impl Term {
fn intern(string: &str) -> Symbol { ... }
fn as_str(&self) -> &str { ... }
}
enum Spacing {
Alone, // not immediately followed by another `Op`, e.g. `+` in `+ =`.
Joint, // immediately followed by another `Op`, e.g. `+` in `+=`
}
Alex Crichton [Thu, 22 Jun 2017 20:14:00 +0000 (13:14 -0700)]
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.
projects / rust.git / log