summary refs log tree commit diff
path: root/src/librustc_interface
AgeCommit message (Collapse)AuthorLines
2020-07-10Rollup merge of #74127 - tamird:allowlist, r=oli-obkManish Goregaokar-2/+2
Avoid "whitelist" Other terms are more inclusive and precise.
2020-07-10Avoid "whitelist"Tamir Duberstein-2/+2
Other terms are more inclusive and precise.
2020-07-10Change some function names.Nicholas Nethercote-11/+11
A couple of these are quite long, but they do a much better job of explaining what they do, which was non-obvious before.
2020-07-10Tweak `spawn_thread_pool`.Nicholas Nethercote-11/+12
This makes the two versions (parallel and non-parallel) more similar to each other.
2020-07-10Add an explanatory comment to `scoped_thread`.Nicholas Nethercote-0/+2
2020-07-09Rollup merge of #74079 - nnethercote:session-globals, r=nikomatsakisManish Goregaokar-16/+17
Eliminate confusing "globals" terminology. There are some structures that are called "globals", but are they global to a compilation session, and not truly global. I have always found this highly confusing, so this commit renames them as "session globals" and adds a comment explaining things. Also, the commit fixes an unnecessary nesting of `set()` calls `src/librustc_errors/json/tests.rs` r? @Aaron1011
2020-07-09Eliminate confusing "globals" terminology.Nicholas Nethercote-16/+17
There are some structures that are called "globals", but are they global to a compilation session, and not truly global. I have always found this highly confusing, so this commit renames them as "session globals" and adds a comment explaining things. Also, the commit fixes an unnecessary nesting of `set()` calls `src/librustc_errors/json/tests.rs`
2020-07-05Use for<'tcx> fn pointers in Providers, instead of having Providers<'tcx>.Eduard-Mihai Burtescu-5/+5
2020-06-28Remove defunct `-Z print-region-graph`Tomasz Miąsko-1/+0
2020-06-25Auto merge of #71858 - petrochenkov:env, r=Mark-Simulacrumbors-0/+35
Print environment variables accessed by rustc as special comments into depinfo files So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes. --- I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo. Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074. Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts. --- Description: - depinfo files are extended with special comments containing info about environment variables accessed during compilation. - Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`. - Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`). - `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends. FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488 Closes https://github.com/rust-lang/rust/issues/70517 Closes https://github.com/rust-lang/rust/issues/40364 Closes https://github.com/rust-lang/rust/issues/44074 A new issue in the cargo repo will be needed to track the cargo side of this feature. r? @ehuss
2020-06-23Rollup merge of #73587 - marmeladema:hir-id-ification-final, r=petrochenkovManish Goregaokar-1/+4
Move remaining `NodeId` APIs from `Definitions` to `Resolver` Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557 TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed. After this, the only remaining work for #50928 should be to adjust the dev guide. r? @petrochenkov
2020-06-23Rollup merge of #73523 - jyn514:everybody_loops, r=ecstatic-morseManish Goregaokar-0/+5
Fix -Z unpretty=everybody_loops It turns out that this has not been working for who knows how long. Previously: ``` pub fn h() { 1 + 2; } ``` After this change: ``` pub fn h() { loop { } } ``` This only affected the pass when run with the command line pretty-printing option, so rustdoc was still replacing bodies with `loop {}`.
2020-06-21Always create a root definition when creating a new `Definitions` object.marmeladema-1/+4
2020-06-20Rollup merge of #73404 - ajpaverd:cfguard_syntax, r=Mark-SimulacrumRalf Jung-1/+1
Update CFGuard syntax Update the naming and syntax of the control-flow-guard option, as discussed in #68793. r? @Mark-Simulacrum
2020-06-19Rollup merge of #73347 - tmiasko:incompatible-sanitizers, r=nikicManish Goregaokar-3/+5
Diagnose use of incompatible sanitizers Emit an error when incompatible sanitizer are configured through command line options. Previously the last one configured prevailed and others were silently ignored. Additionally use a set to represent configured sanitizers, making it possible to enable multiple sanitizers at once. At least in principle, since currently all of them are considered to be incompatible with others.
2020-06-19Fix -Z unpretty=everybody_loopsJoshua Nelson-0/+5
It turns out that this has not been working for who knows how long. Previously: ``` pub fn h() { 1 + 2; } ``` After this change: ``` pub fn h() { loop {} } ``` This only affected the pass when run with the command line pretty-printing option, so rustdoc was still replacing bodies with `loop {}`.
2020-06-16Update CFGuard syntaxAndrew Paverd-1/+1
2020-06-15[WIP] injects llvm intrinsic instrprof.increment for coverage reportsRich Kadel-0/+1
This initial version only injects counters at the top of each function. Rust Coverage will require injecting additional counters at each conditional code branch.
2020-06-14Diagnose use of incompatible sanitizersTomasz Miąsko-3/+5
Emit an error when incompatible sanitizer are configured through command line options. Previously the last one configured prevailed and others were silently ignored. Additionally use a set to represent configured sanitizers, making it possible to enable multiple sanitizers at once. At least in principle, since currently all of them are considered to be incompatible with others.
2020-06-13Ensure that `drop_elaboration_and_check_consts` runs for all const itemsDylan MacKenzie-1/+5
2020-06-12Rollup merge of #73178 - petrochenkov:explint, r=varkorDylan DPC-5/+10
expand: More precise locations for expansion-time lints First commit: a macro expansion doesn't have a `NodeId` associated with it, but it has a parent `DefId` which we can use for linting. The observable effect is that lints associated with macro expansions can now be `allow`ed at finer-grained level than whole crate. Second commit: each macro definition has a `NodeId` which we can use for linting, unless that macro definition was decoded from other crate.
2020-06-09expand: Give reasonable NodeIds to lints associated with macro definitionsVadim Petrochenkov-5/+10
2020-06-08Show `SyntaxContext` in formatted `Span` debug outputAaron Hill-1/+1
This is only really useful in debug messages, so I've switched to calling `span_to_string` in any place that causes a `Span` to end up in user-visible output.
2020-06-08Rollup merge of #72799 - Aaron1011:feature/span-debug, r=petrochenkovRalf Jung-0/+2
Add `-Z span-debug` to allow for easier debugging of proc macros Currently, the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating, since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled, the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once #72618 is merged, this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees, we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise, we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.
2020-06-06Auto merge of #72927 - petrochenkov:rustc, r=Mark-Simulacrumbors-1/+1
Rename all remaining compiler crates to use the `rustc_foo` pattern libarena -> librustc_arena libfmt_macros -> librustc_parse_format libgraphviz -> librustc_graphviz libserialize -> librustc_serialize Closes https://github.com/rust-lang/rust/issues/71177 in particular.
2020-06-04Add `-Z span-debug` to allow for easier debugging of proc macrosAaron Hill-0/+2
Currently, the `Debug` impl for `proc_macro::Span` just prints out the byte range. This can make debugging proc macros (either as a crate author or as a compiler developer) very frustrating, since neither the actual filename nor the `SyntaxContext` is displayed. This commit adds a perma-unstable flag `-Z span-debug`. When enabled, the `Debug` impl for `proc_macro::Span` simply forwards directly to `rustc_span::Span`. Once #72618 is merged, this will start displaying actual line numbers. While `Debug` impls are not subject to Rust's normal stability guarnatees, we probably shouldn't expose any additional information on stable until `#![feature(proc_macro_span)]` is stabilized. Otherwise, we would be providing a 'backdoor' way to access information that's supposed be behind unstable APIs.
2020-06-04Auto merge of #72618 - Aaron1011:feature/early-sourcemap, r=petrochenkovbors-11/+13
Make `SourceMap` available for early debug-printing of `Span`s Normally, we debug-print `Spans` using the `SourceMap` retrieved from the global `TyCtxt`. However, we fall back to printing out the `Span`'s raw fields (instead of a file and line number) when we try to print a `Span` before a `TyCtxt` is available. This makes debugging early phases of the compile, such as parsing, much more difficult. This commit stores a `SourceMap` in `rustc_span::GlOBALS` as a fallback. When a `TyCtxt` is not available, we try to retrieve one from `GLOBALS` - only if this is not available do we fall back to the raw field output. I'm not sure how to write a test for this - however, this can be verified locally by setting `RUSTC_LOG="rustc_parse=debug"`, and verifying that the output contains filenames and line numbers.
2020-06-02Make things build againVadim Petrochenkov-1/+1
2020-05-31Make `SourceMap` available for early debug-printing of `Span`sAaron Hill-11/+13
Normally, we debug-print `Spans` using the `SourceMap` retrieved from the global `TyCtxt`. However, we fall back to printing out the `Span`'s raw fields (instead of a file and line number) when we try to print a `Span` before a `TyCtxt` is available. This makes debugging early phases of the compile, such as parsing, much more difficult. This commit stores a `SourceMap` in `rustc_span::GlOBALS` as a fallback. When a `TyCtxt` is not available, we try to retrieve one from `GLOBALS` - only if this is not available do we fall back to the raw field output. I'm not sure how to write a test for this - however, this can be verified locally by setting `RUSTC_LOG="rustc_parse=debug"`, and verifying that the output contains filenames and line numbers.
2020-05-31Auto merge of #72767 - pnkfelix:track-devirtualized-filenames-issue-70924, ↵bors-4/+7
r=eddyb Track devirtualized filenames Split payload of FileName::Real to track both real and virtualized paths. (Such splits arise from metadata refs into libstd; the virtualized paths look like `/rustc/1.45.0/src/libstd/io/cursor.rs` rather than `/Users/felixklock/Dev/Mozilla/rust.git/src/libstd/io/cursor.rs`) This way, we can emit the virtual name into things like the like the StableSourceFileId (as was done back before PR #70642) that ends up in incremental build artifacts, while still using the devirtualized file path when we want to access the file. Fix #70924
2020-05-31Print accessed env vars as special comments into depinfo filesVadim Petrochenkov-0/+35
2020-05-30Rollup merge of #72669 - petrochenkov:smclean, r=Mark-SimulacrumRalf Jung-14/+15
rustc_session: Cleanup session creation Noticed while reviewing https://github.com/rust-lang/rust/pull/72618.
2020-05-30Rollup merge of #72666 - ivanloz:profile_emit_flag, r=matthewjasperRalf Jung-0/+1
Add -Z profile-emit=<path> for Gcov gcda output. Adds a -Z flag to control the file path that the Gcov gcda output is written to during runtime. This flag expects a path and filename, e.g. -Z profile-emit=gcov/out/lib.gcda. This works similar to GCC/Clang's -fprofile-dir flag which allows control over the output path for gcda coverage files.
2020-05-30more `LocalDefId`sBastian Kauschke-1/+1
2020-05-29Split payload of FileName::Real to track both real and virutalized paths.Felix S. Klock II-4/+7
Such splits arise from metadata refs into libstd. This way, we can (in a follow on commit) continue to emit the virtual name into things like the like the StableSourceFileId that ends up in incremetnal build artifacts, while still using the devirtualized file path when we want to access the file. Note that this commit is intended to be a refactoring; the actual fix to the bug in question is in a follow-on commit.
2020-05-27rustc_session: Cleanup session creationVadim Petrochenkov-14/+15
2020-05-27Add -Z profile-emit=<path> for Gcov gcda output.Ivan Lozano-0/+1
Adds a -Z flag to control the file path that the Gcov gcda output is written to during runtime. This flag expects a path and filename, e.g. -Z profile-emit=gcov/out/lib.gcda. This works similar to GCC/Clang's -fprofile-dir flag which allows control over the output path for gcda coverage files.
2020-05-25Add a small MIR validation passJonas Schievink-0/+1
2020-05-24Collect tokens for `ast::Expr`Aaron Hill-0/+2
2020-05-22Use `OnceCell` instead of `Once`Dylan MacKenzie-15/+14
2020-05-20Eliminate some `Option<NativeLibKind>`sVadim Petrochenkov-21/+21
2020-05-20Rename some types describing native librariesVadim Petrochenkov-22/+22
NativeLibrary(Kind) -> NativeLib(Kind) NativeStatic -> StaticBundle NativeStaticNobundle -> StaticNoBundle NativeFramework -> Framework NativeRawDylib -> RawDylib NativeUnknown -> Unspecified
2020-05-18Implement AST lowering for asm!Amanieu d'Antras-3/+6
2020-05-16rustc_target: Stop using "string typing" for code modelsVadim Petrochenkov-2/+2
Introduce `enum CodeModel` instead.
2020-05-11Fix clippy warningsMatthias Krüger-1/+1
Fixes clippy::{cone_on_copy, filter_next, redundant_closure, single_char_pattern, len_zero,redundant_field_names, useless_format, identity_conversion, map_clone, into_iter_on_ref, needless_return, option_as_ref_deref, unused_unit, unnecessary_mut_passed}
2020-05-10Auto merge of #71825 - contrun:cg-option-strip, r=petrochenkovbors-1/+2
add codegen option strip closes https://github.com/rust-lang/rust/issues/71757 I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker, PtxLinker, MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.
2020-05-10add linking option stripYI-1/+2
move strip option to "Z" add more strip options, remove strip-debuginfo-if-disabled merge strip and debuginfo
2020-05-10Auto merge of #71775 - petrochenkov:crtcfg, r=matthewjasperbors-1/+1
Enable `cfg` predicate for `target_feature = "crt-static"` only if the target supports it That's what all other `target_feature`s do.
2020-05-09Rollup merge of #71234 - maurer:init-array, r=cuviperRalf Jung-0/+1
rustllvm: Use .init_array rather than .ctors LLVM TargetMachines default to using the (now-legacy) .ctors representation of init functions. Mixing .ctors and .init_array representations can cause issues when linking with lld. This happens in practice for: * Our profiling runtime which is currently implicitly built with .init_array since it is built by clang, which sets this field. * External C/C++ code that may be linked into the same process. Fixes: #71233
2020-05-07Reintegrate chalk using chalk-solveJack Huey-0/+1