about summary refs log tree commit diff
path: root/src/libsyntax_pos
AgeCommit message (Collapse)AuthorLines
2019-11-23Rollup merge of #61351 - GuillaumeGomez:stabilize-cfg-rustdoc, r=QuietMisdreavusMazdak Farrokhzad-1/+0
Stabilize cfg(doc) cc #43781.
2019-11-23Auto merge of #66507 - ecstatic-morse:const-if-match, r=oli-obkbors-0/+1
Enable `if` and `match` in constants behind a feature flag This PR is an initial implementation of #49146. It introduces a `const_if_match` feature flag and does the following if it is enabled: - Allows `Downcast` projections, `SwitchInt` terminators and `FakeRead`s for matched places through the MIR const-checker. - Allows `if` and `match` expressions through the HIR const-checker. - Stops converting `&&` to `&` and `||` to `|` in `const` and `static` items. As a result, the following operations are now allowed in a const context behind the feature flag: - `if` and `match` - short circuiting logic operators (`&&` and `||`) - the `assert` and `debug_assert` macros (if the `const_panic` feature flag is also enabled) However, the following operations remain forbidden: - `while`, `loop` and `for` (see #52000) - the `?` operator (calls `From::from` on its error variant) - the `assert_eq` and `assert_ne` macros, along with their `debug` variants (calls `fmt::Debug`) This PR is possible now that we use dataflow for const qualification (see #64470 and #66385). r? @oli-obk cc @rust-lang/wg-const-eval @eddyb
2019-11-22Auto merge of #66460 - cjgillot:hashstable_generic, r=Zoxcbors-7/+48
Add a proc-macro to derive HashStable in librustc dependencies A second proc-macro is added to derive HashStable for crates librustc depends on. This proc-macro HashStable_Generic (to bikeshed) allows to decouple code and some librustc's boilerplate. Not everything is migrated, because `Span` and `TokenKind` require to be placed inside librustc. Types using them stay there too. Split out of #66279 r? @Zoxc
2019-11-21Add feature gate for const `if` and `match`Dylan MacKenzie-0/+1
2019-11-21Rename the cfg attribute from rustdoc to docGuillaume Gomez-1/+0
2019-11-21Gate fallback via `#![feature(never_type_fallback)]`.Mazdak Farrokhzad-0/+1
2019-11-20Rollup merge of #66060 - traxys:test_65401, r=michaelwoeristerMazdak Farrokhzad-0/+1
Making ICEs and test them in incremental This adds: - A way to make the compiler ICE - A way to check for ICE in `cfail` tests with `should-ice` - A regression test for issue #65401 I am not sure the attribute added `should-ice` is the best for this job
2019-11-17Simplify impl for SymbolStr.Camille GILLOT-2/+1
2019-11-17HashStable_Generic for libsyntax_pos.Camille GILLOT-6/+12
2019-11-17Further HashStable_Generic derives.Camille GILLOT-1/+3
2019-11-17Move impl HashStable for Symbol in libsyntax_pos.Camille GILLOT-0/+16
2019-11-17Move impl HashStable for SymbolStr in libsyntax_pos.Camille GILLOT-0/+18
2019-11-17Address review commentsVadim Petrochenkov-1/+0
2019-11-15Remove SourceMapper traitMark Rousskov-34/+8
SourceMap is now in the root of all rustc-specific crates, syntax_pos, so there's no need for the trait object to decouple the dependencies between librustc_errors and libsyntax as was needed previously.
2019-11-15Move SourceMap to syntax_posMark Rousskov-0/+1259
This does not update the use sites or delete the now unnecessary SourceMapper trait, to allow git to interpret the file move as a rename rather than a new file.
2019-11-15Move FatalError to syntax_posMark Rousskov-0/+31
This is a bit unfortunate, but code needs to be able to fatally error early on (in particular, syntax_pos after we move SourceMap there). It's also a tiny bit of code, which means it's ultimately not that bad.
2019-11-12Snap cfgsMark Rousskov-2/+0
2019-11-11Avoid a string comparison in MIR constructionMatthew Jasper-0/+1
2019-11-10Auto merge of #66070 - petrochenkov:regattr, r=matthewjasperbors-0/+2
Support registering inert attributes and attribute tools using crate-level attributes And remove `#[feature(custom_attribute)]`. (`rustc_plugin::Registry::register_attribute` is not removed yet, I'll do it in a follow up PR.) ```rust #![register_attr(my_attr)] #![register_tool(my_tool)] #[my_attr] // OK #[my_tool::anything] // OK fn main() {} ``` --- Some tools (`rustfmt` and `clippy`) used in tool attributes are hardcoded in the compiler. We need some way to introduce them without hardcoding as well. This PR introduces a way to do it with a crate level attribute. The previous attempt to introduce them through command line (https://github.com/rust-lang/rust/pull/57921) met some resistance. This probably needs to go through an RFC before stabilization. However, I'd prefer to land *this* PR without an RFC to able to remove `#[feature(custom_attribute)]` and `Registry::register_attribute` while also providing a replacement. --- `register_attr` is a direct replacement for `#![feature(custom_attribute)]` (https://github.com/rust-lang/rust/issues/29642), except it doesn't rely on implicit fallback from unresolved attributes to custom attributes (which was always hacky and is the primary reason for the removal of `custom_attribute`) and requires registering the attribute explicitly. It's not clear whether it should go through stabilization or not. It's quite possible that all the uses should migrate to `#![register_tool]` (https://github.com/rust-lang/rust/issues/66079) instead. --- Details: - The naming is `register_attr`/`register_tool` rather than some `register_attributes` (plural, no abbreviation) for consistency with already existing attributes like `cfg_attr`, or `feature`, etc. --- Previous attempt: https://github.com/rust-lang/rust/pull/57921 cc https://github.com/rust-lang/rust/issues/44690 Tracking issues: #66079 (`register_tool`), #66080 (`register_attr`) Closes https://github.com/rust-lang/rust/issues/29642
2019-11-10Rollup merge of #66217 - RalfJung:diagnostic-items, r=CentrilYuki Okushi-6/+4
invalid_value lint: use diagnostic items This adjusts the invalid_value lint to use diagnostic items. @Centril @oli-obk For some reason, this fails to recognize `transmute` -- somehow the diagnostic item is not found. Any idea why? r? @Centril Cc https://github.com/rust-lang/rust/issues/66075
2019-11-09Support registering attributes and attribute tools using crate-level attributesVadim Petrochenkov-0/+2
2019-11-09partially port invalid_value lint to diagnostic itemsRalf Jung-6/+4
2019-11-08Rollup merge of #65785 - Centril:compat-to-error-2, r=oli-obkMazdak Farrokhzad-1/+0
Transition future compat lints to {ERROR, DENY} - Take 2 Follow up to https://github.com/rust-lang/rust/pull/63247 implementing https://github.com/rust-lang/rust/pull/63247#issuecomment-536295992. - `legacy_ctor_visibility` (ERROR) -- closes #39207 - `legacy_directory_ownership` (ERROR) -- closes #37872 - `safe_extern_static` (ERROR) -- closes #36247 - `parenthesized_params_in_types_and_modules` (ERROR) -- closes #42238 - `duplicate_macro_exports` (ERROR) - `nested_impl_trait` (ERROR) -- closes #59014 - `ill_formed_attribute_input` (DENY) -- transitions #57571 - `patterns_in_fns_without_body` (DENY) -- transitions #35203 r? @varkor cc @petrochenkov
2019-11-07Rollup merge of #65884 - Centril:non-hardcoded-abis, r=petrochenkovMazdak Farrokhzad-0/+1
syntax: ABI-oblivious grammar This PR has the following effects: 1. `extern $lit` is now legal where `$lit:literal` and `$lit` is substituted for a string literal. 2. `extern "abi_that_does_not_exist"` is now *syntactically* legal whereas before, the set of ABI strings was hard-coded into the grammar of the language. With this PR, the set of ABIs are instead validated and translated during lowering. That seems more appropriate. 3. `ast::FloatTy` is now distinct from `rustc_target::abi::FloatTy`. The former is used substantially more and the translation between them is only necessary in a single place. 4. As a result of 2-3, libsyntax no longer depends on librustc_target, which should improve pipe-lining somewhat. cc @rust-lang/lang -- the points 1-2 slightly change the definition of the language but in a way which seems consistent with our general principles (in particular wrt. the discussions of turning things into semantic errors). I expect this to be uncontroversial but it's worth letting y'all know. :) r? @varkor
2019-11-07parser: don't hardcode ABIs into grammarMazdak Farrokhzad-0/+1
2019-11-07Rollup merge of #66044 - RalfJung:uninit-lint, r=oli-obkYuki Okushi-0/+4
Improve uninit/zeroed lint * Also warn when creating a raw pointer with a NULL vtable. * Also identify `MaybeUninit::uninit().assume_init()` and `MaybeUninit::zeroed().assume_init()` as dangerous.
2019-11-06legacy_directory_ownership -> errorMazdak Farrokhzad-1/+0
2019-11-06Rollup merge of #65973 - eddyb:caller-location-panic, r=petrochenkovMazdak Farrokhzad-1/+18
caller_location: point to macro invocation sites, like file!/line!, and use in core::panic!. The main change here is to `core::panic!`, trying to fix this remaining regression: https://github.com/rust-lang/rust/pull/65927#issuecomment-547625147 However, in order for `caller_location` to be usable from macros the same way `file!()`/`line!()` are, it needs to have the same behavior (of extracting the macro invocation site `Span` and using that). Arguably we would've had to do this at some point anyway, if we want to use `#[track_caller]` to replace the `file!()`/`line!()` uses from macros, but I'm not sure the RFC mentions this at all. r? @petrochenkov cc @anp @nnethercote
2019-11-06Rollup merge of #65776 - nnethercote:rename-LocalInternedString-and-more, ↵Mazdak Farrokhzad-28/+24
r=estebank Rename `LocalInternedString` and more This PR renames `LocalInternedString` as `SymbolStr`, removes an unnecessary `impl` from it, improves comments, and cleans up some `SymbolStr` uses. r? @estebank
2019-11-05Rollup merge of #66025 - petrochenkov:lohi, r=eddybPietro Albini-1/+0
`Span` cannot represent `span.hi < span.lo` So we can remove the corresponding checks from various code
2019-11-03add rustc_error(delay_span_bug_from_inside_query) attributeQuentin Boyer-0/+1
2019-11-02also identiy MaybeUninit::uninit().assume_init() as dangerousRalf Jung-0/+4
2019-11-02Remove the `AsRef` impl for `SymbolStr`.Nicholas Nethercote-10/+0
Because it's highly magical, which goes against the goal of keeping `SymbolStr` simple. Plus it's only used in a handful of places that only require minor changes.
2019-11-02Add some explanatory comments.Nicholas Nethercote-0/+7
2019-11-02Remove an erroneous comment.Nicholas Nethercote-1/+0
2019-11-02Rename `LocalInternedString` as `SymbolStr`.Nicholas Nethercote-18/+18
It makes the relationship with `Symbol` clearer. The `Str` suffix matches the existing `Symbol::as_str()` method nicely, and is also consistent with it being a wrapper of `&str`.
2019-11-01`Span` cannot represent `span.hi < span.lo`Vadim Petrochenkov-1/+0
So we can remove the corresponding checks from various code
2019-11-01Rollup merge of #65902 - gilescope:issue62570, r=estebankTyler Mandry-0/+1
Make ItemContext available for better diagnositcs Fix #62570
2019-10-30caller_location: point to macro invocation sites, like file!/line!.Eduard-Mihai Burtescu-1/+18
2019-10-30Make ItemContext available for better diagnositcs.Giles Cope-0/+1
2019-10-29Rollup merge of #65809 - roblabla:eficall-abi, r=nagisaMazdak Farrokhzad-0/+1
Add new EFIAPI ABI Fixes #54527 Adds a new ABI, "efiapi", which reflects the calling convention as specified by [the current spec UEFI spec](https://uefi.org/sites/default/files/resources/UEFI%20Spec%202_7_A%20Sept%206.pdf#G6.999903). When compiling for x86_64, we should select the `win64` ABI, while on all other architectures (Itanium, x86, ARM and ARM64 and RISC-V), we should select the `C` ABI. Currently, this is done by just turning it into the C ABI everywhere except on x86_64, where it's turned into the win64 ABI. Should we prevent this ABI from being used on unsupported architectures, and if so, how would this be done?
2019-10-25Add new EFIAPI ABIroblabla-0/+1
Adds a new ABI for the EFIAPI calls. This ABI should reflect the latest version of the UEFI specification at the time of commit (UEFI spec 2.8, URL below). The specification says that for x86_64, we should follow the win64 ABI, while on all other supported platforms (ia32, itanium, arm, arm64 and risc-v), we should follow the C ABI. To simplify the implementation, we will simply follow the C ABI on all platforms except x86_64, even those technically unsupported by the UEFI specification. https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
2019-10-25Rollup merge of #65074 - Rantanen:json-byte-pos, r=matkladMazdak Farrokhzad-17/+78
Fix the start/end byte positions in the compiler JSON output Track the changes made during normalization in the `SourceFile` and use this information to correct the `start_byte` and `end_byte` fields in the JSON output. This should ensure the start/end byte fields can be used to index the original file, even if Rust normalized the source code for parsing purposes. Both CRLF to LF and BOM removal are handled with this one. The rough plan was discussed with @matklad in rust-lang-nursery/rustfix#176 - although I ended up going with `u32` offset tracking so I wouldn't need to deal with `u32 + i32` arithmetics when applying the offset to the span byte positions. Fixes #65029
2019-10-25RFC 2008: StabilizationDavid Wood-1/+1
This commit stabilizes RFC 2008 (#44109) by removing the feature gate. Signed-off-by: David Wood <david@davidtw.co>
2019-10-23Rollup merge of #65657 - nnethercote:rm-InternedString-properly, r=eddybMazdak Farrokhzad-115/+5
Remove `InternedString` This PR removes `InternedString` by converting all occurrences to `Symbol`. There are a handful of places that need to use the symbol chars instead of the symbol index, e.g. for stable sorting; local conversions `LocalInternedString` is used in those places. r? @eddyb
2019-10-23Auto merge of #57545 - bovinebuddha:object_safe_for_dispatch, r=nikomatsakisbors-0/+1
Object safe for dispatch cc #43561
2019-10-22RFC 2027: "first draft" of implementationMathias Blikstad-0/+1
These are a squashed series of commits.
2019-10-21Fix the start/end byte positions in the compiler JSON outputMikko Rantanen-17/+78
2019-10-21Remove many unnecessary trait derivations.Nicholas Nethercote-1/+1
2019-10-21Remove `InternedString`.Nicholas Nethercote-115/+5
By using `LocalInternedString` instead for the few remaining uses.