about summary refs log tree commit diff
path: root/src/librustc_interface
AgeCommit message (Collapse)AuthorLines
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
2020-05-07Auto merge of #55617 - oli-obk:stacker, r=nagisa,oli-obkbors-8/+1
Prevent compiler stack overflow for deeply recursive code I was unable to write a test that 1. runs in under 1s 2. overflows on my machine without this patch The following reproduces the issue, but I don't think it's sensible to include a test that takes 30s to compile. We can now easily squash newly appearing overflows by the strategic insertion of calls to `ensure_sufficient_stack`. ```rust // compile-pass #![recursion_limit="1000000"] macro_rules! chain { (EE $e:expr) => {$e.sin()}; (RECURSE $i:ident $e:expr) => {chain!($i chain!($i chain!($i chain!($i $e))))}; (Z $e:expr) => {chain!(RECURSE EE $e)}; (Y $e:expr) => {chain!(RECURSE Z $e)}; (X $e:expr) => {chain!(RECURSE Y $e)}; (A $e:expr) => {chain!(RECURSE X $e)}; (B $e:expr) => {chain!(RECURSE A $e)}; (C $e:expr) => {chain!(RECURSE B $e)}; // causes overflow on x86_64 linux // less than 1 second until overflow on test machine // after overflow has been fixed, takes 30s to compile :/ (D $e:expr) => {chain!(RECURSE C $e)}; (E $e:expr) => {chain!(RECURSE D $e)}; (F $e:expr) => {chain!(RECURSE E $e)}; // more than 10 seconds (G $e:expr) => {chain!(RECURSE F $e)}; (H $e:expr) => {chain!(RECURSE G $e)}; (I $e:expr) => {chain!(RECURSE H $e)}; (J $e:expr) => {chain!(RECURSE I $e)}; (K $e:expr) => {chain!(RECURSE J $e)}; (L $e:expr) => {chain!(RECURSE L $e)}; } fn main() { let x = chain!(D 42.0_f32); } ``` fixes #55471 fixes #41884 fixes #40161 fixes #34844 fixes #32594 cc @alexcrichton @rust-lang/compiler I looked at all code that checks the recursion limit and inserted stack growth calls where appropriate.
2020-05-06Rollup merge of #71269 - Mark-Simulacrum:sat-float-casts, r=nikicDylan DPC-1/+1
Define UB in float-to-int casts to saturate This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.
2020-05-06Define UB in float-to-int casts to saturateMark Rousskov-1/+1
- Round to zero, and representable values cast directly. - `NaN` goes to 0 - Values beyond the limits of the type are saturated to the "nearest value" (essentially rounding to zero, in some sense) in the integral type, so e.g. `f32::INFINITY` would go to `{u,i}N::MAX.`
2020-05-05Rollup merge of #69984 - lenary:lenary/force-uwtables, r=hanna-kruppeDylan DPC-0/+1
Add Option to Force Unwind Tables When panic != unwind, `nounwind` is added to all functions for a target. This can cause issues when a panic happens with RUST_BACKTRACE=1, as there needs to be a way to reconstruct the backtrace. There are three possible sources of this information: forcing frame pointers (for which an option exists already), debug info (for which an option exists), or unwind tables. Especially for embedded devices, forcing frame pointers can have code size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads). In production code, it can be the case that debug info is not kept, so it is useful to provide this third option, unwind tables, that users can use to reconstruct the call stack. Reconstructing this stack is harder than with frame pointers, but it is still possible. --- This came up in discussion on #69890, and turned out to be a fairly simple addition. r? @hanna-kruppe
2020-05-04Add Option to Force Unwind TablesSam Elliott-0/+1
When panic != unwind, `nounwind` is added to all functions for a target. This can cause issues when a panic happens with RUST_BACKTRACE=1, as there needs to be a way to reconstruct the backtrace. There are three possible sources of this information: forcing frame pointers (for which an option exists already), debug info (for which an option exists), or unwind tables. Especially for embedded devices, forcing frame pointers can have code size overheads (RISC-V sees ~10% overheads, ARM sees ~2-3% overheads). In code, it can be the case that debug info is not kept, so it is useful to provide this third option, unwind tables, that users can use to reconstruct the call stack. Reconstructing this stack is harder than with frame pointers, but it is still possible. This commit adds a compiler option which allows a user to force the addition of unwind tables. Unwind tables cannot be disabled on targets that require them for correctness, or when using `-C panic=unwind`.
2020-05-03Auto merge of #71631 - RalfJung:miri-unleash-the-gates, r=oli-obkbors-1/+1
Miri: unleash all feature gates IMO it is silly to unleash features that do not even have a feature gate yet, but not unleash features that do. The only thing this achieves is making unleashed mode annoying to use as we have to figure out the feature flags to enable (and not always do the error messages say what that flag is). Given that the point of `-Z unleash-the-miri-inside-of-you` is to debug the Miri internals, I see no good reason for this extra hurdle. I cannot imagine a situation where we'd use that flag, realize the program also requires some feature gate, and then be like "oh I guess if this feature is unstable I will do something else". Instead, we'll always just add that flag to the code as well, so requiring the flag achieves nothing. r? @oli-obk @ecstatic-morse Fixes https://github.com/rust-lang/rust/issues/71630
2020-05-03Enable `cfg` predicate for `target_feature = "crt-static"` only if the ↵Vadim Petrochenkov-1/+1
target supports it
2020-05-02Set the default stack size to 8MBSimonas Kazlauskas-1/+1
This was the value used before we originally started raising the stack size to infinity.
2020-05-02Prevent stack overflow for deeply recursive codeOliver Scherer-8/+1
2020-05-02fix miri-unleash delayed sanity checkingRalf Jung-1/+1
2020-05-02cleanup: `config::CrateType` -> `CrateType`Vadim Petrochenkov-17/+16
2020-05-02Auto merge of #71716 - alexcrichton:bitcode-follow-up, r=nnethercotebors-2/+1
Rename `bitcode-in-rlib` option to `embed-bitcode` This commit finishes work first pioneered in #70458 and started in #71528. The `-C bitcode-in-rlib` option, which has not yet reached stable, is renamed to `-C embed-bitcode` since that more accurately reflects what it does now anyway. Various tests and such are updated along the way as well. This'll also need to be backported to the beta channel to ensure we don't accidentally stabilize `-Cbitcode-in-rlib` as well.
2020-05-01Remove leftover chalk typesJack Huey-4/+0
2020-05-01Rename `bitcode-in-rlib` option to `embed-bitcode`Alex Crichton-2/+1
This commit finishes work first pioneered in #70458 and started in #71528. The `-C bitcode-in-rlib` option, which has not yet reached stable, is renamed to `-C embed-bitcode` since that more accurately reflects what it does now anyway. Various tests and such are updated along the way as well. This'll also need to be backported to the beta channel to ensure we don't accidentally stabilize `-Cbitcode-in-rlib` as well.
2020-04-29Use .init_array rather than .ctorsMatthew Maurer-0/+1
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. To support legacy systems which may use .ctors, targets may now specify that they use .ctors via the use_ctors attribute which defaults to false. For debugging and manual control, -Z use-ctors-section=yes/no will allow manual override. Fixes: #71233
2020-04-29Remove -Z no-landing-pads flagAmanieu d'Antras-1/+0
2020-04-28Auto merge of #71292 - marmeladema:queries-local-def-id, r=eddybbors-2/+2
Convert more queries to use `LocalDefId` This PR is based on commits in https://github.com/rust-lang/rust/pull/71215 and should partially solve #70853
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-25 16:37:20 +0000