summary refs log tree commit diff stats
path: root/compiler
Commit message (Collapse)AuthorAgeFilesLines
* consider ambiguity for qualified symbols (#23989)metagn2024-08-203-7/+32
| | | | | | | | | | | | | fixes #23893 When type symbols are ambiguous, calls to them aren't allowed to be type conversions and only routine symbols are considered instead. But the compiler doesn't acknowledge that qualified symbols can be ambiguous, `qualifiedLookUp` directly tries to access the identifier from the module string table. Now it checks the relevant symbol iterators for any symbol after the first received symbol, in which case the symbol is considered ambiguous. `nkDotExpr` is also included in the whitelist of node kinds for ambiguous type symbols (not entirely sure why this exists, it's missing `nkAccQuoted` as well).
* sem all call nodes in generic type bodies + many required fixes (#23983)metagn2024-08-207-31/+125
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | fixes #23406, closes #23854, closes #23855 (test code of both compiles but separate issue exists), refs #23432, follows #23411 In generic bodies, previously all regular `nkCall` nodes like `foo(a, b)` were directly treated as generic statements and delayed immediately, but other call kinds like `a.foo(b)`, `foo a, b` etc underwent typechecking before making sure they have to be delayed, as implemented in #22029. Since the behavior for `nkCall` was slightly buggy (as in #23406), the behavior for all call kinds is now to call `semTypeExpr`. However the vast majority of calls in generic bodies out there are `nkCall`, and while there isn't a difference in the expected behavior, this exposes many issues with the implementation started in #22029 given how much more code uses it now. The portion of these issues that CI has caught are fixed in this PR but it's possible there are more. 1. Deref expressions, dot expressions and calls to dot expressions now handle and propagate `tyFromExpr`. This is most of the changes in `semexprs`. 2. For deref expressions to work in `typeof`, a new type flag `tfNonConstExpr` is added for `tyFromExpr` that calls `semExprWithType` with `efInTypeof` on the expression instead of `semConstExpr`. This type flag is set for every `tyFromExpr` type of a node that `prepareNode` encounters, so that the node itself isn't evaluated at compile time when just trying to get the type of the node. 3. Unresolved `static` types matching `static` parameters is now treated the same as unresolved generic types matching `typedesc` parameters in generic type bodies, it causes a failed match which delays the call instantiation. 4. `typedesc` parameters now reject all types containing unresolved generic types like `seq[T]`, not just generic param types by themselves. (using `containsGenericType`) 5. `semgnrc` now doesn't leave generic param symbols it encounters in generic type contexts as just identifiers, and instead turns them into symbol nodes. Normally in generic procs, this isn't a problem since the generic param symbols will be provided again at instantiation time (and in fact creating symbol nodes causes issues since `seminst` doesn't actually instantiate proc body node types). But generic types can try to be instantiated early in `sigmatch` which will give an undeclared identifier error when the param is not provided. Nodes in generic types (specifically in `tyFromExpr` which should be the only use for `semGenericStmt`) undergo full generic type instantiation with `prepareNode`, so there is no issue of these symbols remaining as uninstantiated generic types. 6. `prepareNode` now has more logic for which nodes to avoid instantiating. Subscripts and subscripts turned into calls to `[]` by `semgnrc` need to avoid instantiating the first operand, since it may be a generic body type like `Generic` in an expression like `Generic[int]`. Dot expressions cannot instantiate their RHS as it may be a generic proc symbol or even an undeclared identifier for generic param fields, but have to instantiate their LHS, so calls and subscripts need to still instantiate their first node if it's a dot expression. This logic still isn't perfect and needs the same level of detail as in `semexprs` for which nodes can be left as "untyped" for overloading/dot exprs/subscripts to handle, but should handle the majority of cases. Also the `efDetermineType` requirement for which calls become `tyFromExpr` is removed and as a result `efDetermineType` is entirely unused again.
* allow qualifying macro pragmas (#23985)metagn2024-08-202-9/+12
| | | fixes #12696
* include generic bodies in allowMetaTypes (#23968)metagn2024-08-201-1/+2
| | | | | | | | fixes #19848 Not sure why this wasn't the case already. The `if cl.allowMetaTypes: return` line below for `tyFromExpr` [was added 10 years ago](https://github.com/nim-lang/Nim/commit/d5798b43dec547f372eb49d5a8848a9970b12260). Hopefully it was just negligence?
* fixes #23945; type checking for whenvm expresssions (#23970)ringabout2024-08-201-0/+2
| | | fixes #23945
* fixes #23982; codegen regression passing pointer expressions to inline ↵ringabout2024-08-201-2/+4
| | | | | iterators (#23986) fixes #23982
* fixes #23973; fixes #23974; Memory corruption with lent and ORC (#23981)ringabout2024-08-201-2/+15
| | | | fixes #23973; fixes #23974
* allow `untyped` arguments to fail to compile in overload mismatch error (#23984)metagn2024-08-201-6/+17
| | | | | | | | | | | | | | | | fixes #8697, fixes #9620, fixes #23265 When matching a `template` with an `untyped` argument fails because of a mismatching typed argument, `presentFailedCandidates` tries to sem every single argument to show their types, but trying to type the `untyped` argument can fail if it's supposed to use an injected symbol, so we get an unrelated error message like "undeclared identifier". Instead we use `tryExpr` as the comment suggests, setting the type to `untyped` if it fails to compile. We could also maybe check if an `untyped` argument is expected in its place and not try to compile the expression if it is but this would require a bit of reorganizing the code here and IMO it's better to have the information of what type it would be if it can be typed.
* make all generic aliases tyAlias (#23978)metagn2024-08-201-1/+2
| | | | | | | | | | | | | fixes #23977 The problem is that for *any* body of a generic declaration, [semstmts](https://github.com/nim-lang/Nim/blob/2e4d344b43b040a4dce2c478ca13e49979e491fc/compiler/semstmts.nim#L1610-L1611) sets the sym of its value to the generic type name, and [semtypes](https://github.com/nim-lang/Nim/blob/2e4d344b43b040a4dce2c478ca13e49979e491fc/compiler/semtypes.nim#L2143) just directly gives the referenced type *specifically* when the expression is a generic body. I'm blaming `semtypes` here because it's responsible for the type given but the exact opposite behavior specifically written in makes me think generating an alias type here maybe breaks something.
* fixes for 32bit system (#23980)ringabout2024-08-191-1/+1
|
* Fixes #23962 `resetLoc`doenst produce any cgen code in `importcpp` types ↵Juan M Gómez2024-08-181-1/+4
| | | | (#23964)
* allow generic compileTime proc folding (#22022)metagn2024-08-184-2/+11
| | | | | | | | | | | | | | fixes #10753, fixes #22021, refs #19365 (was fixed by #22029, but more faithful test added) For whatever reason `compileTime` proc calls did not fold if the proc was generic ([since this folding was introduced](https://github.com/nim-lang/Nim/commit/c25ffbf2622a197c15a4a3bd790b1bc788db2c7f#diff-539da3a63df08fa987f1b0c67d26cdc690753843d110b6bf0805a685eeaffd40)). I'm guessing the intention was for *unresolved* generic procs to not fold, which is now the logic. Non-magic `compileTime` procs also now don't fold at compile time in `typeof` contexts to avoid possible runtime errors (only the important) and prevent double/needless evaluation.
* always lookup pure enum symbols if expected type is enum (#23976)metagn2024-08-172-3/+7
| | | | | | | | | | | | | | | | | | | | fixes #23689 Normally pure enum symbols only "exist" in lookup if nothing else with the same name is in scope. But if an expression is expected to be an enum type, we know that ambiguity can be resolved between different symbols based on their type, so we can include the normally inaccessible pure enum fields in the ambiguity resolution in the case that the expected enum type is actually a pure enum. This handles the use case in the issue of the type inference for enums reverted in #23588. I know pure enums are supposed to be on their way out so this might seem excessive, but the `pure` pragma can't be removed in the code in the issue due to a redefinition error, they have to be separated into different modules. Normal enums can still resolve the ambiguity here though. I always think about making a list of all the remaining use cases for pure enums and I always forget. Will close #23694 if CI passes
* fixes default float ranges (#23957)ringabout2024-08-162-6/+10
|
* fix `is` with `type`/`typedesc` crashing the compiler (#23967)metagn2024-08-161-2/+1
| | | | | | | | | | fixes #22850 The `is` operator checks the type of the left hand side, and if it's generic or if it's a `typedesc` type with no base type, it leaves it to be evaluated later. But `typedesc` types with no base type precisely describe the default typeclass `type`/`typeclass`, so this condition is removed. Maybe at some point this represented an unresolved generic type?
* remove nontoplevel type hack + consider symbol disamb in type hash (#23969)metagn2024-08-162-4/+4
| | | | | | | | | | | | | | fixes #22571 Removes the hack added in #13589 which made non-top-level object type symbols `gensym` because they couldn't be mangled into different names for codegen vs. top-level types. Now we consider the new `disamb` field (added in #21667) of the type symbols in the type hash (which is used for the mangled name) to differentiate between the types. In other parts of the compiler, specifically the [proc mangling](https://github.com/nim-lang/Nim/blob/298ada3412c9cf5971abc2b3b891b9bb8612e170/compiler/mangleutils.nim#L59), `itemId.item` is used instead of the `disamb` field, but I didn't use it in case it's the outdated method.
* fixes #23954; uint8 > 8 bit at compile-time (#23955)ringabout2024-08-151-1/+2
| | | fixes #23954
* supports `default` for range types using `firstOrd` with ↵ringabout2024-08-131-3/+10
| | | | | `nimPreviewRangeDefault` (#23950) ref https://github.com/nim-lang/Nim/issues/23943
* fixes #23947; .uint8 compile-time error (#23948)ringabout2024-08-131-11/+14
| | | fixes #23947
* opensym as node kind + fixed experimental switch (#23892)metagn2024-08-1211-43/+82
| | | | | | | | | | | | | | | refs https://github.com/nim-lang/Nim/pull/23873#discussion_r1687995060, fixes #23386, fixes #23385, supersedes #23572 Turns the `nfOpenSym` node flag implemented in #23091 and extended in #23102 and #23873, into a node kind `nkOpenSym` that forms a unary node containing either `nkSym` or `nkOpenSymChoice`. Since this affects macros working on generic proc AST, the node kind is now only generated when the experimental switch `genericsOpenSym` is enabled, and a new node flag `nfDisabledOpenSym` is set to the `nkSym` or `nkOpenSymChoice` when the switch is not enabled so that we can give a warning. Now that the experimental switch has more reasonable semantics, we define `nimHasGenericsOpenSym2`.
* Implemented `compileOption` for `experimental` to test if a feature i… ↵Don-Duong Quach2024-08-121-1/+8
| | | | | | | | (#23933) …s enabled at compile time. #8644 This doesn't handle the case if `{.push experimental.}` is used, but at least we can test if a feature was enabled globally.
* fixes #23936; opcParseFloat accepts the wrong register as the first param ↵ringabout2024-08-121-1/+1
| | | | | | [backport] (#23941) fixes #23936 follow up https://github.com/nim-lang/Nim/pull/20527
* fixes jsbigint64 regression; keeps convs to `Number` in danger mode (#23926)ringabout2024-08-111-1/+7
| | | fixes jsbigint64 regression
* fixes #23932; vmopsDanger for os.getCurrentDir errors (#23934)ringabout2024-08-111-2/+3
| | | | fixes #23932 ref https://github.com/jmgomez/NimForUE/issues/36
* don't treat template/macro/module as overloaded for opensym (#23939)metagn2024-08-112-2/+7
| | | | | | | | | | | | | | actually fixes #23865 following up #23873 In the handling of `nkIdent` in `semExpr`, the compiler looks for the closest symbol with the name and [checks the symbol kind](https://github.com/nim-lang/Nim/blob/6126a0bf46f4e29a368b8baefea69a2bcae54e93/compiler/semexprs.nim#L3171) to also consider the overloads if the symbol kind is overloadable. But it treats the normally overloadable template/macro/module sym kinds the same as non-overloadable symbols, just calling `semSym` on it. We need to mirror this behavior in `semOpenSym`; we treat the captured symchoice as a fresh identifier, so if the symbol we find is a template/macro/module, we use that symbol immediately as opposed to waiting for overloads.
* fixes #14522 #22085 #12700 #23132; no range check for uints (#23930)ringabout2024-08-112-4/+10
| | | | | | | | | | fixes #14522 fixes #22085 fixes #12700 fixes #23132 closes https://github.com/nim-lang/Nim/pull/22343 (succeeded by this PR) completes https://github.com/nim-lang/RFCs/issues/175 follow up https://github.com/nim-lang/Nim/pull/12688
* fixes #23914; jsondoc broken in devel (#23916)ringabout2024-08-111-1/+1
| | | | | follows up https://github.com/nim-lang/Nim/pull/23064 fixes #23914
* fixes #23907; Double destroy using proc type alias with a sink (#23909)ringabout2024-08-111-1/+2
| | | fixes #23907
* fixes #23902; Compiler infers sink in return type from auto (#23904)ringabout2024-08-111-3/+3
| | | fixes #23902
* special handlings for nimble packages to shorten function names (#23891)ringabout2024-08-112-29/+45
| | | | | | | | | | | | | | | | | | | If we need keep readabilities for functions' names, we might put the original names in the comments or in the identifiers like what currently has been done. The new nimble having been shipped since Nim 2.0.0 uses a directory ending with a full hash of a commit for cloned repos, the function names are burderen by this. This PR strips these from package paths and prepends "pkg" for readability. Before: raiseNilAccess__OOZOOZOnimbleZpkgs2Zthreading450O2O045288108d1dfa34d5ade5ce4d922af51909c83cebfZthreadingZsmartptrs_u4 After: raiseNilAccess__pkgZthreadingZsmartptrs_u4
* fixes #13391; VM: Can't get address of object (#23903)ringabout2024-07-291-0/+2
| | | fixes #13391
* fixes #23894; succ/pred shouldn't raise OverflowDefect for unsigned integers ↵ringabout2024-07-261-1/+1
| | | | | | | (#23895) fixes #23894 keeps it consistent with `inc`
* implement genericsOpenSym for symchoices (#23873)metagn2024-07-253-24/+57
| | | | | | | | | | fixes #23865 The node flag `nfOpenSym` implemented in #23091 for sym nodes is now also implemented for open symchoices. This means the intended behavior is still achieved when multiple overloads are in scope to be captured, so the issue is fixed. The code for the flag is documented and moved into a helper proc and the experimental switch is now enabled for the compiler test suite.
* Overload resultion with generic variables an inheritance (#23870)Ryan McConnell2024-07-241-25/+33
| | | The test case diff is self explanatory
* minor improvement on cgen (#23887)ringabout2024-07-241-4/+2
|
* improve mangling packages version names with checksums (#23888)ringabout2024-07-241-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | follow up https://github.com/nim-lang/Nim/pull/19821 dights cannot clash with letters 'Z' and 'O' For `threading-0.2.0-288108d1dfa34d5ade5ce4d922af51909c83cebf` Before: raiseNilAccess__OOZOOZOnimbleZpkgs50Zthreading4548O50O4845505656494856d49dfa5152d53ade53ce52d575050af5349574857c5651cebfZthreadingZsmartptrs_u4 After: raiseNilAccess__OOZOOZOnimbleZpkgs2Zthreading450O2O045288108d1dfa34d5ade5ce4d922af51909c83cebfZthreadingZsmartptrs_u4 <del> nimble or something might use `git rev-parse --short HEAD` to shorten the length of package version names ref https://github.com/nim-lang/nimble/pull/913 </del>
* fixes #19171; have `openArray` converted from `ptr UncheckedArray` be ↵Buldram2024-07-241-2/+9
| | | | | | mutable (#23882) Makes `toOpenArray(x: ptr UncheckedArray)` always return a `var openArray` regardless of if `x` is mutable.
* fixes #23867; fixes #23316; rework nimsuggest for ORC (#23879)ringabout2024-07-231-2/+1
| | | | | | | | fixes #23867 fixes #23316 follow up https://github.com/nim-lang/Nim/pull/22805; fixes https://github.com/nim-lang/Nim/issues/22794 in a different method
* turn some sym flag aliases into enums (#23884)ringabout2024-07-231-18/+13
|
* fixes #23869; sink generic typeclass (#23874)Ryan McConnell2024-07-221-2/+2
| | | | | | | Still have to look this over some. We'll see. I put sink in this branch simply because I saw `tyVar` there and for no other reason. In any case the problem appears to be coming from `liftParamType` as it removes the `sink` type from the formals. #23869
* remove unused field in ConfigRef (#23875)ringabout2024-07-221-1/+0
| | | follow up https://github.com/nim-lang/Nim/pull/14763
* Merge tyUncheckedArray with tySeq in typeRel (#23866)SirOlaf2024-07-201-10/+4
| | | | | | Ref https://github.com/nim-lang/Nim/issues/23836#issuecomment-2233957324 Their types are basically equivalent so they should behave the same way for type relations.
* bypass constraints for tyFromExpr in generic bodies (#23863)metagn2024-07-201-4/+9
| | | | | | | | | | | | | | | | | | | | | | | fixes #19819, fixes #23339 Since #22029 `tyFromExpr` does not match anything in overloading, so generic bodies can know which call expressions to delay until the type can be evaluated. However generic type invocations also run overloading to check for generic constraints even in generic bodies. To prevent them from failing early from the overload not matching, pretend that `tyFromExpr` matches. This mirrors the behavior of the compiler in more basic cases like: ```nim type Foo[T: int] = object x: T Bar[T] = object y: Foo[T] ``` Unfortunately this case doesn't respect the constraint (#21181, some other bugs) but `tyFromExpr` should easily use the same principle when it does.
* fixes nim secret not flushing stdout (#23862)ringabout2024-07-201-0/+1
| | | | | | | | | | | | | | | related to https://github.com/nim-lang/Nim/pull/19584 On Vscode wsl2 Before: ![image](https://github.com/user-attachments/assets/4bb4f92d-757d-4edf-9dcf-17fcb98f0b60) After ![image](https://github.com/user-attachments/assets/289a113e-c27c-4b76-9d13-725ca28f2828)
* fix generics treating symchoice symbols as uninstantiated (#23860)metagn2024-07-191-1/+5
| | | | | | | | | | | | | fixes #23853 Since #22610 generics turns the `Name` in the `GT.Name` expression in the test code into a sym choice. The problem is when the compiler tries to instantiate `GT.Name` it also instantiates the sym choice symbols. `Name` has type `template (E: type ExtensionField)` which contains the unresolved generic type `ExtensionField`, which the compiler mistakes as an uninstantiated node, when it's just part of the type of the template. The compilation of the node itself and hence overloading will handle the instantiation of the proc, so we avoid instantiating it in `semtypinst`, similar to how the first nodes of call nodes aren't instantiated.
* fixes #23858; 2.2.0 rc1 regression with cdecl functions (#23859)ringabout2024-07-183-4/+6
| | | | | | fixes #23858 We should not assign fields to fields for returns of function calls because calls might have side effects.
* Set type of object constructor during annotateType (#23852)SirOlaf2024-07-171-0/+1
| | | | | | Fix https://github.com/nim-lang/Nim/issues/23547 Tested locally with the included test, the test from constantine and the original issue.
* fixes #23848; The comand `nim gendepend` defaults to ORC (#23851)ringabout2024-07-171-1/+2
| | | fixes #23848
* fixes #23837; cursor now processes distinct types with a destructor (#23845)ringabout2024-07-171-2/+11
| | | fixes #23837
* make routine implicitly gensym when other gensym symbol exists again (#23842)metagn2024-07-161-5/+7
| | | | | | | | | | | | | fixes #23813, partially reverts #23392 Before #23392, if a `gensym` symbol was defined before a proc with the same name in a template even with an `inject` annotation, the proc would be `gensym`. After #23392 the proc was instead changed to be `inject` as long as no `gensym` annotation was given. Now, to keep compatibility with the old behavior, the behavior is changed back to infer the proc as `gensym` when no `inject` annotation is given, however an explicit `inject` annotation will still inject the proc. This is also documented in the manual as the old behavior was undocumented and the new behavior is slightly different.
generated by cgit-pink 1.4.1-2-gfad0 (git 2.36.2.497.gbbea4dcf42) at 2025-02-11 11:48:03 +0000