about summary refs log tree commit diff
path: root/src/librustc/session
AgeCommit message (Collapse)AuthorLines
2016-10-03Auto merge of #36847 - alexcrichton:rustc-macro-doc, r=nrcbors-0/+7
rustdoc: Fix documenting rustc-macro crates This commit adds a "hack" to the session to track whether we're a rustdoc session or not. If we're rustdoc then we skip the expansion to add the rustc-macro infrastructure. Closes #36820
2016-09-30rustdoc: Fix documenting rustc-macro cratesAlex Crichton-0/+7
This commit adds a "hack" to the session to track whether we're a rustdoc session or not. If we're rustdoc then we skip the expansion to add the rustc-macro infrastructure. Closes #36820
2016-09-28Rollup merge of #36794 - japaric:target-panic, r=alexcrichtonJonathan Turner-26/+21
add a panic-strategy field to the target specification Now a target can define its panic strategy in its specification. If a user doesn't specify a panic strategy via the command line, i.e. '-C panic', then the compiler will use the panic strategy defined by the target specification. Custom targets can pick their panic strategy via the "panic-strategy" field of their target specification JSON file. If omitted in the specification, the strategy defaults to "unwind". closes #36647 --- I checked that compiling an executable for a custom target with "panic-strategy" set to "abort" doesn't need the "eh_personality" lang item and also that standard crates compiled for that custom target didn't contained undefined symbols to _Unwind_Resume. But this needs an actual unit test, any suggestion on how to test this? Most of the noise in the diff is due to moving `PanicStrategy` from the `rustc` to the `rustc_back` crate. r? @alexcrichton cc @phil-opp
2016-09-28fix librustc test: panic is Option<PanicStrategy> nowJorge Aparicio-1/+1
2016-09-28Allow supplying an error destination via the compiler driverNick Cameron-5/+15
Allows replacing stderr with a buffer from the client. Also, some refactoring around run_compiler.
2016-09-27add a panic-strategy field to the target specificationJorge Aparicio-25/+20
Now a target can define its panic strategy in its specification. If a user doesn't specify a panic strategy via the command line, i.e. '-C panic', then the compiler will use the panic strategy defined by the target specification. Custom targets can pick their panic strategy via the "panic-strategy" field of their target specification JSON file. If omitted in the specification, the strategy defaults to "unwind". closes #36647
2016-09-26Auto merge of #36764 - jonathandturner:rollup, r=jonathandturnerbors-0/+10
Rollup of 14 pull requests - Successful merges: #36563, #36574, #36586, #36662, #36663, #36669, #36676, #36721, #36723, #36727, #36729, #36742, #36754, #36756 - Failed merges:
2016-09-26Rollup merge of #36574 - japaric:link-arg, r=alexcrichtonJonathan Turner-0/+10
rustc: implement -C link-arg this flag lets you pass a _single_ argument to the linker but can be used _repeatedly_. For example, instead of using: ``` rustc -C link-args='-l bar' (..) ``` you could write ``` rustc -C link-arg='-l' -C link-arg='bar' (..) ``` This new flag can be used with RUSTFLAGS where `-C link-args` has problems with "nested" spaces: ``` RUSTFLAGS='-C link-args="-Tlayout.ld -nostartfiles"' ``` This passes three arguments to rustc: `-C` `link-args="-Tlayout.ld` and `-nostartfiles"` to `rustc`. That's not what we meant. But this does what we want: ``` RUSTFLAGS='-C link-arg=-Tlayout.ld -C link-arg=-nostartfiles` ``` cc rust-lang/rfcs#1509 r? @alexcrichton cc @Zoxc This needs a test. Any suggestion?
2016-09-26appease tidyTim Neumann-1/+2
2016-09-26deduplicate inline is_nightly_build implementationsTim Neumann-4/+1
2016-09-26refactor away get_unstable_features_settingTim Neumann-19/+3
2016-09-26make is_nightly_build a method on UnstableFeaturesTim Neumann-4/+1
2016-09-22Auto merge of #36261 - parched:soft-float, r=pnkfelixbors-1/+1
Fix documentation with 'soft-float' codegen option This option doesn't cause software FP routines to be called, it only changes the float ABI. Additionally, this option is ignored by all targets, except the ARM eabihf ones.
2016-09-20rustc_metadata: move more RBML tags to auto-serialization.Eduard Burtescu-1/+1
2016-09-20rustc_metadata: go only through rustc_serialize in astencode.Eduard Burtescu-7/+9
2016-09-19rustc: implement -C link-argJorge Aparicio-0/+10
this flag lets you pass a _single_ argument to the linker but can be used _repeatedly_. For example, instead of using: ``` rustc -C link-args='-l bar' (..) ``` you could write ``` rustc -C link-arg='-l' -C link-arg='bar' (..) ``` This new flag can be used with RUSTFLAGS where `-C link-args` has problems with "nested" spaces: ``` RUSTFLAGS='-C link-args="-Tlayout.ld -nostartfiles"' ``` This passes three arguments to rustc: `-C` `link-args="-Tlayout.ld` and `-nostartfiles"` to `rustc`. That's not what we meant. But this does what we want: ``` RUSTFLAGS='-C link-arg=-Tlayout.ld -C link-arg=-nostartfiles` ``` cc rust-lang/rfcs#1509
2016-09-13Move macro resolution into `librustc_resolve`.Jeffrey Seyfried-7/+2
2016-09-06Auto merge of #36025 - michaelwoerister:incr-comp-hash-spans, r=nikomatsakisbors-0/+35
incr. comp.: Take spans into account for ICH This PR makes the ICH (incr. comp. hash) take spans into account when debuginfo is enabled. A side-effect of this is that the SVH (which is based on the ICHs of all items in the crate) becomes sensitive to the tiniest change in a code base if debuginfo is enabled. Since we are not trying to model ABI compatibility via the SVH anymore (this is done via the crate disambiguator now), this should be not be a problem. Fixes #33888. Fixes #32753.
2016-09-04Auto merge of #36203 - petrochenkov:uvsdot, r=nrcbors-2/+2
Replace `_, _` with `..` in patterns This is how https://github.com/rust-lang/rust/issues/33627 looks in action. Looks especially nice in leftmost/rightmost positions `(first, ..)`/`(.., last)`. I haven't touched libsyntax intentionally because the feature is still unstable.
2016-09-04Fix documentation with 'soft-float' codegen optionJames Duley-1/+1
This option doesn't cause software FP routines to be called it only changes the float ABI. Additionally, this option is ignored by all targets, except the ARM eabihf ones.
2016-09-04Auto merge of #36132 - nrc:save-std, r=@eddybbors-2/+8
Add --Zsave-analysis-api This is a save-analysis variation which can be used with libraries distributed without their source (e.g., libstd). It will allow IDEs and other tools to get info about types and create URLs to docs and source, without the unnecessary clutter of internal-only save-analysis info. I'm sure we'll iterate somewhat on the design, but this is a first draft.
2016-09-04Replace `_, _` with `..`Vadim Petrochenkov-2/+2
2016-09-02rustc: Implement custom derive (macros 1.1)Alex Crichton-0/+14
This commit is an implementation of [RFC 1681] which adds support to the compiler for first-class user-define custom `#[derive]` modes with a far more stable API than plugins have today. [RFC 1681]: https://github.com/rust-lang/rfcs/blob/master/text/1681-macros-1.1.md The main features added by this commit are: * A new `rustc-macro` crate-type. This crate type represents one which will provide custom `derive` implementations and perhaps eventually flower into the implementation of macros 2.0 as well. * A new `rustc_macro` crate in the standard distribution. This crate will provide the runtime interface between macro crates and the compiler. The API here is particularly conservative right now but has quite a bit of room to expand into any manner of APIs required by macro authors. * The ability to load new derive modes through the `#[macro_use]` annotations on other crates. All support added here is gated behind the `rustc_macro` feature gate, both for the library support (the `rustc_macro` crate) as well as the language features. There are a few minor differences from the implementation outlined in the RFC, such as the `rustc_macro` crate being available as a dylib and all symbols are `dlsym`'d directly instead of having a shim compiled. These should only affect the implementation, however, not the public interface. This commit also ended up touching a lot of code related to `#[derive]`, making a few notable changes: * Recognized derive attributes are no longer desugared to `derive_Foo`. Wasn't sure how to keep this behavior and *not* expose it to custom derive. * Derive attributes no longer have access to unstable features by default, they have to opt in on a granular level. * The `derive(Copy,Clone)` optimization is now done through another "obscure attribute" which is just intended to ferry along in the compiler that such an optimization is possible. The `derive(PartialEq,Eq)` optimization was also updated to do something similar. --- One part of this PR which needs to be improved before stabilizing are the errors and exact interfaces here. The error messages are relatively poor quality and there are surprising spects of this such as `#[derive(PartialEq, Eq, MyTrait)]` not working by default. The custom attributes added by the compiler end up becoming unstable again when going through a custom impl. Hopefully though this is enough to start allowing experimentation on crates.io! syntax-[breaking-change]
2016-09-01Add some infrastructure for timing things where time_passes can't be used.Michael Woerister-0/+35
2016-09-01review commentsNick Cameron-1/+1
2016-09-01save-analsysis: add save-analysis-api CLI flagNick Cameron-2/+8
2016-08-31Auto merge of #35718 - michaelwoerister:incr-comp-dir-locking, r=alexcrichtonbors-1/+100
Implement synchronization scheme for incr. comp. directory This PR implements a copy-on-write-based synchronization scheme for the incremental compilation cache directory. For technical details, see the documentation at the beginning of `rustc_incremental/persist/fs.rs`. The PR contains unit tests for some functions but for testing whether the scheme properly handles races, a more elaborate test setup would be needed. It would probably involve a small tool that allows to manipulate the incremental compilation directory in a controlled way and then letting a compiler instance run against directories in different states. I don't know if it's worth the trouble of adding another test category to `compiletest`, but I'd be happy to do so. Fixes #32754 Fixes #34957
2016-08-29incr.comp.: Move lock files out of directory being lockedMichael Woerister-8/+16
2016-08-29Implement copy-on-write scheme for managing the incremental compilation cache.Michael Woerister-1/+92
2016-08-25Fix fallout in tests.Jeffrey Seyfried-2/+6
2016-08-25Refactor away `AttrMetaMethods`.Jeffrey Seyfried-2/+0
2016-08-25Fix debug line info for macro expansions. Vadim Chugunov-0/+2
Macro expansions produce code tagged with debug locations that are completely different from the surrounding expressions. This wrecks havoc on debugger's ability the step over source lines. In order to have a good line stepping behavior in debugger, we overwrite debug locations of macro expansions with that of the outermost expansion site.
2016-08-24Remove drop flags from structs and enums implementing Drop.Eduard Burtescu-6/+0
2016-08-24Disable old trans access via -Z orbit, #[rustc_no_mir] or --disable-orbit.Eduard Burtescu-34/+1
2016-08-11Address comments by reviewers.Michael Woerister-11/+11
2016-08-11Remove the 'cfg' field from session::config::Options.Michael Woerister-210/+16
The 'cfg' in the Options struct is only the commandline-specified subset of the crate configuration and it's almost always wrong to read that instead of the CrateConfig in HIR crate node.
2016-08-11Add the notion of a dependency tracking status to commandline arguments.Michael Woerister-161/+1207
Commandline arguments influence whether incremental compilation can use its compilation cache and thus their changes relative to previous compilation sessions need to be taking into account. This commit makes sure that one has to specify for every commandline argument whether it influences incremental compilation or not.
2016-08-10Auto merge of #34845 - bitshifter:issue-30961, r=alexcrichtonbors-7/+34
Add help for target CPUs, features, relocation and code models. Fix for https://github.com/rust-lang/rust/issues/30961. Requires PR https://github.com/rust-lang/llvm/pull/45 to be accepted first, and the .gitmodules for llvm to be updated before this can be merged.
2016-08-09Auto merge of #35401 - jonathandturner:enable_json_and_new_errors, ↵bors-11/+4
r=jonathandturner Turn on new errors and json mode This PR is a big-switch, but on a well-worn path: * Turns on new errors by default (and removes old skool) * Moves json output from behind a flag The RFC for new errors [landed](https://github.com/rust-lang/rfcs/pull/1644) and as part of that we wanted some bake time. It's now had a few weeks + all the time leading up to the RFC of people banging on it. We've also had [editors updating to the new format](https://github.com/saviorisdead/RustyCode/pull/159) and expect more to follow. We also have an [issue on old skool](https://github.com/rust-lang/rust/issues/35330) that needs to be fixed as more errors are switched to the new style, but it seems silly to fix old skool errors when we fully intend to throw the switch in the near future. This makes it lean towards "why not just throw the switch now, rather than waiting a couple more weeks?" I only know of vim that wanted to try to parse the new format but were not sure how, and I think we can reach out to them and work out something in the 8 weeks before this would appear in a stable release. We've [hashed out](https://github.com/rust-lang/rust/issues/35330) stabilizing JSON output, and it seems like people are relatively happy making what we have v1 and then likely adding to it in the future. The idea is that we'd maintain backward compatibility and just add new fields as needed. We'll also work on a separate output format that'd be better suited for interactive tools like IDES (since JSON message can get a little long depending on the error). This PR stabilizes JSON mode, allowing its use without `-Z unstable-options` Combined, this gives editors two ways to support errors going forward: parsing the new error format or using the JSON mode. By moving JSON to stable, we can also add support to Cargo, which plugin authors tell us does help simplify their support story. r? @nikomatsakis cc @rust-lang/tools Closes https://github.com/rust-lang/rust/issues/34826
2016-08-09Auto merge of #35166 - nikomatsakis:incr-comp-ice-34991-2, r=mwbors-0/+2
Address ICEs running w/ incremental compilation and building glium Fixes for various ICEs I encountered trying to build glium with incremental compilation enabled. Building glium now works. Of the 4 ICEs, I have test cases for 3 of them -- I didn't isolate a test for the last commit and kind of want to go do other things -- most notably, figuring out why incremental isn't saving much *effort*. But if it seems worthwhile and I can come back and try to narrow down the problem. r? @michaelwoerister Fixes #34991 Fixes #32015
2016-08-09add a `-Z incremental-info` flagNiko Matsakis-0/+2
2016-08-07Turn on new errors, json mode. Remove duplicate unicode testJonathan Turner-11/+4
2016-08-06Merge branch 'master' into issue-30961Cameron Hart-94/+65
2016-08-02Auto merge of #35159 - michaelwoerister:incr-comp-implies-orbit, r=nikomatsakisbors-1/+9
Automatically enable -Zorbit if -Zincremental is specified. Fixes #34973 r? @nikomatsakis
2016-08-02Automatically enable -Zorbit if -Zincremental is specified.Michael Woerister-1/+9
2016-08-02rustc: parse -Z orbit=off.Eduard Burtescu-1/+22
2016-08-02Turn -Z orbit on by default.Eduard Burtescu-1/+1
2016-08-01trans: Avoid weak linkage for closures when linking with MinGW.Michael Woerister-1/+5
2016-07-31Suggest use of `--print target-list` when target is not found.Tomasz Miąsko-2/+5
If given target could not be found suggest using `--print target-list`. Previously, error has been reported as: $ rustc --target x86-unknown-linux-gnu error: Error loading target specification: Could not find specification for target "x86-unknown-linux-gnu" After changes it looks as follows: rustc --target x86-unknown-linux-gnu error: Error loading target specification: Could not find specification for target "x86-unknown-linux-gnu" help: Use `--print target-list` for a list of built-in targets
2016-07-28Keep multiple files per work-productNiko Matsakis-10/+13
In the older version, a `.o` and ` .bc` file were separate work-products. This newer version keeps, for each codegen-unit, a set of files of different kinds. We assume that if any kinds are available then all the kinds we need are available, since the precise set of switches will depend on attributes and command-line switches. Should probably test this: the effect of changing attributes in particular might not be successfully tracked?