aboutsummaryrefslogtreecommitdiff
path: root/gcc
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-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-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-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-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-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-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-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-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-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-16call accept_vis directly instead of call it after getThomas Young1-9/+9
2021-07-15Merge #568bors[bot]8-18/+36
568: Add missing DefId mappings r=philberty a=philberty DefIds need to be managed for fntypes which will help in the compilation of optional traitt functions Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-15Merge #569 #570bors[bot]2-13/+24
569: Some trait items are optional and should not cause an error r=philberty a=philberty When a trait item is optional this is not a missing trait item. 570: Add missing test case to close out unit-structs r=philberty a=philberty This test case will catch regressions in changes to initializing unit structs. Fixes #155 Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-15Add missing test case to close out unit-structsPhilip Herron1-0/+8
Unit structs can be initilized in two ways this test case will cover future updates to catch any regressions. Fixes #155
2021-07-15Only error for missing trait items.Philip Herron1-13/+16
Some trait items can be optional such as constants with an expression or functions with a body. This change only warns when there are non optional items missing.
2021-07-15Add DefId mappings to TyTy::FnTypePhilip Herron8-12/+26
This adds the def id to trait items and nested items, this will help with optional trait item compilation.
2021-07-15warn the unused associated functionsThomas Young9-19/+103
2021-07-15Impl items should have a DefIDPhilip Herron1-6/+10
This adds DefId mappings for impl items, this is a building block where the TyTy::FnType will include the DefId of the respective function, which will simplify the backend a bit in relation to optional trait functions with a body.
2021-07-14Merge #566bors[bot]12-178/+402
566: Further error checking for trait impl blocks r=philberty a=philberty This PR introduces enhanced type checking for trait constants and associated types. It also brings in the check to ensure all mandatory trait items are implemented. Note optional trait items cannot be referenced or used yet and will be done in a separate PR. Co-authored-by: Philip Herron <philip.herron@embecosm.com>
2021-07-14Add check for missing items in impl of traitPhilip Herron5-60/+133
If an impl block does not implement all trait-items it is an error. This also takes into account that functions and constants may actually have values and may not need to be implemented by the impl block. Addresses #542
generated by cgit v1.1 at 2025-09-05 05:17:54 +0000