summary refs log tree commit diff
path: root/src/librustc/session
AgeCommit message (Collapse)AuthorLines
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?
2016-07-28Store `crate_disambiguator` as an `InternedString`Niko Matsakis-2/+5
We used to use `Name`, but the session outlives the tokenizer, which means that attempts to read this field after trans has complete otherwise panic. All reads want an `InternedString` anyhow.
2016-07-24Tidy ups for code gen options helpCameron Hart-5/+6
Remove duplication code gen options and updated help to reflect changes.
2016-07-22remove the now-unused multiline error codeAriel Ben-Yehuda-77/+4
2016-07-21Auto merge of #34715 - scottcarr:mir-test, r=nikomatsakisbors-0/+2
Add MIR Optimization Tests I've starting working on the infrastructure for testing MIR optimizations. The plan now is to have a set of test cases (written in Rust), compile them with -Z dump-mir, and check the MIR before and after each pass.
2016-07-20add mir optimization tests, dump-mir-dir optionScott A Carr-0/+2
2016-07-19Merge branch 'master' into issue-30961Cameron Hart-10/+19
2016-07-17Auto merge of #34860 - jseyfried:encapsulate_hygiene, r=nrcbors-2/+2
Clean up and encapsulate `syntax::ext::mtwt`, rename `mtwt` to `hygiene` r? @nrc
2016-07-17Rename `mtwt` to `hygiene`Jeffrey Seyfried-2/+2
2016-07-17Auto merge of #34789 - jonathandturner:simplify_liberror, r=alexcrichtonbors-8/+17
Simplify librustc_errors This is part 2 of the error crate refactor, starting with #34403. In this refactor, I focused on slimming down the error crate to fewer moving parts. As such, I've removed quite a few parts and replaced the with simpler, straight-line code. Specifically, this PR: * Removes BasicEmitter * Remove emit from emitter, leaving emit_struct * Renames emit_struct to emit * Removes CoreEmitter and focuses on a single Emitter * Implements the latest changes to error format RFC (#1644) * Removes (now-unused) code in emitter.rs and snippet.rs * Moves more tests to the UI tester, removing some duplicate tests in the process There is probably more that could be done with some additional refactoring, but this felt like it was getting to a good state. r? @alexcrichton cc: @Manishearth (as there may be breaking changes in stuff I removed/changed)
2016-07-16Merge branch 'master' into issue-30961Cameron Hart-6/+1
2016-07-14Remove emit from emitter, leaving emit_structJonathan Turner-4/+6
2016-07-14Remove BasicEmitterJonathan Turner-4/+11
2016-07-12Mention the crate type cdylib in rustc's usageDridi Boukelmoune-1/+1
2016-07-10Move variant_size_differences out of transJonas Schievink-5/+0
Also enhances the error message a bit, fixes #30505 on the way, and adds a test (which was missing). Closes #34018
2016-07-11Add help for target CPUs, features, relocation and code models.Cameron Hart-2/+28
2016-07-08Adapt backend to trans::partitioning dictating the codegen-unit setup.Michael Woerister-9/+56
2016-07-03prefer `if let` to match with `None => {}` arm in some placesZack M. Davis-8/+5
This is a spiritual succesor to #34268/8531d581, in which we replaced a number of matches of None to the unit value with `if let` conditionals where it was judged that this made for clearer/simpler code (as would be recommended by Manishearth/rust-clippy's `single_match` lint). The same rationale applies to matches of None to the empty block.
2016-06-28cleanup: refactor away `ast::NodeIdAssigner`Jeffrey Seyfried-15/+4
2016-06-23make old school mode a bit more configurableJonathan Turner-1/+4
2016-06-23Consolidate codemap tests and fix more errors for travisJonathan Turner-7/+6
2016-06-23Move errors from libsyntax to its own crateJonathan Turner-8/+8
2016-06-06Remove old -Z options that do nothingJonas Schievink-11/+0
Technically, this is a [breaking-change], but I'm not sure what the policy for -Z flags is (especially unused ones).
2016-06-03Auto merge of #33460 - shepmaster:16-bit-pointers, r=Aatchbors-0/+1
Support 16-bit pointers as well as i/usize I'm opening this pull request to get some feedback from the community. Although Rust doesn't support any platforms with a native 16-bit pointer at the moment, the [AVR-Rust][ar] fork is working towards that goal. Keeping this forked logic up-to-date with the changes in master has been onerous so I'd like to merge these changes so that they get carried along when refactoring happens. I do not believe this should increase the maintenance burden. This is based on the original work of Dylan McKay (@dylanmckay). [ar]: https://github.com/avr-rust/rust
2016-05-27Emit "no-frame-pointer-elim" attribute for closures, shims, and glue.Michael Woerister-1/+6
2016-05-25trans: save metadata even with -Z no-trans.Eduard Burtescu-1/+1
2016-05-25rustc: use a simpler scheme for plugin registrar symbol names.Eduard Burtescu-0/+10
2016-05-20Auto merge of #33553 - alexcrichton:cdylibs, r=brsonbors-1/+4
rustc: Add a new crate type, cdylib This commit is an implementation of [RFC 1510] which adds a new crate type, `cdylib`, to the compiler. This new crate type differs from the existing `dylib` crate type in a few key ways: * No metadata is present in the final artifact * Symbol visibility rules are the same as executables, that is only reachable `extern` functions are visible symbols * LTO is allowed * All libraries are always linked statically This commit is relatively simple by just plubming the compiler with another crate type which takes different branches here and there. The only major change is an implementation of the `Linker::export_symbols` function on Unix which now actually does something. This helps restrict the public symbols from a cdylib on Unix. With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB, which is some nice size savings! [RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510 Closes #33132
2016-05-19rustc: Add a new crate type, cdylibAlex Crichton-1/+4
This commit is an implementation of [RFC 1510] which adds a new crate type, `cdylib`, to the compiler. This new crate type differs from the existing `dylib` crate type in a few key ways: * No metadata is present in the final artifact * Symbol visibility rules are the same as executables, that is only reachable `extern` functions are visible symbols * LTO is allowed * All libraries are always linked statically This commit is relatively simple by just plubming the compiler with another crate type which takes different branches here and there. The only major change is an implementation of the `Linker::export_symbols` function on Unix which now actually does something. This helps restrict the public symbols from a cdylib on Unix. With this PR a "hello world" `cdylib` is 7.2K while the same `dylib` is 2.4MB, which is some nice size savings! [RFC 1510]: https://github.com/rust-lang/rfcs/pull/1510 Closes #33132
2016-05-19Support 16-bit pointers as well as i/usizeJake Goulding-0/+1
This is based on the original work of Dylan McKay for the [avr-rust project][ar]. [ar]: https://github.com/avr-rust/rust
2016-05-18fix indentation of session/mod.rsNiko Matsakis-3/+3
2016-05-18thread the DepGraph to session/crate-storeNiko Matsakis-10/+26
This is a [breaking-change] for plugin authors. You must now create a dep-graph earlier.
2016-05-09Auto merge of #32900 - alexcrichton:panic2abort, r=nikomatsakisbors-4/+37
rustc: Implement custom panic runtimes This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account). Closes #32837
2016-05-09rustc: Implement custom panic runtimesAlex Crichton-4/+37
This commit is an implementation of [RFC 1513] which allows applications to alter the behavior of panics at compile time. A new compiler flag, `-C panic`, is added and accepts the values `unwind` or `panic`, with the default being `unwind`. This model affects how code is generated for the local crate, skipping generation of landing pads with `-C panic=abort`. [RFC 1513]: https://github.com/rust-lang/rfcs/blob/master/text/1513-less-unwinding.md Panic implementations are then provided by crates tagged with `#![panic_runtime]` and lazily required by crates with `#![needs_panic_runtime]`. The panic strategy (`-C panic` value) of the panic runtime must match the final product, and if the panic strategy is not `abort` then the entire DAG must have the same panic strategy. With the `-C panic=abort` strategy, users can expect a stable method to disable generation of landing pads, improving optimization in niche scenarios, decreasing compile time, and decreasing output binary size. With the `-C panic=unwind` strategy users can expect the existing ability to isolate failure in Rust code from the outside world. Organizationally, this commit dismantles the `sys_common::unwind` module in favor of some bits moving part of it to `libpanic_unwind` and the rest into the `panicking` module in libstd. The custom panic runtime support is pretty similar to the custom allocator support with the only major difference being how the panic runtime is injected (takes the `-C panic` flag into account).
2016-05-09Add #[cfg(target_has_atomic)] to get atomic support for the current targetAmanieu d'Antras-0/+10