about summary refs log tree commit diff
path: root/src/librustc_save_analysis
AgeCommit message (Collapse)AuthorLines
2019-03-07hir: remove NodeId from PatKindljedrz-1/+1
2019-02-28Auto merge of #57760 - dlrobertson:varargs1, r=alexregbors-0/+1
Support defining C compatible variadic functions ## Summary Add support for defining C compatible variadic functions in unsafe rust with `extern "C"` according to [RFC 2137]. ## Details ### Parsing When parsing a user defined function that is `unsafe` and `extern "C"` allow variadic signatures and inject a "spoofed" `VaList` in the new functions signature. This allows the user to interact with the variadic arguments via a `VaList` instead of manually using `va_start` and `va_end` (See [RFC 2137] for details). ### Codegen When running codegen for a variadic function, remove the "spoofed" `VaList` from the function signature and inject `va_start` when the arg local references are created for the function and `va_end` on return. ## TODO - [x] Get feedback on injecting `va_start/va_end` in MIR vs codegen - [x] Properly inject `va_end` - It seems like it should be possible to inject `va_end` on the `TerminatorKind::Return`. I just need to figure out how to get the `LocalRef` here. - [x] Properly call Rust defined C variadic functions in Rust - The spoofed `VaList` causes problems here. Related to: #44930 r? @ghost [RFC 2137]: https://github.com/rust-lang/rfcs/blob/master/text/2137-variadic.md
2019-02-27Support defining C compatible variadic functionsDan Robertson-0/+1
Add support for defining C compatible variadic functions in unsafe rust with extern "C".
2019-02-27Rollup merge of #58678 - doctorn:refuse-async-fn-2015-edition, r=varkorMazdak Farrokhzad-2/+2
Deny `async fn` in 2015 edition This commit prevents code using `async fn` from being compiled in Rust 2015 edition. Compiling code of the form: ```rust async fn foo() {} ``` Will now result in the error: ``` error[E0670]: `async fn` is not permitted in the 2015 edition --> async.rs:1:1 | 1 | async fn foo() {} | ^^^^^ error: aborting due to error For more information about an error, try `rustc --explain E0670`. ``` This resolves #58652 and also resolves #53714. r? @varkor
2019-02-24Deny `async fn` in 2015 editionNathan Corbyn-2/+2
Fix style issues and update diagnostic messages Update src/librustc_passes/diagnostics.rs Co-Authored-By: doctorn <me@nathancorbyn.com> Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition Deny nested `async fn` in Rust 2015 edition
2019-02-24hir: remove NodeId from Exprljedrz-1/+2
2019-02-24hir: remove NodeId from Lifetime and Tyljedrz-1/+1
2019-02-14Reduce the size of `hir::Expr`.Nicholas Nethercote-2/+7
From 104 bytes to 72 bytes on x86-64. This slightly reduces instruction counts. Also add an assertion about the size.
2019-02-13Rollup merge of #58137 - ljedrz:cleanup_node_id_to_type, r=estebankMazdak Farrokhzad-4/+4
Cleanup: rename node_id_to_type(_opt) Renames `node_id_to_type(_opt)` to `hir_id_to_type(_opt)`; this makes it clear we are dealing with HIR nodes and their IDs here. In addition, a drive-by commit removing `ty::item_path::hir_path_str` (as requested by @eddyb).
2019-02-12Auto merge of #58341 - alexreg:cosmetic-2-doc-comments, r=steveklabnikbors-5/+5
Cosmetic improvements to doc comments This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase). r? @steveklabnik Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
2019-02-10rustc: doc commentsAlexander Regueiro-5/+5
2019-02-10Revert removed #![feature(nll)]Taiki Endo-0/+1
2019-02-09cleanup: rename node_id_to_type(_opt)ljedrz-4/+4
2019-02-09Rollup merge of #58233 - taiki-e:librustc_save_analysis-2018, r=CentrilMazdak Farrokhzad-82/+79
librustc_save_analysis => 2018 Transitions `librustc_save_analysis` to Rust 2018; cc #58099 r? @Centril
2019-02-08Auto merge of #58191 - varkor:const-generics-ast, r=petrochenkovbors-5/+31
Add const generics to the AST This is mostly split out from https://github.com/rust-lang/rust/pull/53645 in an effort to make progress merging const generics piecewise instead of in one go. cc @yodaldevoid, @petrochenkov r? @eddyb
2019-02-07Fix const generic parameter save analysisvarkor-6/+12
2019-02-07Support const generics in save analysisvarkor-3/+11
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-07Add const params to Defvarkor-0/+7
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-07Add pretty-printing for const genericsvarkor-0/+5
Co-Authored-By: Gabriel Smith <yodaldevoid@users.noreply.github.com>
2019-02-07Remove images' url to make it work even without internet connectionGuillaume Gomez-3/+1
2019-02-07librustc_save_analysis => 2018Taiki Endo-82/+79
2019-01-17Querify glob map usage (last use of CrateAnalysis)Igor Matuszewski-9/+3
2019-01-16Auto merge of #57392 - Xanewok:always-calc-glob-map, r=petrochenkovbors-3/+0
Always calculate glob map but only for glob uses Previously calculating glob map was *opt-in*, however it did record node id -> ident use for every use directive. This aims to see if we can unconditionally calculate the glob map and not regress performance. Main motivation is to get rid of some of the moving pieces and simplify the compilation interface - this would allow us to entirely remove `CrateAnalysis`. Later, we could easily expose a relevant query, similar to the likes of `maybe_unused_trait_import` (so using precomputed data from the resolver, but which could be rewritten to be on-demand). r? @nikomatsakis Local perf run showed mostly noise (except `ctfe-stress-*`) but I'd appreciate if we could do a perf run run here and double-check that this won't regress performance.
2019-01-13Always calculate glob map but only for glob usesIgor Matuszewski-3/+0
Previously calculating glob map was *opt-in*, however it did record node id -> ident use for every use directive. This aims to see if we can unconditionally calculate the glob map and not regress performance.
2019-01-13Rollup merge of #57474 - emilio:save-analysis-path, r=nrcMazdak Farrokhzad-3/+5
save-analysis: Get path def from parent in case there's no def for the path itself. This fixes #57462. The relevant part from the hir type collector is: ``` DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(32) => Entry { parent: NodeId(33), dep_node: 4294967040, node: Expr(expr(32: <Foo>::new)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(48) => Entry { parent: NodeId(32), dep_node: 4294967040, node: Ty(type(Foo)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(30) => Entry { parent: NodeId(48), dep_node: 4294967040, node: PathSegment(PathSegment { ident: Foo#0, id: Some(NodeId(30)), def: Some(Err), args: None, infer_types: true }) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(31) => Entry { parent: NodeId(32), dep_node: 4294967040, node: PathSegment(PathSegment { ident: new#0, id: Some(NodeId(31)), def: Some(Err), args: None, infer_types: true }) } ``` We have the right ID when looking for NodeId(31) and try with NodeId(32) (which is the right thing to look for) from get_path_data. But not when we look from `write_sub_paths_truncated` Basically process_path takes an id which is always the parent, and that we fall back to in get_path_data(), so we get the right result for the last path segment, but not for the other segments that get written to from write_sub_paths_truncated. I think we can stop passing the explicit `id` around to get_path_data as a followup.
2019-01-09save-analysis: Get path def from parent in case there's no def for the path ↵Emilio Cobos Álvarez-3/+5
itself. This fixes #57462. The relevant part from the hir type collector is: ``` DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(32) => Entry { parent: NodeId(33), dep_node: 4294967040, node: Expr(expr(32: <Foo>::new)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(48) => Entry { parent: NodeId(32), dep_node: 4294967040, node: Ty(type(Foo)) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(30) => Entry { parent: NodeId(48), dep_node: 4294967040, node: PathSegment(PathSegment { ident: Foo#0, id: Some(NodeId(30)), def: Some(Err), args: None, infer_types: true }) } DEBUG 2019-01-09T15:42:58Z: rustc::hir::map::collector: hir_map: NodeId(31) => Entry { parent: NodeId(32), dep_node: 4294967040, node: PathSegment(PathSegment { ident: new#0, id: Some(NodeId(31)), def: Some(Err), args: None, infer_types: true }) } ``` We have the right ID when looking for NodeId(31) and try with NodeId(32) (which is the right thing to look for) from get_path_data, but not for the segments that we write from `write_sub_paths_truncated`. Basically `process_path` takes an id which is always the parent, and that we fall back to in `get_path_data()`, so we get the right result for the last path segment, but not for the other segments that get written to from `write_sub_paths_truncated`. I think we can stop passing the explicit id around to `get_path_data` now, will consider sending that as a followup.
2019-01-08save-analysis: use a fallback when access levels couldn't be computedIgor Matuszewski-3/+14
2019-01-04Replace CrateAnalysis::access_levels with queryIgor Matuszewski-3/+3
2018-12-25Remove licensesMark Rousskov-50/+0
2018-12-07Various minor/cosmetic improvements to codeAlexander Regueiro-1/+1
2018-12-06Use a function to access the Hir map to be able to turn it into a query laterJohn Kåre Alsaker-23/+23
2018-11-19save-analysis: fallback to using path idNick Cameron-4/+17
2018-11-16Auto merge of #55936 - nrc:save-rename, r=eddybbors-10/+8
save-analysis: be even more aggressive about ignorning macro-generated defs r? @eddyb
2018-11-14save-analysis: be even more aggressive about ignorning macro-generated defsNick Cameron-10/+8
2018-11-11save-analysis: Don't panic for macro-generated use globsIgor Matuszewski-15/+19
Follow-up to https://github.com/rust-lang/rust/commit/c2bb7cadf24e82b80f403c09e800fe5fad504caf.
2018-11-07Rollup merge of #55734 - teresy:shorthand-fields, r=davidtwcokennytm-1/+1
refactor: use shorthand fields refactor: use shorthand for single fields everywhere (excluding tests).
2018-11-06refactor: use shorthand fieldsteresy-1/+1
2018-10-31save analysis: don't dump macro refsNick Cameron-13/+15
2018-10-31save-analysis: make sure we save the def for the last segment of a pathNick Cameron-2/+1
2018-10-26Remove redundant cloneShotaro Yamada-1/+1
2018-10-26Fix tests and assertions; add some commentsNick Cameron-5/+5
2018-10-26save-analysis: handle missing field namesNick Cameron-6/+7
FIxes https://github.com/rust-lang-nursery/rls/issues/1031
2018-10-26dump refs for path segments in save-analysisNick Cameron-4/+7
Requires adding path segments to the hir map
2018-10-26dump data for prefix path segmentsNick Cameron-131/+22
2018-10-26save-analysis: remove hacky, unnecessary code now that we have spans for ↵Nick Cameron-345/+124
every ident
2018-10-20Auto merge of #55014 - ljedrz:lazyboye_unwraps, r=matthewjasperbors-6/+6
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`. An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
2018-10-19Deprecate the `FxHashMap()` and `FxHashSet()` constructor function hackOliver Scherer-2/+2
2018-10-19Prefer unwrap_or_else to unwrap_or in case of function calls/allocationsljedrz-6/+6
2018-09-30Auto merge of #54601 - cuviper:prep-1.31, r=Mark-Simulacrumbors-1/+1
Bump to 1.31.0 and bootstrap from 1.30 beta Closes #54594.
2018-09-27Bump to 1.31.0 and bootstrap from 1.30 betaJosh Stone-1/+1
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-25 00:22:41 +0000