about summary refs log tree commit diff
path: root/src/librustc_session
AgeCommit message (Collapse)AuthorLines
2020-06-15moved to post_borrowck_cleanup & used MirPatchRich Kadel-2/+2
2020-06-15[WIP] injects llvm intrinsic instrprof.increment for coverage reportsRich Kadel-0/+3
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-85/+96
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-13Report error when casting an C-like enum implementing Dropoddg-0/+11
2020-06-12Rollup merge of #73178 - petrochenkov:explint, r=varkorDylan DPC-2/+3
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-12Rollup merge of #72906 - lzutao:migrate-numeric-assoc-consts, r=dtolnayDylan DPC-1/+1
Migrate to numeric associated consts The deprecation PR is #72885 cc #68490 cc rust-lang/rfcs#2700
2020-06-11Move shipped MinGW linker to self-contained dirMateusz Mikuła-1/+1
2020-06-11Get self-contained directory path via dedicated functionMateusz Mikuła-0/+4
2020-06-10Migrate to numeric associated constsLzu Tao-1/+1
2020-06-09expand: Give reasonable NodeIds to lints associated with macro definitionsVadim Petrochenkov-2/+2
2020-06-09expand: Give reasonable NodeIds to lints associated with macro expansionsVadim Petrochenkov-0/+1
2020-06-09Handle assembler warnings properlyAmanieu d'Antras-0/+3
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-07Rollup merge of #72970 - OddCoincidence:feature-gated-lints, r=petrochenkovDylan DPC-1/+11
Properly handle feature-gated lints Closes #72694
2020-06-05properly handle feature gated lintsJoey Hain-1/+11
- lint: add `feature_gate` field, allow specifying it in `declare_lint!` - generalize the lint feature gate check - librustdoc: generalize whitelisting of feature-gated lints
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-02Make things build againVadim Petrochenkov-1/+1
2020-05-31Print accessed env vars as special comments into depinfo filesVadim Petrochenkov-0/+3
2020-05-30Rollup merge of #72669 - petrochenkov:smclean, r=Mark-SimulacrumRalf Jung-40/+19
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/+3
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-30Rollup merge of #72657 - flip1995:impl_lint_pass-ty, r=matthewjasperRalf Jung-5/+5
Allow types (with lifetimes/generics) in impl_lint_pass cc https://github.com/rust-lang/rust-clippy/pull/5279#discussion_r430790267 This allows to implement `LintPass` for types with lifetimes and/or generics. The only thing, I'm not sure of is the `LintPass::name` function, which now includes the lifetime(s) (which will be `'_` most of the time) in the name returned for the lint pass, if it exists. But I don't think that this should be a problem, since the `LintPass::name` is never used for output for the user (?).
2020-05-30Rollup merge of #72540 - davidtwco:issue-67552-mono-collector-comparison, ↵Ralf Jung-6/+48
r=varkor mir: adjust conditional in recursion limit check Fixes #67552. This PR adjusts the condition used in the recursion limit check of the monomorphization collector, from `>` to `>=`. In #67552, the test case had infinite indirect recursion, repeating a handful of functions (from the perspective of the monomorphization collector): `rec` -> `identity` -> `Iterator::count` -> `Iterator::fold` -> `Iterator::next` -> `rec`. During this process, `resolve_associated_item` was invoked for `Iterator::fold` (during the construction of an `Instance`), and ICE'd due to substitutions needing inference. However, previous iterations of this recursion would have called this function for `Iterator::fold` - and did! - and succeeded in doing so (trivially checkable from debug logging, `()` is present where `_` is in the substs of the failing execution). The expected outcome of this test case would be a recursion limit error (which is present when the `identity` fn indirection is removed), and the recursion depth of `rec` is increasing (other functions finish collecting their neighbours and thus have their recursion depths reset). When the ICE occurs, the recursion depth of `rec` is 256 (which matches the recursion limit), which suggests perhaps that a different part of the compiler is using a `>=` comparison and returning a different result on this recursion rather than what it returned in every previous recursion, thus stopping the monomorphization collector from reporting an error on the next recursion, where `recursion_depth_of_rec > 256` would have been true. With grep and some educated guesses, we can determine that the recursion limit check at line 818 in `src/librustc_trait_selection/traits/project.rs` is the other check that is using a different comparison. Modifying either comparison to be `>` or `>=` respectively will fix the error, but changing the monomorphization collector produces the nicer error.
2020-05-28standardize limit comparisons with `Limit` typeDavid Wood-6/+48
This commit introduces a `Limit` type which is used to ensure that all comparisons against limits within the compiler are consistent (which can result in ICEs if they aren't). Signed-off-by: David Wood <david@davidtw.co>
2020-05-27rustc_session: Cleanup session creationVadim Petrochenkov-40/+19
2020-05-27Implement RFC 2585LeSeulArtichaut-0/+7
2020-05-27Add -Z profile-emit=<path> for Gcov gcda output.Ivan Lozano-0/+3
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-27Allow types (with lifetimes/generics) in impl_lint_passflip1995-5/+5
2020-05-26Rollup merge of #72342 - jsgf:warn-unused-deps, r=petrochenkovDylan DPC-0/+7
Warn about unused crate deps Implements #57274 by adding -Wunused-crate-dependencies. This will warn about any `--extern` option on the command line which isn't referenced by the crate source either via `use` or `extern crate`. Crates which are added for some side effect but are otherwise unreferenced - such as for symbols they define - the warning can be suppressed with `use somecrate as _;`. If a crate has multiple aliases (eg using `foo = { package = "bar" }` in `Cargo.toml`), then it will warn about each unused alias. This does not consider crate added by some other means than `--extern`, including the standard library. It also doesn't consider any crate without `add_prelude` set (though I'm not sure about this). Unfortunately this probably [does not yet work well with Cargo](https://github.com/rust-lang/rust/issues/57274#issuecomment-624839355) as it will over-specify crates, causing spurious warnings. As a result, this lint is "allow" by default and must be explicitly enabled either via `#![warn(unused_crate_deps)]` or with `-Wunused-crate-deps`.
2020-05-26Rollup merge of #72270 - RalfJung:lint-ref-to-packed, r=oli-obkDylan DPC-1/+8
add a lint against references to packed fields Creating a reference to an insufficiently aligned packed field is UB and should be disallowed, both inside and outside of `unsafe` blocks. However, currently there is no stable alternative (https://github.com/rust-lang/rust/issues/64490) so all we do right now is have a future incompatibility warning when doing this outside `unsafe` (https://github.com/rust-lang/rust/issues/46043). This adds an allow-by-default lint. @retep998 suggested this can help early adopters avoid issues. It also means we can then do a crater run where this is deny-by-default as suggested by @joshtriplett. I guess the main thing to bikeshed is the lint name. I am not particularly happy with "packed_references" as it sounds like the packed field has reference type. I chose this because it is similar to "safe_packed_borrows". What about "reference_to_packed" or "unaligned_reference" or so?
2020-05-25Implement warning for unused dependencies.Jeremy Fitzhardinge-0/+7
This will print a diagnostic for crates which are mentioned as `--extern` arguments on the command line, but are never referenced from the source. This diagnostic is controlled by `-Wunused-crate-dependencies` or `#![warn(unused_crate_dependencies)]` and is "allow" by default. There are cases where certain crates need to be linked in but are not directly referenced - for example if they are providing symbols for C linkage. In this case the warning can be suppressed with `use needed_crate as _;`. Thanks to @petrochenkov for simplified core. Resolves issue #57274
2020-05-25Add a small MIR validation passJonas Schievink-0/+2
2020-05-25rename lintRalf Jung-2/+2
2020-05-25add a lint against references to packed fieldsRalf Jung-1/+8
2020-05-22Use `OnceCell` instead of `Once`Dylan MacKenzie-19/+42
2020-05-22Rollup merge of #72309 - petrochenkov:linkunspec, r=matthewjasperRalf Jung-34/+30
Some renaming and minor refactoring for `NativeLibraryKind`
2020-05-20Eliminate some `Option<NativeLibKind>`sVadim Petrochenkov-10/+9
2020-05-20Factor out `NativeLibKind::Dylib` from `NativeLibKind::Unspecified`Vadim Petrochenkov-3/+6
2020-05-20Rename some types describing native librariesVadim Petrochenkov-33/+27
NativeLibrary(Kind) -> NativeLib(Kind) NativeStatic -> StaticBundle NativeStaticNobundle -> StaticNoBundle NativeFramework -> Framework NativeRawDylib -> RawDylib NativeUnknown -> Unspecified
2020-05-20Rollup merge of #72364 - jsgf:remove-unused-deps, r=Mark-SimulacrumDylan DPC-1/+0
Remove unused dependencies Remove some unused dependencies found while while working on https://github.com/rust-lang/rust/pull/72342.
2020-05-19Remove unused dependenciesJeremy Fitzhardinge-1/+0
2020-05-18HIR passes for asm!Amanieu d'Antras-0/+7
2020-05-18Implement AST lowering for asm!Amanieu d'Antras-0/+16
2020-05-17Auto merge of #72248 - petrochenkov:codemodel, r=Amanieubors-10/+21
Cleanup and document `-C code-model` r? @Amanieu
2020-05-16Auto merge of #72178 - tmiasko:inliner-lifetimes, r=nikicbors-0/+10
Consistently use LLVM lifetime markers during codegen Ensure that inliner inserts lifetime markers if they have been emitted during codegen. Otherwise if allocas from inlined functions are merged together, lifetime markers from one function might invalidate load & stores performed by the other one. Fixes #72154.
2020-05-16Rollup merge of #72094 - petrochenkov:overfeature, r=nikicRalf Jung-1/+15
cmdline: Make target features individually overridable Fixes https://github.com/rust-lang/rust/issues/56527 Previously `-C target-feature=+avx2 -C target-feature=+fma` was equivalent to `-C target-feature=+fma` because the later `-C target-feature` option fully overridden previous `-C target-feature`. With this PR `-C target-feature=+avx2 -C target-feature=+fma` is equivalent to `-C target-feature=+avx2,+fma` and the options are combined. I'm not sure where the comma-separated features in a single option came from (clang uses a scheme with single feature per-option), but logically these features are entirely independent options. So they should be overridable individually as well to be more useful in hierarchical build system, and more consistent with other rustc options and clang behavior as well. Target feature options have a few other issues (https://github.com/rust-lang/rust/issues/44815), but fixing those is going to be a bit more invasive.
2020-05-16rustc_target: Stop using "string typing" for code modelsVadim Petrochenkov-10/+21
Introduce `enum CodeModel` instead.
2020-05-14Consistently use LLVM lifetime markers during codegenTomasz Miąsko-0/+10
Ensure that inliner inserts lifetime markers if they have been emitted during codegen. Otherwise if allocas from inlined functions are merged together, lifetime markers from one function might invalidate load & stores performed by the other one.
2020-05-11Rollup merge of #72067 - jonas-schievink:fuel-warn, r=varkorDylan DPC-1/+1
Emit a warning when optimization fuel runs out `eprintln!` gets swallowed by Cargo too easily.
2020-05-11cmdline: Make target features individually overridableVadim Petrochenkov-1/+15
2020-05-10Auto merge of #71825 - contrun:cg-option-strip, r=petrochenkovbors-3/+26
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/.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-28 06:12:28 +0000