aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2021-07-27Merge #598bors[bot]19-46/+513
598: Hello world r=philberty a=philberty ```rust extern "C" { fn puts(s: *const i8); } fn main() { unsafe { let a = "Hello World\0"; let b = a as *const str; let c = b as *const i8; puts(c); } } ``` Fixes #421 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-27Add support for varadic extern "c" functions like printfPhilip Herron9-26/+144
Varadic functions are only allowed in extern functions as far as I know.
2021-07-27Adds support for compilation of extern "C" functions.Philip Herron3-0/+174
This adds extern block compilation support. It currently assumes the C abi and does not perform any name mangling. It does not support varadic arguments yet but its the initial support to get this working. Fixes #421
2021-07-27Merge #599bors[bot]1-1/+1
599: Fix assertion for trait item mappings r=philberty a=philberty These assertions defend against duplicate/bad mappings Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-27Fix assertion for trait item mappingsPhilip Herron1-1/+1
2021-07-27Add flags for FnType FNTYPE_IS_METHOD_FLAG FNTYPE_IS_EXTERN_FLAGPhilip Herron4-16/+125
2021-07-27Add mappings for external itemsPhilip Herron5-11/+75
2021-07-26Add resolution for extern function itemsPhilip Herron2-2/+4
2021-07-26Merge #597bors[bot]10-56/+345
597: Add name-resolution and HIR lowering for extern blocks r=philberty a=philberty Addresses #421 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-26Add name-resolution and HIR lowering for extern blocksPhilip Herron10-56/+345
This is the initial patch to do the ground work to support extern blocks. Type resolution and Generic output still needs to be done to actually support extern blocks. Addresses #421
2021-07-26Merge #596bors[bot]1-1/+2
596: Fix crash when extern function item has no return type r=philberty a=philberty Addresses #421 Fixes #595 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-26Fix crash when extern function item has no return typePhilip Herron1-1/+2
Return types are optional in rust and extern fn items can be a ZST for the result. Addresses #421 Fixes #595
2021-07-26Merge #592bors[bot]14-4/+1520
592: TypeCastExpr r=philberty a=philberty This is the initial type casting rules more test cases will be added over time. To find gaps. Fixes #158 Co-authored-by: Philip Herron <philip.herron@embecosm.com> Co-authored-by: Mark Wielaard <mark@klomp.org>
2021-07-26Initial TypeCast RulesPhilip Herron8-0/+1450
This gives us full explicit control for all casting. Just like other rules. More test cases are needed to close out type-casts by the the end of the traits milestone. Fixes #592
2021-07-26Add GENERIC support for TypeCastExpr to call fold_convert_locPhilip Herron1-0/+18
2021-07-26Lowering Cast Expressions from AST to HIR.Mark Wielaard4-4/+46
This allows for type resolution for TypeCasts.
2021-07-26Add name resolution for TypeCastExprPhilip Herron1-0/+6
This adds name checking and lookups in side tables for the expression and types involved in the compiler pipeline.
2021-07-25Merge #593bors[bot]1-0/+15
593: Support RangeFrom ([x..]) and RangeFromTo ([x..y]) in the parser r=philberty a=dkm Parsing the .. (DOT_DOT) operator to get a range had two issues. Trying to compile: let block = [1,2,3,4,5]; let _rf = &block[1..]; let _rt = &block[..3]; let _rft = &block[2..4]; range.rs:4:23: error: found unexpected token ‘]’ in null denotation 4 | let _rf = &block[1..]; | ^ range.rs:4:24: error: expecting ‘]’ but ‘;’ found 4 | let _rf = &block[1..]; | ^ Since .. can represent either a range from or a range from-to it can be followed by an expression or not. We do have a hack in our pratt-parser so that it is allowed to return a nullptr. But even in that case it will have swallowed the next token. Add another hack to the pratt-parser so that if the next token is one that cannot start an expression and the caller allows a nullptr return then don't skip the token and return immediately. After this patch we can parse the above range expressions, but we still don't handle them fully: range.rs:4:20: fatal error: Failed to lower expr: [1..] 4 | let _rf = &block[1..]; | ^ Ranges are actually syntactic sugar for std::ops::Range[From|To]. Co-authored-by: Mark Wielaard <mark@klomp.org>
2021-07-25Merge #594bors[bot]6-1/+55
594: Support byte and byte string literals r=philberty a=dkm A byte literal is an u8 created as a ascii char or hex escape e.g. b'X'. A byte string literal is a string created from ascii or hex chars. bytes are represented as u8 and byte strings as str (with just ascii < 256 chars), but it should really be &'static [u8; n]. Co-authored-by: Mark Wielaard <mark@klomp.org>
2021-07-25Support RangeFrom ([x..]) and RangeFromTo ([x..y]) in the parserMark Wielaard1-0/+15
Parsing the .. (DOT_DOT) operator to get a range had two issues. Trying to compile: let block = [1,2,3,4,5]; let _rf = &block[1..]; let _rt = &block[..3]; let _rft = &block[2..4]; range.rs:4:23: error: found unexpected token ‘]’ in null denotation 4 | let _rf = &block[1..]; | ^ range.rs:4:24: error: expecting ‘]’ but ‘;’ found 4 | let _rf = &block[1..]; | ^ Since .. can represent either a range from or a range from-to it can be followed by an expression or not. We do have a hack in our pratt-parser so that it is allowed to return a nullptr. But even in that case it will have swallowed the next token. Add another hack to the pratt-parser so that if the next token is one that cannot start an expression and the caller allows a nullptr return then don't skip the token and return immediately. After this patch we can parse the above range expressions, but we still don't handle them fully: range.rs:4:20: fatal error: Failed to lower expr: [1..] 4 | let _rf = &block[1..]; | ^ Ranges are actually syntactic sugar for std::ops::Range[From|To].
2021-07-25Support byte and byte string literalsMark Wielaard6-1/+55
A byte literal is an u8 created as a ascii char or hex escape e.g. b'X'. A byte string literal is a string created from ascii or hex chars. bytes are represented as u8 and byte strings as str (with just ascii < 256 chars), but it should really be &'static [u8; n].
2021-07-23Merge #591bors[bot]1-7/+0
591: Remove error handling in parse_type_no_bounds for PLUS token r=philberty a=philberty parse_type_no_bounds tries to be helpful and greedily looks for a PLUS token after having parsed a typepath so it can produce an error. But that error breaks parsing expressions that contain "as" Cast Expressions like "a as usize + b as usize". Drop the explicit error on seeing a PLUS token and just return the type path parsed. Co-authored-by: Mark Wielaard <mark@klomp.org>
2021-07-23Remove error handling in parse_type_no_bounds for PLUS tokenMark Wielaard1-7/+0
parse_type_no_bounds tries to be helpful and greedily looks for a PLUS token after having parsed a typepath so it can produce an error. But that error breaks parsing expressions that contain "as" Cast Expressions like "a as usize + b as usize". Drop the explicit error on seeing a PLUS token and just return the type path parsed.
2021-07-23Merge #590bors[bot]1-8/+8
590: Better union support in the parser r=philberty a=philberty union is a weak keyword which means it isn't reserved and can be used as a generic identifier. When we see an identifier where a union could be declared we check whether the identifier is "union", but only when the next token is also an identifier. In parse_union we shouldn't skip the first identifier token, because it is already skipped when we call expect_token. Co-authored-by: Mark Wielaard <mark@klomp.org>
2021-07-23Better union support in the parserMark Wielaard1-8/+8
union is a weak keyword which means it isn't reserved and can be used as a generic identifier. When we see an identifier where a union could be declared we check whether the identifier is "union", but only when the next token is also an identifier. In parse_union we shouldn't skip the first identifier token, because it is already skipped when we call expect_token.
2021-07-22Merge #587 #589bors[bot]3-3/+35
587: Add testcase to cover parse errors in unsafe expressions r=philberty a=philberty Fixes #584 589: Support dereference of pointers r=philberty a=philberty Dereference expressions can also be pointer types not just references. Fixes #588 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-22Merge #585 #586bors[bot]3-8/+76
585: Add iterate impl_blocks helper r=philberty a=philberty This helper will allow use to use mappings to iterate all impl blocks within the specified crate. 586: Add mappings for trait items r=philberty a=philberty Add mappings for trait items that can be used for query-based compilation and type checking Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-22Support dereference of pointersPhilip Herron2-3/+26
Dereference expressions can also be pointer types not just references. Fixes #588
2021-07-22Add testcase to cover parse errors in unsafe expressionsPhilip Herron1-0/+9
We had a bug in the parser with unsafe expression this adds a test case to cover the parser issue. Fixes #584
2021-07-22Add mappings for trait itemsPhilip Herron3-8/+58
2021-07-22Merge #582bors[bot]2-5/+15
582: unsafe blocks can be used in expressions r=philberty a=philberty This fixes an issue to allow unsafe within an expression. Co-authored-by: Mark Wielaard <mark@klomp.org>
2021-07-22unsafe blocks can be used in expressionsMark Wielaard2-5/+15
To use an unsafe block expression handle it in null_denotation for the pratt parser. Adjust parse_unsafe_block_expr to take a pratt_parse bool that defaults to false.
2021-07-21Add iterate impl_blocks helperPhilip Herron2-0/+18
2021-07-20Merge #579bors[bot]17-41/+448
579: Raw pointer support r=philberty a=philberty We will need to add the remaining coercion calls for the relevant sites to get the full support we need but this will serve as the initial support. Fixes #124 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-20Merge #581bors[bot]9-6/+69
581: HIR and GENERIC lowering for unsafe blocks r=philberty a=philberty This wires up the code nessecary to compile an unsafe block it does not implement any rules or checks yet. Fixes #382 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-20HIR and GENERIC lowering for unsafe blocksPhilip Herron9-6/+69
This does not implement the rules for unsafe this wires up the code so we can compile unsafe blocks. No checks are being performed on the code yet. Fixes #382
2021-07-20Raw pointer supportPhilip Herron17-41/+448
This adds the initial support for raw pointers. Pointers rely on coercion rules to be able to coerce the raw fat pointers from a borrow expression into a normal raw pointer. Fixes #124
2021-07-20Merge #578bors[bot]1-195/+0
578: Remove unused code r=philberty a=philberty Remove unused code Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-20Remove unused codePhilip Herron1-195/+0
This was part of basing the rust front-end off the gccgo and this was a dup of rust-object-export.c.
2021-07-20Merge #577bors[bot]10-82/+1428
577: Initial type coercion code r=philberty a=philberty This is the initial type coercion code. Coercions are necessary to implement mutability on reference types and for raw pointers in general. Fixes #576 #352 Addresses #434 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-19Assignments are a coercion site in rustPhilip Herron6-21/+41
This implements the reference mutability coercion rules, where the base types must be compatible and the base can turn a mutable reference into a constant one. Address #434 Fixes #576
2021-07-19Initial coercion rulesPhilip Herron3-0/+1354
Lets keep the same unify pattern for coercion rules to keep the code as readable as possible. Addresses #434
2021-07-19Add comment to can_eqPhilip Herron1-1/+9
2021-07-19Reference Types can be mutablePhilip Herron5-11/+25
We need to track mutability on Reference Types and check wether they actually match up. Addresses #576
2021-07-19Refs should be used in the base ctor of BaseTypePhilip Herron1-70/+20
Refs refers to the reference chain used in the type checking resolution of this type. We use to eagerly replace the Inference Vars when they unify or are coerced or default. Fixes #352
2021-07-16Merge #572bors[bot]8-209/+408
572: Cleanup and add const modifiers to equlity interface r=philberty a=philberty As part of an effort to cleanup some of the interfaces within the TyTy module this PR adds a const visitor for accessing each type and updates the can_eq interface to also be const as it should not require mutability. These changes fell out of a branch for optional trait items support. Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-16Make TyTy::BaseType::can_eq constPhilip Herron4-205/+352
When we are trying to check for possible equivalence such as a simple generic function against a substituted one we do not and should not require mutability. This enforces some code tidy up by providing a const visitor pattern for types.
2021-07-16Keep track of impl blocks via mappingsPhilip Herron3-0/+33
If we keep track of the impl blocks within the crate's we can use this as another way to stream line looking up of specific HIR::Items. This will be used to find possible bounds for a receiver in a path probe.
2021-07-16Track the parent impl a probe candidate comes from.Philip Herron1-4/+23
This change keeps an enum for the candidate type and the parent impl block this probed candidate originates from.
2021-07-16Merge #571bors[bot]1-9/+9
571: call accept_vis directly instead of call it after get r=philberty a=thomasyonug call accept_vis directly instead of calling it after get(). Co-authored-by: Thomas Young <wenzhang5800@gmail.com>
generated by cgit v1.1 at 2025-09-25 03:16:10 +0000